Re: Adding an asynchronous getter (Promise) for screen availability status (issue #11)

Hi Anton,

On 09 Sep 2014, at 17:46, Anton Vayvod <avayvod@google.com> wrote:

> I agree it would be the minimum API needed for the needs of the page but the problem is that firing an event without any state actually changed (if the UA knows about screens being available before the event listener is registered) is uncommon.

Agreed. The semantics of a |somethingchange| event is as such that it is fired when |something| changes.

> I think we can easily go down the route of the property being null before any real data is available from the UA and then it being in sync with the onavailablechange event. In the best case, the property will be true upon the page load and the page will start its presentation as soon as it can.
> 
> AFAIK, a similar approach is being considered for device sensors API: https://gist.github.com/rwaldron/5016343

The proposal you refer to above is something Rick put up on his GH when we were discussing various (re)design choises for future APIs some weeks ago. We can certainly learn from it, but it comes with a disclaimer it has not been tested yet.

On the web platform there are various APIs that convey readiness state information via a sync accessor bundled with *change events that fire when the state changes. For example, Document.readyState and HTMLMediaElement.readyState initialize to “loading” and 0 respectively and when the readyState values change, a *change event will be fired.

In this thread we’ve discussed two options to resolve the issue #11:

1) Define presentation.availability attribute with possible values null (default), “available", “unavailable”, fire an availablechange event when the value changes to either “available” or “unavailable” from the default.

2) Keep the current AvailableChangeEvent, add presentation.getAvailable() that returns a Promise that resolves if screens are available:

// one-time async get
presentation.getAvailable().then(doSomething);

// change event
presentation.onavailablechange = function (e) {
  if (e.available) doSomething();
};

Anton - would adding getAvailability() address your concern [1]? I tend to lean toward the option 2).

Thanks,

Anssi

[1] https://github.com/webscreens/presentation-api/issues/11#issuecomment-54480708

Received on Monday, 15 September 2014 13:03:51 UTC