¿Qué enfoque seguir para desarrollar aplicaciones dirigidas a múltiples plataformas?

Para las aplicaciones dirigidas a múltiples plataformas, veo principalmente dos enfoques de desarrollo:

• Busca una plataforma de desarrollo similar a JAVA. Tenga una solución de código y deje que el tiempo de ejecución intermedio maneje diferentes plataformas. Si algo sale mal en cualquier plataforma, modifique un poco el código. Pero mantenlo igual para todos.

• Cree código modular que separe la lógica central y la interfaz de usuario. Desarrolle interfaces de usuario separadas para las plataformas respectivas que llamarán a las mismas bibliotecas centrales. Cree la aplicación por separado para cada una de las plataformas de destino.

Entonces, ¿cuál seguir? Lo sé, la respuesta comenzará con " Depende ". Pero quiero escuchar sus opiniones sobre estos enfoques y los factores a considerar para elegir cualquiera de ellos.

Dejando a un lado las disputas actuales de Oracle / Apache / Google, todavía es difícil vencer a la JVM para este propósito. Es realmente de muy alta calidad en la mayoría de las plataformas, universal, y tiene una buena cantidad de idiomas para elegir (Java, Clojure, Scala, etc.). Le permite apuntar a una arquitectura de máquina única (VM) y no preocuparse demasiado por el hardware específico del usuario final.

Dicho esto, hay ciertos tipos de aplicaciones para las que puede no ser tan adecuado: la creación de redes de bajo nivel viene a la mente, al igual que el procesamiento pesado de gráficos / video.

Ve por HTML5. Cualquier plataforma con un navegador HTML5 puede ejecutar su aplicación. Aunque HTML5 aún no está listo para un gran momento, el enfoque de la aplicación web sí lo está.

En el editor de sonido Audacity usamos wxWidgets como nuestra biblioteca multiplataforma. Dado que necesitamos vincularnos a las bibliotecas C, y necesitamos velocidad y acceso de bajo nivel, un enfoque JVM no funcionaría para nosotros. El código GUI es 95% igual en todas las plataformas. Utilizamos #ifdefs para las pequeñas variaciones. Sin embargo, consideramos esencial contar con un desarrollador que trabaje en cada una de las tres plataformas (Mac, Windows Linux), porque incluso usar la biblioteca multiplataforma es demasiado fácil para que un cambio en una máquina rompa las cosas en otra.

Si puede obtener el rendimiento que necesita, elija JVM. Si no puede, use QT o wxWidgets, y sugeriría QT sobre wxWidgets ya que es menos trabajo hacer que se vea bien.

Como desarrollador en tiempo real, utilicé con éxito una opción similar a 2: módulos específicos de plataforma separados con una API común utilizada por la lógica central. Sin embargo, nada de lo que he hecho ha tenido una interfaz de usuario (redes, audio, transmisión de datos), en este caso es la interfaz de hardware de bajo nivel que es específica de la plataforma.

Lo he hecho de esta manera por varias razones:

1) Para obtener el rendimiento óptimo en cada plataforma

2) Para aprovechar las características que solo se ofrecen en 1 plataforma

3) (J) Las máquinas virtuales no existían para algunas de las plataformas (sistemas integrados, consolas de juegos ...)

Depende de lo que sea importante para ti :)

Cuando nos enfrentamos a esta opción para una aplicación Mac / Windows multiplataforma hace unos 10 años, vimos bien las diversas opciones multiplataforma: Java, Qt, wxWidgets, etc. El problema que tuvimos fue que la apariencia la interfaz de usuario era realmente importante para nosotros, y todas las aplicaciones "multiplataforma" parecían, bueno, comprometidas. Terminamos mordiendo la bala y construyendo nuestro propio núcleo multiplataforma, con una IU personalizada para cada plataforma en la parte superior (escrita en PowerPlant para Mac y MFC en Windows). Con el tiempo nos hemos vuelto bastante buenos en esto, y la parte "multiplataforma" se ha vuelto más gruesa sin comprometer la interfaz de usuario.

Ahora estamos viendo esta decisión nuevamente para un nuevo proyecto. Mirando las opciones ahora, probablemente iría con Qt: es gratis y realmente parece haber madurado bien. Java podría haber sido una opción, pero realmente no podemos tomar el golpe de rendimiento (estamos haciendo el procesamiento de imágenes en 3D).

Si la interfaz de usuario es realmente importante para usted, sospecho que tendrá que invertir mucho tiempo para que las cosas se vean bien en cada plataforma, ya sea que use algo como Qt o haga el suyo. Para una aplicación interna o especializada donde los usuarios podrían aceptar más una IU menos pulida, ¡podría estar bien!

Todos se preocupan mucho por los lenguajes como Java como "multiplataforma", pero de lo que realmente están hablando es de que puedes compilar una vez y ejecutarla en todas partes. Incluso en un lenguaje como Java (o C # / mono), necesitará capas de abstracción para tratar los detalles específicos del sistema operativo en algunas áreas.

C ++, y de hecho la mayoría de los lenguajes, son multiplataforma, solo tiene que compilar para apuntar a cada plataforma.

La clave es el proceso en lugar de las herramientas / idiomas:

1. Asegúrese de tener un proceso de compilación integrado que construya y ejecute las pruebas unitarias para todas las plataformas de destino .
2. Asegúrese de que cada desarrollador realice pruebas en todas las plataformas de destino antes de ingresar el código: esto obviamente significa asegurarse de que cada desarrollador tenga acceso a la cantidad adecuada de máquinas / vms.
3. Resumen bien. Resumen todo lo que se llama en apis nativas. Escriba bibliotecas que envuelvan estas llamadas.
4. Si está haciendo algo más que formas de interfaz de usuario bastante simples que solo atiende al mínimo común denominador, simplemente acepte que el código GUI no es multiplataforma. Resuma su capa de presentación / GUI y codifíquela por separado para cada plataforma. Sí, hay kits de herramientas GUI multiplataforma, que están bien para aplicaciones sencillas, pero si está haciendo algo más avanzado, querrá codificar las capacidades de la plataforma nativa.

Estos pasos son los mismos sin importar el idioma / conjunto de herramientas / marco que utilice.

¡Aproveche la web!

En serio, si quieres EL máximo rendimiento por tu dinero, escribe una aplicación web.

¿Por qué?

• Los clientes web generalmente no requieren mucha energía de la PC.
• Los clientes web están EN TODAS PARTES. No solo PC / MAC / Linux, sino también en teléfonos, dispositivos móviles y más.
• ¡Nada extra para descargar para los usuarios! (Normalmente, a menos que desee algo elegante y use Flash o Silverlight)
• Todos los componentes comunes están en el lado del servidor, y pueden ser Java, .NET, PHP o una mezcolanza de un conjunto de componentes existentes que tiene. ¡Al cliente no debería importarle!

Incluso los dos enfoques que mencionó son muy similares. El navegador web representa HTML para múltiples arquitecturas subyacentes. Del mismo modo, la JVM interpreta el código Java de una manera que tenga sentido para el hardware subyacente. ¡Sin embargo, la web simplemente tiene una base de clientes más amplia!

He tenido muy buena suerte con Mono. Puedo escribir el mismo código para máquinas Windows que para máquinas Linux, y en su mayor parte, funciona en ambos. Y puedo usar las habilidades que ya conozco en C # y Winforms.

Haga una prueba de concepto primero.

Si se trata de una aplicación razonablemente compleja, obtener una prueba de concepto le dará una idea de las características del lenguaje que necesita y qué áreas necesitará para aprovechar el marco o las bibliotecas de terceros.

Las funciones de lenguaje y las bibliotecas que necesita determinarán qué idioma terminará eligiendo (y, por lo tanto, cómo abordará el soporte multiplataforma)

Construí un sistema, comenzando con una aplicación de escritorio, hace 15 años cuando Java todavía estaba en su infancia y no estaba listo para usar en la construcción de este tipo de aplicaciones. Sabía que necesitaba tener un núcleo en C ++ y lo diseñé desde el principio para ser multiplataforma, incluido el uso de tipos de tamaño (por ejemplo, int32 en lugar de int o long), para que pudiera ejecutarse en Mac, Windows y UNIX (pre-Linux dias).

En el momento en que intenté buscar un buen entorno de interfaz de usuario multiplataforma, había algunos que incluían XVT. Realicé el entrenamiento para XVT y cuando comencé a crear una aplicación real, me di cuenta de que no iba a poder crear un aspecto limpio y nativo en la plataforma (comenzando con la Mac). Así que renuncié a esa idea y construí una interfaz de usuario nativa para Mac (PowerPlant) sobre el núcleo portátil.

Un par de años después, nos mudamos a Windows (UI en MFC). Fue más rápido construir una interfaz de usuario la segunda vez, mantuvimos una interfaz de usuario de Mac y Windows en paralelo por un corto tiempo y luego fuimos a Windows. El núcleo más tarde se trasladó a varios sabores de UNIX y Linux, para permitirnos ejecutar cálculos basados ​​en el servidor. El núcleo funcionó bien, con algunos ajustes cuando lo preparamos para 64 bits.

Ahora he vuelto a usar una Mac y desearía poder volver a la Mac, pero el tamaño y la complejidad de la aplicación hacen que esta sea una elección difícil. Todavía tiene sentido que gran parte de esta aplicación sea una aplicación de escritorio, es como un entorno CAD. Pero en lugar de construir la interfaz de usuario nuevamente en un lenguaje C / C ++ específico de la plataforma (y continuar manteniendo una interfaz de usuario basada en MFC), estoy más inclinado a reescribir toda la pila en Java para que pueda ejecutarse en múltiples plataformas.

Todavía puede haber razones para ejecutar un núcleo que no sea Java, digamos C ++ como lo hicimos nosotros. Pero me gustaría ejecutar pruebas de rendimiento tempranas para ver si eso era realmente necesario. Y estaría mirando cuidadosamente mi interfaz de usuario para ver si podría construirla como una aplicación web, conectada al núcleo a través de servicios web, para poder tener una variedad de clientes: aplicaciones de escritorio, aplicaciones móviles, aplicaciones web, etc. Si necesitaba una pieza en C o C ++, ¿podría escribirse bajo una capa de Java? ¿O como un servicio web?

Otra consideración: ¿cuánto tiempo durará su aplicación? ¿Qué tan complejo será? Si tiene alguna idea sobre esto, considere la posible longevidad de cualquier biblioteca de UI que esté utilizando y su capacidad con el tiempo para que las personas ayuden a mantenerlas. Esto puede ser difícil de considerar ahora pero vale la pena pensarlo.

- Alex

Si puede convertirlo en una aplicación web, hágalo una aplicación web. Al usar kits de herramientas como ExtJS , es relativamente fácil crear interfaces de usuario compatibles con varios navegadores compatibles con GUI.

De lo contrario, Java o QT + C ++ o C + Wx son opciones posibles para tener una fuente para todos.

Su segundo enfoque es apropiado si desea que la aplicación se vea y se sienta nativa en cada plataforma de destino. Las aplicaciones nativas de Mac se ven y se sienten diferentes a las aplicaciones nativas de Windows, solo usar otra máscara y teclas no será suficiente para cubrir eso.