Re: [whatwg] Feature-detectable WakeLocks

On Monday, August 18, 2014 at 6:41 PM, Kornel Lesiński wrote:

> WakeLock.request() expecting a string isn't very friendly to feature detection.

The API tells you if a wake lock type is not supported by either rejecting with a TypeError or by a DOMException whose name is NotSupportedError.  
> I'd prefer if individual lock types were instances of objects, e.g. navigator.*Lock objects could be instances of a variant of the WakeLock interface:
> navigator.screenLock.request();
> navigator.screenLock.isHeld();
> navigator.cpuLock.request();
> navigator.cpuLock.release();
Personally, this doesn't strike me as good API design. It means having a bunch of attributes that all use the same class but only differ in name.  
> Alternatively, if the WakeLock was instantiable (to have a standard way for independent page components to share locks) then these objects could be constructors:
> if (navigator.ScreenLock) {
> var lock = new navigator.ScreenLock();
> …
> lock.release();
> }
> (or `new navigator.wakeLocks.Screen()`, etc.)
We don't have any APIs like this today on the Web.  It would be weird :)  

It would just be better to have a constructor on the interface: `new WakeLock("screen")` or whatever.  

But then we are just back discussing the other email about GC, etc.  
> Having specific instances for different types of locks could also enable elegant extensibility of the API, e.g.
> var screenLock = new navigator.ScreenLock();
> screenLock.dimScreen(); // completely made-up API
> var cpuLock = new navigator.CpuLock();
> cpuLock.setThreadPriority("low"); // completely made-up API

IMO, this is not really different from:  

navigator.wakeLock.request("cpu", {
   setThreadPriority: "low"

If we need to start returning an actual WakeLock objects in the future, we can add that.   

Received on Tuesday, 19 August 2014 00:37:41 UTC