Re: [Alarm API] Use cases

On Wednesday, 13 February 2013 at 13:14, Janusz Majnert wrote:

> > > 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.
>  
> Doing strange things in the background is exactly what this API is
> about, IMHO. If you want apps to "operate" only when user explicitly
> launches them, then this API makes no sense and we should use a
> notification system instead.


Right. The things I'm trying to get to is the use cases. The use cases will dictate if we actually need this API or not. You presented a small set, another small set were presented in the spec itself (one of which was showing a notification).  

I've questioned the validity of the "start/wake an application" use case as potentially harmful to users (and hopefully showed that there are ways of doing the same thing more safely using a notification system). I would be really interested to hear more use cases for this API and why implementers feel it is important.

(I've started adding a list a the end of this email - then we can look at each case independently and determine validity/privacy/user-impact/etc. and if they can't be done in any other way).  
  
> > > 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?
>  
> As much as we can. On another note, if you give an app the privilege
> of dialing numbers without explicit consent, it is not the Alarm API's
> fault...

The case I was imagining is the phone unlocking because of the alarm, dropping back to the home screen through close contact with the user's skin, and the phone's system dialler application activating. As many of us have discovered (or remember from the good old days), this happens a lot - specially on phones with one click re-dial. I think everyone knows someone to whom this has happened.  

> > > > 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?
>  
> I see that we both consider this behaviour a mistake. But on the other
> hand, massive commercial success of the Android platform seems to
> prove us wrong.

I don't think it proves us wrong. Commercial success is just that: commercial success - but causation of it's success is not correlated to it's failings. Marketing, price point, availability, appeal, usability, etc. are likely the driving force for Android's success (at least more than "this device is costing me a fair bit of money":)).    
  
> > > 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).
>  
> So you do use an app to periodically download stuff in the background?
Not without permission, no. Also, push notifications appear to be very small (in terms of bytes/cost).     
> That's somewhat similar to the Alarm API, don't you think? As a user,
> don't you think it's a useful feature? How do you disable it when you
> go abroad and don't want to be charged in roaming?

Data roaming is disabled by default. But again, I have complete control over disabling push notifications.  
> I really think that
> the Alarm API is not the problem here. The problem is that there
> should be an easy way to control the billable resources.

Yes, that is certainly part of the solution (like this Data Sense thing from Microsoft: http://www.youtube.com/watch?feature=player_embedded&v=OptGFG0QlvU - I hear Android has something similar, but no on 2.2). However, effort should be done to mitigate the potential problem up front. I shouldn't get a shocking phone bill first to force me to go and look at what just cost me a whole bunch of money.  

Ok, so lets focus on the use cases. Lets make a list from the following question: the Alarm API allows an app to set an alarm so that the app can be woken up later to…  

 * display a notification.  
 * download some data.  
 * show something on the screen.  

 * … ??

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

Received on Wednesday, 13 February 2013 13:56:56 UTC