Confusion about WakefulBroadcastReceiver

☆樱花仙子☆ 提交于 2019-12-04 18:31:56

Does this receiver ensures that you'll receive the broadcast even when the device is in sleep mode?

No.

(I think no, it just keeps the device awake after receiving the broadcast until a call to completeWakefulIntent() is made.)

Correct.

I highly doubt that it's a good practice to start something like an intent service from the receiver

Yes, it is a good practice. That's the entire point.

This would prevent the receiver from releasing the wake lock

The wake lock is held in a static data member, which is why a static method (completeWakefulWork()) is able to release it.

as services are generally used for long operations

The definition of "long" varies. I start using WakefulBroadcastReceiver (or my WakefulIntentService predecessor) for anything that is likely to exceed 10 seconds. However, an IntentService of any form is really only designed for transactional work (e.g., downloading a large file), and so it is not well-suited for cases where the service might need to run indefinitely (e.g., as long as the user wants to talk to a certain chat server).

You only use WakefulBroadcastReceiver when you want to ensure that the CPU will stay alive for the service to complete its work. Otherwise, you use the IntentService directly.

Is this the right way to use this receiver or should it be used only for short operations?

25 seconds is a perfectly reasonable time frame for using WakefulBroadcastReceiver and its associated IntentService.

but more complicated implementations could take their own wake lock here before releasing the receiver's

Sure, though it is unclear what this would gain you. A wake lock is a wake lock. A service-owned wake lock will have the exact same impact on battery as will a receiver-owned wake lock.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!