- From: Marcos Caceres <w3c@marcosc.com>
- Date: Mon, 18 Aug 2014 20:37:14 -0400
- To: Kornel Lesiński <kornel@geekhood.net>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>
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