W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2014

Re: Standby API Specification Proposal

From: Marcos <marcos@marcosc.com>
Date: Thu, 29 May 2014 13:21:58 -0400
To: Ilya Bogdanovich <bogdanovichiy@yandex-team.ru>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, Dominique Hazael-Massieux <dom@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>, Kostiainen, Anssi <anssi.kostiainen@intel.com>, Mats Wichmann <m.wichmann@samsung.com>
Message-ID: <etPan.53876cb6.140e0f76.45d2@Marcoss-MacBook-Pro.local>



On May 29, 2014 at 1:08:39 PM, Ilya Bogdanovich (bogdanovichiy@yandex-team.ru) wrote:
> Hi Marcos,
>  
> >
> > This could also happen with the GC-based model, as the object needs to be kept alive and  
> explicitly deleted to be useful.
> >
> > this.wakeLock = screen.getWakeLock();
> >
> > function youCanSleepAgain(){
> > doSomething(); // exception thrown
> > delete this.wakeLock;
> > }
>  
> That’s true, but choosing between two possible errors - "app should not dim but it does",  
> and “app should dim but it doesn’t” - the second one seems more harmful to me.

Yes, I agree. 

> > Anyway, the point is that there are lots of ways to manage this - and the underlying OS  
> may give the user means to override allowing apps stopping the screen from going to sleep  
> or dimming.
>  
> I didn’t mean modal dialog, but of course browser or OS should have a chance to notify user  
> of such web app behavior and allow him to reject this. And it’s better to notify him before  
> the action starts, than interrupting process when OS would try to dim the screen for the  
> first time.

Ok, cool. Just wanted to make sure. It seems we are pretty much aligned in our thinking then. 
Received on Thursday, 29 May 2014 17:22:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:08 UTC