- 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