PDM Activities

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.

• Crea un novo proxecto de nome U2_01_CreandoActivities.

• MinSDK: 19
• Target_SDK: 27
• Compile_SDK: 27

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:

• Creando unha nova activity
• 

  Creamos unha 'Empty Activity'. Podemos crear diferentes activities cunha serie de compoñentes gráficas xa engadidas previamente e así aforrarnos traballo.

• 

  Non marcamos nin a opción de que poda ser lanzada nin a biblioteca de compatibilidade.

• 

  Como vemos no arquivo de AndroidManifiest.xml se crea unha nova entrada para a activity creada. Antepón un punto xa que Android para lanzar a activity fai uso do identificar completo formado polo nome do paquete e o nome da activity.

• 

  Como sucede en Java, o nome da clase ten que ser o mesmo que o nome físico do arquivo onde está creada. Este nome ten que corresponder có nome indicado no AndroidManifiest.xml

• 

  Para cambiar o nome podemos facer uso da utilidade Refactor => Rename. Premendo o botón dereito sobre o recurso que queiramos cambiar, escolleremos estas opcións y automaticamente cambiará o nome en todos los arquivos necesarios.

• 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:

• Creando unha nova activity coa opción Launcher actividada
• 

  Engade unha sección nova á activity no arquivo AndroidManifiest.xml. Xa veremos para que serve pero esas dúas liñas estalle a indicar ao S.O. Android de que activity pode ser lanzada de forma independente e que non vai recibir datos doutra activity.

• 

  Se ides ao dispositivo físico ou emulador podedes comprobar como aparecen as dúas activities que poden ser lanzadas de forma independente.

• 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:

• Creando unha nova activity coa opción Backwards Compatibility
• 

  A activity creada xa non deriva da clase Activity, se non da clase AppActivity do paquete de compatibilidade v7.

• 

  Engadiuse ao arquivo build.gradle a biblioteca de compatibilidade xa que facemos uso dela na activity creada.

• Indicar que nas opcións de configuración de execución do proxecto, podemos indicar, 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:

• Modificando as opcións da configuración de execución
• 

  Editamos a configuración...

• 

  Podemos escoller a activity a lanzar por defecto e asociar o emulador para que non pregunte por un cada vez que se lanza a aplicación.

• Crea un novo paquete de nome 'tiposactivities' e move as activities creadas anteriormente a ese paquete.

• Creando un novo paquete
• 

  Botón dereito sobre o paquete no que queremos crear un subpaquete.

• 

  Introducimos o nome do paquete a crear.

• 

  Arrastramos as activities ao novo paquete. Sairá unha ventá e premeremos o botón Refactor. Se vos da algún tipo de erro probade a arrastralas dunha en unha e limpar o proxecto e volvelo a compilar.

• 

  Fixarse como agora no AndroidManifiest.xml aparece o novo paquete.

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.

• 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).

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).