Software

Apache Cordova y el desarrollo de aplicaciones híbridas

No hace mucho que os hablamos sobre las aplicaciones nativas, web e híbridas, explicando qué son y en qué se diferencian. Estas últimas son muy interesantes ya que, en determinados casos, pueden competir de tú a tú con los desarrollos nativos de cada plataforma. Por eso, hoy le echamos un vistazo a Apache Cordova, un framework que te permitirá aprovechar tus conocimientos en lenguajes web para crear tus propias aplicaciones.

Aplicaciones web e híbridas, alternativas prometedoras

La perspectiva de desarrollar una aplicación multiplataforma en cuestión de días o pocas semanas puede resultar casi irresistible. Y además, sin tocar una sola línea de código nativo. De ahí que las aplicaciones web sean muy apreciadas y defendidas por muchos, en comparación con las propias de cada plataforma. Las híbridas, no obstante, se sitúan en un punto intermedio: conjunción de lenguajes web y acceso al hardware del terminal. Su elaboración puede resultar más sencilla para según qué desarrolladores, y hoy os muestro algunos ejemplos y comparaciones con las aplicaciones nativas -en este caso, Android-.

Si queréis iniciaros en este mundillo o simplemente hacer alguna que otra prueba, os dejo un enlace a las instrucciones de instalación de Apache Cordova. Lo ideal una vez creado un proyecto es importarlo con un IDE como Android Studio o IntellijIDEA, para que podáis trabajar de forma más cómoda. Yo utilizo este último, y en este artículo quiero centrarme en las aplicaciones que se pueden desarrollar y los resultados obtenidos.

Estructura de la app

La gran diferencia y ventaja -o desventaja- de las aplicaciones web e híbridas es que utilizan lenguajes web, normalmente HTML5, CSS3 y JavaScript. De este modo, a la hora de sentarse a programar, es necesario elaborar desde cero toda la estructura de la interfaz, habitualmente de forma que se parezca a una app nativa. Os dejo a continuación un par de imágenes para que entendáis a qué me refiero.

Inicial

En ambas capturas veis una aplicación recién creada, sin tocar una sola línea de código. A la izquierda, una correspondiente a Apache Cordova, y a la derecha a una nativa.

Partiendo de este punto, se puede apreciar que, valga la redundancia, la nativa tiene mucha más pinta de nativa. Es decir, cuenta con la barra superior con los tres puntos del menú y con un botón flotante. Cualquiera que vea esta interfaz se da cuenta de que está delante de una aplicación Android.

La híbrida, sin embargo, no tiene la misma estructura ni la misma estética. Por defecto, dispone de un conjunto de archivos html, css y js que forman lo que veis, y que habría que modificar en caso de querer parecerse al otro ejemplo.

Cordova apariencia nativa

¿Se puede conseguir, por tanto, una apariencia similar a la nativa? Sí, se puede. El problema es que requiere mucho más esfuerzo y los acabados no son tan logrados. En la captura de la derecha, por ejemplo, podéis ver como justo debajo de la barra superior hay un ligero sombreado, al igual que en el botón. No es algo especialmente importante, pero este y otros son pequeños aspectos que mejoran la experiencia de usuario, y que si bien en una aplicación nativa se añaden automáticamente, en la interfaz web habría que elaborarlos a mano.

Interfaz apaisada

La interfaz en modo apaisado también presenta algunos inconvenientes; en la captura superior, la barra reduce su altura para adaptarla al nuevo modo de visualización, mientras que la apariencia web, no. Esto ocurre debido a que en este último caso, esta tiene una altura fija. Por supuesto, existe la posibilidad de usar medidas relativas, como los porcentajes, los vh o los vw, pero su desempeño no es impecable. Por ejemplo, un porcentaje que en vertical queda perfecto, en horizontal puede ser demasiado escaso. Al fin y al cabo, un 15% del alto de la pantalla no es lo mismo que un 15% del ancho. Una mejor opción serían las media queries de CSS3, pero de nuevo sería aumentar el trabajo y el esfuerzo.

Por supuesto, en las aplicaciones nativas también hay que optimizar el modo apaisado y la interfaz en pantallas mayores, pero lo que os quiero transmitir con estos ejemplos es que la interfaz web requiere todavía de más horas de desarrollo. Lo que os he comentado, además, me sirve para introducir una ausencia muy importante en las aplicaciones híbridas: los dp.

Los dp, una unidad todoterreno

Sabéis que hay muchísimos dispositivos que corren Android como sistema operativo, y sabéis que cada uno tiene un tamaño de pantalla y resolución distintas. Este hecho puede ser un quebradero de cabeza para los desarrolladores, porque es complicado que la interfaz que diseñan con su terminal en particular se adapte bien a la multitud de opciones existentes en el mercado. La solución del androide verde son los dp.

El dp es una medida que escala los píxeles en función de la densidad de pantalla del terminal. Y antes de nada, como una imagen vale más que mil palabras, aquí tenéis una prueba.

DP

La imagen superior muestra lo que ocurriría sin usar los dp. Supongamos que el cuadrado con la etiqueta “Medium Density” tiene un lado de 100 px, y la pantalla del dispositivo un ancho de 350 px. Con una densidad baja, donde por ejemplo el ancho de la pantalla sea de 200 px, esos 100 px del cuadrado ocupan más espacio, resultando en una figura de mayor tamaño (izquierda). Al contrario y como muestra la imagen de la derecha, si la pantalla tiene más píxeles de ancho, el cuadrado sera menor.

Usando los dp, como en la imagen inferior, se usan más o menos píxeles en función de la densidad de la pantalla, haciendo que el tamaño del cuadrado sea aproximadamente el mismo en cualquier dispositivo.

Volviendo a las aplicaciones híbridas, en los lenguajes web no existe esta unidad. Habría que arreglarse con unidades relativas como los em o los porcentajes, pero no es una solución ideal.

Si estáis un poco metidos en el tema, seguro que os estaréis preguntando: ¿y no se puede tener una interfaz nativa en una aplicación híbrida? La respuesta es sí, pero estarías perdiendo cualidades muy diferenciales como la capacidad de tener una apariencia unificada entre sistemas operativos, como iOS, Android o Windows Phone. La idea de las aplicaciones web e híbridas es unificar los ecosistemas, por lo que en cierto sentido esto iría contra la filosofía de Apache Cordova.

Eventos de toque, la baza de JavaScript

Aunque JavaScript permite el uso de multitud de eventos, los más interesantes en este caso son los de toque: touchstart, touchmove y touchend. De esta forma, se puede identificar cuándo un usuario toca la pantalla, arrastra el dedo o lo quita, y actuar en consecuencia. ¿Un buen uso de esto? Un menú lateral al puro estilo Android.

Menu lateral

No obstante, volvemos a la misma reflexión de antes. ¿Se puede hacer? Sí, se puede, pero requiere mucho más esfuerzo y es necesario programarlo desde cero -a no ser, por supuesto, que se tome como base alguno que encontréis por Internet-.

Los plugins y la funcionalidad nativa

Más allá de la interfaz, Apache Cordova permite el acceso a gran parte del hardware de nuestros móviles. De este modo, se pude hacer uso de sensores como el acelerómetro, gestionar los contactos, sacar fotos con la cámara o usar la geolocalización.

Sin embargo, además de los plugins disponibles por defecto, un desarrollador puede elaborar los suyos propios y después compartirlos. iScroll es un ejemplo que me viene bien, ya que aúna el buen hacer de terceras personas, y la mayor complejidad la programación híbrida.

Este plugin permite conseguir contenido en el que se pueda hacer scroll, algo que a priori puede parecer chocante. Al fin y al cabo, toda la vida llevamos haciéndolo en la web sin ningún inconveniente. La diferencia en el caso de las pantallas táctiles es la capacidad de tocar la pantalla, en lugar de usar el ratón. Así, con esto es posible hacer scroll como en cualquier aplicación Android que se os ocurra.

¿El inconveniente? Pues para variar, con código nativo se consigue lo mismo de forma mucho más sencilla.

Para acabar con el apartado de plugins, quiero destacar un aspecto que a mí me ha dado bastantes quebraderos de cabeza. En una aplicación de este tipo, se puede combinar código web con nativo, haciendo que tanto la interfaz como el núcleo de la misma se comuniquen. Así, la forma de enviar datos entre un extremo y otro es mediante un plugin.

Comunicacion

Usando una función JavaScript se puede ejecutar una función Java, de manera que esta última devuelva un resultado a la primera. Si se requiere comunicación en el sentido contrario -de Java a JavaScript- habría que hacer apaños, ya que la idea es que esta se inicie siempre en la parte web. Esto deriva en una complejidad innecesaria, ya que algo tan sencillo como transferir valores para usarlos en segundo plano puede convertirse en algo tedioso y poco eficiente.

Entonces, ¿para qué Apache Cordova?

Aunque parezca que soy un detractor de este framework y de cualquier aplicación que no sea nativa, no es así. Simplemente creo que este tipo de desarrollo es para contextos bastante específicos, no mereciendo la pena en el resto de casos. Intentar elaborar una aplicación utilizando Apache Cordova puede ser muy simple o muy complejo en función de las necesidades y los requisitos de la misma, y una mala decisión sobre qué tecnología utilizar puede repercutir en que una idea llegue a buen puerto. Por supuesto, dentro de este ámbito existen alternativas como Ionic, que últimamente parece que tiene bastante empuje, pero con inconvenientes parecidos.

Como conclusión, yo creo que las aplicaciones híbridas están genial para aprovechar conocimientos web sin tener que tocar una sola línea de Java o Swift, allí donde no se requiera mucha potencia y se pretenda aunar experiencias en distintos sistemas operativos. Para todo lo demás, bajo mi punto de vista, no.

¿Vosotros conocíais Apache Cordova? ¿Os a tocado trabajar con aplicaciones híbridas?

Marco

Marco

Ingeniero de Telecomunicaciones, estudiante y usuario de Android desde el HTC Magic. Muy crítico con todo lo que pruebo, ¡hay quien me llama hater!
Marco
¡Comparte!
Advertisment ad adsense adlogger