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

I think in either case we are requiring the web developer to do extra work
to handle the available state.  The difference is between:

1)

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

// Check value
if (navigator.presentation.available == 'available') {
  doSomething();
}

2)

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

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

Since availability can change multiple times over the lifetime of a page,
doSomething() must be able to handle multiple invocations.

It does seem wasteful to both resolve the pending Promise and invoke the
event handler in the scenario Anton describes.  Option #1 means that
doSomething() will be invoked exactly once if there is an available screen
- regardless of whether it is discovered before the script fragment
executes, or afterward.

To address Dominik's concern about power consumption, it should be okay for
a user agent to always set navigator.presentation.available to |unknown|,
in case it doesn't want to implement background/continuous discovery.

m.


On Mon, Sep 15, 2014 at 10:57 AM, Anton Vayvod <avayvod@google.com> wrote:

> 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
>
>
>