Re: [Alarm API] Use cases

On Wednesday, 13 February 2013 at 00:38, Janusz Majnert wrote:

> 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.


Agreed - seems that APIs might need to take a back seat until that's sorted out.
  
> > > 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.

Right, but in iOS, at least, the decupling of the notification system from the application, and explicitly requiring user action to relaunch an application effectively solves the problem. Also, not allowing applications to open themselves without user action prevents apps from doing strange things in the background.  
> 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.

This is also a nice thing about having a central notification system. You can tell it to ignore stuff from apps you don't care about.  
> > > 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"?
I mean like literally full unlock. Like shows the activity, and then if I hit the back button a few times I'm at the home screen, etc.   
> If you mean that the screen lock is
> disabled, then for me personally this is a bug in the platform.

Yep.   
> 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.

We should prevent that from every happening, no?   
> > > 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.
Agreed. I'm hopeful we can mitigate that as much as possible.  
> > > > 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).  

Right, but why would we replicate this model? Shouldn't we really be looking at all past mistakes and avoiding them?    
> 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.

Well, it does in it's current form. If I'm an iOS user (which I am most of the time), and I wanted to switch to a phone that uses this SysApps stuff, this would concern me greatly.  
> 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).

On iOS, I personally have no idea what is going on - on Android, I generally avoid downloading apps because I'm a bit paranoid about what they might do. On iOS, I generally trust that apps are not downloading stuff in the background (at least not while I am on cellular - I don't get a feeling they are). I do get the occasional push notification, but that's only for some apps that I've granted permission for (I think only Twitter).

Hopefully whatever we define here will not leave users with so much uncertainty.  

--  
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 13 February 2013 12:48:15 UTC