Quiero desarrollar una aplicación móvil. Recientemente leí un artículo en el Foro Telerik , que compara entre tres tipos de aplicaciones móviles y no sé cuál debo seleccionar para empezar. Aquí hay una imagen que describe los pros y los contras de las diferentes opciones de diseño móvil
Para decidir entre estas opciones de diseño, me gustaría comprender mejor los pros y los contras de cada opción de arquitectura que figura en el diagrama. ¿Cuáles son los pros y los contras de cada enfoque de arquitectura?
design
architecture
programming-practices
mobile
Anyname Donotcare
fuente
fuente
Respuestas:
Soy un desarrollador móvil que ha dedicado mucho tiempo a considerar este problema.
¿Por qué preguntas?
Lo más probable es que espere reducir los costos de desarrollo de aplicaciones al:
Las razones también pueden incluir:
Definiciones
Establezcamos exactamente lo que queremos decir con cada uno de los tres enfoques mencionados:
Nativo
Una aplicación que se instala en un dispositivo, generalmente desde su tienda de aplicaciones (aunque a veces se puede cargar de lado). A los fines de esta discusión, la interfaz de usuario de una aplicación nativa no suele consistir en una vista web a pantalla completa solamente.
Web móvil
De hecho, puede ser cualquier página web, sin embargo, para esta discusión, consideremos una aplicación web de una sola página que intenta imitar el aspecto de una aplicación nativa. No es una aplicación nativa, se ejecuta en el navegador del dispositivo.
Aplicación nativa de la aplicación híbrida
híbrida
instanceof.La mayoría de las personas probablemente entiendan que una aplicación híbrida es una aplicación web móvil de una sola página (de nuevo, muy probablemente imitando el aspecto de una aplicación nativa), pero empaquetada como una aplicación nativa con acceso a servicios nativos (a la Phonegap).
Sin embargo, de hecho, hay un espectro entre el modelo Phonegap y el completamente nativo al que hablaré más adelante.
Web móvil
Restricciones técnicas En
primer lugar, enumeremos algunas restricciones técnicas en las aplicaciones web móviles que, en sí mismas, podrían ser decisivas en función de lo que esté haciendo:
Si puede vivir con todo lo anterior, siga leyendo para obtener más información sobre los desafíos de las aplicaciones web de estilo nativo de una sola página. Sin embargo, esta sección no estaría completa sin referencia a la aplicación FT.
Financial Times
La aplicación web FT es un famoso ejemplo de este estilo de aplicación. Aquí hay una característica interesante del periódico Guardian del Reino Unido al respecto.
Sin duda es una hazaña notable de ingeniería. Tenga en cuenta que actualmente solo está disponible solo en iOS ; esto me dice que están encontrando que resolver los desafíos del desarrollo avanzado entre navegadores es realmente muy difícil.
Aplicaciones web de estilo nativo de una sola página
Esta sección se aplica tanto a la web móvil como a las aplicaciones de estilo Phonegap.
La apariencia de estilo nativo dentro de una aplicación web generalmente se logra con un marco como Sencha Touch que proporciona un conjunto de componentes de interfaz de usuario para su uso.
Tales marcos están bien para interfaces de usuario muy simples. Sin embargo, carecen de flexibilidad. No podrá implementar ningún diseño de aplicación nativa con Sencha, deberá adaptar su diseño a lo que el marco puede acomodar.
La principal forma en que estos marcos sufren es tratando de emular las propias complejidades de la interfaz de usuario de la plataforma. ¿Ese pequeño efecto de rebote que obtienes cuando te desplazas hasta el final de una lista en el iPhone? Su marco debe emular eso en Javascript. Es imposible recrearlo por completo, será más lento y sus usuarios se verán atrapados en el "valle misterioso" de una aplicación que se ve como nativa, pero claramente no lo es, y no es técnica. el usuario no podrá señalar exactamente por qué.
El mito de "HTML5 / Javascript es fácil"
La fragmentación de dispositivos dentro de los navegadores web es abundante, y cuando superas los HTML y CSS más básicos, notarás que las cosas no funcionan como cabría esperar. Es posible que pases más tiempo resolviendo problemas complicados de IU de lo que habrías ahorrado haciéndolo de forma nativa dos veces. Si va a ser nativo, tenga en cuenta que las vistas web de aplicaciones nativas no son lo mismo que los navegadores de dispositivos y tienen sus propios problemas de fragmentación.
Y a medida que su aplicación se vuelva más funcionalmente compleja, encontrará que necesita más que habilidades básicas de jquery para mantener su Javascript limpio y fácil de mantener.
Dicho esto, es perfectamente posible crear aplicaciones simples y funcionales con bastante rapidez con este enfoque. Pero es bastante obvio cuando una aplicación lo está haciendo.
Más a lo largo del espectro
Por lo tanto, queremos un mejor UX que las aplicaciones de estilo Phonegap pueden ofrecer, sin escribir absolutamente todo desde cero varias veces. ¿Qué podemos hacer?
Compartir código no UI
Hay una variedad de técnicas disponibles para compartir la lógica de negocios en múltiples plataformas nativas. Google ha lanzado J2ObjC que traduce Java en Objective-C. Con un factorización cuidadosa del código, se podría usar una biblioteca Java tanto en Android como en iOS.
Las bibliotecas como Calatrava y Kirin permiten manipular las bases de código escritas en Javascript (y, por lo tanto, cualquier cosa que pueda compilarse en Javascript) a partir del código nativo. Descargo de responsabilidad: trabajo para Future Platforms que creó Kirin; Hemos tenido un gran éxito al usarlo en iOS con Javascript generado desde Java con GWT, y el código Java también se ejecuta de forma nativa en Android.
Use vistas web ... cuando corresponda
Las vistas web a pantalla completa tienen mucho trabajo por hacer para poder imitar las transiciones de pantalla y los efectos de rebote. Pero una vista web dentro de la aplicación nativa de Chrome puede ser indistinguible de la nativa.
Existen métodos estándar y bien documentados para que las aplicaciones nativas y las vistas web se comuniquen.
Las listas y tablas pueden funcionar particularmente bien cuando se hacen de esta manera, sin embargo, la entrada de texto es un ejemplo de algo que se maneja mejor de forma nativa (para un control total sobre el teclado).
En resumen
El enfoque adecuado para usted depende de lo complicada que sea su aplicación y del nivel de pulido de la interfaz de usuario con el que estará satisfecho.
Mi lema: usa vistas web siempre que puedas, pero asegúrate de que tus usuarios no puedan saberlo .
fuente
¡Primero revise esta encuesta para saber qué está pasando!
comparación entre los tres tipos: Comprender las opciones de desarrollo de su aplicación móvil
Comparaciones entre nativos e híbridos:
HTML5 vs nativo
HTML5 vs aplicación nativa: ¿cuál elegir?
Esta es realmente buena: aplicaciones nativas HTML5 v: consideraciones clave para su estrategia móvil
Comentarios:
fuente
Si necesita acceder al hardware del teléfono, debe crear una aplicación nativa (en HTML5 puede acceder a algunos de los componentes de hardware del dispositivo, como el GPS).
Si se siente más cómodo con el desarrollo web, debe seguir con eso a menos que necesite crear una aplicación nativa.
En cuanto a lo que debe saber, diría que debe tener en cuenta todos los diferentes tamaños de pantalla (incluida la orientación vertical y horizontal). Debe tener en cuenta varias versiones del sistema operativo (esto es más para Android). Dado que se trata de dispositivos móviles, existe la posibilidad de que el usuario responda una llamada telefónica, es un teléfono y tampoco tenga la potencia informática de una computadora de escritorio o servidor.
fuente
Para mí, cuando escribo cualquier aplicación de consumo, lo que es primordial para su éxito es la aceptación y percepción del usuario de la aplicación. Debido a esas cuatro razones para inclinarse a favor de las aplicaciones nativas, a pesar de los costos adicionales asociados con el aprendizaje, la capacitación y la pérdida de WORA (escriba una vez que se ejecute en cualquier lugar) son:
Lo que desea por encima de todo lo demás es una excelente experiencia de usuario que ayuda a que su aplicación tenga éxito en un mercado feroz. Por supuesto, hay excepciones, especialmente la falta de habilidades, la falta de tiempo y presupuesto. A veces, las aplicaciones están orientadas a un conjunto limitado de usuarios comerciales a quienes puede no importarles tanto estas cosas.
Son razones similares a estas que Facebook abandonó su estrategia de aplicación en favor de las aplicaciones nativas para iOS y Android:
Por favor lee:
Mark Zuckerberg: Nuestro mayor error fue apostar demasiado en HTML5 http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /
Por qué Facebook abandonó la Web móvil y se hizo nativo con su nueva aplicación para iOS http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app # awesm = ~ o9jDrRefxdgnpS
Espero que esto ayude.
fuente
Con lo siguiente, mi postura actual sobre esta debacle es que es bueno comenzar con un híbrido, explorar su aplicación, iterar rápidamente sobre los comentarios de los clientes y estabilizar el conjunto de características. Luego, para reescribir la aplicación a nativo de acuerdo con las especificaciones, para mejorar la experiencia.
He dejado fuera la Web móvil, porque tiene un propósito completamente diferente. Si desea estar en las tiendas de aplicaciones, Native / Hybrid es el camino a seguir. Si desea simplificar la implementación y está dispuesto a sacrificar la experiencia y la capacidad técnica, elija Mobile Web.
Pro / Contras Nativo :
Híbrido Pro / Contras :
fuente
Siendo yo mismo un desarrollador móvil, lo peor es el acceso sin conexión. Simplemente obliga a los usuarios a estar en línea, lo que debería funcionar en muchas aplicaciones, pero no en todas.
El otro gran mal aspecto es la lentitud. El tiempo necesario para analizar datos remotos puede llevar mucho tiempo. Sí, puede buscar datos previamente durante el tiempo de carga, pero en todos los demás casos no puede evitar la lentitud.
Descubrí que dicha aplicación terminaba más costosa que las aplicaciones nativas. Ya no los recomiendo a ningún cliente mío.
fuente
El gran problema con las aplicaciones híbridas es la fragmentación de los marcos: claramente hay muchas más (Ionic, Xamarin, React Native, etc.) que plataformas móviles nativas de interés (generalmente solo dos, Android e iOS). Estos marcos compiten, emergen, disminuyen, por lo que ser híbrido no lo salvará de saltar de plataforma en plataforma, incluso si planea mantener a su equipo actual de por vida.
Google y Apple están haciendo todo lo posible para proporcionar y respaldar editores, depuradores, marcos de prueba, herramientas de refactorización y otros medios para desarrollar sus plataformas. Por lo tanto, tomaría una redacción típica " es mucho más fácil desarrollar una aplicación híbrida, editar con su editor favorito y abrir en un navegador " con la reserva razonable. Xamarin y React Native son plataformas de desarrollo, al igual que Swift o Java / Android, y aunque "hello world" puede parecer más corto, eventualmente debería tomar el tiempo comparable para aprender correctamente.
Si, en cualquier caso, surgiera la necesidad de componentes nativos (por ejemplo, la biblioteca de terceros existente debe estar integrada), terminará con tres marcos en lugar de dos: iOS, Android y su marco híbrido en la parte superior, terminando Con una arquitectura más compleja. La depuración de tales aplicaciones, el paso entre llamadas de capas cruzadas, el registro de todas las capas y el mantenimiento del código sincronizado es complejo o, a veces, imposible.
Algunos dicen que la " aplicación se verá exactamente igual para todas las plataformas ". ¿Es realmente algo bueno? La aplicación de Android debe verse como la aplicación de Android y la aplicación de iOS debe verse como la aplicación de iOS.
¿Qué pasa con las nuevas características? Wearables? ¿Aplicaciones instantáneas ahora ofrecidas por la plataforma Android? ¿Muestra datos adicionales en la pantalla externa? Las aplicaciones híbridas ahora admiten muchas características nativas, pero ¿realmente las admiten todas ? En cualquier momento, de inmediato?
Finalmente, no solo el rendimiento y la experiencia del usuario, sino también la seguridad pueden estar más del lado de la aplicación nativa. El marco híbrido agrega la capa de indirección que puede tener errores propios, incluidos errores de seguridad.
Concluyendo todo lo anterior, bajo la posibilidad de elegir, definitivamente elegiría las dos aplicaciones nativas, una para iOS y otra para Android, o simplemente diseñaría una versión móvil del sitio web sin molestarme en el desarrollo de aplicaciones para ninguna plataforma. .
fuente