W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2015

Re: [presentation-api] Rethinking availability monitoring

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Tue, 28 Apr 2015 00:19:19 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-96856003-1430180358-sysbot+gh@w3.org>
Recasting the two scenarios in 

1.  Page checks screen availability once on startup and offers user 
opportunity to present.  If no screen is found, perhaps the user can 
manually check later using UI on the page or in the UA.

2. Page checks availability automatically and events the page whenever
 there is a transition.  This way the page (or the UA) could 
dynamically offer the opportunity to present. There are concerns that 
use of this mode could lead to power consumption issues for the 
presenting device if the discovery implementation prevents it from 
entering a power saving mode.

The API proposed by @avayvod does address the two modes of use:

partial interface NavigatorPresentation {
  Promise<AvailabilityListener> listenForAvailability(/*DOMString
presentationUrl, params*/);

interface AvailabilityListener : EventTarget {
  readonly attribute boolean available;
  attribute EventHandler onavailablechange;

For mode 1, the caller would invoke 

    listenForAvailability.then(function(listener) {
      if (listener.available) offerPresentation();

For mode 2, the caller would invoke

    listenForAvailability.then(function(listener) {
      if (listener.available) {
      } else {
        listener.onavailablechanged = maybeOfferPresentation

Regarding concerns over power usage, the UA could likely optimize to 
only perform active discovery when the page with an  
`AvailabilityListener` was active and available for user input (i.e., 
the foreground tab).  This would limit the usability in contexts like 
Service Workers but I think that's a reasonable tradeoff.  I would 
like to hear if there are any other implementation experiences for 
similar APIs.


GitHub Notif of comment by mfoltzgoogle
Received on Tuesday, 28 April 2015 00:19:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:52 UTC