¿Alguna ventaja de la progtwigción de forma nativa para el desarrollo mobile?

Necesito desarrollar aplicaciones para una compañía en algunos de los principales sistemas operativos mobilees, específicamente, iOS, Android y WP7.

Inicialmente estaba planeando codificar tres aplicaciones separadas para los tres sistemas operativos diferentes, cada uno usando el SDK nativo.

Sin embargo, ¿hay alguna ventaja al hacerlo? Hay varias herramientas multiplataforma disponibles: Sencha, Phonegap, Rhodes, etc. ¿Qué tan "nativas" hacen las aplicaciones creadas por ellos a través de los dispositivos? ¿Qué tipo de integración de hardware tienen (camera, GPS, almacenamiento local, etc.)?

No tengo restricciones de time y no tengo problemas para desarrollar tres aplicaciones nativas si hay alguna ventaja al hacerlo.

EDITAR: en caso de que importe, las aplicaciones tendrán funcionalidades tanto en línea como fuera de línea.

Descargo de responsabilidad: He mantenido un logging de las herramientas multiplataforma que ha mencionado, pero nunca he construido nada con ellas. Si lee esta publicación, probablemente pueda adivinar que, en este momento, soy principalmente desarrollador de Android.

La respuesta es, depende. Ciertamente, hay ventajas para las aplicaciones nativas, pero la pregunta es si te importan (o te importa lo suficiente) esas ventajas para incurrir en gastos generales de desarrollo para múltiples plataforms. Como no has dado muchos detalles sobre el tipo de aplicaciones que estás planeando build, te daré un resumen de lo que sé.

Voy a suponer que estás hablando de soluciones multiplataforma basadas en HTML (como PhoneGap , Sencha y Rhodes ) y no plataforms multiplataforma orientadas a los juegos como Corona SDK o Moai y tampoco el siempre interesante Mono vía MonoTouch y Mono para Android . También estoy excluyendo Titanium que no es compatible con Windows Phone.

Algunas de las lagunas que veo entre las soluciones nativas y las HTML multiplataforma son las siguientes:

  • Familiaridad UI
  • Rendimiento (especialmente UI)
  • Compatibilidad
  • Depuración
  • API de la plataforma

Familiaridad UI

Los usuarios de cada plataforma desarrollan ciertas expectativas sobre cómo funcionan las cosas. Las aplicaciones en iOS a menudo tienen ciertos paradigmas de UI (esa barra arriba con el button Atrás a la izquierda, esas UI networkingondeadas de la tabla / list, etc.), las aplicaciones en Android pueden tener otra (ActionBar, por ejemplo, que es similar, pero no del todo lo mismo que la barra de iOS, o elementos de larga duración para menus contextuales), usuarios de Windows Phone y otros (cuadros y vistas panorámicas). Si genera la misma interfaz de usuario de HTML, probablemente no podrá aprovechar eso. Esos patrones familiares de interfaz de usuario hacen que la aplicación sea más intuitiva y cómoda para el usuario, que generalmente no pasa el time aprendiendo múltiples plataforms.

Actuación

Otra ventaja de los nativos es el performance, especialmente el performance relacionado con la interfaz de usuario, sea ese poder de representación gráfica sin procesar o simplemente cálculos. Si tiene interfaces de usuario sencillas, esto podría no tener importancia, pero si tiene interfaces de usuario animadas complejas, algunas cosas pueden terminar no tan bien. Esto es particularmente cierto en Android, donde tiene una gran variedad de dispositivos, incluidos algunos de bajo consumo.

Compatibilidad

Otra desventaja de usar una herramienta multiplataforma HTML es que los diferentes teléfonos tratan con HTML / CSS / JavaScript de manera diferente. Es gracioso porque esta es una espada de doble filo. Por un lado, es genial que el HTML sea intrínsecamente multiplataforma, por el otro, todavía tienes problemas persistentes que dependen del dispositivo. Esto es especialmente cierto una vez más en Android, donde tiene muchos dispositivos diferentes y donde a los fabricantes les encanta jugar con la implementación de WebView s por alguna razón. Terminas con pequeños errores donde ciertos dispositivos hacen cosas extrañas. Si vas nativo, tendrás una mejor compatibilidad (al precio de poner más trabajo, por supuesto). El soporte para versiones anteriores de Android también tiende a faltar.

Depuración

Depurar JavaScript no es la experiencia más maravillosa en una plataforma mobile. Terminas haciendo muchos loggings en la console. Es viable, pero ciertamente no es tan agradable como entrar a tu código línea por línea. Parece que hay algún progreso en este frente (ver esta herramienta llamada weinre, por ejemplo), pero no puedo comentar lo bueno que es todavía, ya que no he llegado a excavar en él.

No solo es ese tipo de debugging más difícil, pero también es más difícil detectar los errores. Los errores en su código JavaScript no terminarán en sus loggings a less que los capture y los registre manualmente. Puede terminar con cosas que simplemente fallan silenciosamente.

API de la plataforma

En general, los grandes jugadores que has mencionado tienen bastante soporte de hardware decente. Las características que ha mencionado, como la camera, el GPS y el almacenamiento local, son bastante altas en la list de características importantes para los desarrolladores de aplicaciones, por lo que las incluyen. Para get una list completa de las características, probablemente desees ir al website de cada una de ellas (aquí está el cuadro de soporte de alto nivel de PhoneGap por plataforma, por ejemplo), pero en general la gran característica de "teléfono" en la que piensas está ahí. Aún así, hay un montón de cosas más complicadas que, según yo sé, estos frameworks no funcionan o no lo hacen tan bien, en particular las cosas que tienen que ver less con las funciones del teléfono y más relacionadas con la plataforma. Threading es un ejemplo.

El desarrollo de la plataforma cruzada requiere insert una capa de intermediación entre su código y las API nativas. Existen varios costos potenciales para este tipo de capas de intermediación, que incluyen:

  • performance (sobrecarga de intérprete, retraso JIT o pérdida de optimizaciones de comstackdor cruzado),

  • la huella de la memory y el time de carga de la aplicación,

  • si la API de intermediación se mantiene al día con las últimas y mejores API de dispositivos y características de hardware lo suficientemente pronto (si las necesita),

  • si hay API específicas del dispositivo (no multiplataforma) que la API de intermediación expone o no, y si puede agregarlas,

  • si la capa de intermediación proporciona o permite anular las capacidades de presentación de UX / UI para que la aplicación parezca que se comporta y se ve "adecuada" dentro de cada comunidad de dispositivos o App Store,

  • escribir una vez, depurar en todas partes (más testings de regresión multiplataforma de una solución para cualquier plataforma), etc.

Tenga en count que las ineficiencias de performance podrían manifestarse en un drenaje de batería más rápido además de o en lugar de un retraso de UI visible.

Es posible que tenga que comparar testings y / o maquetas y partes principales de testing de usuario de su aplicación particular para determinar si estos types de beneficios valen la pena los costos adicionales de desarrollo requeridos.

Personalmente utilizo PhoneGap. Mantengo mi biblioteca de UI como mínimo, quizás solo use Jquery Mobile. Y mientras el código javascript esté bien escrito, tal vez use un marco mvc, realmente no noto ninguna pérdida de performance.

A veces uso un server php remoto para la database, y las llamadas ajax se ejecutan sin problemas, algunas otras veces uso la bruja de almacenamiento html5 también funciona bien.

Entonces, a less que quieras aprender java o objective-c … 🙂

esta es una de esas preguntas para las que no hay respuesta y hay muchas respuestas decentes; en general, la respuesta es que, a less que exista algún código de controller de dispositivo especializado que sea propietario, el caso general de utilizar la API como se diseñó evitará equivocaciones

Java proporciona una capa de abstracción rica, aunque existe una protección patentada expuesta intencionalmente para la concesión de licencias; mi sugerencia es verlo como si fuera a proteger algo y que responderá a su pregunta mejor que cualquier publicación.