- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Mon, 18 Nov 2013 14:26:24 +0200
- To: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
- Cc: Michael van Ouwerkerk <mvanouwerkerk@google.com>, John Mellor <johnme@google.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
> what is supposed to happen if the device is > off and an alarm cannot be met? This is device and user setting dependent. Wishfully when the device is off and an event triggers, it should be attempted to power on the device in order to handle the alarm. However, user should have a possibility to turn down that behavior through a setting. If the device does not support wake-up on event, then the next time the device is powered on there should be a persistent (until ack'd) notification about the missed event. Best regards, Zoltan On Mon, Nov 18, 2013 at 12:34 PM, 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 Monday, 18 November 2013 12:26:51 UTC