Desarrollo avanzado en apps: el uso del código nativo

Pese a que cada vez hay más plataformas con las que es posible desarrollar aplicaciones móviles con código web, usando JavaScript para la lógica y CSS/HTML para los estilos, de todos es sabido que el resultado más óptimo siempre es el uso del código nativo, ya sea Java en el caso de Android, Swift u ObjectiveC para iOS o .NET para las plataformas de Microsoft. Pero estos lenguajes son más complejos y pueden suponer una barrera para perfiles menos expertos. Aún así siguen naciendo otras respuestas para no abandonar la primera opción y de esto os quiero hablar hoy: la mezcla de código nativo con código híbrido.

Hyperloop, la respuesta de Titanium para el código nativo en apps

Appcelerator Titanium es una plataforma de desarrollo móvil que incluye todo lo necesario para poder lanzar una aplicación. Ha pasado por varias fases desde que era simplemente Titanium Studio, siento totalmente gratuito, hasta que se transformó en lo que conocemos hoy, una decisión que acarreó cierta polémica entre los perfiles más independientes por el nacimiento de sus planes y su coste. Aún así, y aunque a nivel personal no estoy muy de acuerdo, han ido justificando esas tasas con servicios extras, simplificando operaciones básicas en la administración de nuestros proyectos. Por ejemplo: nos proporcionan un panel para gestionar las notificaciones push para nuestros usuarios, o contamos con una tienda de añadidos que sirven de respuesta a necesidades puntuales que podamos tener. Recordemos que Titanium, pese a usar lenguaje web, el resultado final siempre es lenguaje nativo, por lo que el sistema operativo donde ejecutemos nuestra app estará leyendo código hecho para él.

Recientemente los ingenieros de Appcelerator pusieron a nuestra disposición otro servicio extra para justificar el pago de un plan, sea el que sea, y se trata de Hyperloop, un concepto que pretende usar código nativo directamente en la app sin hacer la traducción a JavaScript. ¿Esto qué significa? Lo pondré con un ejemplo: en Android, a la hora de acceder a ciertos rincones del sistema para comunicarnos con el usuario, debemos hacer uso de un seguido de “reglas” establecidas por Google, las cuales no siempre están actualizadas en la API de Titanium, por lo que en ese momento tenemos dos opciones: esperar a que se pongan al día o usar código nativo para solventar dicha necesidad. Hasta ahora, la única manera de hacer algo directamente con código nativo era el uso de algún plug-in creado por la comunidad e implementarlo nosotros mismos, algo que era tedioso y engorroso. Con Hyperloop lo que proponen es usar directamente el código nativo que necesitemos, sin conversiones ni transformaciones, ofreciendo una respuesta directa a una necesidad muy concreta. Sin duda algo fantástico, ya que a partir de ahora podremos mezclar conocimientos con esta plataforma y explotar aún más el rendimiento de las apps.

Pero tanto como Hyperloop, quiero que hagamos un pequeño ejercicio de reflexión de su significado. El objetivo de otros frameworks como Cordova, Ionic o Phonegap era simplificar el desarrollo de apps y llevarlo a perfiles menos técnicos, lo cual no significa que debamos prescindir de ciertos conocimientos, ya que la programación y el diseño siguen presente. Pero ahora estamos hablando de que se pretende fusionar los dos mundos, y tiene cierto sentido en realidad…al menos hasta que las propias empresas decidan implementar las facilidades de Titanium. Lo podemos ver del siguiente modo: tenemos a nuestra disposición un método de crear apps que, pese a ser de pago, nos da un abanico de herramientas muy útiles, como el panel para las notificaciones push, el uso de una base de datos, etc. Es decir, un seguido de servicios para el desarrollo de los cuales no hace falta que nos preocupemos ya que ellos se encargan de administrarlos por nosotros, de ahí la cuota. Y ahora además nos dan la posibilidad de implementar código nativo directamente en nuestro proyecto sin tener que hacer ningún tipo de conversión, lo que a la larga se traduce con menos peso de compilación. Y esto tiene éxito porqué Google o Apple no da esa ventaja. Y mi pregunta es ¿por qué no hacen lo mismo? ¿Por qué no me gestionan otros servicios más allá de registrar una clave de API para mis proyectos? Y de hecho considero que todos los frameworks de desarrollo híbrido deberían dar la posibilidad de poder implementar código nativo sin tener que pasar por el proceso de adaptación.

Aún así, y ya para terminar, Appcelerator ha provocado una consecuencia con su evolución: originalmente era una respuesta muy buena para perfiles novatos que querían introducirse en este mercado a nivel de desarrollo, y en la actualidad ya no lo tengo tan claro, es decir, se ha transformado en una plataforma avanzada la cual ya permite el uso de ObjectiveC o Java para complementar el JavaScript. Esto me hace llegar a la conclusión de que, si bien es cierto que es una característica muy buena, está creando más barreras, y sin duda, si otras plataformas como Cordova adaptan esto a su sistema, otros frameworks que gozan de ser sencillos para el usuario principiante, lo van a dejar fuera del juego, obligando a que pase de nuevo por la curva de aprendizaje y forzarlo a realizar un código de más calidad, más ordenado, más bien pensado… Bueno, visto así, lo mismo tampoco es tan mala idea, ¿No creéis?

Curso relacionado: Curso Superior de Desarrollo de Aplicaciones para Móviles