PDM Activities
Sumario
Introdución
- Como xa comentamos antes, podemos identificar unha 'Activity' con cada unha das pantallas que conforman unha aplicación.
- Isto non é totalmente certo, xa que podemos ter aplicacións que non teñan interface gráfica, coma os servizos, programas que se executan en segundo plano e que responden a un determinado tipo de evento.
- Neste punto imos explicar os diferentes métodos polos que pasa unha Activity cando se crea, ponse en segundo plano ou se destrúe.
- Indicaremos en cada un deles cales serían as principais funcións que poderíamos programar.
- Tamén explicaremos como se define unha activity a nivel de proxecto.
Preparación previa:
- Partimos que xa temos creado o proxecto inicial como xa indicamos anteriormente.
- Se non o temos creado antes, crea un paquete de nome UD2 e dentro deste outro paquete de nome Activities.
- Vos debe quedar como na imaxe anterior. Indicar que fisicamente temos creados os cartafoles UD2/Activities pero como non existen clases no cartafol UD2/ Android Studio o oculta.
Creando Activities
- Cada vez que se crea unha activity, aparece unha nova entrada no arquivo AndroidManifiest.xml.
- Vexamos un exemplo, e crearemos unha nova activity no asistente:
Se non tedes a importación automática de clases teredes que escribilo manualmente o sobre o erro (neste caso teriades que situar o cursor sobre a clase R) premer as teclas Alt+Enter, escollendo a opción import class. Se tedes activada a importación automática soamente tedes que premer en calquera liña da activity.
- Como vimos no asistente, á hora de crear unha activity aparecen dúas opcións que non marcamos:
- Launcher Acivity: Fai que dita activity poida ser lanzada ou executada de forma independente. Isto quere dicir que o resto de activities que non teñen marcada esta opción van necesitar ser invocadas dende outra activity. Ao crear unha activity e marcar esta opción, levará consigo dúas consecuencias:
- A outra opción é a de Backwards Compatibility: Esta opción está colocada para facer uso das bibliotecas de compatibilidade de Android, xa vistas nesta wiki anteriormente.
- Ao marcar esta opción teremos dúas consecuencias:
- Indicar que nas opcións de configuración de execución do proxecto, podemos indicar cal é a activity por defecto a lanzar (se non se especifica será a primeira que sexa de tipo launcher) e o emulador por defecto que vai lanzar:
- Crea un novo paquete de nome 'tiposactivities' e move as activities creadas anteriormente a ese paquete.
- Deixa a lo menos unha activity no paquete inicial, xa que se non a nivel gráfico o Android Studio o fai desaparecer.
- Nota: Lembra, como sucede en Java, cada paquete se traduce nun cartafol a nivel de S.O.
Ciclo de vida das Activities
- Máis información neste enlace.
- Cando se lanza unha activity esta pasa por unha serie de estados e eses estados chaman a unha serie de métodos.
Nota: O estado Resumed: ven ser o estado de running.
- Veremos máis adiante nesta Wiki diferentes métodos para gardar e recuperar o estado dunha Activity.
Métodos asociados aos estados
- Estes son os diferentes métodos e o que se debería facer en cada un deles:
- Método onCreate:
- Definir / instanciar variables – clases
- Definir a interface do usuario.
- Unha vez chamado o método onCreate chama os métodos onStart e onResume de forma consecutiva.
- Método onDestroy: Chamado cando remata a aplicación e se libera da memoria do dispositivo. Tamén pode ser provocado polo S.O. para liberar espazo de memoria. Normalmente non se fai nada neste método, xa que a liberación de recursos se fai nos métodos onPause e onStop, pero se a aplicación usa background Threads ou outro recurso que poida consumir memoria, debe ser destruído neste evento.
- Nota: Só hai un caso no que non pasa polos métodos de onPause e onStop, é cando destruímos a aplicación chamando o método finish() dende onCreate.
- Método onPause: Cando unha aplicación, ocupa parte da pantalla, pero deixa visible parte de aplicación en execución, esta pasa a un estado de PAUSE (por exemplo unha caixa de diálogo aberta por unha aplicación). En caso contrario, se queda totalmente tapada pasa a o estado de STOP.
- Ó volver do estado de Pause, se chama o método onResume.
- Normalmente cando se chama o proc. onPause, é que a aplicación vai deixar de se usada por o usuario. Neste caso se aproveita este estado para facer:
- Parar animacións ou outras actividades que consuman CPU.
- Gardar a información que o usuario espera atopar se volve a cargar a aplicación (redacción dun correo sen rematar,…).
- Liberar recursos do sistema, como transferencias, sensores (GPS), ou calquera recurso que poida afectar á batería (como a cámara).
- Normalmente cando se chama o proc. onPause, é que a aplicación vai deixar de se usada por o usuario. Neste caso se aproveita este estado para facer:
- Non se debe sobrecargar este método con ‘traballo’ pesado de liberación, xa que podemos enlentecer o paso ó seguinte estado. Para iso temos o método onStop.
- Método onResume: Úsase este método para volver a crear aqueles recursos que liberamos no método onPause.
- Hai que ter en conta que entramos neste método cando vimos de inicializar a aplicación e cando paramos a aplicación, polo que pode ser necesario verificar se xa estaban creados os recursos antes de volver a crealos.
- Vexamos un suposto exemplo no que facemos uso da cámara. Como vemos comprobamos se o obxecto que vai facer uso da cámara está xa inicializado.
1 @Override
2 protected void onResume(){
3 super.onResume();
4
5 if (mCamara==null){
6 inicializarCamara();
7 }
8 }
- Método onStop.
- Existen uns poucos casos no que isto sucede:
- Usuario abre outra aplicación ou vai as aplicación recentes e escolle outra. Ata que non volva á nosa aplicación, esta pasa a un estado de stop e se queda en segundo plano.
- Usuario provoca a aparición doutra activity. A primeira activity é parada e comeza a segunda. Se o usuario preme o botón de ‘Volver’ a primeira actividade é reiniciada.
- Usuario recibe unha chamada de teléfono.
- Temos por tanto os métodos onStop e onRestart para dar soporte a estes eventos.
- No método onStop é onde debemos facer as operación que máis leven de liberación de recursos coma poidan ser gardar datos nunha base de datos.
- Nota: O sistema garda o estado das View, polo que os contidos de caixas de texto e outros recursos gráficos se manteñen ó reiniciar a aplicación. Soamente se perden se o S.O. necesita espazo en memoria e quita a aplicación do Stack, destruíndo todo. Nese caso se o usuario volve, os elementos gráficos estarían inicializados.
- Método onRestart e método onStart:
- Cando o sistema chama o método reiniciar tamén chama despois o método onStart (cada vez que aplicación se pon visible).
- Debido a isto, se debe de inicializar os compoñentes que foron liberados no método onStop e tamén se debe aproveitar ese mesmo código cando se crea por primeira vez a aplicación.
- Por exemplo, no método onStart se poden poñer as condicións necesarias para que poida funcionar a aplicación (coma por exemplo recursos que necesitemos, coma GPS, unha cámara,....).
- No método onRestart se poden recuperar cursores de acceso a datos que foran pechados previamente no método onStop. Máis información neste enlace.
-- Ángel D. Fernández González -- (2018).