BroadcastReceiver vs Servicio

Bueno, en android, ¿cuál es la diferencia entre hacer algo en broadcastReceiver y llamar a otro servicio en broadcastReceiver ? Creo que ambos corren en segundo plano, ¿verdad?

En realidad, lo que yo debo hacer es:

En determinados momentos de la vida cotidiana, descargue el evento del usuario (por ejemplo: 9:00 am desayuno) de la base de datos, y configurar el AlarmManager para mostrar la notificación sobre el evento.

Ahora configuro un administrador de alarmas para hacer la tarea anterior. Y estoy desconcertado debo realizar directamente esto en BroadcastReceiver o llamar al servicio en BroadcastReceiver para lograr esto.

Gracias.

Debe hacer lo menos posible el procesamiento en un BroadcastReceiver como sea posible porque (citando desde el blog de Android )

Al manejar una emisión, la aplicación recibe un conjunto fijo de tiempo (actualmente 10 segundos) en el que realizar su trabajo. Si no se completa en ese momento, se considera que la aplicación se está portando mal, y su proceso es lanzado de inmediato al estado de fondo para que sea destruido por la memoria si es necesario.

Definitivamente debe llamar a un servicio desde el receptor para este propósito, si su acción toma más tiempo (conectarse a Internet puede tomar algunos). Los receptores de emisión están limitados por la cantidad máxima de tiempo, tienen que terminar.

Ciclo de vida del proceso

Un proceso que está ejecutando actualmente un BroadcastReceiver (es decir, que actualmente ejecuta el código en su método onReceive (Context, Intent)) se considera un proceso de primer plano y se mantendrá en funcionamiento por el sistema excepto en casos de presión de memoria extrema.

Una vez que vuelve de onReceive (), BroadcastReceiver ya no está activo, y su proceso de hosting es tan importante como cualquier otro componente de la aplicación que se esté ejecutando en él. Esto es especialmente importante porque si ese proceso sólo alojaba el BroadcastReceiver (un caso común para aplicaciones con las que el usuario nunca ha interactuado o recientemente), al regresar de onReceive () el sistema considerará su proceso vacío y agresivamente matar De manera que se disponga de recursos para otros procesos más importantes.

Esto significa que para operaciones de más larga duración, usará a menudo un Servicio junto con un BroadcastReceiver para mantener activo el proceso de contención durante todo el tiempo de su operación.

De: BroadcastReceiver

  • Cómo obtener detalles del proceso de ejecución de fondo android
  • Cómo enviar la ubicación del dispositivo en el servidor cuando sea necesario
  • Robospice en el contexto android.os.Service
  • Android: no se puede iniciar la intención de servicio: ¿no se encuentra?
  • Recibir llamadas durante una hora usando Twilio
  • ¿Cómo implementar callbacks usando IntentService en Android?
  • Servicio de Android en la biblioteca
  • Vista web de Android dentro de un servicio?
  • Observable vs. Servicio en Android
  • Las preferencias compartidas a veces se eliminan
  • Android startService Synchronous?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.