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

Hi Dominik,

We all agreed that the |onavaiablechange| event handler is the only way to
handle the fact that the device availability changes over time otherwise
we'd use a Promise for one time check. So we should assume the page will
add a handler to the |onavailablechange| as soon as it wants to present
something. We want, however, to avoid firing the event immediately with
e.available = true in case the UA already discovered some devices. AFAIK,
just because it's inconsistent with all other event handlers.

How would you see an async getter work along with the event handler? Would
the page get both the event from the event handler and an async callback
from the getter if the UA only started the discovery when the event handler
was added? I don't think we want to pass the same result to the page twice.

<button disabled>Show</button>
<script>
var presentation = navigator.presentation,
    showButton = document.querySelector('button');
    showButton.onclick = show;

// This won't work in case the devices are already discovered by the UA
since we don't want to fire an event immediately after the event handler
was added...
presentation.onavailablechange = function(e) {
  showButton.disabled = !e.available;
};

// ... so use this async method returning a promise.
presentation.getAvailable().then(function() {
    // would the onavailablechange handler called before or after?
    showButton.disabled = false;
  }, function() {
    // if getAvailable() called later in the life of a page after the
devices were available, when would the event handler fire as well?
    showButton.disabled = true;
  }
);
....
</script>

Maybe we could ask the web developers to register the event handler in both
callbacks passed to the Promise instead and trigger the discovery when
|getAvailable()| is called? This would help in the first availability
request case but not if the page just decided to use |getAvailable()| later
on after the event handler was registered.

Am I missing something?

Anton.

On Fri, Sep 5, 2014 at 11:17 AM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:
>
> Hi Anton, Anssi,
>
> On Fri, 2014-09-05 at 07:47 +0000, Kostiainen, Anssi wrote:
> > > Why can't we just have an "available" property to match the event?
> > This seems to be the consistent thing with other APIs.
>
> The reason why we might not want to have an available boolean is because
> it might be associated with a cost to find out whether screens are
> available. If you do a network discovery for screens, or reconfigure the
> wireless radio to browse for screens, for power saving reasons it is
> probably better to only do that on request. Also, because of network
> latencies - the property's value is something that is not synchronously
> available. In a way, the implementation behind the "available" is like
> implementing a synchronous function.
>
> I would prefer an asynchronous getter for that reason - and would prefer
> avoiding and "unknown" state - for which we would have to define
> additional state transitions.
>
> Dominik
>
>