Diferentes opciones

En desarrollo de softwareTanto si se trata de un proyecto lúdico como de un proyecto empresarial formal, un requisito puede satisfacerse con muchas opciones y tecnologías diferentes. Tras un tiempo mirando muchas, es natural pensar cuál es la mejor opción para el requisito.

Consideremos las opciones para crear una aplicación móvil.

A veces, la mejor opción viene determinada por la compatibilidad de las implicaciones de la opción y los puntos fuertes técnicos del equipo de desarrollo. (Cubriré las implicaciones un poco más adelante) La primera opción a considerar cuando se construye una aplicación móvil son las aplicaciones nativas, pero inmediatamente surge una advertencia - cuando el código para una plataforma está hecho, el código tendrá que ser transcrito a otra plataforma. En segundo lugar, cada tecnología nativa tiene sus propias implicaciones. Así que para tener una experiencia móvil satisfactoria en todas las plataformas nativas, se necesita un desarrollador para cada plataforma.

Aunque hubiera un desarrollador para cada plataforma, ¿merece la pena desarrollar una aplicación móvil nativa para cada plataforma en lugar de modificar una página web para que pueda verse en cualquier dispositivo? Se trata de una cuestión importante a tener en cuenta, por lo que a continuación se ofrece una tabla comparativa de las características clave.

Basándonos en esta comparación, parece que una aplicación nativa ofrece un abanico más amplio para la creatividad y las opciones de servicio. Si el equipo de desarrollo se encarga de todos los implicaciones para cada plataforma, entonces podría ser una buena idea desarrollar una aplicación móvil de forma nativa para cada plataforma, teniendo en cuenta que las aplicaciones nativas tienen el mejor rendimiento y suponiendo que la empresa esté dispuesta a pagar un coste más elevado.

Hablemos más de esas "implicaciones".

Implicaciones

Cuando se trata de marcos de software y API, cada marco funciona de forma natural con el programador, al menos interactuando con (en otros dominando) ciertas tecnologías o lenguajes de programación. Esto resulta natural si el marco es una extensión de otra tecnología.

Por ejemplo, considere Node.js, un runtime de JavaScript. Al utilizar Node.js, al ser un runtime JavaScript, el código se programará naturalmente en lenguaje JavaScript. Por lo tanto, trabajar con el framework Node.js implica que el programador conoce, o al menos puede interactuar con, el lenguaje JavaScript. Llamaremos a estas dependencias del framework implicaciones.

A continuación se exponen algunas implicaciones para algunos marcos de aplicaciones móviles.

Hay otro coste que no es visible a primera vista. Aunque los distintos proyectos de plataforma tengan el mismo núcleo y la misma lógica, en última instancia son proyectos individuales. Cada proyecto tiene un lenguaje y un ciclo de vida de la aplicación y SDK diferentes, por lo que cada proyecto necesitará también su mantenimiento especializado. Todo esto puede sumar. Si crear la aplicación de forma nativa parece demasiado caro o el equipo de desarrollo no maneja todas las implicaciones, se puede recurrir a otra estrategia.

El uso de una tecnología multiplataforma se ha hecho muy popular como solución híbrida para el desarrollo móvil, de modo que se puede escribir un conjunto de código que puede utilizarse en múltiples plataformas y ofrecer al usuario una experiencia nativa. Existen muchas tecnologías multiplataforma para aplicaciones móviles, cada una con sus propias implicaciones. La estrategia consiste en elegir una tecnología que tenga una implicación que el equipo de desarrollo domine, además de otra consideración. Como se trata de una aplicación multiplataforma, es importante elegir una solución que tenga un gran porcentaje de código transcriptor; el código que puede escribirse una vez y ejecutarse de forma nativa en todas las plataformas.

Mi experiencia

Cuando decidí que quería desarrollar aplicaciones móviles, lo primero que pensé fue: "¿Qué tecnologías nativas conozco?".

Había utilizado Objective-C para una aplicación de iOS. Si quería hacer una aplicación nativa para Android o Windows Phone, tendría que aprender sobre la estructura de los proyectos y el ciclo de vida de las aplicaciones y esperar poder programar en el lenguaje que utilizaban. Como sólo conocía una tecnología nativa (iOS), decidí que era mejor invertir tiempo en aprender una tecnología multiplataforma.

Entonces pensé: "Si voy a utilizar una tecnología multiplataforma, ¿qué puedo hacer? implicaciones ¿puedo con los mejores?".  Xamarin fue una elección natural para mí, gracias al lenguaje y a la estructura de la aplicación. C# es uno de los lenguajes que mejor manejo, además la estructura era intuitiva. Una página .xml con su código back-end, el ciclo de vida de la aplicación también era tipo C. Conseguí aprender XAML y la estructura y ciclo de vida de la aplicación rápidamente.

Más tarde, descubrí que Xamarin generaba aplicaciones nativas que compartían 95% del código común. También llegué a un nivel aceptable de comprensión de las aplicaciones nativas de Android e iOS. Entonces decidí probar los proyectos nativos generados por Xamarin. Parecía que las aplicaciones nativas estaban muy bien estructuradas y codificadas. Pensé: "Vaya. En teoría, es posible que alguien desarrolle una aplicación nativa completa de Android sin conocer Java ni la estructura de aplicaciones de Android o incluso sin tener Android Studio". Otra ventaja de las tecnologías multiplataforma proviene de la capa de abstracción. Cuando se utiliza Xamarin, el código maneja los eventos móviles (como Swipe) a la manera de Xamarin.

Puedo codificar una vez y utilizar estos eventos sin ni siquiera saber cómo hacerlo de forma nativa.

Decidí que era una buena idea aprovechar al máximo estos proyectos generados e intenté hacer todo en Xamarin, porque algunas cosas no están implementadas en el framework. Por ejemplo, Xamarin no tiene una etiqueta de botón de radio para las aplicaciones de iOS. En lugar de modificar la aplicación de iOS generada y utilizar el botón de radio de Apple, decidí implementar mi propio botón de radio en Xamarin, que se renderizaba de forma nativa en iOS. Esto parecía una buena opción que se convertiría en una ventaja, pero también encontré una desventaja, al hacer un cambio mínimo en un proyecto de Xamarin, se debe volver a compilar para ver los cambios en el dispositivo. Esto puede llevar mucho tiempo si uno quiere probar varios cambios.

Conclusiones

Decidí utilizar Xamarin para crear aplicaciones móviles porque era multiplataforma. Así que la mayor parte del código solo tendría que escribirse una vez. Y los proyectos generados por Xamarin eran nativos. Este no es el caso de todas las tecnologías multiplataforma. El hecho de que los proyectos finales sean nativos es una ventaja, ya que se pueden utilizar las características móviles.

Aún así, estudié proyectos nativos para Android e iOS para poder modificar los proyectos generados si algo no se puede hacer realmente en Xamarin (me di cuenta de que Xamarin no admite todo para todas las plataformas). De nuevo, esto se puede hacer porque Xamarin genera proyectos nativos.

En otras palabras, aprovecho Xamarin para reutilizar código y generar plataformas totalmente nativas en la medida en que me lo permite, pero también sé cómo hacerlo sin Xamarin en caso de que realmente necesite modificar un proyecto nativo. Las implicaciones de Xamarin son mis puntos fuertes en programación. Así es como determiné que Xamarin era la mejor opción para mí a la hora de desarrollar aplicaciones móviles.

Es importante tener en cuenta que la mejor opción es un equilibrio entre los puntos fuertes técnicos del equipo de desarrollo y las implicaciones de la tecnología. Xamarin con antecedentes en plataformas nativas fue la mejor opción para mí, pero tengo antecedentes en C#. Otro desarrollador podría haber trabajado más rápido con Ionic si, por ejemplo, el desarrollador es un maestro en AngularJS.