Métodos para el desarrollo de aplicaciones móviles

• Derivación selectiva. Las modificaciones necesarias están localizadas en unos elementos concretos (ya sean clases del código, ficheros de marcado, estilos u otros recursos), y existe un sistema o herramienta que genera las diferentes versiones mediante la captura y el empaquetado de estos elementos para cada escenario.

• Derivación usando meta programación. Se trata de programar algo que se va a ejecutar en varios escenarios. Para conseguir distintos comportamientos hay varias opciones:

  • Mediante la inyección de objetos o recursos (imágenes, ficheros XMLS, etc.) en el código, de manera que nuestra aplicación deje estos objetos vacíos y se rellenen, en tiempo de ejecución, los objetos específicos de cada escenario. Esta estrategia se baja en el patrón de diseño Inversion of control.

  • Utilizando preprocesadores, que se encargan de cambiar o ampliar nuestro código para adaptarlo a los diferentes escenarios antes de ejecutar.

• Generación automática. El software se debe escribir de una manera específica y solo una vez. A posteriori, existe un proceso que genera automáticamente las aplicaciones correctas para cada escenario, normalmente transformando nuestra aplicación al código particular de cada escenario. En este punto existen más variantes.

• Mínimo común denominador. Se trata de conseguir una aplicación mediante la reducción de los puntos de fragmentación, de manera que no exista la necesidad de adaptar la aplicación.

• GPS, para conocer la posición geográfica y saber qué se debe mostrar.

• Brújula, para saber la orientación actual

• Acelerómetro, para saber cuál es la orientación exacta de nuestro dispositivo y superponer las capas.

• Cámara, para poder captar nuestro alrededor y así ampliar la información (en ocasiones, incluso, varias cámaras).

• Conexión a Internet, para poder obtener la información para ampliar nuestra realidad. Esta conectividad puede venir mediante Internet móvil o WiFi, entre otros.

• Capacidad de procesamiento gráfico muy mejorada, con chips de aceleración gráfica potentes.

• El dispositivo móvil es el primer medio de comunicación masivo real, dado que es capaz de llegar a casi todos los usuarios y en todo momento.

• El primer medio de comunicación permanentemente encendido, pues es capaz de captar y enviar información aun cuando está apagado (apagado en el sentido del usuario, es decir, cerrado, pero no totalmente apagado).

• Primer medio que está siempre con el usuario.

• Medio masivo que tiene incorporado un sistema de pago, que en este caso es mediante la operadora.

• Acceso a Internet mediante redes WiFi o MWWAN.

• Proximidad de otros dispositivos para compartir información.

• Estar constantemente conectado a las redes sociales, lo que requiere que dispongamos de cuentas en esas redes sociales y que tengamos activado el acceso (con los posibles problemas de privacidad).

• Conexiones a otras redes inalámbricas, Bluetooth, GPS, NFC, etc.

• Grandes capacidades de proceso en nuestros teléfonos para realizar las acciones, ya sea la capacidad de proceso interno o bien mediante accesorios.

• Debido a innovaciones y cambios, tenemos que pagar el coste de actualizar nuestra aplicación. Es decir, durante o después del lanzamiento de nuestra aplicación, pueden aparecer nuevas fuentes de fragmentación hardware o software que provoquen que nuestra aplicación se tenga que actualizar. Esto sucede en todos los desarrollos, pero especialmente en el desarrollo de aplicaciones para dispositivos móviles, debido a la gran velocidad del cambio en este sector.

• Limitación de la vida de las baterías. Esto significa que, al utilizar muchas de estas capacidades (por ejemplo, el GPS), hacemos que nuestro terminal pierda autonomía, pues se necesita destinar energía a estos periféricos, y lo mismo sucede con el resto de capacidades. En la materia que nos incumbe, el desarrollo de aplicaciones, tenemos que tener esto muy presente a la hora de diseñar y escribir nuestras aplicaciones, ya que puede afectar mucho a su rendimiento.

• Vulneración de la privacidad. Nuestros dispositivos móviles contienen cada vez más información personal y confidencial, y requieren acceso a esta información para poder sacarle el mayor partido y conseguir integrarse en el contexto. Por eso, siempre que realicéis una aplicación que requiera acceso a información o acceda a datos de otras fuentes (como las redes sociales), debéis tener el permiso explícito del usuario, y este se debe poder revocar.

• Necesidades de hardware. Por ejemplo, la necesidad de mayor velocidad de transmisión. Si nos encontramos en una zona con poca cobertura para nuestra red de transmisión de datos, puede ocurrir que nuestras aplicaciones no funcionen correctamente.

• Necesidades de inversión no previstas debido a novedades del mercado. Si aparece una fuente de fragmentación nueva (por ejemplo, un nuevo dispositivo), debemos invertir en dar soporte a ese nuevo dispositivo. Esta inversión puede suponer no tener que hacer nada o realizar un desarrollo nuevo.

• simplicidad

• facilidad de venta

• gran cantidad de usuarios potenciales

• poca o casi nula capacidad de procesamiento del contexto

• muy baja complejidad de las aplicaciones realizadas

• limitaciones impuestas por la tecnología sobre los diseños de las aplicaciones (ciento sesenta caracteres de texto)

Ejemplo de aplicación básica

Una ejemplo de aplicación es una aplicación para conocer cuál es el tiempo de llegada de un autobús (se envía un SMS a un número concreto y se recibe una respuesta).

• Fácil implementación, testeo y actualización. Incluso se puede realizar gran parte del desarrollo sin necesidad de utilizar dispositivos móviles ni emuladores, hasta llegar a las fases finales del desarrollo.

• Lenguaje conocido y estándar. Los lenguajes de marcas son muy conocidos hoy en día por la mayoría de los desarrolladores, y en la mayoría de los casos se trata de subconjuntos de lenguajes conocidos.

• Pueden soportar múltiples dispositivos con un único código fuente. Para soportar fragmentación entre dispositivos, es necesario utilizar técnicas especiales (como el WURLF).

• Es difícil soportar múltiples dispositivos, así como conseguir la misma experiencia de usuario con varios tipos de navegadores.

• Ofrecen grandes limitaciones a la hora de realizar programas, tanto de proceso como de acceso a la información del dispositivo y del usuario. Por tanto, es difícil conseguir aplicaciones contextualizadas.

• En muchos casos está pensado para ser visualizado con conexiones lentas, pero dichas conexiones pueden ser demasiado lentas y provocar una experiencia de usuario deficiente.

• En la actualidad, la mayoría de los dispositivos nuevos están incorporando estándares más nuevos (como HTML 5), por lo que no se está trabajando en mejorar estos estándares.

• El número de dispositivos que solo pueden ver una página web con este tipo de lenguajes de marcas está disminuyendo.

Ejemplos de web móviles

Cualquier web pública con información para el contribuyente es un buen ejemplo de web móvil. Por ejemplo, http://wap.bcn.cat.

• Posibilidad de acceso a mucha información del dispositivo para realizar aplicaciones relativamente complejas.

• Desarrollo, distribución y pruebas sencillas.

• Convergencia entre aplicaciones de sobremesa y de dispositivos móviles, lo cual tiene muchas implicaciones, como, por ejemplo, que los desarrolladores solo tienen que conocer una tecnología.

• Uso de estándares de la web (claramente definidos).

• Ampliamente soportado por la industria, de manera que la mayoría de los nuevos dispositivos tienen soporte para este tipo de aplicaciones.

• Se necesita un navegador que pueda dar soporte a este tipo de tecnología. Aunque la mayoría de los nuevos dispositivos lo pueden dar, los antiguos no.

• Su rendimiento es menor con respecto a las aplicaciones nativas, pues se ejecuta todo mediante el Javascript del navegador, cuya potencia es limitada.

• Imposibilidad de acceder a todas las posibilidades del dispositivo. No se puede acceder al hardware ni a muchos periféricos (como sensores o cámaras). No se puede acceder a mucha de la información del usuario (contactos, sus citas, etc.).

Ejemplo de aplicación móvil

Actualmente existen muchos ejemplos de aplicaciones web realizadas para ser ejecutadas en sobremesa, que han sido rápidamente portadas a los dispositivos móviles, como son mobile.twitter.com, facebook.com, maps.google.com, etc.

• Todos los puntos a favor de las aplicaciones web móviles.

• Se pueden considerar, en lo que respecta a la instalación y la distribución, como aplicaciones nativas.

• La mayoría de los inconvenientes de las aplicaciones web móviles, a excepción de la instalación en el cliente.

• La experiencia del usuario es, en ocasiones, contradictoria, pues a pesar de tratarse de una aplicación nativa, requiere de conexión a Internet para poder trabajar y funciona según los tiempos de respuesta del navegador.

Ejemplo de aplicaciones móviles nativas

Aplicaciones de acceso a información confidencial, como son las entidades financieras "en línea", que distribuyen la aplicación, pero por su naturaleza no es recomendable que haya datos en el dispositivo físico.

• Acceso total al contexto, con todas las posibilidades que eso conlleva. Consigue las mejores experiencias de usuario.

• Posibilidad de gestión de interrupciones en la aplicación o en las capacidades del dispositivo. Desde saber si tenemos conexión de datos o conexión de localización hasta tener información sobre la batería.

• Son relativamente fáciles de desarrollar si solo se contempla una plataforma.

• Se pueden distribuir por los canales conocidos de aplicaciones que permita la plataforma, con lo que se pueden vender más fácilmente.

• Todas las novedades llegan primero a este tipo de aplicaciones, pues es en este tipo de aplicaciones donde se prueban.

• Portar aplicaciones es costoso. En el caso de querer realizar una aplicación para más de una plataforma, se complica el desarrollo, debido a los problemas de la fragmentación.

• Dependiendo de la plataforma elegida, puede haber fragmentación dentro de cada plataforma, debido a los diferentes tipos de dispositivos o versiones de la plataforma.

• No existe un estándar, por lo que cada plataforma ofrecerá sus peculiaridades.

• Normalmente, para desarrollar, distribuir o probar estas aplicaciones en dispositivos reales, es necesario tener una licencia de pago, dependiendo de la plataforma.

• Las ganancias por estas aplicaciones suelen repartirse entre el creador de la aplicación y la plataforma de distribución.

Ejemplos de aplicaciones nativas

Algunos ejemplos de aplicaciones nativas son los siguientes:

• Aplicaciones para la gestión de la agenda o para encontrar amigos de la agenda con su posición geográfica.

• Alarmas, aplicaciones correo electrónico, etc.

• Aplicaciones sociales, como las aplicaciones de las redes sociales y otras aplicaciones que permiten utilizar el acceso a estas aplicaciones, como los agregadores de redes sociales.

Las siguientes imágenes representan aplicaciones nativas que aprovechan las funcionalidades del dispositivo, como, por ejemplo, aplicaciones de realidad aumentada o juegos.

public class HelloWorld extends HttpServlet {
  ...
  protected void processRequest(
     HttpServletRequest request,
     HttpServletResponse response)
     throws ServletException, IOException {
     
        WURFLHolder wurflHolder = (WURFLHolder) getServletContext()
                    .getAttribute("net.sourceforge.wurfl.core.WURFLHolder");
                                   
        WURFLManager wurfl = wurflHolder.getWURFLManager();
        
        Device device = wurfl.getDeviceForRequest(request);
        
        MarkUp markUp = device.getMarkUp();
        request.setAttribute("markUp", markUp);
        request.setAttribute("device", device);
     ...
  }
}

• Pérdida de controles específicos de una plataforma: Si tenemos un control de la UI o una funcionalidad concreta que solo existe en una plataforma, no podremos generar de manera única, por nuestro desarrollo multiplataforma.

• Integración en el escritorio del dispositivo: Según la plataforma, las posibilidades de añadir elementos en el escritorio de cada usuario varían. Por ejemplo, en Android o Symbian se pueden crear widgets potentes para mejorar la el uso de nuestra aplicación, mientras que en Windows Phone solo es posible añadir iconos de la misma.

• Gestión de la multitarea: Debido a que se trata de conceptos de bajo nivel de cada plataforma, cada una la trata de manera diferente, con restricciones diferentes, por lo que no será fácil hacer código común para todas sin perder mucha potencia.

• Consumo de la batería: Estas aproximaciones requieren de una capa de abstracción sobre nuestro dispositivo, que provoca problemas como la multitarea. De la misma forma, el control sobre el consumo de batería se hace más difícil cuando no se tienen las capacidades concretas de la plataforma. También afecta el hecho de no tener el control sobre la multitarea, ya que esta es una de las maneras de ahorrar las baterías.

• Servicios de mensajería asíncrona o push services: Sirven para implementar elementos como la mensajería instantánea, pero debido a que cada plataforma los implementa de una manera, se hace complicado atacarlos conjuntamente.

• PhoneGap: Son aplicaciones realizadas en HTML 5 con objetos Javascript que permiten el acceso, mediante enlaces, a las funciones nativas para las capacidades que HTML 5 no ofrece. Las aplicaciones se ejecutan sobre un componente que contiene un navegador.

• Rhodes: Son aplicaciones escritas en Ruby que utilizan el patrón de diseño MVC ⁽⁷⁾ y que se ejecutan en máquinas virtuales específicas de Ruby para cada plataforma. Por tanto, son aplicaciones nativas. Incluyen sistemas para sincronizar datos de manera sencilla y conseguir, de esa manera, el cambio de "en línea" a "fuera de línea" sin mucho coste.

• Appcelerator: Son aplicaciones escritas en HTML 5 que son compiladas en aplicaciones nativas. También son capaces de generar aplicaciones de sobremesa clásicas, ejecutables sobre Mac, Linux o Windows.

• Wacapps: Son aplicaciones escritas en HTML 5 con soporte para la distribución por parte de las operadoras.

• Flash: Son aplicaciones que corren sobre un player propietario. Si existe el player correspondiente, no necesitan ser portadas. Se escriben de igual manera que las aplicaciones de sobremesa y tienen las mismas restricciones.

• Java ME: Son aplicaciones escritas en Java, con todas las peculiaridades de los perfiles J2ME, y se ejecutan mediante una máquina virtual, con sus correspondientes restricciones. Actualmente están en casi el ochenta por ciento de los dispositivos móviles del mercado.

• Unity3D: Entorno para desarrollar juegos nativos o web para cada plataforma, como Play Station, Wii, PC, Mac, etc. También da soporte para las Android e Iphone.

• Solo una línea de desarrollo para varias plataformas.

• Aplicaciones que podemos instalar en nuestros dispositivos, que tienen la posibilidad de ser distribuidas en los mercados de aplicaciones.

• Dependiendo del caso, el resultado son aplicaciones nativas que aprovechan en gran medida el potencial del dispositivo y ofrecen un diseño y experiencia de usuario idéntica a las aplicaciones desarrolladas sólo para una plataforma.

• En diferentes grados, tienen acceso parcial a los recursos del dispositivo. Esto significa que, según el grado, no pueden interaccionar con algunas capacidades y, en mayor o menor medida, serán aplicaciones menos eficientes que las aplicaciones nativas.

• Para poder soportar varios dispositivos, suelen tener que hacer el mínimo común denominador de las capacidades. Así, si una plataforma aporta una nueva funcionalidad (por ejemplo, un sistema de comunicación que el resto no tenga), no se podrá implementar sin añadir código específico.

• Soporte parcial. No tienen soporte absoluto para todas las plataformas y versiones.

• Las nuevas funcionalidades tardan en ser soportadas. Dado que las novedades en las plataformas aparecen en un ritmo muy elevado y en cortos periodos de tiempo, si se utilizan estos entornos para el desarrollo, es necesario esperar un tiempo para poder utilizar dichas herramientas. En el mejor de los casos, si se trata de código libre o ampliable, podemos realizar una implementación para tener acceso a esa funcionalidad.

• Se requiere pagar la licencia, si la tiene, para el entorno de desarrollo, además de la licencia propia de cada plataforma para poder distribuir la aplicación.

• Alta volatilidad del entorno: Con cambios en entornos de desarrollo, nuevos terminales y nuevas tecnologías a un ritmo mucho más elevado que en otros entornos de desarrollo.

• Equipos de desarrollo pequeños: Dado que los desarrollos móviles suelen ser proyectos relativamente pequeños, los equipos no suelen ser muy grandes. Generalmente son llevados a cabo por desarrolladores individuales o por PYME.

• Software no crítico: No suelen ser aplicaciones de alto nivel de criticidad, dado que suelen ser aplicaciones para entretenimiento o gestión empresarial no crítica.

• Ciclos de desarrollo cortos: Dada la evolución constante de la industria, se requieren ciclos de vida realmente cortos para poder dar salida a las aplicaciones a tiempo.

• Exploración. Se dedica a la planificación y a los conceptos básicos del proyecto. Es diferente del resto de fases.

• Inicialización. Se preparan e identifican todos los recursos necesarios. Se establece el entorno técnico.

• Productización o fase de producto. Se repiten iterativamente las subfases, con un día de planificación, uno de trabajo y uno de entrega. Aquí se intentan utilizar técnicas como la del test driven development para conseguir la mayor calidad.

• Fase de estabilización. Se llevan a cabo las acciones de integración para asegurar que el sistema completo funciona correctamente.

• Fase de pruebas y reparación. Tiene como meta la disponibilidad de una versión estable y plenamente funcional del sistema según los requisitos del cliente.

• Dificultades por el desconocimiento de la tecnología. Suele tratarse de tecnologías nuevas, en ocasiones desconocidas para los desarrolladores. Eso repercute en el tiempo de aprendizaje y puede ocasionar desviaciones por contratiempos no conocidos

• Disponer de dispositivos reales. Para poder realizar un buen proyecto de desarrollo de aplicaciones móviles, es necesario poder probarlo en dispositivos reales. Para ello, se debe planificar una fase de pruebas reales.

• Time to market. A la hora de planificar hay que tener muy en cuenta el que suele tardar una idea en llegar al mercado e intentar reducirlo al máximo, pues la competencia es muy grande.

• Prototipado. Es importante planificar cuando se va a conseguir el primer prototipo (y, tal vez, la primera salida en beta), pues el prototipado rápido puede ser muy útil para este tipo de aplicaciones.

• ¿Quien va a ser nuestro usuario? ¿En qué momento va a utilizar nuestra aplicación?

• ¿Qué requerimientos mínimos de hardware son necesarios?

• ¿Necesitamos gestionar el modo "en línea" y "fuera de línea"?

• ¿Deben existir datos de terceros? (desde un mapa, hasta datos del propio dispositivo).

• Model-View-Controler (MVC). Se utiliza para poder separar al máximo la lógica de la visualización e interacción, y así poder dar soporte a más escenarios, como puede ser el caso de una aplicación para smartphone y la misma para tablet PC.

• Threading. Se refiere al uso de hilos en segundo plano para realizar tareas largas que bloqueen al usuario.

• Delegation. Se trata de delegar una parte del trabajo hacia otro objeto sin que este tenga que ser una subclase del primero. En el caso de los desarrollos móviles, es muy útil para delegar trabajos relacionados con la interfaz, de manera que pueda trabajar con eventos de manera muy sencilla y sostenible.

• Modelo de memoria gestionada. En general, las aplicaciones no se ejecutan directamente sobre la plataforma, sino que suele haber una capa intermedia o middleware, y esta suele gestionar la memoria. Sin embargo, para poder hacerlo de manera eficiente, es necesario realizar algunas acciones o convenciones.

• Usabilidad. La usabilidad de la aplicación se debe tener muy en cuenta (debemos tener presente que la mayoría de usuarios no tendrán tiempo ni ganas de leer los manuales). Una buena práctica para mejorar la usabilidad es adaptar las aplicaciones a los comportamientos estándares de la plataforma, de manera que el usuario pueda aprovechar reglas mnemotécnicas o hábitos adquiridos.

• Responsividad. La aplicación debe responder a las acciones de usuario lo mejor posible y de manera ágil. Es un punto muy importante pues el usuario de dispositivos móviles suele ser más exigente que el de aplicaciones tradicionales en situaciones parecidas. Algunas plataformas, como Android, son muy estrictas a la hora conseguir que la aplicación sea suficientemente responsiva. Si la aplicación no es suficientemente ágil a la hora de responder al usuario, el sistema debe avisarle de esta circunstancia y permitir que la cierre inmediatamente.

• Optimización de recursos. Los dispositivos móviles, incluso los actuales, cuentan con unos recursos mucho más reducidos que las aplicaciones de sobremesa o las páginas web. Esto quiere decir que tenemos que hacer un buen uso de la memoria y del procesador del dispositivo, por lo que es conveniente cerrar los recursos que no se necesiten para evitar los problemas asociados.

  También es importante prestar mucha atención al consumo de batería de la aplicación. Por ello, es recomendable evitar cálculos excesivos (como los cálculos de coma flotante), el uso de las funciones de vibración o el uso de las conexiones inalámbricas. Cada una de estas recomendaciones se debe adaptar a la plataforma específica donde trabajamos, pues los fabricantes nos darán las recomendaciones concretas.

  Otra buena práctica, en este sentido, es perfilar la aplicación con las herramientas propias de la plataforma para encontrar problemas.

• Accesibilidad de la aplicación. Debemos tener en cuenta al diseñar la aplicación que los usuarios pueden necesitar acceder a ella de diferentes maneras. Por ejemplo, si tenemos una aplicación con formularios, es ideal que sea accesible tanto a través de las pantallas táctiles como de los trackballs.

Ejemplo de aplicación de tipo pay-in

• Registrarnos y, generalmente, pagar para conseguir una cuenta de desarrollador que nos acredite como responsables de las aplicaciones.

• Subir la aplicación a la tienda a través de su zona de desarrollador.

• Superar el proceso de aprobación, lo que puede tardar días o semanas. En todas las tiendas es posible que nuestra aplicación sea eliminada en caso de causar problemas o bien de incumplir alguna de las normas de dicha tienda.

Ejemplo de opiniones sobre las aplicaciones