Android Intro
•Descargar como PPT, PDF•
9 recomendaciones•4,652 vistas
Materiales del Seminario "Introducción a Android" impartido por Paradigma Tecnológico y Javahispano el 25 de noviembre de 2010 en San Pablo CEU
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Android Intro
Similar a Android Intro (20)
Más de Paradigma Digital
Más de Paradigma Digital (20)
Último
Último (16)
Android Intro
- 2. ¿Qué es y de dónde viene?
- 3. ¿De dónde viene? Operadores Móviles Fabricantes de teléfonos Semiconductores Comercialización Software
- 4. Línea cronológica 5 Nov, 2007 34 Líderes tecnológicos forman la Open Handset Alliance 12 Nov, 2007 Primeras pruebas de desarrolladores con el SDK 28 Ago, 2008 Se anuncia el Android Market 23 Sep, 2008 Primer teléfono Android 23 Sep, 2008 Android 1.0 SDK release 1 disponible 21 Oct, 2008 Código fuente liberado
- 6. Arquitectura
- 10. Ejemplo Entorno de Desarrollo
- 21. Ejemplo Crear Nuevas Actividades
- 25. Ciclo de Vida (II)
- 26. Ejemplo Ciclo de Vida
- 27. Geolocalización
- 30. Conclusiones
- 32. ¿Preguntas?
Notas del editor
- La plataforma Android nace a partir de la iniciativa de un grupo de compañías que tenían un idea clara: construir una nueva experiencia de usuario para los usuarios de dispositivos móviles. Este grupo de compañías, en gran medida liderada por Google, creó la Open Handset Alliance con la idea de remar todos hacia el mismo sitio con el objetivo de conseguir lo que querían y como hoy en día todo podemos ver parece que lo están consiguiendo. Parte del éxito de esta alianza es el numero de empresas que lo forman, que todas son lideres tecnologicos y el sector del mercado en el que están especializadas. Esta alianza está formada por: Operadoras móviles Fabricantes de móviles. Fabricantes de chips. Empresas software. Compañías de comercialización. Y las empresas que andan detrás de esto tienen nombres como Google, HTC, Motorola, T-Mobile, Telefónica, Vodafone, Nvidia, Ericsson, Dell, Toshiba… Con esta alianza lo que se pretende es que cada miembro se comprometa a fomentar un ecosistema móvil abierto permitiendo a la industria innovar más rápidamente y responder a la demanda de los consumidores. El primero objetivo ha sido crear la plataforma Android con la ambición de ser la primera plataforma abierta y completa específica para dispositivos móviles. Al decir “completa” lo que se refieren es que proporcionan a operadores móviles, fabricantes y desarrolladores todo lo necesario para trabajar con ella.
- La Open Handset Alliance se fundó en Nov de 2007. En esa época eran 34 lo miembros de la alinza, actualmente son más de 70. Unos días más tarde salió a la luz la versión beta del SDK para que los primeros desarrolladores empezases a utilizar y generar un feedback. Además se convocó un concurso de aplicaciones con bastantes premiso para animar a la comunidad a empezar a generar código. Un año después se anunción el Android Market como principal canal de distribución para las aplicaciones. En septiembre de se año se anuncia el primero movil Android y al mismo tiempo se da a conocer la version 1.0 del SDK. Un mes mas tarde se acabaría con la liberación del código de esta primera version. Desde entonces hasta hoy en día.. Pues han pasado muchas cosas. Se han multiplicado el número de terminales existentes y el número de compañias que lo ofrecen y vamos ya por una version 2.2 del sistema. Dentro de poco la 2.3
- Vamos a ver ahora qué es Android. Android no es solo un sistema opertivo que llevamos en nuestros móviles. Android en realidad es un conjunto de software para dispositivos móviles que incluye el sistema operativo, middleware (que no permite crear una capa de abstracción entre el hardware y como nosotros accedemos a este hardware a través de métodos definidos) y aplicaciones fundamentales tales como un navegador integrado, clientes de email, gestión de contactos de nuestra agenda. Android está construido sobre el núcleo Linux 2.6 y es un proyecto Open Source. Esto implica muchas cosas pero al final con lo que uno se queda es que detrás va a tener una comunidad muy grande que la va a apoyar y donde vas a poder encontrar muchisima información, además de una libertad para hacer cosas con tu teléfono que no te proporcionan otras plataformas. (Esteve Jobs dijo que quien quisiera ver porno se comprara un Android pero bueno, creo que con un Android puedes hacer otras muchas cosas además de ver porno) Android está diseñado para poder acceder a TODAS las capacidades de tu dispositivo. A TODAS. Esto se puede hacer gracias a que la plataforma te proporciona librerias y herramientas para ello. Puede acceder a la cámara, al gps, al cliente de SMS,… De esta manera quitá los límites que solían tener la aplicaciones que programabamos antiguamente y que solo nos dejaba acceder a determinados recursos del teléfono. Gracias a esto el abanico y la riqueza de las aplicaciones que se puede constuir es muchisimo mayor.
- Como he comentado antes la base de la arquitectura Android un núcleo Linux en la versión 2.6. Esta capa sirve de abstracción entre los elementos hardware y el resto de la pila software que vamos a ver. Por ser la capa más cercana al hardware es la que se encarga de gestionar los servicios más básico como la administración de procesos y de memoria, la conectividad o los controladores. Por encima del núcleo tenemos una capa de bibliotecas. Estás bibliotecas están escritas en C/C++ y la utilizan varios componentes del sistema Android. Como es la capa más cercana al núcleo vemos que tiene por ahí LIBC que es la librería estándar C para la versión de Linux embebida. También tiene librerías para la reproducción multimedia, para el acceso a BBDD o para aceleración 3D por ejemplo. Android Runtime: Android en lugar de apostar por instalar una máquina virtual de java como puede ser Java ME creó su propio máquina virtual que llamó Dalvik Es una máquina virtual que ejecuta archivos en un formato ejecutable propio. Estos ejecutable se crean a partir de código java mediante una de las herramientas que proporcionan el SDK. Esté formato está optimizado para hacer un uso eficiente de memoria ya que no hay que olvidar que todo este invento se va a ejecutar sobre dispositivos con recursos bajos. Una de las características de esta máquina es que está diseñada para que se pueda ejecutar múltiples instancias de ella. De esta manera cada aplicación de Android corre en su propio proceso y además con su propia instancia de la maquina virtual. Sobre la máquina Dalvik se encuentran la librerías que te permiten utilizar casi todas la bibliotecas básica de Java. Application Framework: Por encima de estas capas se dispone del Application Framework que te proporciona las clases necesarias para hacer aplicaciones Android y un nivel de abstracción para el acceso a recursos hardware. Además te proporciona lo necesario para administrar la interfaz de usuario y los recursos de la aplicación. Las aplicaciones del core utilizan este mismo framework! Application Layer Por último tenemos la capa de aplicación. Aplicaciones escritas por el desarrollo usando las de la API. Estas aplicaciones están escritas en código java y se apoyan en las clases y servicios del application framework.
- Para empezar a desarrollar con Android nos tenemos que bajar el Android SDK. Hay versiones para Linux, Windows y MAC y en este paquete van las herramientas y las APIs necesarias para hacer una aplicación completa. Acutalmente andan por la versión 2.2 y la 2.3 está a punto de salir. Como he comentado las aplicaciones de Android están escritas en java por lo que necesitamos el JDK en alguna de las dos últimas versiones. Y aunque esto no es obligatorio, esta bien tener un IDE de Java. Nosotros hemos utilizado eclipse que funciona bastante bien y tiene un plug-in que te facilita bastante la vida.
- El SDK nos provee de un emulador de Android para poder probar nuestras aplicaciones. Este emulador es un implementación de la máquina virtual Dalvik lo que hace que el comportamiento de nuestros aplicaciones sobre este sean muy muy similar al que tendrán sobre casi cualquier teléfono Android. Cuando trabajéis con ello o lo arranquéis veréis que le cuesta un poco pero es un coste que hay que sufrir para que te pueda emular absolutamente todo. Tiene un acceso total a la red, podéis simular recibir SMS, podéis poner el móvil en horizontal o vertical, el trackball… vamos casi cualquier cosa. El plug-in ADT del eclipse además integra el emulador de la SDK con lo que nos va a ser muy fácil utilizarlo. Si no siempre se puede acceder a el por telnet y la línea de comandos. Para utilizar el emulador primero es necesario crear una dispositivo virtual de Android. Con esto nosotros vamos a configurar tanto el software que va a correr en el emulador como el hardware que se va a simular que tiene nuestro teléfono. En el dispositivo virtual se pueden configurar muchas cosas. Para crearlo vamos primero a tener que decir que versión del sistema operativo vamos a usar para esta máquina. Esta utilidad es muy buena de cara a probar nuestra aplicación en las diferentes versiones de Android. También podemos decirle la resolución de pantalla que queremos. Igual que antes esto es muy útil ya que cada vez más hay más número de pantallas de diferentes tamaños y calidades. También podemos indicarle si queremos que tenga capacidad para una tarjeta SD y de que tamaño la queremos. Podemos decirle si queremos pantalla táctil o no. Si quisiéramos probar como funciona el trackball también podemos hacerlo Si queremos simular el GPS, también podemos hacerlo. En definitiva, el dispositivo virtual nos creamos una imagen del teléfono sobre el que vamos a probar nuestra aplicación. Generalmente cuando diseñas un aplicación te dicen: queremos compatibilidad desde la versión 1.6 de Android y para este móvil que el de gama más baja donde queremos que funcione. Desde nuestra experiencia nosotros lo que hacemos es programar la aplicación para la versión más alta de Android emulador hardware de nivel medio y cuando ya lo tenemos funcionando probamos sobre otras versiones y adaptamos lo que sea necesario. De todas formas la compatibilidad entre versiones a nosotros nos ha resultado bastante alta.
- El emulador nos va a servir para probar nuestra aplicación viendo como se ve, como se comporta y como se interacciona con ella. Sin embargo lo que a nosotros nos interesa de ver es que está pasando por debajo. Para esto tenemos una herramienta de depuración que se llama DDMS que utiliza el Android Debug Bridge para comunicarse con nuestro emulador o nuestro teléfono. Con esta herramienta podemos ver todos los procesos que están corriendo en nuestra dispositivo y controlarlos. Podemos ver también el estado de la memoria y en que estado se encuentra la pila. También podemos explorar el sistema de fichero del teléfono y ver si estamos accediendo a él correctamente guardando algo en un fichero ya que se pueden recuperar los archivos del dispositivo. Y lo más útil, podemos ver los logs que va soltando el sistema. El plug-in ADT inluye un vista en el eclipse que nos va a dar acceso a todo esto.
- Service: es la solución cuando queremos hacer trabajo en background. Cuando necesitamos acutalizaciiones periodicas y no interaccionar con un interfaz. Content provider: es el mecanismo genérico de android para compartir datos entren aplicaciones. Esto forma parte de la idea de separa la capa de datos de la de aplicación y de esta manera poder reutilizar los datos que se encuentren en mi teléfono. Por ejemplo si quiero acceder a mis contactos. BroadcastReceiver: ejemplo Bateria baja
- Activity Este componente es el principal a la hora de empezar a implementar. Una Activity representa una pantalla de nuestra aplicación. Generalmente nuestras aplicaciones están formadas por varias pantallas y por lo tanto por varios Activities. Por ejemplo podemos tener una primera pantalla con una lista de contactos y al pulsar sobre uno de ellos se abre otra pantalla con los detalles de este contacto. Detrás de cada una de estas pantallas va a haber un Activity. En Android las actividades se agrupan en pila de tal forma que cuando se lanza una actividad con su nueva pantall esta se coloca en la cima de la pila. La actividad se encuentra en la cima de la pila es la que visualmente se encontrará en primera plano y responderá a las acciones del usuario. Si se finaliza esa actividad o se pulsa sobre el botón back del teléfono la actividad que estaba justo debajo de esta pasa a ser la cima del la pila y se coloca en el primer plano. Todas las Actividades de una aplicación tienen que ir declaradas en un fichero que se llama AndroidManifest.xml. En este fichero además de esto van declaradas algunas otras cosas que según avancemos lo iré explicando. De momento quedaros con que las actividad las tiene que declarar aquí. Si queremos mostrar una nueva pantalla tendremos que crear una clase que herede de la clase Activity. Al crearla veremos que podremos sobrescribir método onCreate(Bundle …). Esté método se ejecuta una única vez cada vez que se crea la Activity y es donde se suele inicializar las variables necesarias y donde se asigna la interfaz de usuario que se desea. Para asignar una interfaz de usuario a una actividad se usa el método setContentView() en el método onCreate() y como parámetro se le puede pasar un elemento gráfico como podría ser un textBox. En este caso la interfaz gráfica consistiría unicamente en un textbox. Sin embargo nosotros vamos a querer formar vistas más complejas que una caja de texto. Con android los diseños de la interfaz gráfica se realiza en archivos XML y cuando queramos asignar una interfaz a nuestra actividad lo que le pasaremos a este método será este XML. Os voy a explicar como se construye una pantalla simple y os pongo un ejemplo para que podemos entender mejor todo esto.
- En Android hay dos maneras de construir interfaces gráficas: mediante código java en nuestra clase o mediante código XML. Como habéis visto antes la primera vez he construido una caja de texto con código java y he dicho que esa iba a ser mi pantalla. Y la segunda he puesto R.layout.main. Bien, pues con ese R.layout.main vamos a estar llamando a un fichero XML en el que está definida como va a ser esa pantalla y realmente está va a ser la forma más útil y eficiente de construirlas ya que independizas la capa de presentación del resto del código. Generalmente vamos a tener un fichero por cada pantalla que vamos a mostrar. Android te proporciona muchos elementos gráficos que te permiten diseñar tu aplicación más rápidamente ya que vas a poder modificar los atributos del elemento y además te van a proporcionar los elementos necesarios para contrar los eventos sobre los objetos gráficos. Principalmente tiene dos categorías: los Widgets y los layouts. Los Widgets son los típicos elementos que se pueden encontrar en cualquier interfaz, botones, cajas de texto, radiobutton… aunque hay algunos más avanzados que nos van a facilitar mucho la vida. Por ejemplo los ListWiews nos va a generar la estrucutura necesaria para hacer un lista y poder rellenarla sin mucho código. Los Layouts son elementos que controlan y contienen tanto Widgets cómo otros layouts. Por ejemplo LinearLayout ordenan los elementos que contienen en filas o columnas dependiendo de si queremos orientación vertical u horizontal. Los RelativeLayout ordenan lo elementos en función de posiciones relativas, es decir, si tenemos dos botones le podemos decir que el botón 2 lo queremos a la derecha del botón 1. Estos layouts se puede anidar entre si por lo que las combinaciones que se puede hacer bastante amplias. Ojo, Android tiene un sistema de jerarquia de vista…. Bla bla bla, cuidado con el númeor de niveles que ralentiza y penaliza… bla bla bla Eclipse integra un editor gráfico para las interfaces y te hace una preview de cómo va a quedar aunque veréis que no es todo lo potente que nos gustaría. La verdad es que hay pocas herramientas gratuitas para construirlas. Hay una que se llama DroidDraw que de las gratuitas es la mejor que he encontrado y para crearte una base de tu pantalla no está mal. Puedes ir arrastrando elementos y te genera un código. Al final en cuanto os familiaricéis un poco con el XML vais a acabar tecleando directamente el código porque veréis que es bastante sencillo. Vamos a ver un ejemplo para que os enteréis un poco mejor de que va todo esto.
- La clase R es un clase autogenerada que contiene en todo momento una serie de constantes con los ID de todos los recursos de la aplicación contenidos en la carpeta de recursos, /res/ La carpeta DRAWABLE: hay tres en función de las capacidad del teléfono y la densidad de pixeles. Ojo con los nombres que le ponemos a los recuros. Han de ser nombres válidos según la sintaxis Java.
- Ahora vamos a ver como podemos hacer que nuestra aplicación reaccione si el usuario toca la pantalla o hace una determinada acción. Como he comentando antes Android nos proporciona bastante elementos gráficos a los que podemos modificar sus forma y sus atributos pero además nos proporciona interfaces con métodos que saltarán ante los diferentes eventos que se produzcan en el teléfono. Lo que se hace es recuperar el elemento grafico de la interfaz, asignarle el Listener e implementar el método listener que corresponde a la acción determinada. Vamos a ver un ejemplo práctico. Pondremos una caja de texto editable, un botón y un caja de texto simple y queremos que al pulsar el botón el texto de la caja editable aparezca en la caja de texto. Aunque aquí he puesto el implements lo he puesto para que se ve más claro aunque en mucho sitios veréis definido el método en el propio setOnClickListener.
- La Intents es el mecanismo utilizado en Android para intercambiar mensajes entre una actividad y otra o entre distintas aplicaciones. Se puede utilizar para varios objetivo dentro de la aplicación pero vamos a ver el más común que es para arrancar nuevas actividades. Para arrancar una actividad se llama al método startActivity (Intent) al que se le pasa como argumento un objeto de la clase Intent. En el primer caso para abrir explícitamente la actividad que nosotros deseamos le pasamos como parámetros el contexto de la aplicación y la clase Activity que queremos arrancar. El primero parámetro, el Contexto, no lo he menciona aún. Para que tengáis una primera idea el contexto es un clase que proporciona acceso a los recursos de la aplicación, acceso a la base de datos y otras cosas. La clase Activity hereda de la clase Context por lo que toda clase que herede de Activity también será un Contexto en sí. Por eso el MyActivity.this. En el momento que se ejecute el startActivity() se arrancará la actividad MySecondActivity y se volverá visible para el usuario. Después para terminar la actividad nueva que hemos comenzado tenemos dos opciones: pulsar sobre el botón “Back” del teléfono o ejecutar en la nueva actividad el código finish(). Si queremos que la actividad nueva nos retorne algo podemos utiliza el startActivityForResult. Le pasamos el intent igual y un ID que elegimos nosotros por si queremos identificar desde donde estamos llamando a la actividad. A veces es necesario discernir entre si se llama desde un lado u otro. En la Actividad destino hacemos un setResult con el código y si quisieramos un intent con objetos. En la clase origen sobrescribimos el método OnActivityResult donde nos llegan lo datos (un intent, el resultcode y el requestcode) Implícitamente: Como comentaba antes también hay una manera implícita de abrir nuevas Activities. Cuando utilizas esta forma al intent le das un acción que quieres ejecutar y en alguno casos algún dato que necesite. Cuando utilizas este Intente para comenzar la actividad Android en tiempo de ejecución busca la que mejor se ajuste a lo le estas pidiendo y te la lanza. De esta manera estás reutilizando la funcionalidad de otras aplicaciones sin necesidad de saber que aplicación es necesaria para ello. El caso que he puesto es aquel en el que por ejemplo queremos realizar una llama desde nuestra aplicación y no queremos implementar un marcador. Escribiendo la acción y el teléfono se lanzar el marcador propio de android. Pag. 112 del libro de Wrox Intents. Pag. 172
- Como hemos visto antes con la llamada implicítia Android resuelve que tipo de aplicación se ajusta más a la acción que nosotros queremos hacer. Nosotros también podemos hacer llamadas implícitas en nuestra aplicación y que sea una de nuestras actividades las que se lance gracias al artefacto Intent-Filter Los intent-filters se definen en la etiqueta Activity en el AndroidManifest.xml y definen el tipo de Intent que esa actividad va a escuchar y a reaccionar ante ellos. Es decir definimos que tipo de acción es capaz de llevar a cabo nuestra actividad. Con esto no solo conseguiremos que esta actividad responda a peticiones de nuestra propia aplicación sino que incluso cualquier otra aplicación que desee llevar a cabo una acción que encaje con nuestra actividad la lance. Cuando nosotros creemos un Intent y hagamos startActivity Android va a resolver el tiempo de ejecución que tipo de actividad se ajusta mejor a lo que queremos hacer. Si ese intent concuerda con alguno de los intent-filter que hemos definido entonces Android resolverá que esa es la actividad que tiene que lanzar y la arrancará. Para definir un intent-filter se utilizan varias etiquetas: action: usa el atributo android:name para espcificar el nombre de la acción que se va realizar. Este parámetro ha de ser un String único. categroy:utilizar el atributo android:name bajo que circunstancias se va a realizar la acción. Dentro de un intent-filter se puede definir multiples categorias y puedes utilizar las tuyas propias o las estándar de android: ALTERNATIVE: especifica la acción que se va a hacer en lugar de la que se hace por defecto para el tipo de datos pasados en el intent. ELECTED_ALTERNATIVE: cuando hay una lista posible ayuda a decidir cual es la que se va a ejecutar. BROWSABLE: si quieres que tu aplicación responda eventos de tu navegador como interceptar links a una determinada dirección DEFAULT: define que se ejecuta la acción por defecto para el tipo de datos que se le pasa. GADGET: si queremos que nuestra Actividad pueda ejecutarse empotrada en otra. HOME: si pones esta categoría y no defines una acción estas definiendo un alternativa al Home nativo. LAUNCHER: definiendo esta categoría consigues que tu actividad aparezca en el menú de aplicaciones de Android. Data: esta etiqueta te deja especificar a que tipos de datos va a reaccionar tu actividad. Puedes incluir varios data si quieres que reaccione ante diferentes tipos de datos. Además puede combinar esta etiquetas con varios atributos android:host: lo dice el propio nombre, especifica un host valido. android:mimytype: especificas tipo de componente que tu actividad es capaz de procesar. android:path: especifica un path para URI que incluyes en el intent android:port: puerto android:scheme: ejeplo “http” o “content” El primer Intent-Filter con el que nos vamos a encontrar es aquel que es necesario para que la aplicación se pueda lanzar como una aplicación cualquiera. Para ello se implementa un intent-filter con la acción MAIN y la Categoria LAUNCHER. La Acción main especifica que la Actividad MyActivity es la principal y la categoria LAUNCHER hará que esté disponile desde el menú de aplicaciones. Como he comentado Android resuelve los intents en tiempo de ejecucción. Cómo los resuelve. Cuando llamar a startActivity de forma implicita Android hace una lista con todos lo Intent-filter disponible para la acción especificada y si resuelve que varios son adecuados te enseñará una lista para que elijais cual quieres lanzar. (Una intent-filter será seleccionado si tiene la misma acción especificada que el intent o si no se ha definido acción en el intent-filter y si tiene todas las categorías del intent o si no se ha definido categoría en el intent-filter) Intent-filter. Pag. 178. Wrox; Broadcast Events/Receiver, pag. 19
- Ahora que hemos visto como podemos arrancar una actividad desde otra pensamos.. ¿y como le paso algun dato si quiero? Pues bueno, se puede utilizar variables estáticas como en java aunque no es lo recomendable. Para el paso de parámetros android utiliza también lo intents. Dentro de ellos puedes incluir objetos y después recuperarlos en la nueva actividad que has lanzado. Se pueden pasar tipos básicos, String, Byte, Long, Integer, Array de String… o cualquier otro objeto siempre que este implemente la interfaz parcelable.
- Aprovechando que ya he contando el tema de los intent-filters un podia pensar. Ah, cuando por ejemplo se me está agotando la batería y el teléfono me da un aviso tienen que ser algo así. Bueno, pues lo que utiliza el sistema para darte estos avisos son los eventos de Broadcast. Estos eventos de broadcast se difunden con un Intent en el que va una acción definida y unos datos y para soltarlos al sistema se utiliza el método sendBroadcast(). Aquí os he puesto un ejemplo en que creo un intent con una acción definida por mí que es “Mensaje recibido”. La idea es que yo tengo un servicio que cuando me llega un mensaje envío un mensaje broadcast y por otro lado tengo un receptor que escucha este tipo de mensaje. Cuando le llega uno con la acción “mensaje_recibido” entra en el OnReceive y hace lo que yo quiera. Por ejemplo podría mostrar una pantalla con un aviso y el nombre de quien me ha enviado el mensaje. Android tiene muchos mensaje ya definidos, por ejemplo el de batería baja, el de la llamada entrante.. Y el sistema suelta esto mensaje así que yo podría hacerme un clase que escucha al evento Batería baja y por ejemplo hacer que mi teléfono se apagase si el nivel de batería es de menos del 10 %.
- Como os decía al principio un servicio es un componente de una aplicación sin interfaz que corre en background. Los servicios se suelen utilizar cuando se crea una aplicación que requiera actualizaciones periódicas y que necesite poca o ninguna interacción con el usuario. Por ejemplo el reproductor de música, o el servicio de geoposicionamiento. Para crear un servicio crea un clase que extienda de Service y sobrescribir el onBind y onCreate (). Generalmente es bueno sobrescribir el onStartCommand que es el método que se llama cada vez que se arranca un Servicio con el startService (). El método onStartCommand devuelve una constante que controla como responderá el sistema si el servicio se reinicia después de que este haya terminado. Lo más común es que devuelva la constante esa que veis en la transparencia que básicamente le dice al sistema que cada vez que se reincie el servicio se ejecute el método onStartCommand. Hay que tener en cuenta que los servicios se lanzan en la hebra principal de la aplicación por lo que es conveniente hacer el procesado gordo del servicio en un hebra que arrancamos en este método onStartCommand y cuando esta termine de hace lo que sea parar el Servicio. Si quieres crear un servicio y que puedan interaccionar con él entonces deberás sobrescribir el método del servicio onBind() . Desde donde quieras conectarte al servicio tendrás que utilizar un ServiceConnection y sobrescribir los método onServiceConnected y onServiceDisconected . Una vez conectado al servicio tendrás disponible todos lo método y atributos de este servicio. Binding. Pág 331.
- Ahora que ya hemos visto los primeros pasos para construir una aplicación y que hemos introducido como arrancar varias actividades vamos a ver como es el ciclo de vida de una aplicación en Android. Es bastante importante tener los diferentes estados para poder hacer una aplicación que sea estable. Como os he contado antes En Android la actividades se agrupan en pila. De tal forma que cuando en nuestra aplicaciones lanzamos una nueva actividad y esta se hace visible se pone arriba de la pila dejando a la anterior justo debajo. Si nosotros pulsamos sobre el botón BACK que tienen los móviles o terminamos la actividad esta se retira de la pila y vuelve a estar visible la anterior y posicionada arriba de la pila. Cuando el terminal anda justo de recursos echa un vistazo a esta pila y decide que actividades se va cargar. Por eso tenemos que tener especial cuidado a la hora de por ejemplo guardar datos sensibles o el estado en el que se encuentra nuestra aplicación para que si el sistema decida matar algún proceso podamos recuperarlo después. Una Activity puede tener 4 estados. - Active: es el estado correspondiente a cuando la actividad se encuentra en primer plano y respondiendo a las acciones del usuario. En este punto la actividad se encuentra en el tope de la pila. Cuando actividad se encuentra en estado esta con la prioridad más baja si el sistema decide que tiene que matar algún proceso. Paused: se corresponde a cuando la aplicación está visible pero ha perdido el foco porque alguna otra actividad se ha puesto sobre ella y no la tapa del todo o tiene alguna transparencia. En este punto la actividad mantiene todo sus estado y sus datos como si estuvier activa pero con la diferencia de que no responde a las acciones del usuario.. Stopped: cuando la actividad ha sido totalmente tapada por otra. Auqnue aquí también mantiene todos sus datos y estado si el sistema requiere matar algún proceso por estaba bajo de recursos esta actividad tiene muchas papeletas para ser matada así que es importante que cuando la aplicación pase a este estado salvar lo necesario. Inactive: que es cuando la actividad no se ha arrancado o se ha matado su proceso. En este estado la actividad no se encuentra ni en la pila de actvidades. Las transiciones entre estado y estado se notifican mediante llamadas a los siguiente métodos onCreate // onStart // onResume // onPause // onStop // onDestroy Todos estos métodos se suele utilizan sobrescribiéndolos en nuestras actividades para que hagan algo cuando la actividad cambia de estado. Pag. 112 del libro Wrox.
- El ciclo de vida completo de una actividad abarca desde la llamad al método onCreate hasta el método onDestroy(). En el primero es donde se crean las variables, se crean las vistas y recursos y en el último donde se liberan. Estos métodos se llaman solo una vez el primero cuando se crea la actividad y el ultimo cuando se destruye. El ciclo correspondiente a la parte visible va desde el método onStart() hasta el onStop(). Estos métodos se pueden llamar múltiples veces ya que nuestra aplicación puede estar corriendo y una veces visibles y otras no. Nuestra aplicación estará en primer plano y con el foco del usuario desde que se llama al onResume() hasta el onPause(). En el onPause se suele utilizar salvar datos en persistencia que el usuario haya metido en la aplicación o para por ejemplo alguna animación para que no consuma tanta CPU. Android define unos cuantos puntos en lo que califica la actividad como apta para ser matada si fuera necesario. Estos puntos son cualquier momento después de que los métodos onPause, onStop o onDestroy terminen de ejecutar el código que llevan dentro. Como el onPause es el primero que se llama es importante salvar todo los datos que puedan se sensible a memoria persistente en este método. No os dejéis engañar, que se defina que tras estos método el sistema se pueda cargar la aplicación no quiere decir que no lo pueda hacer en otros puntos. Pero bueno, en condiciones normales de baja memoria se comportará así. Si el sistema anda muy mal y se empieza a colgar pues es como cualquier sistema, matará lo que haga falta antes de morir. Salvar el estado de la aplicación Cuando el usuario por ejemplo está con la aplicación y la da al botón para volver a la Home lo que espera es que si más adelante abre la aplicación se la encuentre en el mismo estado en el que la dejó. Para capturar este estado se puede implementar el método onSaveInstanceState() que android llama justo antes del onPause(). A este método se le pasa un objeto Bundle donde se puede almacenar el estado de nuestra aplicación y parejas clave/valor. Cuando la actividad se arranca de nuevo el Bundle se le pasa al onCreate y a un método que se le llama después del onStart(), onRestoreInstanceState(). OJO! Puesto que el onSaveInstanteState() no siempre se llama no hay que utilizar para guardar cosas en persistencia. Para eso usar el onPause.
- Ahora que ya sabemos un poquito sobre cosas básicas de android voy a enseñaros como hacer un ejemplo simple de geolocalización utilizando el GPS del teléfono y los mapas de google. Hoy en día la geolocalización está en todos lados, haces un comentario en twitter geolocalizados, las cámaras de foto ya incluyen gps para decirte donde la tomaste la foto.. Así que creo que está bien saber como usar la geolocalización. Android te da acceso a los servicios de geolocalización a través del paquete android.location. El principal componente de este paquete es el servicio LocationManager y el LocationProvider. El primero te da los medio necesarios para acceder a los servicios de geolocalización y el segundo representa la forma de localización que se va a utilizar (por ejemplo, con tu móvil te puedes geolocalizar a través de Wifi, GPS o de la triangularización de las antenas que te dan cobertura). Esto es importante porque las diferencias entre el consumo de batería y recursos entre una u otra tecnología son bastante importantes Utilizando el LocationManager podrás hacer varias cosas: 1. Hacer peticiones al LocationProvider para obtener la última ubicación conocida 2. Asociarse a un LocationProvider para que nos de actualizaciones de la posición 3. Determinar alertas para detectar cuando el usuario se aproxime a una ubicación determinada. Para seleccionar un LocationProvider utilizamos el método getProvider al que le pasamos que tipo de tecnología vamos a usar. Aunque lo más útil y común no es que tu selecciones el sistema que vas a usar si no que lo le digas los requisitos que necesitas para el servicio y que sea Android quien decida de las tecnologías que tiene el teléfono cual te puede proporcionar lo que tu necesitas. Es posible que tengas un teléfono sin GPS así que si tu pones a piñón que quieres utilizar el GPS pues no va a funcionar en muchos teléfonos. Para eso se utiliza la clase Criteria. A esta clase le dice que si quieres por ejemplo utilizar un precisión alta de localización