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

Re: [presentation-api] Rethinking availability monitoring

From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 May 2015 16:50:53 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-106483395-1432831853-sysbot+gh@w3.org>
@obeletski please, read the original description of this issue, it has
 a brief summary and some links to mailing list discussions. From the 
meeting notes:

Mark_Watson: So, startSession handles this, but some way to monitor 
available screens in the background would be pretty useful. Problem is
 enabling continuous monitoring when an event handler is attached to a
 property is considered bad practice, right?

Mark_Foltz: right.

Anssi: Adding an event listener should not have side effect, that's a 
shared practice.

Mark_Foltz: So, how does geolocation handle this?

Anssi: Example of the deviceOrientation. If your phone is staying flat
 and you attach an event listener, you will not get an event up until 
the phone moves. The spec cannot force the user agent to fire an event
 when the event listener is attached.

Now imagine the following scenario: the UA started running background 
availability monitoring of second screens because page A attached a 
listener to |onavailablechange|. The UA finds the screens and fires an
 event - page A knows there're screens available. Then page B is 
loaded by the user and it attaches its own listener - if the UA 
follows good practices of implementing events, it will not fire the 
event to page B because the availability state hasn't changed. But 
page B doesn't know the current state so it will assume there's no 
devices available.

The common practice is to provide a current state property - which is 
what the first proposal is about.
If we follow the second proposal - the page would have to wait until 
the promise resolves and attach a listener only then. Otherwise it 
would get both the promise resolved and event firing depending on when
 it attached the listener.

As long as the page attached a listener, it doesn't matter if there's 
a property we have to update in runtime. There's a way to stop 
background discovery if the page cares (detach the event listener and 
abandon the reference to the AvailabilityListener) but I would expect 
most of the pages won't and would rely on the browser to optimize the 
battery and performance for them.

GitHub Notif of comment by avayvod
Received on Thursday, 28 May 2015 16:51:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 May 2015 16:51:08 UTC