Definitivamente las aplicaciones móviles tienen toda la atención de las empresas ya que el no tener presencia móvil en estos tiempos es como no tener sitio web hace 10 años. Este disrruptor tecnológico ha hecho que los departamentos de TI de las empresas se enfrenten a escenarios a los cuales no están acostumbrados y por lo tanto quedan expuestos a el “conocimiento” de terceros que se presentan como conocedores del mundo móvil y muchas veces no es así.
En este nuevo mundo móvil y por la ya mencionada falta de experiencia de las empresas se cometen muchos errores que pasan desapercibidos por muchos y por mucho tiempo; entre estos errores podemos mencionar los siguientes:
-
Diseñamos las aplicaciones móviles como si fueran aplicaciones Web: como estamos tan acostumbrados al mundo web, llevamos los mismos conceptos a los dispositivos móviles, lo cual en la mayoría de los casos es un groso error porque a nivel móvil no se tiene el mismo poder computacional, la misma energía disponible e incluso la misma cantidad de ancho de banda. Igualmente los usuarios no se comportan de la misma manera cuando utiliza un aplicativo móvil y un aplicativo web.
-
Creamos las aplicaciones sin pensar en el impacto que tendrán en el dispositivo donde van a correr: Esto es provocado porque seguimos usando las tecnologías que hemos usado siempre para hacer cosas diferentes. Un ejemplo típico de esta situación es el uso de servicios web SOAP para su consumo desde los aplicativos móviles; esto porque el servicio SOAP utiliza XML para representar todo el mensaje que se envía de ida y vuelta y como ya lo hemos mencionado en este blog, el procesamiento del XML requiere mucho poder computación, por lo tanto mucha energía lo que conlleva a que la batería de los celulares se drene rápidamente lo que conlleva a que el usuario final no use mas la aplicación.
-
Tiempos de espera elevado entre transacciones: Como normalmente hacemos transacciones para aplicaciones web, en donde un usuario puede esperar hasta un minuto en frente de la computadora para que su transacción se lleve a cabo, procedemos a crear la transaccionabilidad de la misma forma en las aplicaciones móviles. Sin embargo a nivel móvil las transacciones deben de ser mas rápidas y con información mas condensada – cada bit que se transporta importa.
-
Agregamos la misma funcionalidad del sitio web a la aplicación móvil: Este es otro error grave, ya que las aplicaciones móviles no deben tener funcionalidades que no aplican bien o que no se resuelven bien en la plataforma, – ejemplo los filtros de lista en línea – ya que en una pantalla tan pequeña normalmente no se logra comprender fácilmente la funcionalidad y los usuarios terminan descartándola. Además, el consumo de recursos intensos – consultas vía web por letra digitada por ejemplo –, terminan dando la impresión de que la aplicación no es de calidad, cuando en realidad son aspectos externos los que terminan dando esa idea.
-
Aplicaciones transaccionales móviles web: Este quizás sea uno de los temas más complicados de tratar en lo que se refiere al desarrollo móvil. Las empresas con tal de tener presencia móvil, terminan haciendo sitios web que permitan hacer transacciones vía el dispositivo móvil. Aunque desde un punto de vista informativo las aplicaciones web móviles funcionan de maravilla, desde un punto de vista transaccional pueden ser muy problemáticas. Esto porque las aplicaciones móviles pueden salirse de una transacción por razones mínimas ( entrada de un msm, una llamada, un mensaje de facebook, etc ) y con eso el manejo de la cancelación de la transacción se vuelve muy truculenta. Igualmente la confianza del usuario no es la misma si usa una aplicación nativa a una aplicación web porque básicamente trae miedos (muchas veces con toda razón) de los peligros de las transacciones vía web.
-
Uso de bases de datos en los dispositivos: Por increíble que parezca esta idea (ahora solo falta alguien pidiendo un servidor web en el móvil) hay aplicaciones que para funcionar necesitan una base de datos local. Las bases de datos no son para usarse en dispositivos móviles ya que consumen recursos necesarios para el dispositivo, agrega necesidad de trabajo en “background” por lo que el consumo de batería es constante, además la seguridad de los datos pasa a otro nivel porque un usuario podría perder su dispositivo y por lo tanto sus datos en donde podrían existir transacciones importantes como movimientos financieros que están en cola esperando por una conexión para llevarse a cabo.
-
Funcionalidad de la aplicación móvil – agregar valor al usuario de la aplicación: Definitivamente el objetivo de tener una aplicación móvil no es solo presencia en alguna plataforma, si no también dar valor agregado al usuario de la misma. Nadie va a consultar las noticias de una empresa mas de una vez y en la empresa seguramente tampoco las van a actualizar de forma seguida. Es importante que el usuario encuentre de valor la aplicación y le permita llevar a cabo acciones que le mejoran la percepción hacia la empresa. Tener una aplicación por tenerla, no tiene sentido ya que requiere tiempo y dinero para desarrollarla y al final en lugar de dar una buena imagen, haremos que nuestros clientes piensen que todos los servicios que oferta la empresa son de esa calidad.
Dado este escenario tan apocalíptico, cual es la perspectiva mas adecuada para desarrollar las aplicaciones móviles? En realidad existen muchas formas de desarrollar aplicaciones móviles útiles para el usuario final. Entre las cosas que podemos mencionar que hay que tener en cuenta a la hora de hacer estos desarrollos podemos enumerar algunas importantes:
-
La aplicación tiene que ser diseñada con la funcionalidad móvil necesaria para que el cliente aprecie el valor de la misma. Debe de ser fácil de administrar y actualizar por parte de la empresa desarrolladora y debe de causar un impacto positivo en el cliente. Por ejemplo, si la aplicación es para teléfonos, NO DEBEMOS usar GRIDS.
-
Utilizar JSON como esquema para serializar datos que viajan a través de servicios: JSON es mas simple de parsear y requiere menos poder computacional que XML, si utilizamos JSON para representar nuestros datos vamos a tener mejor desempeño a la hora de consumir servicios desde un dispositivo móvil.
-
Las transacciones deben de ser expeditas; es decir los servicios que se consumen deben de llevar a cabo solo una tarea y retornar la información solicitada, con esto nos garantizamos que el tiempo de respuesta sea el optimo. Además la cantidad de datos a retornar debe de estar pre filtrada, por ejemplo nunca deberíamos presentar en un dispositivo móvil todas las transacciones del cliente en la pantalla principal de la aplicación.
-
La aplicación debe de integrarse con el middleware de la empresa para que su funcionalidad aporte valor al usuario. Por ejemplo, en una aplicación móvil podría ver mis transacciones bancarias del ultimo mes, y ver por solicitud los meses anteriores; o también podría ver todas las solicitudes de servicio al cliente que tiene y el estado de cada una – de nuevo en cantidades manejables.
-
Los servicios que consume la aplicación móvil son los mismos servicios que consumen otras aplicaciones tales como el sitio web, lo que garantiza uniformidad en los procesos que se mandan a ejecutar. Esto quiere decir que seguramente vamos a tener que agregar endpoints REST para soportar JSON en el servicio.
-
Minimizar el uso de base de datos: No es que no necesitemos en alguna momento una base de datos en nuestra aplicación móvil, pero sin duda el aplicativo debe de estar en línea siempre que sea posible; sin embargo, cuando se requiere que pueda llevar ciertas tareas estando offline, debemos buscar métodos alternativos para guardar estas transacciones que se deberán sincronizar luego con el repositorio central. Además, no toda la funcionalidad debería estar disponible online solo la realmente es necesaria; por ejemplo, las consultas no deberían estar disponibles offline, pero transacciones que se pueden ejecutar después contra el repositorio centralizado si podrían guardarse en el dispositivo para ejecutarlas cuando haya conexión.
-
Preferiblemente codificar la aplicación en la plataforma de desarrollo nativa, esto principalmente porque las aplicaciones nativas tienen mejor desempeño que las aplicaciones web o las aplicaciones que se convierten en nativas a partir de algún framework de desarrollo móvil como phonegap o Sencha Touch; esto principalmente porque aunque estos frameworks generan código nativo, las instrucciones generadas no siempre son las optimas.
Azure Mobile Services
Entre las opciones existentes quizás la mas simple para iniciar con el desarrollo móvil conectado a la capa media de la empresa esta la de Azure Mobile Services. Esta plataforma nos permite enfocarnos en el trabajo de la aplicación en si, y nos permite olvidarnos de todo lo requerido para manejar la conectividad de la aplicación con nuestros centros de datos o procesos de negocio ya existentes. Lo que hace el Azure Mobile service es generar un proxy en la nube que recibe solicitudes de la aplicación móvil y las redirecciona a donde nosotros le indiquemos, en primera instancia a una base de datos en Azure pero lo ideal para integrarlo con nuestro data center es direccionar al Azure Service Bus el cual a través de sus diferentes mecanismos interconecta la aplicación móvil con nuestros procesos de negocio que residen “on premises”.
Plataformas soportadas
Azure mobile services nos permite generar proyectos en las plataformas móviles mas populares, las cuales son al día de hoy Android, iOS, Windows Phone, Xamarin, Windows Store y HTML 5 + js para abarcar las demás opciones existentes. en realidad el proxy se genera para todas las plataformas y los desarrolladores eligen sobre cual quieren trabajar.
En nuestro próximo post veremos como iniciar el desarrollo móvil utilizando Azure Mobile Services.
