uso compartido de código angularJS a través de la aplicación Ionic híbrida y el sitio web móvil normal


11

Ok, entonces en nuestro 'laboratorio de innovación', actualmente hay un impulso para usar Ionic, un marco de aplicación híbrido construido sobre Cordova para acceso nativo y angularJS para el 'código web'.

También hay algunos proyectos que son web móvil pura, que utilizan Angular + bootstrap para un diseño receptivo, por ejemplo.

La cuestión es que algunos proyectos que se presenten necesitarán tener un sitio web móvil y aplicaciones nativas (híbrido iónico). La mayoría de las funciones y pantallas serán las mismas, compartiendo back-end y la mayor parte de la interfaz de usuario, pero aún habrá alguna diferencia.

Entonces mi pregunta es; Cómo diseñar un proyecto para que pueda ser tanto un proyecto iónico como un sitio web angular normal con 2 enfoques de implementación diferentes. Se reutiliza la mayor parte del código, pero algunas vistas para el sitio web móvil y algunas vistas para la aplicación híbrida (usando más componentes y convenciones nativas), tal vez también algunas diferencias de enrutamiento.

¿Es eso una buena idea?

Y en el código compartido, ¿hay una manera simple de saber en qué caso se encuentra? algunas FI, algunas directivas inactivas fuera de su contexto, etc.

Parece que falta algún tipo de enlace del que no estoy al tanto.

Gracias por adelantado.

Respuestas:


2

Puede construir un núcleo compartido que contenga algunos componentes atómicos ( https://docs.angularjs.org/guide/component ) / Services.

La aplicación web, la aplicación de Android, la aplicación ios, la aplicación de supervisión ... todas utilizarán las funcionalidades proporcionadas por el núcleo, de forma adaptativa.

Imagínese si desea implementar una aplicación de Android. Usar https://material.io tiene sentido, junto con algunas capacidades de Android. La aplicación para iOS tendrá un diseño diferente ( https://developer.apple.com/ios/human-interface-guidelines/overview/themes/ ), etc.

¡Construya una implementación sólida, y use componentes atómicos y adáptelos!


0

Para aplicaciones móviles que usan Ionic y aplicaciones web que usan AngularJS o Angular, es muy común que algunas de estas aplicaciones tengan una funcionalidad compartida, así como conectarse al servidor y obtener algunos datos, pero eso no significa que no tendrá una copia de ese código en tus nuevos proyectos.

Mi punto es que si sabe que solo habría diferencias de capa de IU y el proyecto requiere una aplicación web y una aplicación móvil y puede tener 3 niveles donde la IU para la aplicación web puede estar en angular y la aplicación móvil puede estar en iónico. Los beneficios que obtiene al usar funciones nativas como cordova phonegap o ionic pueden ser mucho más que mantener todo en un solo tipo.

Solo quiero dejar en claro que no es difícil cambiar entre estas IU en caso de que su cliente quiera convertir una aplicación web a una aplicación móvil nativa.

Comenzaría con las siguientes preguntas

  1. ¿Este proyecto necesita una interfaz de usuario separada para dispositivos móviles?
  2. ¿Este proyecto necesita funciones móviles nativas?
  3. ¿Este proyecto necesita una interfaz de usuario separada y funciones respaldadas para dispositivos móviles?

Si su respuesta es sí para los 3, cree dos proyectos. Si su respuesta es sí para 1 y 2, cree una aplicación web y backend angular junto con la aplicación iónica o de teléfono. Si su respuesta es sí a 1, entonces recomendaría usar angular para ambos.

Si en algún momento desea usar vistas angulares en iónico (busque cosas iónicas), tendrá el mismo código tanto para el front end, la aplicación móvil y la aplicación web. Al final podrás gestionar lo siguiente de forma independiente:

  1. Migraciones de bases de datos
  2. Funcionalidad de servidor del lado del servidor con API que se conecta a 1 para datos
  3. Aplicación web front-end que utiliza vistas angulares que consumen 2
  4. Si se necesita una aplicación móvil, usa Ionic / phonegap para resolver las dependencias del dispositivo, pero usa Angular para crear vistas y consumir 2.

Espero que esto ayude y abra un poco de discusión.

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.