Souvenirs de IT

• La aplicación fue desarrollada principalmente en entorno Linux, con el fin de utilizar herramientas gratuitas pero poderosas, como el lenguaje de programación PHP, el IDE Netbeans, y el gestor de bases de datos MySQL; pero también debido a que la computadora no tenía los recursos suficientes para correr el emulador de Android en Windows, y este corría de forma más eficiente en Linux. Adicionalmente, la versión de Linux que utilizaba era Manjaro (mi primera experiencia con una distro basada en Arch Linux), con el entorno OpenBox, lo que la hacía significativamente más rápida y liviana que Windows y muchas versiones de Linux.
• El vídeo fue grabado con una herramienta cuyo nombre no recuerdo, pero que irónicamente no poseía interfaz gráfica.
• La ventana del emulador fue posicionada sobre la vista previa de una imagen de un teléfono celular, ajustada al tamaño del emulador, para que pareciera que el emulador tenía un skin de teléfono celular.

• Uso de imágenes PNG y JPG. Cuando se usan imágenes e la web, surge la pregunta: ¿qué formato de imagen debo usar? En términos generales, es recomendable utilizar imágenes PNG para logos e íconos, cuando estos sean de múltiples colores y compuestos principalmente de figuras geométricas y texto, ya que este tipo de imagen permite mostrar estos detalles con una excelente calidad, y además permite el uso de transparencias. Por otra parte, se recomienda el uso de imágenes JPG para fotografias, dibujos u otro tipo de imágenes que muestren una amplia gama de tonos y colores, ya que esta clase de gráficos no requieren bordes lisos ni definidos, y además este formato permite mostrar las tonalidades con un tamaño de archivo pequeño. Pueden utilizarse otros formatos, pero estos dos son los que presentan la mejor combinación de calidad y tamaño de archivo, y además son soportados por HTML desde versiones previas.
• Optimización de imágenes. Antes de utilizar imágenes, es necesario comprimirlas, y además reducirlas al tamaño (ancho X alto) mínimo posible, pero sin sacrificar demasiado la calidad. Si la aplicación está destinada a dispoitivos de múltiples tamaños, puede ser conveniente tener las imágenes en múltiples tamaños, y mostrarlas dependiendo de la pantalla del dispositivo. Está de más decir que usualmente los dispositivos más grandes (tablets) poseen mejor hardware que los de tamaño menor (smartphones), y pueden mostrar imágenes de mayor tamaño con un menor costo en el desempeño. Adicional a esto, cuando son íconos pequeños, se recomienda el uso de sprites, que básicamente son archivos de imágenes que contienen múltiples imágenes dentro de sí, y que son "recortadas" y mostradas mediante CSS.
• Usar fuentes en lugar de imágenes para los íconos, si el diseño de estos se basa principalmente en figuras geométricas, y son de un solo color. Ello debido a que las fuentes son básicamente imágenes vectoriales, y los visores web pueden dibujarlos sin mayor inconveniente. Además, al ser vectoriales, pueden ajustarse a cualquier tamaño, y verse siempre de la misma forma, a diferencia de las imágenes que se pueden ver demasiado afiladas o borrosas si se reducen o aumentan de tamaño. En este sentido incluso son preferibles a los sprites. Existen varias fuentes que porporcionan una generosa cantidad de íconos cuyas figuras se basan en acciones comunes, como Font Awesome y Ionicons. Pero si estas colecciones no contienen todos los íconos que usted desea, o usted posee íconos propios para añadir a su aplicación, existen técnicas para convertirlos a imágenes vectoriales, y posteriormente a fuentes que pueden ser añadidas a la aplicación híbrida o incluso su propio sitio web. Adicionalmente, son ua alternativa al uso de imágenes vectoriales SVG, las cuales noe son soportadas en las plataformas más antiguas.
• Efectos CSS. Para animaciones, efectos y ajustes en el despliegue de elementos en la aplicación, se recomienda el uso de transiciones, transformaciones y otras propiedades CSS, ya que son más rápidas y fáciles de implementar que mediante Javascript, y usualmente presentan un mejor desempeño. Sin embargo el soporte de las distintas transiciones está supeditado a la versión del sistema operativo del dispositivo móvil, por lo que es necesario verificar esto.
• Reducir elementos DOM. Al maquetar una aplicación HTML, se recomienda utilizar la menor cantidad de elementos posible, y eliminar los nodos del DOM que ya no se usen. Cada elemento dentro del DOM ocupa memoria, y requiere recursos para su dibujado, incluso aunque no sea visible, por lo que al disminuir la cantidad de estos, ahorramos recursos.
• Seleccionar cuidadosamente el framework a utilizar. Existen distintos frameworks para el desarrollo de aplicaciones híbridas HTML, que proporcionan funcionalidades por defecto, lo cual permite agilizar el desarrollo, tales como JQuery Mobile, Sencha Touch, App Framework, PhoneJS, Onsen UI, Ionic Framework, etc. Sin embargo, es necesario tener en cuenta el costo que estos pueden causar en el desempeño, así como el soporte que poseen para los distintos sistemas operativos. Además es necesario sopesar la curva de aprendizaje, ya que un framework mal usado puede llevar a fugas de memoria, uso excesivo de recursos y reducción en general del desempeño de las aplicaciones.
• Verificar el soporte de tecnologías HTML, CSS y Javascript, para las plataformas objetivo. Esto es necesario para no minar la experiencia del usuario, al poseer funcionalidades que solamente son visibles en ciertas plataformas, pero que presentan fallas o incluso no existen en otras. Unas excelentes herramienta en línea para verificar esto es caniuse.com y W3 Schools, ya que poseen un listado bastante completo de elementos HTML, CSS y Javascript, así como los navegadores/plataformas que los soportan.

Hace poco más de un año empecé a desarrollar aplicaciones móviles, y por mi experiencia previa con sitios web, opté por el desarrollo de aplicaciones HTML híbridas en lugar de nativas, para hacer el desarrollo más rápido. Pero veamos...

¿Qué son las aplicaciones híbridas?

¿Cuáles son sus ventajas?

¿Existen desventajas?

¿Ser o no ser?

• ¿Es una aplicación intensamente gráfica? Si lo es demasiado, es mejor utilizar la tecnología que presente un mejor desempeño, y en este caso, al menos hasta el momento, la mejor alternativa es una aplicación nativa. Pero si es una aplicación no tan gráfica, como por ejemplo una app informativa, o incluso hasta un juego ligero en 2D, entonces una aplicación híbrida puede ser una buena opción.
• ¿El sistema operativo y hardware objetivo es viejo o reciente? A medida es más nuevo, se brinda un mayor soporte a las tecnologías web y aplicaciones híbridas. Si es más viejo, habría que evaluar si soporta o no las características que tengamos en mente para nuestra aplicación.
• ¿Puedo acceder a todas las funcionalidades que necesito? Tomando como base que una aplicación nativa puede acceder al 100% de funcionalidad disponible, habría que investigar y evaluar si el framework que utilizaré para mi aplicación posee las funciones que requiero, o aunque no las posea, es posible desarrollarlas y añadirlas (y por supuesto cuento con el tiempo para hacerlo).
• ¿Tengo poco tiempo y solo conozco tecnologías web/nativas? Creo que es el punto de menor relevancia de los mencionados, pero lo suficientemente importante para tener en consideración. ¿Por qué? Porque tanto el desarrollo de aplicaciones nativas como el uso de frameworks para aplicaciones híbridas posee su curva de aprendizaje. Además, el desarrollo de aplicaciones híbridas requiere siempre cierto conocimiento de las herramientas nativas subyacentes, principalmente para la preparación del entorno de desarrollo (SDKs, dispositivos de prueba, depuración, etc.). Y por qué no, esta prodría ser una buena oportunidad de aprender una tecnología y alternativa de desarrollo que no conocía, ya sea nativa (si viene del entorno web) o híbrida (si ya posee experiencia en el desarrollo nativo).