Diferencia entre revisiones de «PDM Activities»
(No se muestran 12 ediciones intermedias de otro usuario) | |||
Línea 13: | Línea 13: | ||
+ | '''Preparación previa:''' | ||
+ | * Partimos que xa temos creado o proxecto inicial como [https://wiki.cifprodolfoucha.es/index.php?title=PDM_UD1_Co%C3%B1ecendoAndroidStudio#Creando_un_proxecto_Base xa indicamos anteriormente]. | ||
+ | : Se non o temos creado antes, crea un paquete de nome '''UD2''' e dentro deste outro paquete de nome '''Activities'''. | ||
+ | [[Imagen:PDM_Activity_0A.jpg|350px|center]] | ||
+ | : 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. | ||
<br /> | <br /> | ||
=Creando Activities= | =Creando Activities= | ||
+ | |||
+ | * En Android existen moitos tipos de 'Activities'. | ||
+ | : Todas elas teñen en común que son ventás onde se van 'debuxar' elementos da interface do usuario. | ||
+ | |||
+ | * Neste punto imos centrarnos en dous tipos de activity: | ||
+ | :* [https://developer.android.com/reference/android/app/Activity?hl=en Activity] | ||
+ | :: Son activities clásicas onde o usuario van interaccionar con compoñentes gráficos. | ||
+ | |||
+ | :* [https://developer.android.com/reference/androidx/appcompat/app/AppCompatActivity AppCompatActivity] | ||
+ | :: Son activities que derivan de Activity e que se atopan dentro da librería de compatibilidade v7. | ||
+ | :: Teñen a mesma función que as de clase Activity (servir como pantallas para interaccionar con compoñentes gráficos). Inicialmente foron creadas para que se puidera empregar o AppBar en versións de Android anteriores a que aparecera. | ||
+ | :: Existen novas funcionalidades que van poder ser empregadas en versións Android anteriores a que apareceran grazas o uso desta clase [https://wiki.cifprodolfoucha.es/index.php?title=PDM_UD1_Bibliotecas_de_compatibilidade como xa vimos anteriormente nesta Wiki]. | ||
+ | |||
+ | :: Na versión actual de Android Studio (Sept.2019) xa crea por defecto as activities desta clase. | ||
+ | |||
+ | |||
+ | |||
* Cada vez que se crea unha activity, aparece unha nova entrada no arquivo '''AndroidManifiest.xml'''. | * 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: | : Vexamos un exemplo, e crearemos unha nova activity no asistente: | ||
− | <gallery caption="Creando unha nova activity" widths="350" heights="300px" perrow="2"> | + | <gallery caption="Creando unha nova activity no paquete UD2.Activities" widths="350" heights="300px" perrow="2"> |
Image:PDM_Activity_1.jpg| Creamos unha 'Empty Activity'. Podemos crear diferentes activities cunha serie de compoñentes gráficas xa engadidas previamente e así aforrarnos traballo. | Image:PDM_Activity_1.jpg| Creamos unha 'Empty Activity'. Podemos crear diferentes activities cunha serie de compoñentes gráficas xa engadidas previamente e así aforrarnos traballo. | ||
− | Image:PDM_Activity_2.jpg| Non marcamos | + | Image:PDM_Activity_2.jpg| '''Non marcamos a opción de que poda ser lanzada''' (Launcher Activity). |
− | Image:PDM_Activity_3.jpg| 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. | + | Image:PDM_Activity_3.jpg| 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 (vos aparecerá un paquete diferente ao da imaxe, pero o concepto é o mesmo). |
− | Image:PDM_Activity_4.jpg| 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 | + | Image:PDM_Activity_4.jpg| 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. |
Image:PDM_Activity_4B.jpg| Se ao crear unha activity vos da un erro coa clase R, pode ser debido a que non teñades importado dita clase. | Image:PDM_Activity_4B.jpg| Se ao crear unha activity vos da un erro coa clase R, pode ser debido a que non teñades importado dita clase. | ||
Image:PDM_Activity_4C.jpg| Se non tedes [http://wiki.cifprodolfoucha.es/index.php?title=PDM_UD1_Co%C3%B1ecendoAndroidStudio#Automaticamente 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. | Image:PDM_Activity_4C.jpg| Se non tedes [http://wiki.cifprodolfoucha.es/index.php?title=PDM_UD1_Co%C3%B1ecendoAndroidStudio#Automaticamente 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. | ||
Image:PDM_Activity_5.jpg| 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. | Image:PDM_Activity_5.jpg| 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. | ||
</gallery> | </gallery> | ||
+ | |||
+ | : <u>Nota:</u> Fixarse que na imaxe o nome do paquete está errado. Pon 'UD2.Acvities'. Probade a cambiar o nome coa mesma opción 'Refactor'. | ||
+ | |||
+ | |||
+ | |||
+ | <br /> | ||
+ | * Ao cambiar a forma en como Android Studio crea a activity por defecto (de clase AppCompatActivity), teremos dúas consecuencias: | ||
+ | |||
+ | :* Se [https://wiki.cifprodolfoucha.es/index.php?title=PDM_UD1_Bibliotecas_de_compatibilidade#Versi.C3.B3n_antiga empregamos a opción antiga das bibliotecas de compatabilidade]: | ||
+ | ::<gallery caption="Empregando AppCompactActivity con bibliotecas de compatibilidade antigas" widths="350" heights="300px" perrow="2"> | ||
+ | Image:PDM_Activity_8.jpg| A activity creada <u>xa non deriva da clase Activity</u>, se non da clase AppCompatActivity do paquete de compatibilidade v7. | ||
+ | Image:PDM_Activity_9.jpg| Engadiuse ao arquivo '''build.gradle''' a biblioteca de compatibilidade xa que facemos uso dela na activity creada. | ||
+ | </gallery> | ||
+ | |||
+ | <br /> | ||
+ | :* Se [https://wiki.cifprodolfoucha.es/index.php?title=PDM_UD1_Bibliotecas_de_compatibilidade#Versi.C3.B3n_actual empregamos a nova forma androidx] teremos que: | ||
+ | ::<gallery caption="Empregando AppCompactActivity con bibliotecas de compatibilidade androidx" widths="350" heights="300px" perrow="2"> | ||
+ | Image:PDM_Activity_8B.jpg| A activity creada <u>xa non deriva da clase Activity</u>, se non da clase AppCompatActivity do paquete de compatibilidade androidx.appcompat.app. | ||
+ | Image:PDM_Activity_9B.jpg| Engadiuse ao arquivo '''build.gradle''' a biblioteca de compatibilidade xa que facemos uso dela na activity creada. | ||
+ | </gallery> | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
− | * Como vimos no asistente, á hora de crear unha activity | + | * Como vimos no asistente, á hora de crear unha activity aparece unha opción que indica Launcher Activity: |
:* 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: | :* 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: | ||
<gallery caption="Creando unha nova activity coa opción Launcher actividada" widths="350" heights="300px" perrow="2"> | <gallery caption="Creando unha nova activity coa opción Launcher actividada" widths="350" heights="300px" perrow="2"> | ||
+ | Image:PDM_Activity_6A.jpg| Creamos unha segunda activity no mesmo paquete (UD2.Activities) coa opción Launcher Actividada. | ||
Image:PDM_Activity_6.jpg| 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. | Image:PDM_Activity_6.jpg| 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. | ||
− | Image:PDM_Activity_7.jpg| Se ides ao dispositivo físico ou emulador podedes comprobar como aparecen as dúas activities que poden ser lanzadas de forma independente. | + | Image:PDM_Activity_7.jpg| Se lanzadas a aplicación e ides ao dispositivo físico ou emulador podedes comprobar como aparecen as dúas activities que poden ser lanzadas de forma independente. |
</gallery> | </gallery> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Línea 65: | Línea 107: | ||
<gallery caption="Creando un novo paquete" widths="350" heights="300px" perrow="2"> | <gallery caption="Creando un novo paquete" widths="350" heights="300px" perrow="2"> | ||
Image:PDM_Activity_12.jpg| Botón dereito sobre o paquete no que queremos crear un subpaquete. | Image:PDM_Activity_12.jpg| Botón dereito sobre o paquete no que queremos crear un subpaquete. | ||
− | Image:PDM_Activity_13.jpg| Introducimos o nome do paquete a crear. | + | Image:PDM_Activity_13.jpg| Introducimos o nome do paquete a crear. Lembrar que cada paquete está dentro dun cartafol. O paquete UD2 non aparece xa que non hai clases nel. Se abrimos o explorador de arquivos e creamos un arquivo dentro do cartafol UD2 veremos como Android Studio o amosa. |
Image:PDM_Activity_14.jpg| 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. | Image:PDM_Activity_14.jpg| 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. | ||
+ | Image:PDM_Activity_14B.jpg| Prememos o botón de 'Refactor'. | ||
Image:PDM_Activity_15.jpg| Fixarse como agora no AndroidManifiest.xml aparece o novo paquete. | Image:PDM_Activity_15.jpg| Fixarse como agora no AndroidManifiest.xml aparece o novo paquete. | ||
</gallery> | </gallery> | ||
Línea 80: | Línea 123: | ||
− | * | + | * Unha aplicación de Android pode estar conformada por moitas activities (pantallas) e incluso llegar a chamar a outras aplicación. |
+ | : Cada vez que unha activity chama a outra, a primeira non se destrúe, se non que queda nunha cola LIFO (Stack). | ||
+ | : Cando prememos o botón Back do móbil ou pechamos a activity actual, recupera a activity que estaba na cola. | ||
+ | [[Imagen:PDM_Ciclo_Vida_1.jpg|400px|center]] | ||
− | [[Imagen:00_basic-lifecycle.png| | + | |
+ | |||
+ | |||
+ | |||
+ | * Cando se lanza unha activity esta pasa por unha serie de estados e eses estados chaman a unha serie de métodos, ao igual que cando pechamos ou abrimos unha nova activity. | ||
+ | |||
+ | [[Imagen:00_basic-lifecycle.png|800px|center]] | ||
<u>Nota:</u> O estado '''Resumed:''' ven ser o estado de running. | <u>Nota:</u> O estado '''Resumed:''' ven ser o estado de running. | ||
+ | * Veremos [http://wiki.cifprodolfoucha.es/index.php?title=Ciclo_de_vida_dunha_aplicaci%C3%B3n máis adiante nesta Wiki] diferentes métodos para gardar e recuperar o estado dunha Activity. | ||
<br /> | <br /> | ||
Línea 96: | Línea 149: | ||
::* Definir / instanciar variables – clases | ::* Definir / instanciar variables – clases | ||
::* Definir a interface do usuario. | ::* Definir a interface do usuario. | ||
+ | ::* Vincular datos a listas. | ||
:: Unha vez chamado o método onCreate chama os métodos onStart e onResume de forma consecutiva. | :: Unha vez chamado o método onCreate chama os métodos onStart e onResume de forma consecutiva. | ||
Línea 101: | Línea 155: | ||
− | :* '''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. | + | :* '''Método onDestroy''': Chamado cando remata a aplicación e se libera da memoria do dispositivo, cando pechamos unha activity ou cando prememos o botón BACK. Tamén pode ser provocado polo S.O. para liberar espazo de memoria. Se a aplicación usa background Threads ou outro recurso que poida consumir memoria, debe ser destruído neste evento. Normalmente liberaremos os recursos que foron 'instanciados' no método onCreate. |
:: <u>Nota:</u> 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. | :: <u>Nota:</u> 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. | ||
Línea 123: | Línea 177: | ||
:: 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. | :: 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. | + | :: A aplicación permanece neste estado ata que se cambie de activity ou |
+ | |||
+ | :: 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. Isto pode pasar nunha aplicación multiventana no que pasemos o foco a outra ventá e despois volvamos á ventá inicial. | ||
<syntaxhighlight lang="java" line highlight=""> | <syntaxhighlight lang="java" line highlight=""> | ||
@Override | @Override | ||
Línea 157: | Línea 213: | ||
:: 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,....). | :: 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 [https://developer.android.com/reference/android/app/Activity#onRestart() neste enlace]. | :: No método onRestart se poden recuperar cursores de acceso a datos que foran pechados previamente no método onStop. Máis información [https://developer.android.com/reference/android/app/Activity#onRestart() neste enlace]. | ||
+ | |||
+ | :: A aplicación non permanece nestes estados, se non que pasa directamente ao estado Resumed e chama ao método asociado onResume(). | ||
+ | |||
+ | |||
+ | |||
+ | * '''<u>NOTA IMPORTANTE:</u>''' Se sobreescribides calquera destes métodos tedes que chamar en primeiro lugar ao método da superclase da forma: super.Método(); | ||
+ | |||
+ | <br /> | ||
+ | '''[https://wiki.cifprodolfoucha.es/index.php?title=Programaci%C3%B3n_de_dispositivos_m%C3%B3biles#UNIDADE_2:_A_interface_de_usuario. Enlace a la página principal de la UD2]''' | ||
+ | <br /> | ||
+ | <br /> | ||
+ | '''[https://wiki.cifprodolfoucha.es/index.php?title=Programación_de_dispositivos_móbiles Enlace a la página principal del curso]''' | ||
+ | <br /> | ||
<br> -- [[Usuario:angelfg|Ángel D. Fernández González]] -- (2018). | <br> -- [[Usuario:angelfg|Ángel D. Fernández González]] -- (2018). |
Revisión actual del 13:01 21 nov 2020
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
- En Android existen moitos tipos de 'Activities'.
- Todas elas teñen en común que son ventás onde se van 'debuxar' elementos da interface do usuario.
- Neste punto imos centrarnos en dous tipos de activity:
-
- Son activities clásicas onde o usuario van interaccionar con compoñentes gráficos.
-
- Son activities que derivan de Activity e que se atopan dentro da librería de compatibilidade v7.
- Teñen a mesma función que as de clase Activity (servir como pantallas para interaccionar con compoñentes gráficos). Inicialmente foron creadas para que se puidera empregar o AppBar en versións de Android anteriores a que aparecera.
- Existen novas funcionalidades que van poder ser empregadas en versións Android anteriores a que apareceran grazas o uso desta clase como xa vimos anteriormente nesta Wiki.
- Na versión actual de Android Studio (Sept.2019) xa crea por defecto as activities desta clase.
- 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:
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 (vos aparecerá un paquete diferente ao da imaxe, pero o concepto é o mesmo).
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.
- Nota: Fixarse que na imaxe o nome do paquete está errado. Pon 'UD2.Acvities'. Probade a cambiar o nome coa mesma opción 'Refactor'.
- Ao cambiar a forma en como Android Studio crea a activity por defecto (de clase AppCompatActivity), teremos dúas consecuencias:
- Se empregamos a nova forma androidx teremos que:
- Como vimos no asistente, á hora de crear unha activity aparece unha opción que indica Launcher Activity:
- 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:
- 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.
- Unha aplicación de Android pode estar conformada por moitas activities (pantallas) e incluso llegar a chamar a outras aplicación.
- Cada vez que unha activity chama a outra, a primeira non se destrúe, se non que queda nunha cola LIFO (Stack).
- Cando prememos o botón Back do móbil ou pechamos a activity actual, recupera a activity que estaba na cola.
- Cando se lanza unha activity esta pasa por unha serie de estados e eses estados chaman a unha serie de métodos, ao igual que cando pechamos ou abrimos unha nova activity.
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.
- Vincular datos a listas.
- 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, cando pechamos unha activity ou cando prememos o botón BACK. Tamén pode ser provocado polo S.O. para liberar espazo de memoria. Se a aplicación usa background Threads ou outro recurso que poida consumir memoria, debe ser destruído neste evento. Normalmente liberaremos os recursos que foron 'instanciados' no método onCreate.
- 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.
- A aplicación permanece neste estado ata que se cambie de activity ou
- 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. Isto pode pasar nunha aplicación multiventana no que pasemos o foco a outra ventá e despois volvamos á ventá inicial.
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.
- A aplicación non permanece nestes estados, se non que pasa directamente ao estado Resumed e chama ao método asociado onResume().
- NOTA IMPORTANTE: Se sobreescribides calquera destes métodos tedes que chamar en primeiro lugar ao método da superclase da forma: super.Método();
Enlace a la página principal de la UD2
Enlace a la página principal del curso
-- Ángel D. Fernández González -- (2018).