- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Apr 2015 00:19:19 +0000
- To: public-secondscreen@w3.org
Recasting the two scenarios in https://github.com/w3c/presentation-api/issues/81#issuecomment-96709089: 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) { maybeOfferPresentation(true) } 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 See https://github.com/w3c/presentation-api/issues/81#issuecomment-96856003
Received on Tuesday, 28 April 2015 00:19:20 UTC