Cicle de vida
El cicle de vida d'una aplicació està íntimament lligat al d'una activitat, i el seu cicle de vida també. Per a conèixer millor com funcionen les aplicacions veurem com s'organitzen en l'àmbit d'usuari.
Un concepte important en l'Android són les tasques o tasks. Una tasca conté una o diverses activitats, i d'alguna manera és la tasca d'usuari per a aconseguir alguna cosa.
Exemple de tasca
Per a poder escriure un correu electrònic tindrem:
- L'activitat de gestor de correu electrònic, per a veure la llista.
- L'activitat del client de correu electrònic; després se seleccionarà compondre un correu nou.
- Posteriorment, per a triar el destinatari, l'activitat del selector de contactes.
- I si volem afegir una fotografia, l'activitat de la galeria.
Piles de tasques i d'activitats i les seves transicions
Es pot sortir d'una tasca prement el botó Enrere (Back) o bé amb el botó Inici (Home). En el cas del botó enrere es destruirà la tasca i totes les activitats, i per tant si torna a aquesta activitat s'haurà perdut l'estat (llevat que es desi explícitament). En canvi, si se surt de la tasca per mitjà del botó Inici (Home) l'estat de l'activitat està implícitament desat.
Per tant, una tasca té diverses activitats, i la raó és que una activitat pot invocar una altra activitat, i totes són en la mateixa tasca. Quan una activitat en crea una altra ho fa per mitjà d'un intent, i ho pot fer de dues maneres: esperant resultats (startActivitatForResult()) o no esperant-los (startActivitat()). En tots dos casos, una vegada finalitzada amb l'activitat creada, es torna a l'activitat creadora. Això es pot produir moltes vegades gràcies a les piles d'activitats dins d'una tasca. Aquestes tasques també tenen la seva pila per a permetre interrupcions i en certa manera permetre múltiples fils d'execució.
ExempleSi estem treballant amb una aplicació de calendari i veiem en una cita que hi ha una adreça electrònica i volem enviar un correu electrònic a aquest compte, però en aquest punt ens truquen al telèfon.
Com a resultat, a la pila de tasques tindrem dues tasques, una l'aplicació de calendari, i una altra la corresponent a l'aplicació de telèfon, a causa que la segona ha interromput la primera.
A més la primera tasca tindrà diverses activitats, en concret la llista d'elements del calendari, l'activitat per a veure un element del calendari concret, i finalment l'activitat que correspon a una altra aplicació, que és la de tramesa de correu electrònic.
Quan finalitzi la tasca de telèfon tornarem a la tasca anterior i amb l'activitat de correu electrònic.
Per tot això les activitats s'han de comunicar entre si, i invocar una activitat sembla una cosa bastant habitual, i això és un gran punt a favor de l'Android. Però d'altra banda es defensa fer que les activitats estiguin tan poc acoblades entre si com sigui possible. Això s'aconsegueix amb els intents.
Hi ha activitats que poden tenir diversos punts d'entrada i per a això defineixen diversos IntentFilters. Amb aquests IntentFilters també es poden fer activitats que esperin intecions conegudes, com pot ser enviar un correu electrònic o triar una fotografia. Si hi ha més d'una activitat per a un mateix intent, ens preguntarà quina activitat cal iniciar en produir-se aquesta intenció. La informació dels intents als quals reaccionarà una activitat està definida en el manifest.
Com veiem, una activitat pot estar en diversos estats mentre s'està executant, que es poden resumir bàsicament en tres estats diferents:
- Resumida. L'activitat és en primer pla i té el focus de l'usuari. També es coneix com a estat d'execució o running.
- Pausada. Hi ha una altra activitat en primer pla i està resumida, però la pausada és encara visible. Això pot succeir quan l'activitat en primer pla no cobreix tota la pantalla o bé és parcialment transparent. L'activitat manté tota la informació de memòria i és completament viva, encara que pot arribar a ser destruïda en cas extrem de falta de memòria.
- Acabada. L'activitat està totalment ocultada per una altra activitat, i està en segon pla. L'activitat és totalment viva, però no és visible i pot ser destruïda quan el sistema necessiti més memòria.
Les activitats pausades o acabades el sistema les pot destruir avisant (cridant al mètode finish()) o directament destruint el procés de sistema. Quan una activitat torna després de ser destruïda, es construeix novament.
Per a aconseguir programar les transicions d'estats de manera flexible i mantenible, l'Android proveeix un sistema de repetició de trucada o call back, de manera que el desenvolupador pot prendre les accions apropiades en cada moment. A continuació podem veure a la figura següent quines són:
Cicle de vida d'una activitat en l'Android
Hi ha alguns esdeveniments que són especialment importants:
- onCreate. És el punt d'inici, on hem d'inicialitzar tota la interfície gràfica a més de crear tots els elements. Com que s'hi pot arribar després d'haver estat destruïda, és possible que hàgim de recuperar l'estat d'algun origen persistent.
- onPause i onStop. Són els esdeveniments corresponents a les parades de l'aplicació, i s'ha de desar l'estat de la sessió corresponent. Després d'aquests esdeveniments l'aplicació passa a estar pausada (onPause) o acabada (onStop).
- onResume i onStart. L'aplicació torna de l'estat pausada o acabada i ha de recuperar la informació de la sessió.
- onDestroy. Són el punt on s'han d'alliberar els recursos, i és just abans de destruir definitivament l'aplicació.
Quant al cicle de vida és important tenir en compte que una vegada s'ha passat l'estat onPause (sempre succeeix abans d'un onStop i un onDestroy) l'aplicació pot ser destruïda directament pel sistema operatiu. Per tant, la manera segura d'emmagatzemar la informació de l'estat de la sessió és en el mètode onPause, però cal fer-ho amb compte, perquè estem bloquejant l'activitat següent i podem empitjorar l'experiència d'usuari.
Per a facilitar la vida al desenvolupador, hi ha un mètode al qual crida el sistema quan creu que és necessari desar l'estat: onSaveInstanceState(). Totes les vistes l'implementen amb una implementació per defecte; per exemple, un camp de text en desa el valor. Es basa a desar parells de clau i valor per a poder ser recuperats a posteriori. En el cas de les activitats succeeix el mateix, i es pot sobreescriure el comportament per defecte per a desar l'estat, i l'objecte on es desen les claus-valor passarà al mètode onCreate quan es recuperi l'estat després de ser destruït; pot utilitzar també el mètode onRestoreInstanceState.
Tot aquests mètodes utilitzats per a gestionar la destrucció i la creació de les activitats tenen especial interès a causa que quan hi ha canvis en la configuració (com l'orientació de la pantalla, l'idioma, l'aparició del teclat virtual) el sistema reinicia l'activitat (es crida a onDestroy i després onCreate). Això és per a facilitar l'aplicació a adaptar-se a les noves configuracions.
