AlarmManager y distinto comportamiento si la app está corriendo o no

[mocelet]

Pensaba que era una pregunta tonta, pero no hay consenso en las redes...

Básicamente quiero que aparezca una notificación a cierta hora para recordar al usuario que tiene que entrar a la app y hacer algo, pero si el usuario ya está en la app en vez de notificación quiero avisar por otros medios (vistas propias de la app, vaya).

Opción 1. En SO sugieren tener una variable estática en plan "visible" que en el onResume lo pongas a true y en el onPause lo pongas a false, para que en el onReceive puedas saber si la app está en background y mostrar la notificación o si está en primer plano (y enviarle un Intent a la app para que se abra la actividad correspondiente o lo que sea).

Opción 2. Lo que tenía pensado inicialmente es, al pausar la app, programar la alarma. Y el onReceive simplemente muestra la notificación. Si se reanuda la app, quito la alarma y uso el postDelayed del Handler para mostrar lo que tenga que mostrar. Si salgo de la app otra vez pues otra vez programo la alarma.

Opción mixta. La alarma no la quito nunca, pero sí que pongo un flag para que la notificación no salga si la app está visible. Y en la app siempre tengo el Handler con la tarea programada, al fin y al cabo ya estoy dentro de la app y me parece más limpio y menos propenso a errores que el aviso venga de un handler y no del servicio de alarmas de Android que tiene otras cosas más importantes que hacer.

¿Votaciones?

EDIT: También en SO (http://stackoverflow.com/questions/18038399/how-to-check-if-activity-is-in-foreground-or-in-visible-background) hablan de los ActivityLifecycleCallbacks... pero no he seguido leyendo porque necesito algo que funcione en Android 2.2 xD

EDIT 2: El AlarmManager cada vez es más surrealista, no había visto el setExactAndAllowWhileIdle, se ve que el setExact de KitKat ya no es tan exacto gracias a Doze. Y resulta que ese método no te asegura que la alarma avise si hay dos ejecuciones programadas con menos de un minuto de antelación (en la documentación pone 15 minutos pero salió un desarrollador diciendo que estaba mal el javadoc, menos mal...)

[Dexafree]

Opción 1. En SO sugieren tener una variable estática en plan "visible" que en el onResume lo pongas a true y en el onPause lo pongas a false, para que en el onReceive puedas saber si la app está en background y mostrar la notificación o si está en primer plano (y enviarle un Intent a la app para que se abra la actividad correspondiente o lo que sea).


Esta es la forma que utilicé una vez cuando lo necesité, y mientras no te encuentres en situaciones de baja memoria no deberías tener problemas... Si necesitas mas fiabilidad siempre puedes tirar de las SP.
Overkill, lo se, pero sin problemas en condiciones de baja memoria

Respecto al tema de la alarma, es una de esas cosas que siempre me han parecido extremadamente enrevesadas de hacer en Android (aunque creo recordar que en N lo simplificaban).
Del handler yo me fío para tiempos de espera cortos, pero para tiempos largos nunca lo he utilizado (he sobreentendido que es para un tiempo de espera "largo", de minutos como mínimo, imagino), ya comentaras si te funciona!

no he seguido leyendo porque necesito algo que funcione en Android 2.2

En el trabajo también tengo un proyecto en el que es necesaria la compatibilidad con 2.2... A que duele no poder utilizar una enorme cantidad de cosas nuevas? :cry:

[mocelet]

Del handler yo me fío para tiempos de espera cortos, pero para tiempos largos nunca lo he utilizado (he sobreentendido que es para un tiempo de espera "largo", de minutos como mínimo, imagino)

Nunca me había planteado por qué no iba a ser de fiar mientras no se apague el dispositivo, pero he estado indagando en los relojes de Android (http://developer.android.com/intl/es/reference/android/os/SystemClock.html) y he aprendido algo nuevo.

Los relojes, sí, esto es como el chiste, si tengo un reloj sé qué hora es, si tengo varios no estoy tan seguro...

En mi servidor Java soy feliz con System.currentTimeMillis para guardar timestamps absolutos y con System.nanoTime para medir diferencias relativas de tiempo sin que me afecte el reloj "que da la hora" (wall clock).

Me había acostumbrado a usar System.nanoTime para todo lo que sea medir intervalos de tiempo dentro de la app, sabiendo evidentemente que en caso de reiniciarse el dispositivo cambia la referencia y cualquier valor pasado ya no sirve (i.e. no tiene sentido guardar un valor de nanotime en almacenamiento persistente, como mucho en el saveInstanceState que sabes que en caso de reinicio del dispositivo se borra).

Resulta que en Android aparentemente nadie te asegura que si el móvil entra en suspensión el reloj de nanoTime siga contando porque se basa en uptimeMillis (si duerme no cuenta) no en elapsedRealtime (http://developer.android.com/intl/es/reference/android/os/SystemClock.html#elapsedRealtime()) (si duerme cuenta).

Los Handler usan el uptimeMillis, así que si el móvil se duerme, al despertar tienes que volver a programar la tarea o se ejecutará con retraso (todo el tiempo que estuvo durmiendo)

[Dexafree]

Aprovecho este hilo para comentar dos cosas:

1. Se han publicado los vídeos de la DroidCon de San Francisco, y hay uno que habla sobre el tema de gestión de tiempo en Android:

CzNFjCQhCV0

2. He encontrado esta librería, y esta bastante bien parida en cuanto a crear Jobs y que el sistema decida cuando ejecutarlos:

https://github.com/evernote/android-job

[mocelet]

Tiene muy buena pinta esa biblioteca, es un caos tanto API.

No volví a tocar el tema por cierto, después del asunto RoboVM me lié la manta a la cabeza y ahora estoy a saco con Swift, UIKit y SpriteKit (me toca la moral un poco que Swift también meta su runtime que ocupa unos megas ¬¬').

Hablando de tareas, me gusta más el Grand Central Dispatcher de iOS y sus distintas colas. En el fondo es lo mismo que un Handler y unos Executors, pero es más intuitivo.

En cualquiera de los casos hay que tener cuidado si programas una tarea para más adelante porque igual ya la app ni siquiera está visible. Todavía no entiendo qué utilidad tiene que el Handler (o GDC en el caso de apps) siga ejecutando tareas de una actividad en el hilo principal cuando la actividad está en pausa o detenida.

[Dexafree]

Hablando de tareas, me gusta más el Grand Central Dispatcher de iOS y sus distintas colas. En el fondo es lo mismo que un Handler y unos Executors, pero es más intuitivo.

Para tareas simples, esto es amor del bueno:
https://gist.github.com/Arasthel/30154ab8e922c73c0291