Advertisement
  1. Code
  2. Android SDK
Code

6 Normas para una Grandiosa Experiencia de Usuario Android

by
Length:LongLanguages:

Spanish (Español) translation by Rafael Chavarría (you can also view the original English article)

Las aplicaciones Android más populares tienen algo en común: todas proporcionan una gran experiencia de usuario. En este artículo, compartiré algunos consejos que ayudarán a tu app a resaltar.

Independientemente del tipo de aplicación que tengas en mente, o tu audiencia meta, diseñar una gran experiencia de usuario puede ayudarte a asegurar que tu app es un éxito. En este artículo, voy a compartir seis cosas que deberías y no deberías hacer, para asegurar que tu app entrega la mejor experiencia posible a tus usuarios finales.

Ya que crear y lanzar una aplicación Android es un proceso de muchos pasos, estaré tocando cada parte del ciclo de vida de desarrollo Android--desde tomar decisiones difíciles sobre cuales versiones de Android deberías soportar, hasta crear un producto que será atractivo para una audiencia global, hasta analizar el rendimiento de tu app después del lanzamiento.

1. No Te Quedes Colgado Tratando de Soportar Cada Versión de Android

Mientras que es natural querer poner tu app en frente de tantos usuarios como sea posible, no caigas en la trampa de asumir que soportar más versiones de Android siempre es la mejor aproximación.

La llave para atraer una audiencia grande es proporcionar la mejor experiencia de usuario posible, y establecer tus miras en soportar tantas versiones de Android como sea posible puede de hecho dañar tu experiencia general de usuario.

El mayor problema es que mientras continuas regresando a la historia de liberaciones de Android, se va a volver más difícil hacer que tu app funcione bien con las liberaciones más antiguas.

Algunas veces, podría haber un punto claro en donde tu app se vuelve incompatible con versiones antiguas de Android. Por ejemplo, si tu app requiere de manera absoluta acceso a Bluetooth Low Energy (BLE), entonces tu aplicación no va a poder ejecutarse en nada anterior a Android 4.3--la versión en la que el soporte BLE fue añadido a la plataforma Android.

Sin embargo, algunas veces esta línea podría no ser tan clara, y podrías encontrarte debatiendo si modificar o no o incluso remover características no críticas, para poder crear algo que pueda ejecutarse en una versión particular de Android. Las compañías pequeñas pueden mermar la calidad de experiencia de usuario, así que siempre ten en cuenta el impacto que estos cambios tendrán sobre tus usuarios.

En adición, personalizar, optimizar y probar tu app para cada versión diferente de Android requiere tiempo y esfuerzo, así que también necesitarás preguntarte si esta inversión vale las potenciales recompensas. Básicamente, ¿cuántos usuarios más podrías ganar potencialmente soportando cada versión de Android? Puedes tener un indicador de cuántos dispositivos Android están ejecutando cada versión de la plataforma Android, revisando las estadísticas en el Tablero de Google.

Por último, no hay respuesta universal correcta o incorrecta, así que necesitarás poner en la balanza los pros y contras y decidir que tiene más sentido para tu proyecto en particular.

Una vez que has decidido qué versiones de Android vas a soportar, agrega esta información a tu archivo build.gradle a nivel de módulo usando minSdkVersion (la API más baja con la que tu app es compatible), targetSdkVersion (el nivel de API más alto contra el que probaste tu aplicación), y compileSdkVersion (la versión del SDK de Android que Gradle debería usar para compilar tu app).

Para asegurar que tu app se beneficia de las últimas características de Android mientras permanece compatible con liberaciones anteriores, es recomendable que establezcas tu minDskValue tan bajo como sea posible, mientras estableces targetSdkVersion y compileSdkVersion a la última versión del SDK de Android.

2. Has Diseño para Múltiples Pantallas

Cuando estás trabajando en una app Android, no es poco común que pases la mayor parte del tiempo probando esa app en tu propio smartphone o tableta Android. Particularmente durante las etapas tempranas del desarrollo de app, crear múltiples Dispositivos Virtuales Android (AVDs) será probablemente la última cosa en tu cabeza.

Sin embargo, ¡no pierdas de vista del panorama completo! Es fácil quedarse colgado diseñando para una pantalla que está físicamente frente a ti, pero es esencial que tu app se ve bien y funcione correctamente a lo largo de un amplio rango de dispositivos Android.

El sistema Android escalará automáticamente tus diseños, drawables y otros recursos de manera que se generen de manera apropiada para el tamaño de la pantalla actual, pero para la mejor experiencia de usuario deberías apuntar a crear la ilusión de que tu app fue diseñada para el dispositivo específico del usuario. ¡Depender solo del auto escalado no será suficiente!

Para asegurar que tu app entrega la mejor experiencia de usuario a lo largo de un amplio rango de dispositivos, necesitarás proporcionar recursos alternativos que están optimizados para diferentes dispositivos, tales como drawables que apuntan a cubetas de densidad generalizadas de Android, y alternar tus diseños que están optimizados para modo apaisado.

Una vez que has creado tus recursos alternativos, necesitarás crear directorios alternativos que están etiquetados con los calificadores de configuración apropiados, y después colocar los recursos dentro de esos directorios--por ejemplo, un directorio res/layout-land contendría diseños que están hechos para orientación apaisada. El sistema Android entonces cargará automáticamente el recurso que mejor empareje a la configuración de pantalla actual en tiempo de ejecución.

Mientras que la mayoría de calificadores de configuración son relativamente sencillos, proporcionar recursos que apunten a diferentes tamaños de pantalla es un poco más complejo, requiriendo que especifiques el valor dpi exacto  en donde el sistema debería comenzar a usar este recurso. Así qué, básicamente necesitas decirle al sistema, "Quiero usar este diseño cuando mi app esté siendo mostrada en dispositivos con 800dpi o más ancho de pantalla disponible"

Llegas a estos valores probando tu app a lo largo de un amplio rango de diferentes AVDs y tomando nota de todos los tamaños de pantalla con los que tus recursos por defecto están teniendo dificultades--por ejemplo, tal vez tu diseño por defecto comienza a verse amontonado una vez que el dispositivo cae bajo cierto límite de dpi.

Hay tres calificadores de configuración de tamaño de pantalla que puedes usar en tus proyectos:

  • smallestWidth sw<value>dp. Te permite especificar el espacio horizontal mínimo que debería estar disponible antes de que el sistema puede usar los recursos en este directorio. Por ejemplo, si tuvieras un conjunto de diseños que requieren 800dpi o más, crearías un directorio res/layout-sw800dp. Nota que el smallestWidth de un dispositivo es un valor fijo que no cambia cuando el usuario cambia su dispositivo entre orientación de vertical y apaisada.

  • Available screen width w<value>dp. El espacio horizontal mínimo que debe estar disponible antes de que el sistema pueda usar estos recursos. Un valor w<value>dp de un dispositivo cambia cuando el usuario cambia entre modo vertical y horizontal.

  • Available screen height: h<value>dp. La altura mínima que debe estar disponible antes de que el sistema pueda usar estos recursos. El valor h<value>dp del dispositivo cambiará dependiendo de si el usuario está sosteniendo el dispositivo en vertical u horizontal.

Diseñar para múltiples pantallas es en su mayoría sobre crear versiones alternativas de los recursos de tu proyecto y agregarlas a los directorios apropiados--después enjuague y repita. Sin embargo, hay algunos trucos adicionales que puedes realmente ayudarte a crear la ilusión de que tu app fue diseñada para el dispositivo específico del usuario:

  • Usa drawables de densidad específica en combinación con imágenes 9-patch. Si el sistema necesita re-dimensionar una imagen para encajar en la pantalla actual por defecto re-dimensionará la imagen entera, lo cuál puede llevar a imágenes borrosas, pixeladas o extrañas. Para los mejores resultados posibles, deberías especificar los pixeles exactos que el sistema debería replicar si necesita re-dimensionar tu imagen, entregando los drwaeables de tu proyecto como imágenes 9-patch. Proporciona múltiples versiones 9-patch de cada drawable, en donde cada 9-patch apunte a diferente densidad de pantalla, y el sistema entonces cargará la imagen 9-patch que sea más adecuada para la densidad de pantalla actual y estirará las secciones 'estirables' de la imagen 9-patch, si es requerido. Puedes crear imágenes 9-patch usando cualquier editor PNG, o puedes usar el editor Draw 9-patch que está incluido en el SDK de Android (lo encontrarás en sdk/tools/Draw9patch.bat).

  • Crea múltiples archivos dimens.xml. Es recomendable que definas tus valores de diseño en un archivo dimens.xml separado en vez de apuntalarlos en tu proyecto. Sin embargo, puedes llevar esto un paso más allá y crear múltiples archivos dimens.xml que apunten a diferentes tamaños de pantalla y densidades. Por ejemplo, podrías crear un archivo values-ldpi/dimens.xml en donde definas los valores que tu app debería usar si está instalada en un dispositivo que cae en la categoría de "baja" densidad. El sistema entonces cargará las dimensiones apropiadas para el dispositivo actual, las aplicará a tu diseño.

  • Considera usar fragmentos. Los fragmentos te proporcionan una manera de dividir una Activity en componentes separados que puedes entonces mostrar en diferentes formas, dependiendo de la configuración actual de pantalla. Por ejemplo, podrías considerar elegir mostrar múltiples fragmentos lado a lado en un diseño multi-panel cuando tu app está instalada en un dispositivo con una pantalla más grande, y como Activities separadas cuando el espacio está más limitado. La manera más simple de agregar un fragmento a tu diseño es insertar un elemento <fragment> en archivo layout resource. De manera alternativa, puedes agregar fragmentos a un diseño vía el código de tu aplicación--este método podría ser más complicado, pero te da la flexibilidad añadida de poder agregar, remover o reemplazar fragmentos en tiempo de ejecución.

3. Considera Soportar Distintos Lenguajes

Android es un sistema operativo global, así que si tu app va a proporcionar la mejor experiencia de usuario a esta audiencia global entonces deberías considerar localizar tu app para diferentes lenguajes, y potencialmente diferentes regiones.

Típicamente, la parte más grande de localizar una app es traducir el archivo strings.xml de tu proyecto a diferentes lenguajes que quieres soportar. A menos que seas fluído en tus idiomas meta, vas a necesitar la ayuda de un traductor. Si no tienes a nadie en mente, entonces los servicios de Traducción Google Play App de la Consola de Desarrollador pueden apuntarte en la dirección de traductores potenciales.

Youll find a Purchase Translations option in the Google Play Developer Console

Una vez que has elegido a un traductor, deberías dar un vistazo crítico a tu archivo strings.xml antes de enviarlo para traducción. Revisa cosas como errores de ortografía y de dedo, y asegúrate de que tu strings.xml esté formateado de una manera que sea fácil de leer, teniendo en mente que tu traductor podría no ser un desarrollador Android.

Deberías también proporcionar tanto contexto como sea posible, así que asegúrate de que agregas un comentario a cada cadena explicando para qué es, en donde y cuándo aparecerá en tu app, y cualquier restricción que el traductor necesite conocer. Por ejemplo, si una cadena necesita permanecer menor a 10 caracteres de longitud para poder encajar en su espacio dentro del diseño, ¡entonces esto es algo que el traductor necesita saber!

Una vez que el traductor te ha devuelto tus archivos strings.xml, necesitarás crear un directorio para cada archivo alternativo, lo que significa que necesitarás trabajar sobre qué calificadores de configuración usar.

Un calificador de configuración local consiste en un código ISO, el cuál es esencialmente un código de lenguaje, y un código opcional de país o regional, el cuál es precedido por una r minúscula. Por ejemplo, si quisieras proporcionar texto en Francés (fr) para la gente ubicada en Canadá (can), entonces crearías un directorio res/values-fr-rcan .

Si quieres proporcionar texto localizado, entonces ten en mente que algunas de las cadenas podrían expandirse o encogerse significativamente durante la traducción, así que necesitarás probar que tus diseños se acomoden a todas las versiones del string de tu proyecto.

La manera más sencilla de probar tus recursos localizados es instalar tu app en un AVD y después emular las diferentes ubicaciones y ajustes de lenguaje. En este punto, el sistema cargará las versiones localizadas de tus recursos y las mostrará en tu app.

Puedes cambiar los ajustes locales en un AVD otorgando los siguientes comandos Android Debug Bridge (abd):

Seguido por:

Nota, necesitarás reemplazar el fr.CAN con cualquier calificador de configuración contra el que quieras probar.

Si has diseñado tu app con las mejores prácticas en mente, entonces tus diseños deberían ser lo suficientemente flexibles para mostrar la mayoría de tus cadenas localizadas. Sin embargo, si la longitud de tus cadenas varía dramáticamente entonces podrías necesitar proporcionar diseños alternativos que están optimizados para diferentes locales.

Mientras el archivo strings.xml de tu proyecto es generalmente el recurso principal que necesitarás para localizar, deberías también considerar si hay otros recursos que podrías necesitar traducir como drawables que contienen texto, video o audio que contienen diálogo, o cualquier otro recurso que podría ser inapropiado para el locale que estás apuntando.

Una vez que tienes confianza de que has proporcionado todos los recursos localizados y has desempeñado tu propia ronda de pruebas, deberías considerar establecer una prueba beta con hablantes nativos en cada una de tus locales meta. Los hablantes nativos pueden regularmente captar errores que incluso un traductor podría pasar por alto, y podría ser capas de darte algún consejo sobre cómo puedes hacer tu app más atractiva para esta sección particular de tu audiencia. Puedes organiza este tipo de prueba beta dirigida vía la Consola de Desarrollador Google Play.

Cuando finalmente estás listo para lanzar tu app, asegúrate de que te tomas el tiempo para crear versiones localizadas de tu página de app de Google Play, ya que esto hará instantáneamente más atractiva a tu app para usuarios internacionales que están navegando por la Google Play Store. Deberías también intentar proporcionar capturas de pantalla que muestren claramente el texto localizado dentro de tu app, para que los usuarios no se queden adivinando si solo tradujiste tu página de Google Play, y no el texto dentro de tu app.

¡Y el trabajo duro no termina una vez que has lanzado tu app! Una vez que has atraído a tu audiencia internacional, necesitarás apegarte a ellos proporcionando soporte vigente a través de múltiples lenguajes---incluso si eso significa recurrir a máquinas de traducción como Google Translate. Por lo menos, deberías mantener un ojo en tus valoraciones de Google Play, para ver si los usuarios en ciertos lugares están reportando problemas similares, que podrían indicar un problema con uno o más de los recursos localizados de tu app.

4. ¡No Te Olvides de la Accesibilidad!

Como un desarrollador de apps, querrás asegurarte de que todos pueden disfrutar usar tu app, así que es importante considerar qué tan accesible es tu app para gente que podría estar experimentándola sin sonido, color y otros visuales, o cualquier que interactúe con su dispositivo Android vía una herramienta de accesibilidad como un lector de pantalla.

Android está diseñado con la accesibilidad en mente, así que tiene un número de características integradas de accesibilidad que puedes utilizar sin tener que hacer cualquier cambio fundamental al código de tu aplicación.

Veamos a unas cuantas modificaciones que puedes hacer a tu proyecto, que tendrán un gran impacto sobre la accesibilidad de tu proyecto:

Considera Proporcionar Descripciones Adicionales de Contenido

Los servicios de accesibilidad como TalkBack leen texto en pantalla en voz alta, haciéndola una herramienta importante para ayudar a usuarios con problemas relacionados con la visión interactuen con sus dispositivos Android.

Cuando diseñas tu aplicación Android, deberías considerar que tan fácil sería para los usuarios navegar tu app usando solo el texto en pantalla. Si necesitas proporcionar contexto adicional, entonces puedes agregar una descripción de contenido a cualquiera de los componentes UI de tu app, que entonces serán leídos en voz alta por servicios como TalkBack. Para agregar descripción de contenido, abre el archivo layout resource de tu proyecto y agrega un atributo android:contentDescription al componente UI en cuestión, seguido por la descripción que quieres usar.

Soporta Enfoque de Navegación

Los usuarios con visión limitada o destreza manual limitada podrían encontrar más fácil interactuar con sus dispositivos usando un control direccional, como un trackpad, D-pad o teclado, o software que emula un control direccional. Para asegurar que tu app soporta este tipo de navegación enfocada, necesitarás agregar el atributo android:focusable="true” a cada uno de tus componentes de navegación de tu app.

Cuando los usuarios navegan tu app usando controles direccionales, el foco se pasa de un elemento UI a otro en un orden que es determinado automáticamente usando un algoritmo. Sin embargo, puedes anular estos valores por defecto y especificar cuál componente UI debería ganar enfoque cuando el usuario se mueve en una dirección en particular, agregando los siguientes atributos XML a cualquiera de tus componentes UI: android:nextFocusUpandroid:nextFocusDown, android:nextFocusLeft, y android:nextFocusRight. Por ejemplo:

Haz Tu Texto Redimensionable

Los usuarios con discapacidades visuales podrían elegir incrementar el tamaño de la fuente que aparece en su dispositivo. Para asegurar que cualquier cambio de fuente se refleje en tu app, define tu texto en pixeles escalares--y no olvides probar que impacto tendrán varios tamaños de fuente Android en la UI de tu app, solo en caso de que necesites hacer algunos ajustes a tu diseño.

Usa Tamaños de Objetivos Touch Recomendados

Para ayudar a la gente con retos de destreza manual a navegar tu app, es recomendado que establezcas todos los objetivos táctiles a 48 x 48 dpi o superior, y asegúrate de que el espacio entre estos objetivos es al menos 8 dpi.

Considera Deshabilitar Controles Caducos

Algunos componentes UI podrían desaparecer automáticamente después de que ha pasado cierto periodo de tiempo--- por ejemplo, los controles de reproducción de video frecuentemente desaparecen una vez que el video se ha estado reproduciendo por unos momentos.

El problema es que los servicios de accesibilidad como Talkback no leen controles hasta que el usuario se ha enfocado en ellos, así que si un control caduco se desvanece antes de que el usuario tenga oportunidad de enfocarse en el, entonces no serán conscientes de que esos controles existen incluso. Por esta razón, deberías considerar actualizar controles caducos a controles permanentes siempre que los servicios de accesibilidad estén habilitados.

5. Pon el Desempeño de Tu App a Prueba

Solo porque tu app no falla o arroja ningún error durante las pruebas, no significa automáticamente que se está desempeñando bien, ya que algunos problemas de desempeño pueden ser insidiosos y difíciles de detectar durante las pruebas regulares. Nadie disfruta usar una app que tarda en cargar por siempre, se traba cada vez que intentas interactuar con ella y engulle la memoria disponible, así que siempre debes someter a tu app a un número de pruebas de rendimiento antes de lanzarla al público.

El SDK de Android viene con un amplio rango de herramientas que puede usar para probar específicamente el rendimiento de tu app. En esta sección, vamos a ver unas cuantas que definitivamente querrás usar; sin embargo, hay muchas más que vale la pena investigar (encontrarás más información en los documentos oficiales de Android).

Nota que todas estas herramientas solo pueden comunicarse con una app en ejecución, así que necesitarás asegurarte de que la app que quieres probar está instalada ya sea en un AVD o dispositivo físico que está conectado a tu máquina de desarrollo.

Antes de que comencemos, vale la pena notar que si identificas un problema con el desempeño de tu app, es recomendable que cronometres tu código antes de que intentes corregir este problema. También puedes cronometrar tu código de nuevo después de que creas que has arreglado el problema, y serás capas de ver exactamente qué impacto tienen tus cambios en el desempeño de tu app.

Puedes cronometrar tu código usando TraceView, el cuál puedes acceder seleccionando la pestaña DDMS de Android Device Monitor, después seleccionando el dispositivo y el proceso que quieres perfilar, y dando clic al icono Start Method Profiling (en donde el cursor está posicionado en la siguiente captura).

In the Android Device Monitor select the DDMS tab followed by Start Method Profiling

En este punto puedes seleccionar Trace based profiling (rastrea la entrada y salida de cada método) o Sample based profiling (recolecta las llamadas a una frecuencia especificada por ti). Una vez que has hecho tu selección, pasa un tiempo interactuando con tu app. Cuando estás listo para ver los resultados, puedes cargar el archivo de seguimiento al visor dando clic al icono Stop Method Profiling. El archivo de rastreo muestra cada hilo de ejecución como una fila separada, para que puedas ver exactamente que tanto tarda cada parte de tu proyecto en ejecutarse.

Identificación de Sobregiro

Cuando el sistema dibuja la UI de tu app, este comienza con el contenedor de mayor nivel y después trabaja a través de la jerarquía de tu vista, potencialmente dibujando vistas encima de otra en un proceso conocido como re-dibujo. Mientras cierta cantidad de re-dibujo es inevitable, puedes reducir el tiempo que toma a tu aplicación generarse identificando y removiendo cualquier instancia de re-dibujo excesivo o innecesario.

Si tienes un dispositivo ejecutando Android 4.2 o superior, puedes revisar la cantidad de re-dibujo presente en cada app instalada en ese dispositivo, seleccionado Settings > Developer Options > Debug GPU Overdraw > Select overdraw areas. El sistema entonces agregará una superposición coloreada a cada área de la pantalla, indicando el número de veces que cada pixel ha sido dibujado.

  • Sin Color. Este pixel fue pintado una vez.

  • Azul. Un re-dibujo de 1x. Estos pixeles fueron pintados dos veces.

  • Verde. Un re-dibujo de 2x.

  • Rojo claro. Un re-dibujo de 3x.

  • Rojo oscuro. Un re-dibujo de 4x o más.

La mayoría de las aplicaciones incluyen algún nivel de re-dibujo, pero si detectas grandes areas de re-dibujo en tu aplicación entonces deberías buscar si hay alguna forma de reducir el número de veces que cada pixel está siendo re-dibujado, y uno de los métodos efectivos es remover vistas innecesarias.

El Visor de Jerarquía del Android Device Monitor proporciona un alto nivel de vistazo general de la jerarquía entera de tu app, que puede ayudarte a identificar vistas que no están contribuyendo a nada a la imagen final que el usuario ve en pantalla.

Para lanzar el Visor de Jerarquía, da clic al botón Hierarchy View del Android Device Monitor, y después selecciona el dispositivo y la Actividad que quieres inspeccionar, seguido por el icono azul Load the view hierarchy into the tree view.

In the Android Device Monitor select the Hierarchy View button followed by Load the view hierarchy into the tree view

Podrías también querer exportar la salida del Visor de Jerarquía como documento de Photoshop. Esta es una técnica particularmente efectiva para identificar vistas que no están contribuyendo a nada a la UI final, ya que cada vista es mostrada como una capa separada de Photoshop, significando que puedes ocultar y mostrar cada capa y ver exactamente qué impacto tendrá esto en la imagen final que el usuario ve en pantalla.

Para crear un documento PSD, simplemente da clic al icono Capture the window layers as a Photoshop document.

Detectando Fugas de Memoria

La recolección de basura (Garbage collection) es un comportamiento normal de sistema que es importante para asegurar que tu app y tu dispositivo como un todo continúan ejecutándose suavemente.

Sin embargo, si tu app no está administrando la memoria apropiadamente---tal vez está goteando memoria o o colocando un número grande de objetos en un periodo corto de tiempo---entonces esto puede disparar eventos GC más frecuentes que también duran más. Puedes echar un vistazo a exactamente que eventos GC están ocurriendo en tu app en la ventana principal de Android Studio; abre la pestaña Android Monitor hacia el fondo de la ventana, seguido por la pestaña Monitors. La herramienta Memory Monitor entonces comenzará a grabar el uso de memoria de tu app automáticamente.

Select the Android Monitor tab towards the bottom of the main Android Studio window followed by the Monitors tab

Si sigues interactuando con tu app, entonces eventualmente verás una caída repentina en la cantidad de memoria colocada, indicando que un evento GC ha ocurrido. Repite este proceso, asegurándote de que exploras áreas diferentes de tu app, y mira qué impacto tiene esto en los eventos GC. Si detectas cualquier comportamiento GC extraño, entonces querrás investigar más allá ya que esto podría indicar un problema con la manera en que tu app está usando memoria.

Hay un par de herramientas que puedes usar para reunir más información sobre el uso de memoria de tu app. Primeramente, puedes usar la pestaña Heap del Android Device Monitor para ver cuánta memoria apilada esta usando cada proceso, que marcará cualquier proceso que esté engullendo memoria disponible.

Para usar la herramienta Heap, selecciona la pestaña DDMS del Android Device Monitor, seguido por el proceso de quieres examinar, y después da clic al botón Update heap. La pestaña Heap no mostrará ninguna información hasta que un evento GC haya ocurrido, pero si te sientes impaciente siempre puedes disparar un evento GC dando clic al botón Cause GC.

Open the Heap tool by selecting DDMS Heap

Otra herramienta que puede ayudarte a reunir información sobre el uso de memoria de tu app es Allocation Tracker, que te permite ver exactamente qué objetos está asignando tu app a memoria. Para usar Allocation Tracker, selecciona la pestaña DDMS de Android Device Monitor, seguido de Allocation Tracker y los procesos que quieres examinar.

Da clic al botón Start Tracking y pasa algún tiempo interactuando con tu app, especialmente cualquier parte que sospeches pudiera estar causando problemas de administración de memoria a tu app. Para ver toda la información que el Allocation Tracker ha reunido durante el periodo de muestreo, selecciona el botón Start Tracking, seguido del botón Get Allocations.

6. Usa Herramientas Analíticas

Entender a tu audiencia es una parte crucial de crear una app exitosa.

Teniendo acceso a información sobre quién es tu audiencia y cómo están usando tu app significa que puedes tomar decisiones más informadas sobre cómo construir sobre el éxito de tu app---y mejorar en las áreas en donde tu app no está tan bien.

Reunir este tipo de información de usuario es particularmente útil para identificar tendencias a lo largo de diferentes secciones de tu audiencia. Por ejemplo, podrías decidir que un cierto segmento de tu audiencia es particularmente valioso---tal vez están acumulando el porcentaje más alto de compras integradas, o están invirtiendo una cantidad de tiempo por encima de la media en tu aplicación. Armado con esta información, puedes tomar pasos extra para dar soporte a estos usuarios, asegurando que tus usuarios más valiosos permanecen enganchados con tu app.

En el otro lado de la balanza, podrías descubrir un área en donde tu app está teniendo dificultades. Por ejemplo, tal vez los usuarios que están ejecutando una versión particular tienen tasas de enganche considerablemente bajas, o son más propensos a desinstalar tu app. En este escenario, podrías querer probar tu app sobre esta versión en particular de Android para ver si hay un bug o cualquier otro error que pudiera estar arruinando la experiencia de usuario para esta sección de tu base de usuarios.

Básicamente, entre más datos puedes recoger sobre tu audiencia y su comportamiento, más oportunidades de mantener feliz a tu usuario existente, atrayendo nuevos usuarios, y generalmente entregando una grandiosa experiencia completa para cualquiera que se ponga en contacto con tu app.

En esta sección voy a ver dos servicios que pueden poner una cantidad abundante de información en la punta de tus dedos: Firebase Analytics y la Consola de Desarrollador de Google Play.

Firebase

Puedes usar Firebase Analytics para reunir información sobre tus usuarios, tales como su edad, género y ubicación, mas información sobre 500 eventos dentro de la app. Incluso puedes definir tus eventos personalizados, si se requiere.

Para agregar Firebase Analytics a tu proyecto, necesitarás Google Play Services 10.0.1 o superior y el Repositorio de Google versión 26 o superior, así que abre el SDK Manager y asegúrate de que estos componentes están actualizados. También necesitarás estar ejecutando Android Studio 1.5 o superior, y estar registrado con una cuenta gratuita Firebase.

Si estás ejecutando Android 2.2 o superior, entonces puedes conectar tu app a Firebase Analytics usando el Asistente Firebase. Abre Android Studio, lanza el proyecto en cuestión, y:

  • Selecciona Tools > Firebase desde la barra de herramientas de Android Studio.

Launch the Firebase Assistant by selecting Tools from the Android Studio toolbar followed by Firebase

  • Da clic para expandir la sección Analytics, después selecciona el enlace Log an Analytics event.

  • Da clic al botón Connect to Firebase.

  • En el diálogo que aparece, opta por crear un nuevo proyecto Firebase.

  • Da clic al botón Connect to Firebase.

  • Después de unos momentos, deberías ver un mensaje Connected.

  • Da clic al botón Add analytics to your app.

  • En el diálogo subsecuente, da clic a Aceptar cambios.

¡Y eso es todo! Ahora puedes ver toda tu información de Firebase Analytics registrarse en la Consola Firebase, seleccionando el proyecto que quieres examinar, y después selecciona Analytics. Esta información se actualizará periódicamente a lo largo del día.

La Consola de Desarrollador

También puedes ganar una visión valiosa al desempeño de tu app y comportamiento de usuario vía la Consola de Desarrollador.

Para ver esta información, ingresa a tu cuenta de Consola de Desarrollador, selecciona la app que quieres examinar y después selecciona Dashboard desde el menú a mano izquierda.

La Consola de Desarrollador contiene mucha información útil, así que vale la pena tomarse el tiempo para explorar sus varias secciones a detalle. Sin embargo, hay algunas cuantas áreas que podrían ser de interés particular:

  • User Acquisition Performance. Esta sección contiene un desglose de cómo los usuarios están encontrando el listado de Google Play de tu app, por ejemplo el porcentaje de usuarios que llegaron a tu página vía un enlace UTM-tagged, un anuncio AdWords, o el número de gente que simplemente encontró tu app navegando la tienda Google Play.

  • Finance. Si has implementado una estrategia de monetización, tales como productos dentro de la app o una opción de suscripción, entonces puedes usar la Consola de Desarrollador para revisar el rendimiento financiero de tu app. La sección Finance contiene información como la cantidad promedio que cada usuario está invirtiendo en tu app,cuánto ingreso está siendo generado por cada producto que ofreces a través de tu app, y cuánto cada sección de tu base de usuarios está gastando, basado en factores como su ubicación geográfica, edad, y la versión de Android que están usando.

  • Crashes & ANRs. Esta sección contiene toda la información que los usuarios han enviado acerca de fallos de aplicación y la aplicación no respondiendo (ANR), dándote oportunidad de identificar y corregir cualquier problema que pudiera ocurrir en tu app antes de que los usuarios comiencen a dejarte valoraciones negativas en Google Play. Nota que los fallos que no son reportaos por los usuarios no aparecerán en la Consola de Desarrollador.

También podrías querer considerar descargar la app de Consola de Desarrollador de Google Play, que te permite revisar toda esta información en el camino.

Conclusión

En este artículo, vimos seis cosas que deberías y no deberías hacer cuando estás desarrollando una app Android. ¿Cuáles son tus reglas de oro para diseñar una gran experiencia de usuario? Deja un comentario abajo y déjanos saber.

Mientras tanto, ¡revisa algunos de nuestros otros cursos y tutoriales sobre programación Android!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.