Re: [Alarm API] Use cases

2013/2/12 Marcos Caceres <w3c@marcosc.com>:
>
>
> On Tuesday, 12 February 2013 at 08:52, Robin Berjon wrote:
>> On 12/02/2013 08:40 , Christophe Dumez - SISA wrote:
>> > The way I see it. The application that registered the alarm gets
>> > spawned if it is not currently running and the alarm goes off. Then,
>> > the "alarm" event is fired.
>>
>
> If the app is closed, this means reconstructing the whole application's DOM, etc. Imagine it was a game that set the alarm, and it has to load all its needed resources (could include ones that require communication over HTTP), JS libraries, and so on (and make sure you navigate to the correct page). This sounds very heavy + memory + cpu + battery intensive and for what use case in particular? If the actual use case was to notify the end-user of something ("Your spaceship has landed on planet Xubar!"), then it should have instead scheduled a notification for some given time (a "scheduled notification", as opposed to a "push notification").

It doesn't necessarily need to be like this. The application that
registered the alarm will be launched (I presume we will soon decide
what the "initial" state in the app lifecycle is) and the alarm event
will be fired. What the application does with the alarm is entirely up
to itself. If it decides to load some resources or access any other
APIs, it will still be bound by the rules we set for the APIs. I agree
that it may be confusing for the user to unlock their phone and find
an application launched (in foreground/background). On the other hand
Android does this all the time (all those Google services running for
no apparent reason).
All in all, a well behaved app should handle the alarm in a way that
will not annoy the user.


> So, the behaviour appears to be more: if the application is running, and the device is unlocked (but potentially sleep), then fire this event at the application (nay, some page in the application that registered the event!).. Because if the screen is locked, and the application fires up, you've just unwittingly unlocked the user's device (not a bad thing, but could suck if your phone is in your pocket at the time!).
>
> I'll note that Android (2.2) behaves like this: If an alarm clock app is running, and a timer is set, then Android will wake and open the application (and I mean fully unlock the phone in your pocket!). In contrast, iOS does not do this (thankfully!) - but instead displays a notification on the lock screen. I don't know if this changed in Android 4.0.
>
> Returning to Android, if the user has gone to the trouble to set a lock pattern or similar, and the alarm application is still open, then Android will fire up one particular "activity" (screen) and allow the user to interact with it - doing anything else causes the lock screen to be shown.
>
> I tried to see what B2G does, but it was a bit unstable (it actually didn't work in the clock application). However, I did notice that an alarm I had set much earlier ended up firing when I opened B2G again a few hours later. I don't know if this behaviour is desirable. If my phone was switched off, and I missed the alarm, then I don't think it should fire after the fact (it was quite an unexpected surprise that the thing would start blaring sound at me from an alarm set a few hours before!).
>
>> That does indeed seem like the desirable behaviour, but it would need to
>> be specified. Maybe this needs to wait on the runtime document being
>> sufficiently advanced that lifecycle requirements can be stated clearly?
>
> Maybe, but then the security document would need to cover all cases for each API (I'll note WAC's core specification tried to do this, and it just ended up creating a bunch of redundancy that eventually fell out of sync… so my recommendation is to avoid that). I think APIs should be able to define their own role within the lifecycle - but yes, we need the lifecycle specified in the security doc… but I wonder how different it's going to be compared to what we are used to.
>
> In the meantime, would it be worth while to document what various platforms do? Like, on my iPhone, if I set a timer, it uses a modal popup and says "Timer done!" and an OK button - but the alarm allows me to snooze or cancel the alarm. Other interesting features:
>
> * if the device is off when the alarm and timer are set, both go off only if the device is rebooted before the alarm and timer were set to go off. Otherwise, they are forgotten. This is unlike B2G - or what appears to be currently specified.
>
> In iOS, applications cannot set alarms (i.e., there is no API for that). They can only set notifications [1].
>
> On Android 2.2, on restarting, OS Alarms are retained, but timers are forgotten. Also, if an application that set a time is "killed", both the timer and the alarm is forgotten. This is not the case in iOS: if you kill the Clock app (using the "task manager"), both timers and alarm still go off (they appear to be centrally registered independently of the clock application, thankfully - as it guarantees that alarm will work even if the clock application crashes!).
>
> This begs the question: should developers even have access to setting system level alarms?
>
>> > I - indeed - don't think we can currently
>> > schedule a notification. All we can do is have the application show
>> > the notification when the alarm event is fired.
>>
>> I think it makes more sense to leave that up to the application indeed.
>
> That can be problematic because it seems to make presumptions about how the notification system works (that you only show notifications just in time - Both iOS, and Windows Phone, for instance, allow developers to temporally schedule a notification [1] [2] … also cute that on WP7 they make a distinction between an alarm and a reminder). For example, in iOS, I downloaded and installed a third party "Alarm Clock" app. The app allows you to "set an alarm", but if you leave the application, the only way for the alarm to notify you that the alarm has gone off, is to show a notification. If the application crashes or is killed, the notification is still delivered.
>
> IMO, this is far better than the model Android is using and what is being proposed by the Alarm API. It means that an application can be safely shut down, the notification can still be delivered (now or later), and the user can return to the app is they actually want to (by, for example, clicking on the notification).
>
> I ran the idea of adding time to the Web Notifications API with Annevk, and he seemed open to it… maybe something to consider.

Notifications are not enough IMHO. With the Alarm API we want to be
able to actually do some application specific work, not just display a
message. For example an email or Twitter app might want to download
updates and then show a notification.
I agree that we should clearly specify what to do with the alarms that
cannot be "delivered" due to various conditions (like power off). I
wonder how cron handles this?

>
> [1] https://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html#//apple_ref/doc/uid/TP40008194-CH103-SW1 (https://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html%23//apple_ref/doc/uid/TP40008194-CH103-SW1)
> See also: http://stackoverflow.com/questions/9445090/alarm-clock-app-in-ios
>
> [2] http://msdn.microsoft.com/en-us/library/microsoft.phone.scheduler.schedulednotification(v=vs.92).aspx
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>

/Janusz Majnert

Received on Wednesday, 13 February 2013 09:17:29 UTC