I have an Android app that sends videos to streaming devices. I would like to hire someone to write a Roku channel for it, the Roku channel would need to receive a command to play a video and return back to the app whether it succeeded, and also send to the app some playback state events like when the video is paused, buffering, etc, as well as let the app query the current position and duration of the video.
For this I was hoping to run a web server on the Roku but on my initial conversations with Roku developers (still interviewing) it seems like brightscript might not allow that? Is that the case? And if so, what is the preferred way to have communication between the mobile app and the Roku? I can easily run a web server on the mobile app (already do) but then the Roku would have to open a connection to the mobile app and wait for the command, is that possible?
“casolorz” wrote:
I have an Android app that sends videos to streaming devices. I would like to hire someone to write a Roku channel for it, the Roku channel would need to receive a command to play a video and return back to the app whether it succeeded, and also send to the app some playback state events like when the video is paused, buffering, etc, as well as let the app query the current position and duration of the video.
For this I was hoping to run a web server on the Roku but on my initial conversations with Roku developers (still interviewing) it seems like brightscript might not allow that? Is that the case? And if so, what is the preferred way to have communication between the mobile app and the Roku? I can easily run a web server on the mobile app (already do) but then the Roku would have to open a connection to the mobile app and wait for the command, is that possible?
Thank you.
You CAN have a web server inside a Roku application, my channel IP Camera Viewer Pro does just that for the “Easy Add” feature (aka the user uses their browser on the computer or phone to enter the camera info).
See echo server here: https://sdkdocs.roku.com/display/sdkdoc/roStreamSocket
You CAN have a web server inside a Roku application, my channel IP Camera Viewer Pro does just that for the “Easy Add” feature (aka the user uses their browser on the computer or phone to enter the camera info).
See echo server here: https://sdkdocs.roku.com/display/sdkdoc/roStreamSocket
Thank you for that info, I had seen that but it seems like it is just a socket, so the developer I hire would need to implement an HTTP server on top of that. I was hoping there was some Roku provided or Open Source library that already did that. Is there one?
“casolorz” wrote:
… what is the preferred way to have communication between the mobile app and the Roku? I can easily run a web server on the mobile app (already do) but then the Roku would have to open a connection to the mobile app and wait for the command, is that possible?
your use case does not require a Roku-side server.
if i were implementing this, i’d have the external app launch the Roku channel via ECP, passing URL to be contacted back. Then Roku do a long-poll http to the Android app - while it sounds counter-intuitive for reversing the implementation of who the client and who the server is, that’s lower level implementation detail; the mobile app can still control the Roku play.
“casolorz” wrote:
… what is the preferred way to have communication between the mobile app and the Roku? I can easily run a web server on the mobile app (already do) but then the Roku would have to open a connection to the mobile app and wait for the command, is that possible?
your use case does not require a Roku-side server.
if i were implementing this, i’d have the external app launch the Roku channel via ECP, passing URL to be contacted back. Then Roku do a long-poll http to the Android app - while it sounds counter-intuitive for reversing the implementation of who the client and who the server is, that’s lower level implementation detail; the mobile app can still control the Roku play.
That is exactly what I’m currently discussing with the developers I’m interviewing. Is long-poll pretty easy to do on the Roku?
“casolorz” wrote:
That is exactly what I’m currently discussing with the developers I’m interviewing. Is long-poll pretty easy to do on the Roku?
Yes. “Long poll” is just a normal HTTP call, the twist is that the web server is “holding the ball” till it has a command to send back. i.e. it’s a way to reverse control.
Think Roku periodically, repeatedly asking the phone “got any orders for me?” - “no”, till eventually app says “ok, play this” or “ok, pause”. That’s “polling”.
If inclined, that can be optimized to the server holding on response to the request till it has new info to send. That’s long polling.
“casolorz” wrote:
That is exactly what I’m currently discussing with the developers I’m interviewing. Is long-poll pretty easy to do on the Roku?
Yes. “Long poll” is just a normal HTTP call, the twist is that the web server is “holding the ball” till it has a command to send back. i.e. it’s a way to reverse control.
Think Roku periodically, repeatedly asking the phone “got any orders for me?” - “no”, till eventually app says “ok, play this” or “ok, pause”. That’s “polling”.
If inclined, that can be optimized to the server holding on response to the request till it has new info to send. That’s long polling.
Yeap I’ve done it before with other projects, I was hoping to avoid that since the mobile app is likely to have less resources than the roku (I’m guessing) but sounds like it will be my best option. Thanks for the help.
Would a combination of the mobile app having a server and roInput make sense? or is roInput going away someday?
“casolorz” wrote:
Would a combination of the mobile app having a server and roInput make sense?
Sure, you can “push” messages Android->Roku with ECP /input, send the opposite way via http. No long or repetitive polling: even better.
“casolorz” wrote:
Would a combination of the mobile app having a server and roInput make sense?
Sure, you can “push” messages Android->Roku with ECP /input, send the opposite way via http. No long or repetitive polling: even better.
Great, thanks.
