Duda ciclo apk Android (que no de activity xD)

[otto_xd]

Hola.

Pues nada, que estoy liado con una cosilla y como soy un poco vago, me vendria muy bien saber cuando se cierra el ultimo activity de un apk, o el apk en si mismo, ya que tengo que realizar tareas en ese preciso momento.

Hay alguna forma de saber cuando sucede esto, o tengo que currarme algun mecanismo que haga comprobaciones en cada stop y start?

Saludos y gracias!

[firesign]

No soy ningun guru en cosas demasiado avanzadas de Android, pero se me ocurre una idea "a lo bestia": meter el codigo en cada "onDestroy" de tus Activity. Pero no ejecutar ese codigo cuando se destruya cada Activity estando las demas en funcionamiento, puedes comprobar antes de ejecutarlo si el paquete de tu aplicacion esta activo (abierto) en ese momento.

Si te vale y no lo entiendes bien del todo, me lo dices y te pongo un poco de codigo de ejemplo.

EDITO: veo que basicamente lo que te he propuesto es lo que tu tenias en mente :loco:

[otto_xd]

No soy ningun guru en cosas demasiado avanzadas de Android, pero se me ocurre una idea "a lo bestia": meter el codigo en cada "onDestroy" de tus Activity. Pero no ejecutar ese codigo cuando se destruya cada Activity estando las demas en funcionamiento, puedes comprobar antes de ejecutarlo si el paquete de tu aplicacion esta activo (abierto) en ese momento.

Si te vale y no lo entiendes bien del todo, me lo dices y te pongo un poco de codigo de ejemplo.

EDITO: veo que basicamente lo que te he propuesto es lo que tu tenias en mente :loco:
Si, a las malas tendre que hacer eso, pero no me gusta la solucion.

Lo malo es que he visto que se puede heredar de application, pero no tiene metodo para controlar cuando se finaliza una funcion.

Sigo dandole vueltas, porque ademas es algo que creo que voy a tener que usar de forma intensiva en el trabajo, y me gustaria dar con la solucion elegante.

Lo del ciclo de los activities mola, pero ya podrian haber tenido en mente que puede que necesites hacer cosas cuando termina el app :S

[^MiSaTo^]

No existe ningún método para eso en Android (hay un onTerminate (http://developer.android.com/reference/android/app/Application.html#onTerminate%28%29)pero es sólo para el emulador y no funciona siempre).
Por otro lado, tampoco android te asegura que la apli se llegue a cerrar. De eso se encarga el gc y te aviso desde ya que NO SIEMPRE mata los procesos (ni tiene por qué, de hecho si miras en la documentación del SO verás que pone eso mismo).
Resumiendo, que no se puede controlar/saber de ninguna manera cuándo se va a cerrar realmente una aplicación.
Lo que hacíamos nosotros, era mirar cuándo la aplicación va a pasar a background después de dar al botón back (no dando a home ni nada así, sino cuando vas a "salir" de ella) y justo antes de eso es cuando hacíamos lo que fuera. También creo que para asegurarnos mirábamos la pila de activities, pero esto ya no lo recuerdo, fue en Noviembre cuando lo hicimos (y ahora estoy haciendo algo parecido con Windows Phone y no se si estoy mezclando con ello xD)

[otto_xd]

No existe ningún método para eso en Android (hay un onTerminate (http://developer.android.com/reference/android/app/Application.html#onTerminate%28%29)pero es sólo para el emulador y no funciona siempre).
Por otro lado, tampoco android te asegura que la apli se llegue a cerrar. De eso se encarga el gc y te aviso desde ya que NO SIEMPRE mata los procesos (ni tiene por qué, de hecho si miras en la documentación del SO verás que pone eso mismo).
Resumiendo, que no se puede controlar/saber de ninguna manera cuándo se va a cerrar realmente una aplicación.
Lo que hacíamos nosotros, era mirar cuándo la aplicación va a pasar a background después de dar al botón back (no dando a home ni nada así, sino cuando vas a "salir" de ella) y justo antes de eso es cuando hacíamos lo que fuera. También creo que para asegurarnos mirábamos la pila de activities, pero esto ya no lo recuerdo, fue en Noviembre cuando lo hicimos (y ahora estoy haciendo algo parecido con Windows Phone y no se si estoy mezclando con ello xD)
Si, si esa es la solucion a la que ya llegamos, pero no me parece para nada limpia.

Asumimos que no tiene prque cerrarse una app, pero no puedo hacerlo en un onstop u onpause, ya que se tiene que hacer cuando estas en el ultimo activity de la lista, de forma que al dar a back se salga, ya que sino romperia el funcionamiento del resto de activities.

Pues nada, creo que al final voy a optar por usar algun metodo en onstart que compruebe si esta lanzado lo que necesito, y otro en onstop que compruebe que no es el ultimo de la lista... al menos quedara mas limpio que como lo tenia antes (todo dentro de onstart onstop)

Muchas gracias!!

Pd.vi lo de terminated y me parecio una guarrada increible, no se para que tienen esa clase si no sirve para nada :S

[^MiSaTo^]

Si, si esa es la solucion a la que ya llegamos, pero no me parece para nada limpia.

Asumimos que no tiene prque cerrarse una app, pero no puedo hacerlo en un onstop u onpause, ya que se tiene que hacer cuando estas en el ultimo activity de la lista, de forma que al dar a back se salga, ya que sino romperia el funcionamiento del resto de activities.

Pues nada, creo que al final voy a optar por usar algun metodo en onstart que compruebe si esta lanzado lo que necesito, y otro en onstop que compruebe que no es el ultimo de la lista... al menos quedara mas limpio que como lo tenia antes (todo dentro de onstart onstop)

Muchas gracias!!

Pd.vi lo de terminated y me parecio una guarrada increible, no se para que tienen esa clase si no sirve para nada :S
No, es una guarrada pero de verdad que no hay otra. Incluso aunque creas que el SO ha matado el proceso, muchas veces es mentira. Nuestra apli hacía llamadas a un servidor cada 5 segundos, y cuando en la lista de procesos aparecia que estaba cerrada, en el server seguíamos recibiendo las peticiones desde ella.
Así que no, no hay manera de hacerlo más limpia (o nosotros no encontramos una manera más limpia vaya).
No tiene ningún sentido porque tanto en iOS como en WinPhone tienes un OnTerminate en la clase Application y ambos tienen multitarea, garbage collector y toda la pesca. Y ese método funciona vaya. Pero Android no, por qué? Ah uno de los misterios de Android xD

PD: ahora entiendes por qué lo odio y por qué me parece que está diseñado como el culo? XD

[otto_xd]

No, es una guarrada pero de verdad que no hay otra. Incluso aunque creas que el SO ha matado el proceso, muchas veces es mentira. Nuestra apli hacía llamadas a un servidor cada 5 segundos, y cuando en la lista de procesos aparecia que estaba cerrada, en el server seguíamos recibiendo las peticiones desde ella.
Así que no, no hay manera de hacerlo más limpia (o nosotros no encontramos una manera más limpia vaya).
No tiene ningún sentido porque tanto en iOS como en WinPhone tienes un OnTerminate en la clase Application y ambos tienen multitarea, garbage collector y toda la pesca. Y ese método funciona vaya. Pero Android no, por qué? Ah uno de los misterios de Android xD

PD: ahora entiendes por qué lo odio y por qué me parece que está diseñado como el culo? XD
A mi me parece que tiene ideas muy buenas, ojo que no he tocado WP ni IOS, pero hay cosas que no tienen sentido.

Sobre esas llamadas, si estabais usando un runnable que se llama a si mismo con un handler, ahi tienes el motivo, a nosotros nos paso que se quedaba de fondo.

Lo mismo nos paso con un hilo, que matabas el activity y se quedaba lo otro funcionando.

La verdad es que hay cosas que tienen 0 sentido, cada aplicacion en teoria corre en un entorno virtualizado, pero luego pasan cosas como esas xDD

[^MiSaTo^]

A mi me parece que tiene ideas muy buenas, ojo que no he tocado WP ni IOS, pero hay cosas que no tienen sentido.

Sobre esas llamadas, si estabais usando un runnable que se llama a si mismo con un handler, ahi tienes el motivo, a nosotros nos paso que se quedaba de fondo.

Lo mismo nos paso con un hilo, que matabas el activity y se quedaba lo otro funcionando.

La verdad es que hay cosas que tienen 0 sentido, cada aplicacion en teoria corre en un entorno virtualizado, pero luego pasan cosas como esas xDD
No, no era un runnable con un handler ;) Pero we, te digo lo que a Chukii: Android mola hasta que programas para iOS y haces una apli gorda en Android. Ahí te das cuenta que lo que en iOS te lleva nada hacer, en Android es 3 veces más. Y que en cuanto te sales un poco de las cosas "estandards" es un p00to desastre.
Por ejemplo, el tema de la concurrencia... en fin xD En cuanto tienes más de 3-4 threads concurrentes (que en la otra apli los teníamos) la apli se volvía loca. O como cuando descubrimos que el ciclo de vida de los Activities no siempre es como pone en la documentación.

[firesign]

Si, el tema de no saber cuando se acaba la aplicación realmente es un cachondeo, porque pierdes el control de ciertas cosas. Yo por ejemplo lo estoy comprobando con los últimos ejemplos que estoy haciendo: me dejo el GPS activado y salgo de la aplicación, y veo como se queda activado un cierto tiempo completamente variable, hasta que en un determinado momento se apaga (ya no sale el indicador del GPS en la barra de tareas), y entonces entiendo que se ha terminado la aplicación completamente.

Lo que pasa es que algunas veces son unos segundos, mientras que otras me ha dado tiempo de llegar del curro a mi casa, salir a comprar, y volver, y el GPS seguía ahí, tirando, el móvil al rojo, y la batería bajando "en tiempo real" :)

EDITO: lo de dejarlo activado es simplemente para probar esto, que en la realidad se apagará al salir de la Activity que lo necesita, pero son pruebas que he estado haciendo.

[^MiSaTo^]

Si, el tema de no saber cuando se acaba la aplicación realmente es un cachondeo, porque pierdes el control de ciertas cosas. Yo por ejemplo lo estoy comprobando con los últimos ejemplos que estoy haciendo: me dejo el GPS activado y salgo de la aplicación, y veo como se queda activado un cierto tiempo completamente variable, hasta que en un determinado momento se apaga (ya no sale el indicador del GPS en la barra de tareas), y entonces entiendo que se ha terminado la aplicación completamente.

Lo que pasa es que algunas veces son unos segundos, mientras que otras me ha dado tiempo de llegar del curro a mi casa, salir a comprar, y volver, y el GPS seguía ahí, tirando, el móvil al rojo, y la batería bajando "en tiempo real" :)

EDITO: lo de dejarlo activado es simplemente para probar esto, que en la realidad se apagará al salir de la Activity que lo necesita, pero son pruebas que he estado haciendo.
Es por lo que te digo, es el garbage collector el que decide cuándo quiere matar una aplicación, y hasta entonces la apli pese a parecer "cerrada" realmente está en segundo plano. Por eso el tiempo es variable ;)

[pakoito]

No hay mejor forma de cerrar un apli android que poniendo un botón que tire un exception controlado jajajaja En mi apli es el nativo el encargado de cerrar la api por debajo y tenemos un par de métodos, pero supongo que no es tu caso.

[^MiSaTo^]

No hay mejor forma de cerrar un apli android que poniendo un botón que tire un exception controlado jajajaja En mi apli es el nativo el encargado de cerrar la api por debajo y tenemos un par de métodos, pero supongo que no es tu caso.

Y cómo cerrais las aplis? Amos, estás seguro que de verdad se cierran? Porque te aseguro que es el SO el que se encarga de ello... aunque desde el ndk (si es a eso a lo que te refieres con "nativo") no se cómo se hace.

[Monguer Guaper]

Y las cosas que tienes que hacer al cerrar el activity no se pueden hacer en otro momento o controlar de otra manera?

[pakoito]

Y cómo cerrais las aplis? Amos, estás seguro que de verdad se cierran? Porque te aseguro que es el SO el que se encarga de ello... aunque desde el ndk (si es a eso a lo que te refieres con "nativo") no se cómo se hace.Ndk es a lo que me refiero con nativo, si. Lo de la excepción era una broma. El director de cocos2d-x tiene un método que se encarga de cerrar la apli, y luego el sistema la borrará. De las pruebas que he hecho, con back hay veces que se cierra y hay veces que no, y no encuentro el patrón.


Ends the execution, releases the running scene.

It doesn't remove the OpenGL view from its parent. You have to do it manually.

[^MiSaTo^]

Nativo no es el ndk, nativo es java.
Por otro lado esque NO hay patrón. Como te digo es el SO quien decide cuándo matar el proceso, por tanto NUNCA puedes saber cuándo se va a cerrar realmente. Las aplis se quedan en background y aunque mires en el "administrador de tareas" no la verás, pero realmente no está cerrada.

[pakoito]

Nativo no es el ndk, nativo es java.
Por otro lado esque NO hay patrón. Como te digo es el SO quien decide cuándo matar el proceso, por tanto NUNCA puedes saber cuándo se va a cerrar realmente. Las aplis se quedan en background y aunque mires en el "administrador de tareas" no la verás, pero realmente no está cerrada.Bueno saberlo, porsiaca. NDK es lo que uso entonces, para mayor corrección, peroooo estoy usando métodos JNI que es el Java Native Interface y es independiente de Android, eso es lo que me confundía :/

[otto_xd]

No, no era un runnable con un handler ;) Pero we, te digo lo que a Chukii: Android mola hasta que programas para iOS y haces una apli gorda en Android. Ahí te das cuenta que lo que en iOS te lleva nada hacer, en Android es 3 veces más. Y que en cuanto te sales un poco de las cosas "estandards" es un p00to desastre.
Por ejemplo, el tema de la concurrencia... en fin xD En cuanto tienes más de 3-4 threads concurrentes (que en la otra apli los teníamos) la apli se volvía loca. O como cuando descubrimos que el ciclo de vida de los Activities no siempre es como pone en la documentación.

Claro, pero a los handler creo recordar que le pasas runnables, y lo malo es que el muy ****** se ejecuta en un hilo paralelo, asi que puede dar problemas.

Cuando empezamos a aprender android lo primero que miramos fue eso, nos quedamos locos, y era que dentro del runable que era ejecutado por el handler, volviamos a encolar la accion, asi no terminaba xD

---------- Post añadido a las 22:56 ---------- Post anterior a las 22:37 ----------


Y las cosas que tienes que hacer al cerrar el activity no se pueden hacer en otro momento o controlar de otra manera?

Por muchas razones no, sobretodo porque es manipular cosas del sistema en un segundo plano que tiene efecto directo he instantaneo en el activity visible, pero al final lo he guarreado lanzandolo siempre en el onresume de los activities y parandolo en onstop puede dar la sensacion de que todo funciona

Lo de destruirlo lo dejo para el ondestroy, aunque no es seguro que entre, LOL.

Por cierto, a nosotros siempre que hacemos un GC (o lo hace el sistema como es habitual) nos mata los procesos que pasaron a segundo plano. Lo chungo es que nos los matan SIEMPRE, como si tuviera un planificador muy agresivo de memoria el cacharro donde lo probamos.

Si algun dia tengo tiempo mirare el kit de implementacion de android para ver todos esos parametros :S

PD.Muchas gracias a todos ;)