Re: [Task Scheduler] Repeating alarms

> How does this work for Android alarms?

Android API Reference [1] says as follows:

Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted.

Best regards,
Tomoyuki

[1] http://developer.android.com/reference/android/app/AlarmManager.html


On Nov 18, 2013, at 19:34 , Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com> wrote:

> I don't think that is handled, but I think it would be good if we had an answer to what should happen. Should it fire when the device is turned on again? Should it be ignored? Does it depend on what kind of tasks/alarm?
> 
> How does this work for Android alarms?
> 
> Kenneth
> 
> 
> On Mon, Nov 18, 2013 at 11:32 AM, Michael van Ouwerkerk <mvanouwerkerk@google.com> wrote:
> How is that situation currently handled for one-shot alarms?
> 
> /m
> 
> 
> 
> On Mon, Nov 18, 2013 at 10:07 AM, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com> wrote:
> I am OK with recurring alarms, but what is supposed to happen if the device is off and an alarm cannot be met?
> 
> Kenneth
> 
> 
> On Wed, Nov 13, 2013 at 1:38 PM, John Mellor <johnme@google.com> wrote:
> I notice that the API only allows one-shot alarms (setTimeout style), so apps that want to run periodically (both at exact times like a recurring alarm/calendar event, and inexact times like background syncing) must schedule a new task every time their task gets started.
> 
> That helps to keep the API nice and simple, but I worry that it might cause sporadic failures. Specifically, if the app crashes, gets killed, or hits an exception, in between the task starting and the app scheduling its next execution, it will never be run again (until the app is next manually launched, at which point a well-written app might check that the task is still scheduled, though many apps may neglect to do this).
> 
> Two possible solutions:
> 
> 1. Automatically schedule an additional task if a task crashes or gets killed. However, there's a risk that this would perform actions twice (e.g. if the background task sends an email, and we run an additional task with the same data, 2 emails might get sent); alternatively we could pass null data, but then that might confuse an app that only every schedules itself with data. So I'm not really sure this is workable.
> 
> 2. Add a recurring alarm variant. It might make sense to only allow inexact alarms to automatically recur; this would also allow us to simplify the API, as with inexact alarms you don't actually need to specify an interval, instead the browser will heuristically determine how often you deserve to get run (or we could allow providing a "minimum interval", which is the period of time after a given task execution during which the task should *not* be run, and after that the browser can schedule the task whenever).
> 
> What do people think?
> Thanks,
> John
> 
> 
> 
> -- 
> Kenneth Rohde Christiansen
> Web Platform Architect, Intel Corporation.
> Phone  +45 4294 9458 ﹆﹆﹆
> 
> 
> 
> 
> -- 
> Kenneth Rohde Christiansen
> Web Platform Architect, Intel Corporation.
> Phone  +45 4294 9458 ﹆﹆﹆

Received on Wednesday, 20 November 2013 01:00:22 UTC