Mark - thank you for your attention and shedding light into a corner case:
1. In general there is not only one "current" channel running. The most obvious example is a screensaver running over another channel. I think there are also a few other corner cases where more than one brightscript context can be running. So this would need to be clarified; for example, to exclude screensavers.
I could not find conceptual description of how screen savers work on Roku (code example is not documentation), my understanding so far is that the active channel gets paused and screen saver runs until interrupted, is that not the case? In particular i am foggy on what happens if channel Foo is running in regular mode when screen saver kicks-in and the chosen screensaver is Foo as well (i.e. Foo advertised itself as screen saver and was chosen in Settings); is new context spawned - or call is forced within regular Foo - or no saver is called - or crash happens.
But let me do some hand-waving about the intent of /query/channel, perhaps that gives the answer for this and other corner cases: it is expected to return the channel# that is currently having control of the screen and (potentially) is receiving the user input. The one that is active front and center; that "has the focus" in Windows parlance; the "first responder" on Apple NS/Cocoa platform. Whether there are other contexts in the background (suspended/zombies, main menu) does not matter.
The idea is that the ECP client can check what is on screen right now (at very coarse level: channel#) and also know who will get it if sending a button press. If screen saver is on, first input will get consumed and SS terminated, right? So it is useful /query/channel to indicate when screen saver is on. Accordingly, remoting app then may opt not to disrupt player's slumber - or to send "superfluous" keypress to dispense with the S/S and then it can check "the real" channel and send inputs to it. Now what exactly /channel returns during screen saver time may not be important - it might be say fixed "-2" or the screen saver channel number negated (i can't think of why knowing exact SS is useful, if they cannot receive input) - but knowing when is napping matters.
2. This mechanism doesn't completely solve the race condition you mention in your discussion. The box could return that Pandora is running, and then 100 ms later the user could exit with the physical remote and you'd still be air talking. Perhaps a better solution would be to add a parameter to the input command to specify the id of the channel that you believe you're talking to, and to get a specific error code if the wrong one is running.
True, does not completely
solve it - but this REP is not trying to address all of /input's issues, of which this is just example. /channel would have multiple uses - for example showing channel-name in title bar (or another, non-obtrusive place) of remoting app; like so (mockup):
automatically popping custom control elements (subject to channel maker volunteering the means, say song name/artist/cover). I have some thoughts related to your idea though but let me open separate thread as not to de-focus.
PS. i just realized that as "free bonus" we'd get a bit improved "accessibility" to the player. Accessibility for disabled people (specifically blind or of low vision
). iPhone/iPad have a "VoiceOver" accessibility setting that reads aloud as touching screen elements (and so does Android, it is called "TalkBack" there). Never heard of it? - chances are you have better than 20/70 vision. I had no idea of those settings either but learned there are legally-blind Roku users that use them, more here
. Some day RokuCo may be able to put as much effort in accessibility as Apple/Google did - but in the mean time the mobile remote apps can help.