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

Hi Anssi,

as I described earlier, having an async getter for the current availability
state (e.g. option 2) would result in a double notification coming to the
page in the case the UA hasn't started screen discovery at the moment
presentation.getAvailability() was called in your example: if the screens
are available, both the promise would be resolved and |availablechange|
event would fire as well. So doSomething() will have to be idempotent. I
would try to avoid imposing this requirement on the web developers, that's
why I tend to lean towards option 1).

Thanks,
Anton.

On Mon, Sep 15, 2014 at 2:02 PM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> 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