Cursos de orientación profesional

ACCIONES COFINANCIADAS CON FONDOS COMUNITARIOS DEL FONDO SOCIAL EUROPEO,

A TRAVÉS DEL PROGRAMA OPERATIVO FONDO SOCIAL EUROPEO DE CANARIAS 20072013
CON UN PORCENTAJE DE CONFINANCIACIÓN DEL 85%.
 Día 1
 ¿Qué es Android?
 Actividades e intenciones
 Día 2
 Layouts y controles gráficos
 Recursos, menús y diálogos
 Día 3
 Persistencia de datos y content providers
 Gráficos y animaciones 2D y 3D
 Día 4
 Servicios en segundo plano
 Control del hardware especial
 Día 5
 App Widgets y Live folders
 Publicación de aplicaciones
Creación de aplicaciones móviles en Android

Rayco Araña
rayco.arana@gmail.com
Instituto SIANI
 Preparándonos para publicar
 Mercado
 Optimización
 Buenas prácticas
 Prueba, prueba y prueba
 Android Market
 Preparándonos para publicar
 Mercado
 Optimización
 Buenas prácticas
 Prueba, prueba y prueba
 Android Market
 Fragmentación del mercado
 La gran amenaza para Android
▪ Varios teléfonos recientes salen con versión 1.5!
▪ Todos los iPhone tienen acceso a la última versión
 Fragmentación del mercado
 Consecuencia
▪ Debemos desarrollar nuestras aplicaciones
compatibles con varias versiones del SDK
 Estrategia
▪ android:minSdkVersion con valor 3 (v1.5)
▪ Permite su ejecución desde 1.5 en adelante
▪ android:targetSdkVersion a la última versión
▪ Nos permite usar las nuevas APIs
▪ android:maxSdkVersion
▪ Limitar hasta probar puede evitar malas valoraciones
 Fragmentación del mercado
 Estrategia
▪ Adaptar la aplicación en función de la versión
▪ Los recursos soportan la versión del SDK como
discriminante
▪ Soportar distintos tamaños de pantalla
▪ Las nuevas versiones introducen nuevas dimensiones y
relaciones de aspecto
▪ Crear distintas configuraciones de AVDs
▪ Versiones 1.5 y última como mínimo
▪ Distintas configuraciones de tamaños y densidades de
pantallas
 Limitaciones del móvil
 Pocos recursos
 Pantalla pequeña
 Energía limitada
 Las aplicaciones móviles deben ser eficientes
▪ +Rápido == --CPU == +++Batería
▪ Debemos optimizar nuestras aplicaciones
 ANR (Android Not Responding)
 Nuestro gran enemigo!
 Se lanza si nuestra aplicación no
atiende a un evento
▪ 5 sec. para input del usuario
▪ 10 sec. para BroadcastReceiver
 El usuario puede esperar o forzar
el cierre 
 ANR (Android Not Responding)
 Tips and Tricks
▪ Evita hacer cosas pesadas en el main-thread
▪ Los manejadores de eventos y del ciclo de vida de las
actividades deben ser lo más pequeños y óptimos posibles
▪ Usa hilos para hacer las tareas pesadas
▪ No bloquees el hilo principal en espera de un hilo hijo
▪ Usa un Handler para que el hilo hijo notifique al main-
thread
▪ En el caso de BroadcastReceiver, no usar hilos sino lanzar
un servicio para tareas pesadas
 Optimizando nuestra aplicación
 Los extremos son siempre malos
▪ Una mala API por tener rendimiento nos puede
pasar factura en el mantenimiento
 Herramientas de Profiling
▪ Nos pueden dar pistas sobre donde necesitamos
mejorar
▪ Se cumple la regla del 80/20
▪ 80% del tiempo de ejecución es solo el 20% del código
▪ Un cambio de algoritmo suele tener mayor impacto que
muchas optimizaciones de bajo nivel
 Optimizando nuestra aplicación
 Evita crear/destruir objetos
▪ Evita objetos temporales
▪ Especialmente en bucles o UI
▪ Contribuye a menos recolecciones de basura
▪ Una recolección puede causar un «parón» momentáneo de
la aplicación
▪ Especialmente crítico en juegos
▪ ¡Ojo! El método draw es un bucle implícito
 Optimizando nuestra aplicación
 Usa métodos nativos
▪ Usa la API del sistema siempre que puedas
▪ Los métodos pueden estar implementados en
C/C++
▪ String.indexOf() - Entre 10-100x más rápido que en Java
▪ No para operaciones muy pequeñas
▪ La llamada a código nativo es más costosa que a
interpretado
 Optimizando nuestra aplicación
 Virtual sobre Interface
▪ Llamadas a través de una interfaz son hasta 2x más costosas
▪ Ej. Uso de Map para referenciar a un HashMap
▪ Desventaja, código menos flexible al mantenerlo
▪ Solucionable con un buen IDE  Refactorizar
 Optimizando nuestra aplicación
 Static over Virtual
▪ Más rápido al no requerir indirección
▪ Si el método no accede a campos internos del objeto, hacerlo
estático
▪ Es una buena práctica, ya que indica que ese método no altera el
estado del objeto
 Optimizando nuestra aplicación
 Evita el uso interno de getters y setters
▪ Dentro de la misma clase, accede directamente al campo
▪ Desde fuera NO!
▪ Evitamos llamadas a metodos virtuales innecesarias
 Optimizando nuestra aplicación
 Cachea la búsqueda de campos
▪ El acceso a un campo miembro de una clase es más lento que
el acceso a una variable local
▪ Los parámetros tienen igual rendimiento que una local

for (int i = 0; i < this.getCount(); i++)

dumpItem(this.items[i]);

int count = this.getCount();

Item[] items = this.items;

for (int i = 0; i < count; i++)

dumpItems(items[i]);
 Optimizando nuestra aplicación
 Palabra clave final
▪ Constantes (static vs static final)
▪ Evita el acceso mediante field lookup, más lento
▪ Inicialización más rápida de la clase (inicialización en el primer uso
de la clase)
▪ En variables locales
▪ Si va a ser usada por una clase anónima declarada en el propio
método
 Optimizando nuestra aplicación
 Evita los Enums
▪ No funcionan como en C++/C# donde se representan con un
simple entero
▪ Se representa con una clase
▪ Genera un .class, ocupa espacio en disco
▪ Tiene una inicialización en el primer uso
▪ Un acceso provoca un static field lookup
▪ Alternativa  static final int
▪ Tratado como constante, se usa de forma inline
 Optimizando nuestra aplicación
 Evita variables en punto-flotante
▪ Es habitual que las CPU de móviles no soporten operaciones
con float y double
▪ En ese caso, se realizan por software!
▪ Pueden llegar a tardar del orden del milisegundo
▪ La división de enteros puede también ser por software
▪ Trick
▪ Desplazamiento para dividir/multiplicar por 2
▪ Calcular con aproximaciones menos costosas
 Optimizando nuestra aplicación
Action Time
Add a local variable 1
Add a member variable 4
Call String.length() 5
Call empty static native method 5
Call empty static method 12
Call empty virtual method 12.5
Call empty interface method 15
Call Iterator:next() on a HashMap 165
Call put() on a HashMap 600
Inflate 1 View from XML 22,000
Inflate 1 LinearLayout containing 1 TextView 25,000
Inflate 1 LinearLayout containing 6 View objects 100,000
Inflate 1 LinearLayout containing 6 TextView objects 135,000
Launch an empty activity 3,000,000
 Buenas prácticas
 Implementa onSaveInstanceState() y onPause()
▪ En cualquier momento puede haber una llamada y tu
aplicación se cierra
▪ Evita que el usuario pierda todos los datos no guardados
explícitamente
▪ Puede maldecirte a ti o a quien llamó (o a los dos)

 Usa ContentProvider’s en vez de datos crudos

▪ Te permite cambiar tu representación sin afectar terceras
aplicaciones
▪ Ej. Fichero de datos en la tarjeta de memoria vs ContentProvider
 Buenas prácticas
 No interrumpas al usuario
▪ No abras una actividad desde un BroadcastReceiver o un
servicio
▪ Piensa que puede estar hablando por teléfono!!
▪ Usa una notificación y asóciale una intención para lanzar tu
actividad
▪ El usuario es notificado y abrirá tu actividad cuando pueda/quiera
 Buenas prácticas
 No sobrecargues una actividad
▪ Diseña pensando en el modelo de «backstack»
▪ Piensa que una misma actividad puede ser usada múltiples
veces (sin ser la misma instancia)
▪ Una misma actividad puede «aparecer» varias veces en la pila
de histórico sin que tengan que tener los mismos datos
 Buenas prácticas
 Extiende el tema del sistema
▪ Mejora la experiencia del usuario, todo tiene la misma
apariencia
▪ Usa el tema del sistema como base y sobrescribe lo que
necesites
▪ Evita usar posiciones o medidas hard-coded, usa relativas
▪ El UI se adaptará a pantallas de diferentes tamaños
 Buenas prácticas
 La conexión a internet es lenta
▪ No siempre el usuario tendrá 3G
▪ Gran parte del tiempo estará en GPRS
▪ Minimiza el número de conexiones y la cantidad de datos a
transmitir
▪ El emulador puede engañarte
▪ Cambia la configuración en Eclipse para simular conexiones más lentas
 Buenas prácticas
 No presupongas pantalla táctil o teclado
▪ Los teléfonos pueden tener diferentes tipos de teclado
▪ QWERTY completo, 40, 12 o menos teclas
▪ La disposición de las teclas pueden cambiar
▪ No tienen porque tener pantalla táctil
▪ Aunque ahora mismo todos tengan, pueden salir teléfonos de gama
media/baja con Android
 Prueba, prueba y prueba
 Implanta una metodología orientada a la prueba
▪ Evita malos comentarios y puntuaciones bajas por poner una
aplicación llena de bugs
 Haz uso de test unitarios
▪ Elimina los frecuentes y mal vistos fallos de regresión
 IoC – Inyección de dependencia
▪ Patrón de diseño orientado a la prueba
▪ Guice, framework de Google con soporte para Android
▪ Google Wave está hecho con esto!
 Preparándonos para publicar
 Mercado
 Optimización
 Buenas prácticas
 Prueba, prueba y prueba
 Android Market
Showroom

Android Market
• La tienda de aplicaciones
en Android
• Forma cómoda de
gestionar aplicaciones
• Nuevas posibilidades
para el desarrollador
independiente
• Muestra icono,
descripción y
screenshots de la
aplicación
 Características
 Apertura
▪ No está cerrado, cualquiera puede apuntarse (no es gratis)
 Sencillez
▪ Sólo 3 pasos: Registro, subida y publicación
 Comunidad
▪ Los usuarios pueden puntuar y comentar las aplicaciones
 Preferencia
▪ Puedes distribuirlas tanto gratuitas como de pago
 Administración
▪ Estadísticas de descargas, puntuaciones y comentarios
 ¿Qué necesito para poder publicar
aplicaciones?
▪ Residir en alguno de los países soportados
▪ Cuota de inscripción única de $25
▪ AppStore $99/año
▪ Encontrarse en alguno de los siguientes países
▪ Australia, Austria, República Checa, Francia, Alemania, Italia,
Países bajos, Polonia, Singapur, España, Reino Unido,
Estados Unidos
▪ Cumplir la política de contenido
▪ Cumplir las leyes de exportación de EEUU
 Si queremos además vender aplicaciones
 Registrarse como comerciante de Google Checkout
(Gratuito)
 Encontrarse en alguno de los siguientes países
▪ Austria, Francia, Alemania, Italia, España, Reino Unido, Países
bajos, Estados Unidos.
 Tarifas
 70% para ti, 30% para Google
▪ Si pones una aplicación a 1.00 €, te ingresarán 0.70 € en tu
cuenta
▪ Tu controlas los reembolsos a los clientes (pueden ser
parciales)
▪ Máximo 24 horas después de la compra
▪ En la AppStore son 90 días
▪ En caso de reembolso, Google también devuelve su parte
▪ En la AppStore, el desarrollador devuelve el 100% (en teoría, te puedes
arruinar)
 Aplicaciones que se pueden ver en el Market
 Gratuitas
 De pago
 Gratuita + Publicidad
▪ Varias plataformas publicitarias
▪ Ej. AdMob (Comprada por Google recientemente)
▪ Capaces de funcionar off-line
 Gratuita limitada y completa de pago
▪ Conocidas como versiones Lite
▪ Buena forma de promoción/prueba
 Android Market
 Mejorable…
▪ No tiene códigos promocionales
▪ Interesante para entregar a medios, regalar, hacer sorteos,
etc.
▪ Falta una plataforma fuera de Android
▪ Poder buscar/comprar/descargar aplicaciones desde el PC
▪ Aplicación Market muy mejorable
▪ Escaparate de promoción
▪ Más descargadas del mes, semana, día…
▪ Integración con YouTube
 Versionado
 En el fichero de manifiesto de la aplicación
▪ android:versionCode
▪ Número entero, debe incrementarse con cada nueva versión
▪ Será el usado por otras aplicaciones para determinar si se trata de una
versión más o menos nueva (Ej. Market)
▪ android:versionName
▪ Tipicamente <major>.<minor>.<point>
▪ Es usada para mostrarse al usuario
▪ No tiene porque tener ese formato
 Firma
 Necesario para poder instalar el apk en Android
 Clave pública y privada puede ser auto-firmada por
nosotros
 No uses la clave con la que publicas en desarrollo!
▪ Eclipse y Ant soportan dos modos de compilación
▪ Debug  Gestiona automaticamente las claves generadas para tal
proposito
▪ Release  Usa la nuestra, teniendo que proporcionar el password si es
necesario

 Guarda la clave privada en lugar seguro!

▪ Si la pierdes, no podrás publicar actualizaciones
 Firma
 Puedes usar las utilidades estándar de java
▪ keytool y jarsigner
 Una vez firmada, usa zipalign para optimizar el apk
▪ Reduce la cantidad de memoria requerida al ejecutar la
aplicación
▪ Alinea los ficheros a 4-byte, por el uso de mmap
Creación de aplicaciones móviles en Android

Android Market
Developer Console
 Publicación de aplicaciones
 Android Developer Reference
▪ http://developer.android.com/guide/practices/screens_support.html
▪ http://developer.android.com/guide/practices/design/performance.html
▪ http://developer.android.com/guide/practices/design/responsiveness.html
▪ http://developer.android.com/guide/practices/design/seamlessness.html
▪ http://developer.android.com/guide/publishing/app-signing.html
▪ http://developer.android.com/guide/publishing/versioning.html
▪ http://developer.android.com/guide/publishing/preparing.html
▪ http://developer.android.com/guide/publishing/publishing.html

 Android Market Development

▪ http://market.android.com/support/