Android me!
El ascenso de Android es innegable. Su creador, Andy Rubin, es el clásico ejemplo de emprendedor exitoso que ha pasado por Microsoft, Apple y Google. En la actualidad, está trabajando en su nueva empresa como CEO, Playground.global.
Parte de su éxito se debe a que era de código abierto, permitiendo así a los fabricantes ajustar el sistema operativo a sus terminales móviles.
Como devs, nos interesan conocer no tanto las características como las capacidades. Las capacidades son los que van a limitar nuestra propagación en diferentes terminales. Por ejemplo: una aplicación que necesite de la capacidad de NFC, no se expandirá por dispositivos sin NFC.
Debemos evitar la duplicación de objetos, crear variables u objetos que no utilizamos. Porque nuestro objetivo es el rendimiento y la eficiencia. La batería debe ser optimizada porque es nuestra aliada.
Conceptos
Application Name: es el que aparecerá en el launcher. TODO en Android está medido, como el título, icono, medidas entre ambos elementos en el launcher. Patrones de diseño. Cuando el nombre de la app es demasiado largo, empiezan a surgir problemas. No se ve completo, gastando batería y recursos en dibujar el texto, calcular si entra en las medidas y volver a dibujar si esto no se cumple. Es un consumo ineficiente que debemos evitar. Company Domain: A partir de aquí se genera el package. Garantiza la unicidad entre las actualmente 3.000.000 aplicaciones que existen en la Play Store. Se suele utilizar el dominio de la compañía, invertido, a modo de webs.
Hay un dominio que se puede utilizar en común para experimentar y no está permitido para publicar para Play Store: com.example. Será la norma para crear nuestras apps en clase.
Librerías
Igual que en las distribuciones de Linux, la mayor parte de las librerías están escritas en C/C++. Son dependientes del sistema operativo.
Las librerías nos facilitan las tareas para programar y utilizar las herramientas en el sistema operativo. Para desarrollar en Android, hablaremos con la API del framework y así poder gestionar. Los Managers nunca se instancian, siempre se obtienen para nuestras aplicaciones, un Manager para desarrollarlas todas. Resource gestiona todos los recursos del sistema, Notification para
Content Providers pueden ser instanciados, para registrarlo en el sistema. Es una Clase con métodos definidos intermediaria para insertar/recoger/añadir/eliminar un elemento. Estos son estandar. Pero sirve para acceder o compartir información del sistema para otras aplicaciones, ya sea de una base de datos SQLITE, fichero XML… Como por ejemplo consultar las llamadas de teléfono.
Toda aplicación de Android se ejecuta en un entorno protegido gracias al Runtime. Se ejecuta en una sandbox que, de tener mal funcionamiento o ser malintencionada, no afecta a otras. Toda aplicación se identifica con un id de usuario, que será la que identifica la aplicación en el sistema operativo. Si tenemos dos apps de un mismo dev, tendrán los mismos permisos. POR ESO, Facebook App y Messenger App se pueden comunicar en el mismo dispositivo. Nunca una aplicación podrá acceder a otra aplicación de dev diferente, porque identificadores son diferentes. Si Facebook App falla, los fallos no se propagan a todas las apps en la pila.
El hilo principal está reservado para las interacciones de usuario, es una UI Thread. Solo escucha los eventos del usuario, tocando pantalla. Si tarda más de cinco milisegundos, debe ir en un hilo independiente.
Manifest
Existe un fichero AndroidManifest.xml que determina cómo se ejecuta la app. Es el punto de entrada de la aplicación, un Main. Determina la estructura de un proyecto. Cuando ejecutamos en Android Studio, funciona porque el manifesto lo permite, especificando localización, permisos a ejecutar, título de app… y entonces la ADB puede ejecutar con los debidos parámetros de ejecución, instalación, con las rutas dadas… Lo primero que se lee cuando ejecutamos es el Manifest, así que las incongruencias entre este y el resto del código ejecutarán fallos.
Las apps se basan en Activities. Las Activities son pantallas independientes que marcan acciones del usuario. A partir de ellas podemos definir una aplicación y sus funcionalidades básicas. Funcionan como un stack, que se acumulan y por las que se retrocede hasta el final de la aplicación.
Toda aplicación tiene un ID único.
Siempre existe un hilo de proceso principal. Y si se sobrecarga, más de 5 segundos sin respuesta es señal de mala salud para la aplicación.
El sistema está protegido de permisos inadecuados, pero se pueden solicitar a la hora de instalar la aplicación. A partir de la versión Marshmallow, se pide a los usuarios que acepten o denieguen los permisos que se piden.
La interfaz gráfica se compone de widgets, que forman una Vista. La Clase View crea componentes o widgets. Una serie de widgets forman un Layout.