Developers

[TheEndless]

"EnTerr" wrote:
Building completely proprietary protocol via sockets for each channel is brain-dead. There is (alas only partial) solution in SDK 3:

Since Firmware version 3.0:
• input enables a developer to send custom events to their Brightscript application. It takes a user defined list of name-value pairs sent as query string uri parameters. The external control server places these name-value pairs into a BrightScript associative array and passes them directly through to the currently executing channel script via a Message Port attached to a created roInput object. Please refer to Section 3.1 below for more detailed recommendations on how to pass your data. Messages of type roInputEvent have a GetInfo() method that will obtain the associative array. The arguments must be URL-encoded. This command is sent via a POST with no body.
Example: POST /input?acceleration.x=0.0&acceleration.y=0.0&acceleration.z=9.8

This ensures only one-way communication, injecting data from outside to running app. But there is no way to query status - this being the kind of synchronous invocation (http request - needs to pause and wait for result while message is passed to queue and wait to be handled and reply returned - then retuen that back) it seems against messaging implementation in brightscript (from the little i have seen). Which is a dirty shame, because i have been looking recently at the external control protocol of DirecTV DVRs - it reports status very nicely, what program is playing now, what's next on which channel etc

Wow.. thanks for the pointer. Not sure how I overlooked that. I could have sworn we had discussed that recently and it was said that it couldn't be done. Maybe I was getting determining if an app was running (which, as far as I'm aware, still isn't possible) confused with sending data to the running app.

[jbrave]

Yeah, its pretty cool, we used both launch params and roinputevent at MusicHackdaySF in May.

There seems to be a bug though:

1. launch app with params
2. call sub with listener params
3. listen for params in the sub
4. if you get new params, return to main with the params data
5. launchparams are waiting at the listener port in main after returning from the sub, so if the next thing that you hit after returning from the sub is check for a message at the port in main(), the app will act like it just got another message, except it is the first message that launched the app.

One should be able to get around this if one architects better, musichackday was just that: hack hack hack.

[WillEV]

Any news on the main apps mentioned though?

🙂

[RokuKevin]

No update on Netfix, Pandora, etc.... processing params.

--Kevin

[WillEV]

Does the new v3 version of the Pandora channel have this capability?

[RokuKevin]

No, but there will be apps that process launch params by the end of the year 😉

--Kevin

[WillEV]

"RokuKevin" wrote:
No, but there will be apps that process launch params by the end of the year 😉

--Kevin

OK, now I'm excited. Any chance of being on a beta program for those apps?

[WillEV]

Any news on the apps that have launch parameters? Itching to write some cool integration here 🙂

[jaredcasper]

Seems like it's time for another bump of this thread. The search functionality released last year is able to launch netflix, hulu, etc. on a particular movie/show, which gives some indication the apps themselves support it, presumably using some parameters passed to them. Can any app or ECP client do that same thing?

[benrowe]

Another Bump! for this thread. Control over Netflix and some other more prominent channels would be great!