Uso, limitaciones y coste de aplicaciones Android

Uso de la aplicación en un dispositivo real

Terminado el desarrollo en entorno de pruebas, tarde o temprano, nuestra aplicación debe ejecutarse en un dispositivo real. Para realizar esto es necesario conectar el dispositivo Android al ordenador mediante un cable a un puerto USB.
Para confirmar que estamos utilizando la configuración de depuración adecuada se siguen estos pasos:

• En Eclipse, desde la perspectiva Java (es decir, no DDMS), se elige Run/Debug Configurations (Ejecutar/Configuraciones de depuración).
• Se hace doble clic en la configuración de depuración que se ha creado para esta aplicación (por ejemplo, Test1Debug).
• En la ficha Target se cambia el modo de Automatic a Manual (normalmente, conviene el uso Automatic).
• Se confirman los cambios con el botón Apply.
• Se conecta un único dispositivo Android en un puerto USB mediante el cable correspondiente.
• Se hace clic en el botón Debug y aparecerá un cuadro de diálogo que nos permite elegir el dispositivo que se utilizará en la depuración (tendrá que aparecer en la lista el dispositivo que acabamos de conectar al puerto USB; si no aparece se debe verificar la conexión y si se han instalado los controladores).
• Se elige el dispositivo y se hace clic en el botón OK.
• Eclipse instala la aplicación en el dispositivo, le asocia el depurador y ejecuta la aplicación.

El dispositivo debería comportarse de modo similar a las pruebas realizadas con el emulador. También podemos utilizar las funciones de la perspectiva DDMS para depurar la aplicación en el dispositivo.

Limitaciones en el desarrollo de aplicaciones móviles

El desarrollo de aplicaciones móviles tiene mucho en común con el desarrollo de aplicaciones de escritorio y esto facilita el aprendizaje para quienes han tenido experiencia en el entorno PC. No obstante el entorno móvil nos impone un cambio drástico en el modo en que se diseña debido a las restricciones que nos impone el hardware.
Cuando diseñamos una aplicación debemos pensar que si nuestra aplicación tiene éxito se instalará en una amplia gama de dispositivos móviles, algunos de alta gama y otros no tanto. Lo importante es que nuestra aplicación esté bien diseñada y eso significa que hace un uso adecuado de todos los recursos, que los libera cuando ya no son necesarios y que no consume más de lo imprescindible. Si logramos que nuestra aplicación tenga un buen rendimiento en un dispositivo de baja gama lo hará aún mejor en uno de alta gama sin que modifiquemos nada.

Aquí hablamos específicamente sobre aplicaciones móviles Android y no de aplicaciones Android en general porque Android puede ser el sistema operativo en dispositivos como tabletas que no tienen las mismas restricciones dado que se parecen mucho más a los portátiles.

Es evidente que se intenta llevar a los dispositivos móviles todas las funcionalidades que se han logrado implementar en los ordenadores normales y portátiles pero mientras que hay funcionalidades que se han transportado sin problemas existen otras que chocan con ciertas restricciones. 
Si se comparan las capacidades de un dispositivo móvil con las de un ordenador portátil podemos notar que:

• Las pantallas son más pequeñas.
• Las pantallas tienen menor resolución.
• Los procesadores son menos potentes.
• La memoria RAM está más limitada.
• La tasa de transferencia de datos es menor.
• Las conexiones de datos suelen ser menos estables.
• El coste de la transferencia de datos es más alto.

En cada nueva generación de móviles la distancia con los portátiles se van estrechando aunque hay cosas que no tienen fácil solución, por ejemplo: el tamaño de la pantalla. A diferencia a lo que ocurre en la evolución de los ordenadores de escritorio en los que la potencia se mejora con mayores procesadores y mejor ventilación y donde el espacio físico no es un problema pero no esperemos que en el corto plazo los fabricantes de móviles le den prioridad a las mejoras en los procesadores, dado que en un móvil lo que se busca en primer término es menor tamaño, menor peso, más duración de la batería y mejor resolución de la pantalla.  Y esto ¿qué traducción tiene para los desarrolladores?: debemos minimizar y optimizar el uso del procesador para que nuestro código se ejecute rápido y nuestra aplicación responda lo antes posible ya que no podemos esperar que la llegada de un procesador más potente sea la solución de una aplicación mal diseñada.  La eficiencia del código es importante siempre, incluso en entornos donde el procesador no es el cuello de botella, pero en los entornos móviles no sólo es importante sino que es imprescindible.

El tamaño pequeño de un dispositivo móvil es uno de los factores más valorados por los usuarios y por ese motivo mientras no haya evolución tecnológica los fabricantes se encuentran con el problema que si colocasen procesadores y baterías más potentes el tamaño y el peso del dispositivo llegaría a límites que los usuarios no aceptarían.

Coste de usar nuestra aplicación

Cuando diseñamos una aplicación móvil nuestra intención es que tenga éxito porque eso significa más usuarios y en definitiva nuestro éxito profesional. Es evidente que los desarrolladores no tenemos que pagar las facturas de los usuarios y a veces nos olvidamos que el entorno móvil trae aparejado costes adicionales por conexión, variables según los proveedores y los países, pero en todo caso siempre existentes. 
¿Adónde se quiere llegar? Que si bien un factor importante del éxito de nuestra aplicación es la funcionalidad que entrega al usuario pero también existe el factor de coste de uso que puede hacer que nuestra aplicación sea rápidamente descartada.
No hace falta decir que todo coste asociado a la funcionalidad de nuestra aplicación debe estar totalmente justificado y optimizado para que sea el mínimo posible. Si finalmente utilizamos una función que puede provocar un cargo adicional al usuario deberíamos, en primer término, advertirlo y, en segundo término, permitir su activación/desactivación mediante una configuración correcta. Por ejemplo, quizá nuestra aplicación envía un SMS ante una determinada situación y esto quizá implique un cargo al usuario, por lo tanto debería ser una acción configurable.
Estas recomendaciones deberían respetarse incluso aunque no impliquen costes adicionales, simplemente por razones de buen diseño:

• Transferir sólo los datos necesarios.
• Evitar accesos repetidos (datos que ya podemos tener en memoria).
• Siempre que sea posible evitar actualizaciones innecesarias cuando la actividad no esté visible.
• Permitir la programación de tareas de transferencias de datos en las horas elegidas por el usuario (es decir, en los horarios que le convenga económica o funcionalmente).

El problema de las pantallas

El usuario de los móviles lo quiere todo pero es difícil compatilizar pequeño tamaño y poco peso con pantallas grandes. El diseñador ya tiene un gran problema para colocar toda la información disponible de una aplicación en una interfaz gráfica que lo limita por todos los lados. Está claro que si los móviles hubieran aparecido antes que los ordenadores quizá no pretenderíamos que esos mismos gráficos que vemos en las pantallas de 17 o 19 pulgadas se visualicen de modo similar en pantallas varias veces más pequeñas pero las cosas son como son y para el diseñador de aplicaciones móviles ya es todo un desafío lograr interfaces de usuario intuitivas y funcionales.
Normalmente se intenta mantener el aspecto de la interfaz de usuario para los distintos tipos de pantallas pero la realidad es que el diseño en pantallas pequeñas debe realizarse siguiendo paradigmas diferentes, aprovechando el uso de colores, formas y gráficos y evitando pantallas completas de texto. 
Otro factor que se debe tener en cuenta es que en las pantallas de dispositivos móviles el principal modo de dar órdenes al dispositivo es mediante el toque en la pantalla táctil y los controles que reciben esa entrada deben tener el tamaño suficiente para no producir entradas indebidas; pero el mundo Android es tan amplio que también debemos tener en cuenta que hay dispositivos que no se basan en la pantalla táctil o que tienen esa capacidad pero como alternativa secundaria; hay dispositivos Android con pantallas de 3 pulgadas, tabletas de 10 pulgadas y Google TV de 40 pulgadas, todos con diferentes resoluciones, y nuestras interfaces de usuario tienen que aprovechar esa variedad y saber escalarse correctamente.

 
El almacenamiento no es infinito

La tecnología del almacenamiento en disco y en memorias flash ha logrado que las capacidades de almacenamiento llegue a niveles impensables hace 3 o 4 años. Paralelamente al aumento de la capacidad existe algo que todos sufrimos incluso en los entornos PC: siempre encontramos el modo de llenar los discos con contenido, si antes nos conformábamos guardando música hoy sólo nos conformamos guardando la colección completa de las películas ganadoras del Oscar. Es una batalla perdida porque si ayer nomás 500GB era una enormidad de espacio… ¿cómo puede ser que hoy con varios TB sigamos teniendo problemas? Por este motivo, pese a que la capacidad de almacenamiento crezca siempre debemos pensar que el espacio disponible para nuestras aplicaciones será escaso.
Nuestras aplicaciones pueden estar instaladas en la tarjeta SD en lugar de utilizar el almacenamiento interno pero con ciertas limitaciones que veremos más adelante en detalle y por lo tanto no es una solución para todos los casos. El tamaño del compilador de nuestra aplicación es importante pero los puntos críticos están en otras partes: el espacio del almacenamiento de datos que requiera nuestra aplicación (esto tiene importancia independientemente que la aplicación esté siendo utilizada o no) y la gestión de los recursos durante la ejecución con la debida liberación de los recursos no utilizados (esto afecta el uso de la memoria). El uso de la memoria caché mejora el rendimiento de las aplicaciones pero debemos siempre tener en cuenta que todo recurso escaso, como la memoria caché, debe estar bien administrado.

Accesos realistas a la Web

Cuando diseñamos y desarrollamos la aplicación nuestro entorno de prueba normalmente será el emulador de Android y algunos dispositivos reales. Generalmente cuando utilizamos dispositivos reales lo  hacemos con conexiones fiables y de buena velocidad algo que en la vida real no siempre ocurre. Debemos preocuparnos en crear entornos de prueba similares a los que pueden suceder en la realidad; afortunadamente el emulador de Android nos permite ajustar la velocidad y la latencia (demora) de nuestra conexión de red. 
Para definir el comportamiento de nuestra conexión en el emulador:

• Se selecciona Debug Configurations…. (configuraciones de depuración).
• En el panel de la izquierda se elige Android Application y se selecciona la configuración que se quiere ajustar. 
• En la ficha Target y se eligen los valores para Network Speed y Network Latency.

 

Entre las opciones disponibles:

• GPRS: General Packet Radio Service  (Servicio General de Paquetes Vía Radio) es una extensión del Sistema Global para Comunicaciones Móviles (Global System for Mobile Communications o GSM) para la transmisión de datos mediante conmutación de paquetes.
• EDGE: Enhanced Data Rates for GSM Evolution (Tasas de Datos Mejoradas para la evolución de GSM). También se suele denominar EGPRS (Enhanced GPRS); es una tecnología de la telefonía móvil celular, que actúa como puente entre las redes 2G y 3G. EDGE se considera una evolución del GPRS (General Packet Radio Service).  
• UMTS: Universal Mobile Telecommunications System (Sistema Universal de Telecomunicaciones Móviles) y también es otra de las tecnologí​as sucesoras de GSM.
• HSCSD: High-Speed Circuit-Switched Data  y también es otra mejora al mecanismo de transmisión de datos de GSM o circuit-switched data (CSD). 
• HSDPA: High Speed Downlink Packet Access (Acceso de alta velocidad de enlace descendente) también conocida como 3.5G, 3G+ o turbo 3G, es la optimización de la tecnología espectral UMTS/WCDMA, incluida en las especificaciones de 3GPP.

El acceso a la Web desde los dispositivos móviles nos permite implementar un amplio abanico de funcionalidades pero debemos tener en cuenta que el acceso Web no es ni tan rápido ni tan fiable como en el entorno fijo por esos motivos como diseñadores de aplicaciones móviles que acceden a la Web debemos presuponer que la conexión será más lenta, más costosa y menos fiable; gracias a la expansión de los entornos WiFi las cosas van cambiando a mejor pero como diseñadores debemos estructurar las aplicaciones para escenarios pesimistas, si finalmente las conexiones se comportan mejor de lo previsto tanto mejor nuestra aplicación quizá no tendrá que gestionar tantas pérdidas de conexión pero si esto ocurriese, la aplicación estará preparada para hacerlo.