GetInfo() and external control Input command
Hi all. I'm the developer of the Roku Remote app for Android, and have been working with the external controls commands for a while. But now I'm jumping into channel development and could use some h...
Forum Discussion
Ran into this thread while looking for documentation on roInput. After some meditation - while there is not enough info in problem description to be 100% certain - i think i understand what was happening in greno/@jbrave's cases:
It must be that there were 2 roInput objects created in 2 different places (presumably with different ports) - and when /input arrives, both get the same event posted to them. And since A and B do not process their queues in sync, long time may pass till B is closed and the loop of A is ran - just to discover there is another /input copy waiting there, so it seems to be repeating.
This is not necessarily a bug of how the firmware works - nor having >1 roInput is necessarily a mistake. There might be a corner case in which this is useful, something like 2 different components wanting to get notified independently of the same /input. It may also be the case that the behavior has changed since 2011 (say making the factory createObject("roInput") always return the same singleton - with the consequence that screen A will stop receiving roInputEvents after B does setPort) - no idea, since there is still no documentation 😛
A reasonable work-around for Greno's case (given a time machine) would be to use only 1 global roInput (with 1 own port) and each screen's A, B, C's event loop to also check roInput's port on the side.
It must be that there were 2 roInput objects created in 2 different places (presumably with different ports) - and when /input arrives, both get the same event posted to them. And since A and B do not process their queues in sync, long time may pass till B is closed and the loop of A is ran - just to discover there is another /input copy waiting there, so it seems to be repeating.
This is not necessarily a bug of how the firmware works - nor having >1 roInput is necessarily a mistake. There might be a corner case in which this is useful, something like 2 different components wanting to get notified independently of the same /input. It may also be the case that the behavior has changed since 2011 (say making the factory createObject("roInput") always return the same singleton - with the consequence that screen A will stop receiving roInputEvents after B does setPort) - no idea, since there is still no documentation 😛
A reasonable work-around for Greno's case (given a time machine) would be to use only 1 global roInput (with 1 own port) and each screen's A, B, C's event loop to also check roInput's port on the side.
