Cuando nos piden desarrollar una aplicación para dispositivos móviles, siempre se nos presenta una primera pregunta que dirige el rumbo del resto del desarrollo a realizar:
“Se espera que los usuarios cuenten con conectividad a internet para utilizar la aplicación de forma permanente (tanto sea por 3G o Wifi)?”
Si la respuesta es afirmativa, entonces es viable y generalmente conveniente plantear que la aplicación se realice basada en una WEB con HTML5, CSS y demases.
Hacerlo de esta manera da unas cuantas ventajas:
a) La aplicación desarrollada no depende del dispositivo móvil que se esté utilizando. Esta es la ventaja de mayor fuerza! Teóricamente si se hacen las cosas bien, se podría acceder a la misma aplicación desde un IPhone o un BlackBerry o un Android y seria transparente para el usuario final.
b) Relacionado con la ventaja anterior, no se deben mantener diferentes versiones de la aplicación para cada una de las plataformas posibles.
c) Relacionado una vez más, tampoco se necesita expertos en diferentes tecnologías de desarrollo; ya que básicamente se estaría programando en “WEB” con las tecnologías tradicionales solamente teniendo los cuidados necesarios de hacer interfaces más simples con tamaños más grandes para que sean visibles desde pantallas pequeñas.
d) No se requiere de actualizaciones a la aplicación cliente, ya que las actualizaciones se realizan sobre el servidor web y se reflejan automáticamente en todos los clientes (como en cualquier desarrollo web).
Así mismo, si el cliente no desea que “se note” que se está accediendo a una página web desde el dispositivo móvil y desea que parezca una aplicación “dentro del teléfono”, es posible desarrollar una cáscara que enmascare la aplicación web a la que se estaría accediendo dentro de un entorno de una aplicación cliente. Aunque claramente, esta cáscara por más simple que sea, deberá ser programada en cada una de las plataformas posibles (iOS, Android, WindowsPhone, etc.), mantenida y actualizada en caso de ser necesario. Pero probablemente la cáscara en sí no tendrá demasiadas actualizaciones con lo cual no necesariamente es un problema.
En cualquier caso, el gran TRADE OFF de optar por esta opción es que se requiere conectividad a internet de manera obligatoria para el uso de la aplicación.
Y, aunque las redes van avanzando paulatinamente, haciendo que exista cobertura en prácticamente cualquier lugar. Aún esto no es del todo garantizable; tanto sea porque no hay cobertura o porque la cobertura es de muy mala calidad haciendo que las velocidades de acceso sean inaceptables. Sobre todo en algunas zonas del interior de la Argentina.
Por lo tanto, si el factor conectividad es un factor determinante y no puede garantizarse; debemos caer en la segunda alternativa. Esta alternativa requiere que desarrollemos una aplicación CLIENTE para cada plataforma. La cual residirá en el dispositivo móvil y probablemente posea su propia “mini” base de datos. Las ventajas de esta alternativa:
a) No depende de si existe conectividad a internet o no.
b) Podemos hacer uso del hardware y del software del dispositivo móvil (la cámara, el gps, integrar nuestra aplicación con la agenda interna del teléfono, etc.). Este punto es especialmente importante y en algunos casos puede ser un factor decisivo para optar por esta alternativa.
c) La respuesta de la aplicación es probablemente más fluida que navegando una WEB (esto es bastante relativo).
Por otro lado, el gran TRADE OFF en este caso sería que se requiere mantener una versión de la aplicación para cada una de las plataformas en las que se desee que la aplicación esté disponible (iOS, Android, BlackBerry, WindowsPhone) y además, en algunos casos, en más de una versión (ejemplo en Android: gingerbread, ice cream sandwich, jelly bean, etc.). Además no olvidemos que esto implica contar con desarrolladores en cada una de estas plataformas.
Así mismo, si la aplicación necesita sincronizar información contra algún servidor central; efectivamente en algún momento se requerirá que exista una decente conectividad a internet para realizar dicha sincronización. Y esto implica necesariamente manejar alguna estrategia de sincronización con gestión de errores, inconsistencias e integridad de los datos. Este proceso puede llegar a convertirse en algo bastante complejo.
Por último, existe un caso emblemático de esta disyuntiva entre esta dos arquitecturas de aplicación que le paso a Facebook con su versión para móviles.
Les dejamos el link, por si les interesa revisarlo:
Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5
Entonces… cuál será la arquitectura de nuestra próxima aplicación mobile :)?
Comments are closed, but trackbacks and pingbacks are open.