有没有办法使用AlarmManager或者设置基于实时报警更简单的方法？ [英] Is there an easier way to use AlarmManager or to set real-time based alarms?

问题描述

似乎以根据实际经过的时间（相对于正常运行时间，当装置睡其中停止）时操作的唯一方式是AlarmManager

是否有一个的容易的方式做挂钟为主，通过各地AlarmManager？

一个开放源码的包装推迟exectuion，例如

对于正常的定时操作，您可以使用一个处理程序，它是这样一个简单的任务应该是一样容易：

• 实施处理程序回调（无需注册）


• 实例化一个处理程序


• 呼叫sendEmptyMessageDelayed或类似的功能


• 要清理所有的延迟设定，只需拨打 removeCallbacksAndMessages（空）

然而，处理程序仅支持基于正常运行时间延迟，（如果要检查服务器的新邮件每15分钟例如）有时是不够的。

如果你想那些，看来你必须使用AlarmManager，这是不是很舒服的：

• 定义的操作为您报警


• 创建一个接收器（通过创建一个专用的接收器类，并声明其清单，或实现接口，使用注册的registerReciever接收器，并注销其完成时）


• 为您的操作创建一个意图


• 总结说，待处理的意图意图，如果你想取消报警存储挂起的意图


• 获取报警管理器（这需要上下文）


• 设置报警


• 当你想取消报警，使用存储的PendingIntent取消


• 您应该决定拥有多个意向或意向与变化的数据，你必须拯救他们都在事后清理警报管理

解决方案

  

对于正常的定时操作，您可以使用一个处理程序

仅从前景的活动。任何其他使用处理程序的长期轮询是不可靠的，充其量，甚至忽略了您对正常运行时间计算的关注。

  

定义的操作为您报警

这是没有必要的。它甚至不是一个好主意。

  

创建一个接收器（通过创建一个专用的接收器类，并声明其清单，或实现接口，使用注册的registerReciever接收器，并注销其完成时）

如果你想要的事件时，你是不是在前台，并走下车报警发生时设备处于睡眠状态（ _WAKEUP 报警），清单注册接收机是必需的。如果 _WAKEUP 是不需要的，服务就足够了。如果你只需要在前台，并在活动收到的情况下，使用 createPendingResult（）给你一个的PendingIntent 将触发的onActivityResult您的活动（）。不过，在后一种情况下，它会更有意义使用 postDelayed（）在查看或处理程序。

  

和储存待处理的意图，如果你想取消报警

如果存储的PendingIntent 是一个选项，然后处理程序是你所需要的，而 AlarmManager 不合适。要取消闹铃，你需要一个相当于的PendingIntent （即一个底层意图对象的基础上匹配 filterEquals（）键，其中的PendingIntent 运行[活动，服务，广播]是一样的）。

  

当您要取消报警，使用存储的PendingIntent取消

没有，您可以通过创建一个相当于取消的PendingIntent 。

  

如果你决定有多个意向或意向与变化的数据，你必须拯救他们都在事后清理警报管理

没有，你取消他们通过创建一个相当于的PendingIntent 。

  

有没有一种简单的方法做挂钟为主，通过各地AlarmManager一个开放源代码的包装？

延迟exectuion，例如

创建包装code本，涵盖了80％的工作将采取你的确要比写你的问题更少的时间。我不知道该专用库，部分是因为不会有所有的东西给它。

或者使用 ScheduledExecutorService的和激活锁定，短期的事情。这是不适合每15分钟的场景，因为它使设备清醒所有的时间。

It seems that the only way to time actions based on the actual elapsed time (as opposed to uptime, which stops when the device sleeps) is the AlarmManager.

Is there an an easy way to do "wallclock"-based delayed exectuion, for example through an open-source wrapper around AlarmManager?

For normal timing operations, you can use a handler, which is as easy as such a simple task should be:

• Implement the handler callback (no registration necessary)
• Instantiate a Handler
• Call sendEmptyMessageDelayed or similar functions
• To clean up all your set delays, just call removeCallbacksAndMessages(null)

However, Handler only supports uptime-based delays, which sometimes are not sufficient (e.g. if you want to check the server for new messages every 15 minutes).

If you want those, it seems that you have to use the AlarmManager, which is not very comfortable:

• Define an action for your alarm
• Create a receiver (either by creating a dedicated receiver class and declaring it the manifest, or implementing the interface, registering the receiver using registerReciever, and unregistering it when done)
• Create an intent for your action
• Wrap said intent in a pending intent, and store the pending intent if you want to cancel the alarm
• Fetch an alarm manager (this requires a context)
• Set the alarm
• When you want to cancel the alarm, cancel it using the stored pendingIntent
• Should you decide to have multiple intents or intents with changing data, you will have to save them all to clean up the alarm manager afterwards

解决方案

For normal timing operations, you can use a handler

Only from a foreground activity. Any other use of Handler for long-term polling is unreliable at best, even ignoring your concerns regarding uptime calculations.

Define an action for your alarm

This is not necessary. It is not even a good idea.

Create a receiver (either by creating a dedicated receiver class and declaring it the manifest, or implementing the interface, registering the receiver using registerReciever, and unregistering it when done)

If you want the event to occur when you are not in the foreground and the alarm to go off while the device is asleep (_WAKEUP alarms), the manifest-registered receiver is required. If _WAKEUP is not needed, a service will suffice. If you only need to be in the foreground and receive the event in an activity, use createPendingResult() to give you a PendingIntent that will trigger onActivityResult() of your activity. Though, in this latter case, it would make more sense to use postDelayed() on a View or Handler.

and store the pending intent if you want to cancel the alarm

If storing a PendingIntent is an option, then Handler is all you need, and AlarmManager is unsuitable. To cancel an alarm, you need an equivalent PendingIntent (one where the underlying Intent objects match based on filterEquals() and where the PendingIntent operation [activity, service, broadcast] is the same).

When you want to cancel the alarm, cancel it using the stored pendingIntent

No, you cancel it by creating an equivalent PendingIntent.

Should you decide to have multiple intents or intents with changing data, you will have to save them all to clean up the alarm manager afterwards

No, you cancel them by creating an equivalent PendingIntent.

Is there an an easy way to do "wallclock"-based delayed exectuion, for example through an open-source wrapper around AlarmManager?

Creating wrapper code for this that covers 80% of the work would have taken you less time than it did to write your question. I am not aware of a dedicated library for this, partly because there wouldn't be all that much to it.

Or, use ScheduledExecutorService and a WakeLock, for short-term things. This is unsuitable for "every 15 minutes" scenarios, as it keeps the device awake all of the time.

这篇关于有没有办法使用AlarmManager或者设置基于实时报警更简单的方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！