No seré el mejor programador de móviles pero con todos estos años puedo estar seguro de lo que no hay que hacer.

Java, .Net, C++,  eso que Google dice que es Java, Objective C y otras pequeñas alternativas (Appforge el más notable) tienen la misma idea en común: Implementar las funciones absolutamente necesarias en el espacio más pequeño posible.

Lo primero que tienen que dominar es el diseño de pantallas con el  criterio “Menos es mas”. Dominar el espacio es el principal aspecto en el diseño de móviles. Seguidamente, tienen que dominar el manejo de los tamaños y formas de pantalla. Antes esto era sencillo, pero con la introducción de terminales de resolución mayor y con rotación de pantalla que debemos considerarlos desde el inicio. Cada vez es más dificil pero deberíamos considerar una versión totalmente dummy basada solamente en lógica de pantallas.

Seguidamente, tenemos que dominar los recursos locales. Controlar la cámara, el nivel de batería, crear archivos, bases de datos y todo eso. Tenemos que verificar el entorno en la que está corriendo nuestra aplicación para poder acomodar las funciones. Por ejemplo, si el dispositivo soporta rotación de pantalla, tenemos que diseñar como se acomodará la pantalla en cada rotación, o que si la batería está muy baja, alertar al usuario.

En el tema de los recursos locales, tenemos que recalcar un tema fundamental: Bases de datos. En su defecto podemos utilizar archivos de texto, pero si tenemos manejo de bases de datos, nos ahorraremos un montón de tiempo. Además, si elegimos correctamente, podemos incluso ahorrarnos mucho tiempo en un tema importante que se llama sincronización que veremos mas adelante. Siempre verifiquen este tema en la plataforma en la que están desarrollando para saber realmente que es lo que pueden y no pueden hacer.

La aplicación móvil el día de hoy es sinónimo de aplicación conectada, pero no es necesariamente correcto, pero si nuestra aplicación lo es, resaltará por sobre las demás. Si nuestra aplicación es para una empresa (Line of Business que le dicen), entonces esto es crítico. Para ir directo al grano, deben suponer que la red es de lo peor y que no es confiable, por lo que tienen que pensar en el concepto de transacciones. Incluso, algunas plataformas obligan a que todas las llamadas a la red sean asíncronas lo cual nos obliga a manejar Threads y esas cosas elegantes.  Lo que tienen que hacer es traducir lo siguiente al lenguaje que utilicen: Llamar a la red – Esperar una respuesta y controlar el timeout – Verificar la respuesta  – Ejecutar un procedimiento de control de errores. Todo esto de preferencia en un Thread separado al de la aplicación principal. Finalmente, lo que hay que pasar por el canal ya depende de lo que querramos hacer aunque sobresale el protocolo HTTP y webservices, con variantes ligeras como el JSON. Personalmente, prefiero lo crudo: POST y GET y listo. XML también sirve pero el XML Parser puede general algo de overhead. Lo mejor es que se tomen el tiempo de crear unas clases para manejar el xml de forma óptima y reutilizarlo en todas sus aplicaciones.

Y listo, con esto ya podemos empezar a diseñar la aplicación. Y para el diseño el criterio fundamental es cómo repartir la lógica y los datos. Si tenemos que poner una lista de opciones, tenemos que evaluar el costo y el trabajo que hay que hacer para implementarla basado en cuan frecuentemente hay que actualizar esta lista. Si la comunicación nos complica,  entonces nos conviene poner todo en una base de datos local y manejar la actualización mediante una actualización de versiones, pero si la lista se tiene que actualizar muy seguido, tal vez convenga hacer una llamada a un servidor en la red.

También deben tomar en cuenta las restricciones de memoria y de uso de recursos de cada plataforma. Por ejemplo, J2ME tiene restricciones en el tamaño de la base de datos, BADA pone un límite a la cantidad de tablas y en la cantidad de llamadas a conexiones de datos por la red, iPhone no te deja controlar ciertos recursos locales como prender o apagar el Bluetooth.

Una  nota importante es la sincronización. Tener la data correcta en el móvil puede ser una tarea bastante complicada así que tenemos que investigar que opciones tenemos en cada plataforma.

Finalmente, un pedido sincero: enfoquen su aplicación alrededor de una sola función principal. Alrededor pondremos funciones complementarias que nunca lleguen al nivel de complejidad de la primera. Ciertamente que si tenemos que hacer una aplicación empresarial nos van a pedir que pongamos todo el ERP en un móvil, pero a lo que me refiero es a las iteraciones en la aplicación, iteración 1 con la función ancla 1 y para la iteración 2 recién pensaremos en incluir otra función grande. El diseño tiene que considerar todas las funciones desde el principio, pero la implementación debe ser por etapas, porque por mas empresarial que seamos, nunca se utilizarán por completo todas las funciones.

Para terminar, aquí unas ideas para que las apliquen : Objetos, MVC y Agile. Estos tres combinados les permitira no repetir trabajo de programación y evitar los errores siempre teniendo en cuenta que no podemos recargar a la aplicación con un diseño super complejo.




    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s



%d bloggers like this: