cross platform - mega - Aplicaciones de escritorio multiplataforma: ¿un enfoque?

ejemplo xamarin forms (9)

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 debas construir uno y luego el otro, sino que trates de hacer algo terriblemente difícil como usar los mismos diagramas de clase UML para ambos. Esto te obligará a hacer el trabajo duro 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 una base de código, sino compartir un diseño de software.

Tengo lo que creo que es una idea excelente 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 la siguiente: ¿es mejor intentar construir ambos "simultáneamente", es decir, tratar de mantenerlos en paridad de características incluso a través del ciclo de desarrollo; ¿o es mejor hacer una "derecha" y luego seguirla con la otra?

Los pros para mantener la paridad parecen ser:

Es más fácil mantener alineados los algoritmos, ya que lo implemento en un idioma, simplemente me conecto al otro
Es más fácil asegurar que en el lanzamiento, ambas aplicaciones estén disponibles de inmediato

Las desventajas de mantener la paridad parecen ser:

Más difícil de hacer; el cambio constante de idioma puede hacer que mi cabeza explote (ya paso esto en el trabajo cada vez que trabajo C # por 4 días y de repente tengo que mantener una de nuestras viejas soluciones VB.NET)

Los pros de uno, luego del otro, parecen ser:

Sin cambio constante de idioma
Una plataforma puede estar en prueba mientras la otra está siendo construida

Los contras de uno y luego del otro parecen ser:

Volviendo a lo que entonces será el código "antiguo" para portar los algoritmos
Potencialmente, perder interés en "rehacer" lo que ya hice

Es cierto que esto es muy ambicioso ... Y solo soy un tipo, 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 de abajo:

Sí, una API común es factible, sin embargo, las convenciones de llamadas no serían, o al menos no serían fáciles. 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 como Java, pero estoy eligiendo no hacerlo por un par de razones: (1) No he hecho Java para siempre , y ahora estoy peligrosamente descalificado. :) (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 ...

¿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 algo multiplataforma? Si desea un tiempo de lanzamiento al mercado, parece un desperdicio planear hacer todo dos veces.

¿Qué pasa con el uso de 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 forma, toda la lógica podría establecerse 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.

Por cierto, esta es la forma (¿o era?) De clases como java.io.File funciona.

Cuéntanos cómo fue.

editar

Creo que la forma en que las grandes compañías se suman a esto es usar C ++ y usar las horquillas para el código específico de la plataforma.

Si fuera usted, iría con un marco de trabajo y / o lenguaje de programación multiplataforma, hoy en día tiene muchos lenguajes / marcos que funcionan multiplataforma como Java, QT (con ambos lenguajes Java y C ++ para usar el kit 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 fuera, 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.

Tanto los pros y los contras que mencionas 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 dijo que desea 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.

Me gustaría desarrollar para cualquier plataforma la audiencia objetivo más grande (como en su aplicación asesina) primero, y luego usar las lecciones inevitables que aprendería en el camino para mejorar la forma en que desarrollaría para el otro (s).

Primero debe concentrarse en escribir su aplicación para una plataforma y preocúpese por 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?

Si vas a tener que aprender una nueva tecnología de todos modos (Objective-C), le daría otra mirada a Java. Intentar desarrollar el mismo programa dos veces para dos plataformas diferentes y aprender demasiadas cosas a la vez puede significar que terminas 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 opta por Java, solo tendrá que lidiar con algunas peculiaridades de la IU y de la instalación en cada plataforma: la mayor parte de su aplicación (y, lo que es más importante, cualquier corrección 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 se entregó primero solo a Windows y luego hicieron una reescritura de Java. Sin embargo, algunas funciones todavía son solo ventanas, pero me alegra usarlo en una Mac).

Depende en cierta medida de la aplicación que desea escribir; por ejemplo, ¿desea admitir el 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 UI 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.

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