RE: [Alarm API] Use cases

> -----Original Message-----
> From: Janusz Majnert [mailto:jmajnert@gmail.com]
> Sent: Wednesday, February 13, 2013 9:39 AM
> To: Marcos Caceres
> Cc: Robin Berjon; Christophe Dumez - SISA; public-sysapps@w3.org
> Subject: Re: [Alarm API] Use cases
> 
> Hi,
> 
> >> 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.
> >
> > Any idea at what point should it be fired? And what happens if this is a
> multipage application (or would the "main" html page be always the
target)?
> 
> The application, even multipage, has some specific entry document.
> That's the place where the event should be fired. To get any conclusive
> details, we need to wait for the execution and security model document.
> 

To add to Janusz's comment, in the current proposal (I'm quoting Samsung's
proposal which has not been decided to be a final text yet. The discussion
on merging the proposals from Samsung and Mozilla is going on.) [1], we
intended to define the single entry point to be the *main browsing context*
[2] of system applications which is the only browsing context which the
runtime MUST fire the lifecycle events and other system defined events on.

IMO, *alarm* event specifically SHOULD be fired no matter which states the
application is in (Running, Paused or Terminated. [3]) That is, when the app
is in running state, the alarm event should be dispatched on the main
browsing context right away; when it is in paused state, the runtime should
resume the app and fire the resume event and the alarm event in succession
on the main browsing context; when in terminated state, the runtime should
launch the app and fire the launch event and the alarm event in succession
on the main browsing context as soon as the launching finishes.

[1]
http://sysapps.github.com/sysapps/proposals/Sysapps-Runtime/Overview.html
[2]
http://sysapps.github.com/sysapps/proposals/Sysapps-Runtime/Overview.html#ru
ntime-browsing-context
[3]
http://sysapps.github.com/sysapps/proposals/Sysapps-Runtime/Overview.html#ex
ecution-lifecycle-states-and-events


> >> What the application does with the alarm is entirely up to itself.
> >
> > Sure. But again, I'm not getting a very clear use case (some comments
> below about the ones you listed . I'm not saying there are none, I'm just
> struggling a bit to understand what they are). I'm also worried about
> "spammy" applications that become impossible for the user to kill:
> >
> > window.onclose = function(){
> > // create alarm to open app 10 minutes later and remind you to buy my
> > crap! :) };
> 
> How is this problem solved for native apps on platforms like iOS, Android,
> Windows7, MacOS etc? I don't think we can on one hand give some privileges
> to an application and then effectively control every possible
abuse/misuse.
> In case of the example you gave above I agree with what you wrote earlier
> (or in another thread on Alarm API) - there should be a straightforward
> way for the user to review/delete/disable alarms set by apps.
> 
> >> 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).
> >
> > This could potentially be problematic if it unlocks in your pocket (and
> start making phone calls accidentally, etc.).
> 
> What do you mean by "unlocks"? If you mean that the screen lock is
> disabled, then for me personally this is a bug in the platform. No
> application should be able to unlock the screen, apart from the locker of
> course. If the app starts making unwanted calls then you're out of luck, I
> guess.
> 
> >> On the other hand
> >> Android does this all the time (all those Google services running for
> >> no apparent reason).
> >
> > heh:) I've personally have not experienced this (I'm still using my
> trusty Samsung GT-9000 with Androind 2.2.x, aka "the workhorse"). Is this
> a 4.x thing?
> 
> This is off-topic, but yes - my Android 4.1 keeps running google maps,
> calendar and youtube as background services of some sort.
> 
> >> All in all, a well behaved app should handle the alarm in a way that
> >> will not annoy the user.
> >
> > I'm not too concerned about well behaving apps; I'm concerned about the
> ones that use the API naively or maliciously. In the wrong hands, this API
> can do some seriously annoying things.
> 
> I agree. Most APIs we will be working on have this potential.
> 
> >> > 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'm a bit worried about the above use cases personally (and I know you
> are just giving examples). But as someone who is on pre-paid (and travels
> a bit), I don't want apps to ever do this. I only want apps to download
> stuff for me if I initiated this action (e.g., I open Twitter and I open
> my email). Otherwise, this API will need a serious permissioning model as
> it could potentially cost the user a great deal of money.
> 
> I agree with your standpoint. Then again I think smartphones are already
> way past this point. Consider all these apps for Android - you really have
> to configure each and every one of them not to use the network (via
> synchronisation options). Some of the free apps will download ads whenever
> a data connection is available. Now I'm not saying that this is a good
> model, I just think that the Alarm API doesn't make this situation worse.
> What could solve this problem? - A platform-wide mechanism for granting
> one-time or "blanket" access to resources for which the user may
> potentially be charged. And I'm really looking forward to something like
> this, because now I have data connections disabled on my smartphone so
> that my low data cap is not exceeded by traffic that I didn't explicitly
> request (which also means that I cannot receive MMS messages, because on
> Android you cannot disable one APN and still use others).
> 
> Regards,
> Janusz

Received on Wednesday, 13 February 2013 10:03:41 UTC