¿Qué contexto recibe BroadcastReceivers al escuchar BOOT_COMPLETED?
AlarmManagers en Android pierden todas sus alarmas registradas cuando el teléfono pierde energía.
Utilizo el siguiente receptor de difusión para activar en el arranque de android:
- Lectura de un mensaje NDEF desde una etiqueta NFC desde una aplicación de Android
- Enviar difusión al hacer clic en la notificación
- No se puede establecer la alarma de repetición en el tiempo de arranque
- Cómo hacer referencia a una vista en una notificación personalizada
- Problema con la cancelación del AlarmManager - PendingIntent
public class AlarmBootReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) { Cursor alarmCursor = MainActivity.dbHelper.loadAlarms(); // Iterate through every stored alarm and set those alarms. // .... alarmCursor.close(); } } }
-
Cuando onReceive del receptor de difusión se activa en el arranque del sistema, ¿qué parámetro de contexto se da al método? Tengo que saber el contexto, porque necesito el contexto para cancelar las alarmas establecidas en ese contexto.
-
Supongo que la llamada a MainActivity.dbHelper.loadAlarms () no es segura porque MainActivity no se inicializa en el arranque del sistema. ¿O es seguro porque dbhelper y loadAlarms () están todos inicializados y declarados estáticos?
- ¿Cuál es el concepto de intención pendiente? ¿Por qué y cuándo utilizamos intención pendiente?
- Iniciar la aplicación sólo si no está en ejecución
- New PendingIntent actualiza la intención actual
- ¿Cómo enviar datos a través de PendingIntent a Broadcast?
- OnActivityResult para PendingIntent
- El clic de Android en la notificación no abre la Actividad adjunta
- No se puede enviar la intención pendiente del widget, SendIntentException
- Abrir la aplicación Android desde la notificación PUSH
Cuando
onReceive
del receptor deonReceive
se activa en el arranque del sistema, ¿qué parámetro de contexto se da al método? Tengo que saber el contexto, porque necesito el contexto para cancelar las alarmas establecidas en ese contexto.
En este caso, obtendrás el Context
aplicación global en onReceive()
. Sin embargo, es irrelevante. No necesitas saberlo.
Para cancelar las alarmas más tarde, creará un PendingIntent
y podrá usar cualquier Context
que desee hacer. Las alarmas no están vinculadas a un Context
específico, solo están vinculadas a una aplicación específica.
Supongo que la llamada a MainActivity.dbHelper.loadAlarms () no es segura porque MainActivity no se inicializa en el arranque del sistema. ¿O es seguro porque dbhelper y loadAlarms () están todos inicializados y declarados
static
?
Si dbHelper
es de hecho static
e inicializado en la creación de instancia ( no en onCreate()
), entonces esta llamada está bien. En general, llamar a los métodos estáticos en las actividades es mal visto, ya que es fácil hacer algo estúpido suponiendo que la Activity
se ha configurado correctamente. Sería mejor mover estos métodos estáticos a una clase general de utilidades, que no es una Activity
y sólo contiene métodos static
. Esto parecería menos sospechoso.
No importa qué tipo de Context
recibe su BroadcastReceiver (en cualquier caso, su ApplicationContext
) porque: 1) Usted no debe usar un DBHelper que está asociado con una Activity
. En su lugar, haga que sea Singleton y utilícelo en toda la aplicación. 2) Su AlarmManager
debe configurarse utilizando un Service
. Por lo tanto, su buena idea para llamar al servicio en su onReceive()
y establecer las alarmas de ese servicio
- Android: Demasiada memoria asignada mientras usa png en lugar de imágenes vectoriales
- Sugerencia de marcador de posición al escribir EditText en Android