Desarrollo de aplicaciones móviles multiplataforma [cerrado]


109

Se están lanzando cada vez más plataformas móviles y los sdk están disponibles para los desarrolladores. Hay varias plataformas móviles disponibles: Android, iOS, Moblin, Windows Mobile 7, RIM, symbian, bada, maemo, etc.

Y hacer aplicaciones multiplataforma es un dolor de cabeza para los desarrolladores. Estoy buscando cosas comunes en las plataformas que ayuden a los desarrolladores que quieran portar la aplicación a todas las plataformas. Como cuáles son las resoluciones de pantalla de diferencia, métodos de entrada, soporte de gl abierto, etc., comparta los detalles que conoce para cualquiera de las plataformas.

O hay posibilidades, escribiendo código en html (tipo de cosa de widget) y cargándolo en la aplicación nativa. Sé sobre Android, en el que podemos agregar la vista web a la aplicación llamandosetContentView(view)

Comparta los detalles de la clase donde podemos agregar la vista html en la aplicación nativa de diferentes tipos de plataformas que conoce.

El propósito de este hilo es compartir detalles comunes entre desarrolladores. marcando como comunidad wiki.

Biblioteca y herramientas multiplataforma


1
Si bien encontré un hilo interesante que está relacionado con este, stackoverflow.com/questions/3326110/…
sohilv

otra buena publicación sobre desarrollo multiplataforma: stackoverflow.com/questions/51988/…
sohilv

1
Votó para cerrar esto como duplicado. Esto es demasiado importante para dividirlo en dos preguntas. stackoverflow.com/questions/51988/…
ripper234

1
Recientemente escribí en un
Anshu Dwibhashi

Respuestas:


97

Mi respuesta aquí cubre algunas de las limitaciones técnicas de las herramientas de plataformas cruzadas, pero permítanme expandirme un poco:

Creo que las herramientas multiplataforma históricamente siempre han sido también rans porque tales herramientas tienen un enfoque filosófico equivocado.

Todos los puntos de venta de las herramientas multiplataforma son los beneficios que aportan a los desarrolladores . Están convencidos de que permiten a los desarrolladores escribir una vez y ejecutar en cualquier lugar. Se venden con la idea de que permiten a los desarrolladores expandir su mercado sin aprender nuevas API. Se venden con la idea de que permiten a los desarrolladores reducir el costo y el tiempo de comercialización.

Lo que las herramientas de plataforma cruzada NO se venden es el beneficio que brindan a los usuarios finales .

El beneficio para el usuario final no es un argumento de venta porque el desarrollo multiplataforma rara vez es un beneficio para el usuario final. Al usuario final no le importa cuánto tuvo que trabajar el desarrollador para llevar el producto al mercado. Tampoco les importa en cuántas plataformas se puede ejecutar la aplicación cuando no usan una sola plataforma. Solo les importa si la aplicación hace lo que necesitan en el hardware en el que necesitan ejecutarla. A menos que tengan una necesidad específica de ejecutar la aplicación en muchas plataformas diferentes, el hecho de que lo haga no les aporta ningún valor.

Por el contrario, los compromisos inevitables de hacer una API multiplataforma significan que todas las aplicaciones creadas por la API serán, en el mejor de los casos, de grado B en todas las plataformas. Nunca serán la mejor herramienta para usar en cada plataforma.

Todo esto significa que, en la mayoría de los casos de uso, las herramientas multiplataforma brindan al usuario final un producto inferior en comparación con los creados con API específicas de la plataforma. El usuario final siempre tendrá una mejor opción.

Usted gana dinero a largo plazo proporcionando a los usuarios finales las herramientas más útiles. Si no se concentra filosóficamente en hacer la vida del usuario final más fácil y productiva, está prácticamente condenado desde el principio. Los usuarios finales tienen muchas opciones y si su herramienta no es una de las mejores, no la tendrá en el mercado.

Solo debe utilizar herramientas multiplataforma si cree que "los usuarios se beneficiarán realmente de ejecutar esta aplicación en muchas plataformas diferentes". Si comienza a buscar herramientas multiplataforma únicamente porque le facilitarán la vida (a los desarrolladores), entonces las ha elegido por el motivo equivocado y le harán más daño de lo que ayudarán.


52
Bueno, menos trabajo (innecesario) para los desarrolladores significa ciclos de actualización más rápidos, nuevas funciones más rápidas, correcciones de errores más rápidas, etc. Con la misma mano de obra se puede lograr más. Considero esto como un beneficio para el usuario final.
Schoetbi

10
En teoría, un desarrollo más rápido podría ser mejor para el usuario final, pero esa no es la base filosófica de la mayoría de las API multiplataforma. He visto muchos intentos de utilizar tales herramientas en muchos entornos y el enfoque siempre está en facilitar la vida del desarrollador a expensas de la calidad del producto final. Además, la promesa de una solución más rápida y económica rara vez se cumple. Siempre parece haber un espectáculo que detiene el enganche en algún lugar que come la mayor parte del tiempo ahorrado.
TechZen

5
Para llevar mi punto a casa, considere esto: Existen API multiplataforma para muchas clases diferentes de hardware y sistema operativo. ¿Cuántas aplicaciones multiplataforma utiliza personalmente de forma habitual? ¿Cuántas aplicaciones multiplataforma ha utilizado alguna vez que pensó bien? La gente ha estado impulsando API multiplataforma desde que ha habido más de una plataforma, pero nunca han tenido éxito en ninguna parte. No tienen éxito porque no producen las aplicaciones más útiles para los usuarios finales.
TechZen

4
@TechZen: estoy usando StackOverflow ahora en mi navegador web y no veo ninguna razón para buscar un cliente nativo. Creo que generalizas demasiado tus afirmaciones.
Youval Bronicki

4
Me molesta bastante que este tipo de debate filosófico subjetivo obtenga la marca correcta en un sitio web técnico. Lo que es peor, la tesis de esta publicación no es válida para la mayoría de los programas principales que usamos hoy: los navegadores web son multiplataforma; Photoshop, MS Office, Dropbox y otros productos son multiplataforma; simplemente abra el menú Inicio o el Finder y enumere los tipos específicos de la plataforma; lo más probable es que encuentre pequeños productos de utilidad. Su argumento sería válido si cree que los teléfonos móviles son radicalmente diferentes (una suposición muy válida), pero parece que no hay argumentos para construir esa base.
kizzx2

14

Existen varios enfoques para el desarrollo multiplataforma en dispositivos móviles. Por supuesto que todos tienen limitaciones. Ninguna solución logra aprovechar todas las funcionalidades del dispositivo como puede hacerlo una aplicación nativa.

Reutilización de código

Si bien todos los sistemas operativos móviles no usan el mismo lenguaje de desarrollo y API, a veces puede compartir algunas clases o código de nivel lógico.

C ++, por ejemplo, probablemente se pueda reutilizar para una aplicación de iOS , para una aplicación de Android utilizando el NDK , para una aplicación Symbian, ya que están desarrolladas en C ++, etc.

Algunas soluciones también ofrecen la posibilidad de escribir la aplicación en un idioma diferente al que normalmente utiliza el dispositivo. Los más famosos (de hecho el único que conozco) son comerciales y se basan en el proyecto Mono (desarrollo C #):

Pero no estoy seguro de que realmente podamos llamar a este desarrollo multiplataforma, ya que la reutilización del código es limitada según el dispositivo:

  • Windows Phone 7 no permitirá el desarrollo de código nativo (tal vez en futuras actualizaciones)
  • El proyecto AFAIK mono like no existe para todas las plataformas (¿todavía?) Bada, webOS, maemo, etc.

Y la parte de la interfaz de usuario también permanece específica para cada dispositivo.

desarrollo web

Una respuesta habitual cuando se pregunta sobre el desarrollo multiplataforma para móviles es el desarrollo web. Entonces necesitaríamos un contenedor, que usará el navegador móvil, para que se vea y se comporte como una aplicación nativa. Así es como funcionan algunos de los marcos multiplataforma que veremos más adelante.

El auge de HTML5 trae al desarrollo web funcionalidades que solo podrían hacerse con una aplicación nativa como geolocalización, aplicación fuera de línea, almacenamiento local.

Podemos encontrar cada vez más marcos para desarrollar aplicaciones web para móviles con un aspecto nativo al aprovechar los últimos estándares web HTML5, CSS3, Js:

Pero HTML5 es todavía muy joven y la implementación puede variar de un navegador a otro. La mayoría de los navegadores móviles predeterminados usan el motor WebKit (la principal excepción es Windows mobile / phone que usa Internet Explorer) y, aun así, no necesariamente admiten las mismas funcionalidades . La base de datos local todavía es incómoda para trabajar y no podemos estar seguros de cómo la implementarán los diferentes navegadores. Además, incluso con HTML5, el desarrollo web sigue siendo muy limitado en comparación con una aplicación nativa. No puede acceder a contactos, cámara, acelerómetro, etc.

Editar: A principios de este mes, el W3C ha entregado algunas advertencias sobre la evolución de HTML5: artículo de ZDNet

Por lo tanto, solo se adaptará a una categoría limitada de aplicaciones.

Marcos multiplataforma

Y además tenemos los marcos de aplicaciones móviles multiplataforma. Con el que presumiblemente puede desarrollar una vez y desplegar en diferentes plataformas. Estas soluciones suelen centrarse en iOS y Android y se basan en el motor WebKit. Ofrecen más interacción con las funcionalidades del teléfono mientras se desarrollan con tecnologías web. Los más conocidos son Nitobi PhoneGap, RhoMobile Rhodes, Appcelerator Titanium. Pero muchos otros están ahí fuera y no todos usan la misma técnica como MoSync, que traduce su código a su propio lenguaje intermedio antes de compilarlo para la plataforma deseada.

[1] Recuerde que Apple tiene una política especial sobre las aplicaciones escritas para su plataforma. No parecen estar bloqueando estas aplicaciones en esta fecha, pero es una información que debe tenerse en cuenta. Editar: Apple ha cambiado esta política desde el 9 de septiembre.


6

Obtiene algo en común cuando se implementa como una aplicación web (html5 como se mencionó anteriormente), pero para las aplicaciones nativas ricas, las API son completamente diferentes para los distintos teléfonos inteligentes.

HTML5 puede mejorar un poco las cosas, pero para hacer cosas interesantes es necesario ser nativo.

Hay marcos de teléfonos inteligentes 'multiplataforma' como Phonegap, pero he escuchado en su mayoría cosas malas sobre su uso para el trabajo "real". (muchos gastos generales, etc.)


5

Sí, html5 está recibiendo algo de atención. También debería mirar este consorcio y plataforma para el cuarto trimestre. No estoy seguro del éxito de ese proyecto, ya que parece un gran desafío, pero aquí están los detalles:

Sitio web: http://www.wholesaleappcommunity.com/default.aspx

Noticias: http://news.google.de/news/search?aq=f&pz=1&cf=all&ned=us&hl=en&q=%22Wholesale+Applications+Community%22

WAC tiene como objetivo publicar su especificación inicial y los componentes de su SDK para los desarrolladores en noviembre. Esta especificación se basará en los estándares W3C y creará una plataforma sólida para desarrollar aplicaciones web móviles ricas. WAC también proporcionará compatibilidad con versiones anteriores para dispositivos basados ​​en las especificaciones JIL y BONDI actuales. ( http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=31021 )

.

Es una coalición internacional de alrededor de 25 empresas de telecomunicaciones que tiene como objetivo crear una plataforma abierta a todos los desarrolladores y venderla a todos los usuarios de teléfonos móviles. ( http://www.downloadsquad.com/2010/02/15/atandt-wholesale-applications-community-is-a-platform-not-an-app/ )


1

Hasta donde yo sé, la mayoría de esos dispositivos pueden ejecutar esto:

Java ME: la plataforma de aplicaciones más ubicua para dispositivos móviles

Creo que esto puede servir tanto de buen como de mal ejemplo.


En realidad, no hay java en el iPhone, y hasta donde yo sé, java me no se ejecuta en Android
Alaa Nassef

El desarrollo de Android es masivamente Java. developer.android.com/reference/java/net/package-summary.html
Nick Garvey

No conozco los detalles, pero Avian JVM permite que Java se ejecute en dispositivos iOS.
Quazi Irfan
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.