Apps móviles con HTML5

Actualmente estamos en un punto en la historia de la web en el que el lenguaje de etiquetas HTML5 ha evolucionado tanto que permite acciones complejas en relación con el dispositivo donde se ejecuta. Tal es la situación que incluso puede detectar componentes nativos como el GPS, la cámara o el almacenamiento. Esto hace unos años era impensable y es lo que ha permitido que existan apps muy capaces sin necesidad de pasar por la barrera del código nativo. Hemos hablado de Ionic, Angular y otros frameworks que alimentan todo esto, y hoy vamos a ver algunas de las aplicaciones que no pasan de esta fase y por qué. Vamos allá.

HTML 5 como un buen aliado para escribir aplicaciones móviles

¿Por qué deberíamos preferir una app híbrida en HTML5 y no una nativa? Bien, antes de nada hay que concretar que no únicamente están construidas en html, y es que, si recordamos, es un lenguaje de etiquetas que por si solo no es capaz de hacer nada. Junto a él van cogidos de la mano Javascript y CSS. Digamos que todo aspecto gráfico necesita de un lenguaje de programación, o scripting, que otorgue la lógica a los procesos, y aquí entra en juego JS.

Hay distintos frameworks que nos van a ser de ayuda, como Angular, pero hay que comprender que cuando se dice “aplicación html5” no estamos obviando que detrás de esa fachada hay una maquinaria que se encarga de que todo funcione. De lo contrario tendríamos una página web corriente y moliente, y además estática, lo cual haría imposible cualquier interacción con el usuario más allá de navegar entre ficheros de formato html. Entonces, ¿qué podemos hacer? Apoyarnos en JavaScript para poder ejecutar tareas más complejas, como por ejemplo acceder al GPS. Esto es importante por una simple razón: reducción de costes en desarrollo. Pensad que si no se apuesta por esta solución, la empresa responsable debería destinar recursos a un equipo de desarrollo por plataforma. Esto implica, en la mayoría de los casos, un equipo para Android y otro para iOS, contando que cada equipo tendrá integrantes con altos conocimientos de la plataforma nativa.

Otra opción es contratar personal que sean todoterreno en este ámbito, pero por ende también desearán cobrar más, como es lógico. La solución radica en usar frameworks híbridos, y, tal y como hemos visto en anteriores posts, estos usan lenguajes web íntegramente para entregar el producto deseado. Ejemplos de estas aplicaciones podrían ser los siguientes:

• Uber, tenemos mucha polémica recientemente en España con esta plataforma para pedir transporte, pero dejando de lado el tema legal, Uber decidió usar un sistema híbrido para poder complacer usuarios de todas las plataformas sin necesidad de tener que desarrollar código nativo.
• Slack, un software para mantenerse comunicado con tu equipo de trabajo, similar a lo que podría ser Skype, pero con la diferencia de que está construido con ReactJS, un framework (otro más) Javascript que permite crear, no solo aplicaciones móviles, también se aplica para generar programas de escritorio.
• McDonald’s, desde que servicios como Deliveroo, JustEat y muchos otros que han aparecido, los gigantes de la restauración han necesitado adaptarse a los tiempos y ofrecer su propio servicio de entrega a domicilio, todo a través de su aplicación móvil, por supuesto. El resultado es una aplicación híbrida, y creedme cuando os digo que el resto de servicios hacen uso de la misma tecnología, para poder cubrir la demanda de ello.

Y muchas más que hay ahí fuera.

¿Cómo funciona y por qué?

La idea detrás de esta manera de construir apps se basa en la potencia actual de los navegadores y los lenguajes web. Debemos entenderlo como una cápsula que contiene toda la lógica web, actuando esta como nuestro navegador favorito, ya sea Firefox o Chrome (Internet Explorer no cuenta, ya que no es favorito de nadie), de modo que todo el ecosistema queda encerrado dentro de la cápsula y el terminal solo se encarga de proporcionar los recursos. De ahí el término “encapsulación”, muy empleado en la actualidad. El término correcto es webview, un componente en las APIs móviles que se encarga de poner en funcionamiento todo lo anterior. Si traducimos su nombre, “vista web”, podemos deducir todo lo mencionado. ¿Por qué? Tal y como venía explicando, es más sencillo y barato vitaminar una vista web que emplear esfuerzo, tanto económico como de personal, en construir una nativa. Pero el motivo de más peso detrás es que si construyes bien una webview, con una buena estructura y arquitectura de la información, puedes aprovechar el código tanto para las plataformas móviles como para el escritorio, haciendo pequeños arreglos específicos para cada uno. Esto, como es de esperar, fue muy goloso para las empresas de desarrollo, sobretodo las encargadas de hacer aplicaciones para terceros, ya que se dieron cuenta de que con relativamente poco esfuerzo tenían el negocio servido para sus clientes.

Todo esto ha ido creciendo con el avance de los navegadores y las APIs móviles, y, de hecho, como decía, hace 7 años esto era algo impensable, desde luego. De modo que, una vez más, el avance de la tecnología nos ha brindado facilidades para el desarrollo.

Curso relacionado: Curso Superior de Programación con HTML5 y CSS