Aplicaciones de escritorio multiplataforma: ¿un enfoque?

Question

Tengo lo que creo que es una idea arrolladora para una aplicación. Por definición, esta sería una aplicación de escritorio, y se relaciona con algunos servicios de nivel bastante bajo proporcionados por las plataformas para las que lo escribiría (Windows Search Service, Mac OS X Spotlight server).

Mi intención es tanto una versión de Mac OS X como de Windows. La intención absoluta es, en realidad, no compartir el código, sobre todo porque muy poco (si alguno) de él podría ser común. Debido a esto, tengo la intención de utilizar marcos completamente diferentes (Cocoa/Obj-C en Mac, C#/WPF/PInvoke en Windows) y hacer que ambos se sientan "nativos" de sus plataformas, ciudadanos de aplicaciones de primera clase, si así lo desean.

Mi pregunta es esta: ¿Es mejor intentar y compilar ambos "simultáneamente", es decir, tratar de mantenerlos en paridad de características incluso durante el ciclo de desarrollo; ¿o es mejor hacer una "derecha" y luego seguirla con la otra?

los profesionales para mantener la paridad parecen ser:

• más fácil mantener los algoritmos de alineación, como se implemento en un idioma, Simplemente puerto a otro
• fácil asegurar que en el lanzamiento, ambas aplicaciones están disponibles de inmediato

Los contras de mantener la paridad parece ser:

• Más difícil de hacer; cambio de idioma constante podría hacer estallar la cabeza (ya pasar por esto en el trabajo cada vez que trabajar C# durante 4 días luego de repente tienen que mantener una de nuestras viejas soluciones VB.NET)

Las ventajas de uno, entonces el otra, parecen ser:

• Ningún lenguaje constante conmutación
• una plataforma puede estar en la prueba mientras que el otro se está construyendo

los contras de uno, luego el otro, parecen ser:

• Volviendo a lo que será entonces "viejo" código de puerto de los algoritmos
• Potencialmente perder interés en "hacer de nuevo" lo que ya he hecho

Es cierto que esto es muy ambiciosa. .. Y solo soy un chico, haciéndolo en "tiempo libre" (hah). Si estuvieras en el mismo barco y estuvieras familiarizado con ambas suites de tecnología, ¿cómo te acercarías a esto?

Actualizado

En respuesta a algunas preguntas desde abajo:

Sí, una API común es, sin embargo convenciones de llamada no serían factibles - o al menos, no es fácil. Pretendo definir las mismas clases, pero con un código específico de la plataforma. (Esto parece bastante crítico, ya que Windows Search Service y Spotlight funcionan de manera muy diferente.)

Podría ir con algo así como Java, pero estoy eligiendo no por un par de razones: (1) No he hecho Java en para siempre, y ahora estoy peligrosamente no calificado. :) (2) Parte de esto es un ejercicio para aprender Objective-C haciendo "esencialmente" la misma aplicación en tecnologías con las que estoy familiarizado; y (3) Aunque Swing puede proporcionar una apariencia principalmente nativa en OS X, su interfaz de usuario de Windows nunca se siente del todo bien, y realmente quiero que ambas aplicaciones se sientan como pertenecientes a sus respectivos sistemas.

El tiempo de comercialización no es una gran consideración; Siento que la idea de la aplicación en sí será bastante segura. Más importante que TTM es hacer que la aplicación se sienta bien y proporcionar la funcionalidad ...

Answer 1

Primero debe concentrarse en escribir su aplicación para una plataforma y preocúpese de portarla más tarde. Se garantiza que su proyecto fallará si no lo completa, y tratar de escribirlo para dos plataformas a la vez seguramente aumentará el tiempo total de desarrollo. ¿Y puede nombrar una pieza de software comercial que falló porque no era compatible con múltiples plataformas?

Answer 2

Desarrollaría para cualquier plataforma la mayor audiencia objetivo (como en su aplicación asesina) primero, luego usaré las inevitables lecciones Aprendería en el camino a mejorar la forma en que desarrollaría para el otro (s).

Answer 3

Si fuera usted, iría con un marco de trabajo y/o lenguaje de programación multiplataforma, hoy en día tiene muchos idiomas/frameworks que funcionan multiplataforma como Java, QT (con ambos lenguajes Java y C++ para usar el juego de herramientas), C# con MONO, GTK + con C (gtkmm con C++, gtk # y Mono para C#). Por lo tanto, es más simple si lo hace en un idioma/marco que en dos simultáneamente, porque si escribe la misma aplicación en dos idiomas/marcos diferentes, le costará tiempo de desarrollo adicional la mitad del tiempo que puede tener en sus manos. marco y el lenguaje porque sabes desde el principio que tu plataforma objetivo es multiplataforma. Si ahora su plataforma principal sería, por ejemplo, Windows y más tarde a los usuarios de Mac les gusta mucho la aplicación, entonces es la razón para volver a escribirla apuntando a otra plataforma y utilizando sus herramientas de desarrollo.

Answer 4

Tanto los pros y los contras que ha mencionado son absolutamente válidos. Personalmente, odio volver atrás y volver a hacer algo incluso en un idioma diferente de tener que cambiar constantemente la mentalidad del lenguaje. Ya estoy haciendo esto todos los días, donde estoy haciendo tanto el desarrollo del servidor en Python como el lado del cliente en JavaScript.

Dicho esto, ¿qué hay de separar las cosas de bajo nivel de las cosas de interfaz de usuario de alto nivel. Construya las cosas de bajo nivel en cada plataforma para que tengan exactamente las mismas API. La implementación interna subyacente puede ser totalmente diferente, no importa, siempre y cuando ambos expongan la misma interfaz. Creo que te resultará interesante hacerlo. También dijiste que quieres que la interfaz de usuario se sienta nativa en cada plataforma, entonces, ¿por qué no considerar algo como SWT en Java? Si SWT y Java no son una opción, entonces supongo que tendrás que construir cosas de alto nivel usando WPF y Cocoa. Pero en este momento, su trabajo será más fácil ya que llamaría a la misma API que creó anteriormente en sus bibliotecas de bajo nivel.

Answer 5

¿Está seguro de que no puede abstraer los servicios de bajo nivel en una interfaz común y aún tener suficiente aplicación (como la interfaz de usuario) para hacer que sea más económico desarrollarse en plataformas multiplataforma? Si desea un tiempo de lanzamiento al mercado, parece un desperdicio planear hacer todo dos veces.

Answer 6

¿Qué hay de usar un tercer idioma como pegamento para las llamadas nativas?

He oído que python o ruby ​​tienen buenas capacidades para la integración lib nativa. La diferencia se puede abstraer a través de una API interna.

De esta manera, toda la lógica se podría establecer en el tercer idioma y la parte específica en el otro.

Lo mismo puede aplicarse a Java, pero creo que la integración parece un poco más difícil.

BTW esta es la forma (¿o era?) Clases como java.io.El archivo funciona

Cuéntanos cómo te fue.

edición

Creo que la forma grandes empresas van con esto está utilizando C++ y el uso de horquillas para el código específico de la plataforma.

Answer 7

Aunque he estado buscando fanáticamente una solución de escritorio para ambas plataformas, no creo que haya ningún problema con la creación de la aplicación dos veces ... probablemente tenga sentido.

Dicho esto, no creo que deba compilar una y luego la otra, pero trate de hacer algo locamente difícil como , utilice los mismos diagramas de clase UML para ambas. Esto te obligará a hacer el arduo trabajo de dividir la aplicación en las partes que son idénticas y las partes que son, por definición, específicas de la plataforma.

La idea no es compartir un código base, sino compartir un diseño de software.

Answer 8

Si va a tener que aprender una nueva tecnología de todos modos (Objective-C), le daría otra mirada a Java. Tratar de desarrollar el mismo programa dos veces para dos plataformas diferentes y aprender demasiadas cosas a la vez puede significar que termines con un programa que no funciona bien con ninguno de los dos, o un desastre insoportable si te sientes seducido por el uso de funciones disponibles en una plataforma, pero no en el otro.

Si va con Java, solo tendrá que lidiar con algunos IU y peculiaridades de instalación en cada plataforma: la mayor parte de su aplicación (y, lo que es más importante, las correcciones de errores que realice) se exportarán de inmediato. Las UI de Java parecen bastante maduras en este momento, y hay un montón de código de UI reutilizable (por ejemplo, los componentes de JIDE son agradables). Si la idea de su aplicación es realmente arrolladora, puede contratar personal para que realice las "aplicaciones ciudadanas de primera clase" una vez que gane sus millones.

También puede ver cómo otras aplicaciones multiplataforma se han entregado con éxito; por ejemplo, consulte firefox, thunderbird, openoffice y vea qué puede reutilizar. También sé de varias aplicaciones multiplataforma hechas en Java; por ejemplo, uso PersonalBrain y crashplan, y ambas parecen estar basadas en Java, y no es intrusiva en absoluto. (Curiosamente, PersonalBrain primero se entregó Windows y luego hicieron una reescritura de Java. Sin embargo, algunas funciones siguen siendo solo ventanas, pero estoy contento de usarlo en una Mac.)

Depende en cierta medida de la aplicación quieres escribir, por ejemplo, ¿quieres apoyar iPhone en algún momento? De ser así, hay pocas opciones actualmente, pero para usar el objetivo C, y es probable que vea un poco de reutilización de sus esfuerzos de MacOSX si planea con anticipación.

Hagas lo que hagas, definitivamente te sugiero dividir la IU de la lógica principal de tu programa, y ​​hacer que la lógica principal sea lo más portátil posible. De lo contrario, estarás reinventando cada rueda en cada plataforma.

Answer 9

Como suelo mencionar con preguntas como esta, también debería consultar al menos Real Studio, que le permite crear aplicaciones de escritorio nativas desde el mismo código base. También le permite conectarse a servicios de bajo nivel utilizando declaraciones o complementos.