Pre-project Details Gathering

Your explanation is confused, so perhaps you should talk to your developers first. In particular your are calling "server" what the client usually is (web browser) and "client" where the server tends to be (linux box). Plus why would both client and server now reside on a Roku?

Or you would have to get in much more details here by explaining what and how does your project do.

I'm not confused :). Just didn't explain it as well as I should have. And this is preliminary information I'm looking for, some very basic information before I engage the dev team.

>In particular your are calling "server" what the client usually is (web browser) and "client" where the server tends to be (linux box).
>Plus why would both client and server now reside on a Roku?

What I mean is that there is a piece of software that would have to run on the roku which is the client.
The server is where the browser or channel would get it's data from in order to display the information to the user on the roku.

Currently, users head to the server to use their browser to view the data but instead, the browser portion would be the channel, for lack of better words since I don't know the terminology of the Roku just yet.

So, you are right in your understanding of my post but what I mean is that the client and the display would both be on the Roku, with the data fetched from servers on the Internet of course. Thus, client/server application, just not explained as clearly as it should have been.

Rrrright. So (1) should say "server" and whether that's C/C++ doesn't matter since it will still stay outside a Roku. It'll just have to serve data requests (presumably JSON or XML) over HTTP to Roku.

(2) should say "client" and that's the app ("channel") that will run on a Roku. You'll use the remote buttons to navigate the screen. The likelihood that you'll use the pointer built in the game remotes is very low because (a) RokuCo has discontinued that hardware as of end of 2016 and (b) they have never exposed that functionality in the public SDK

(3) You could potentially use the MAC address but that's frowned upon, because what happens if the user has >1 Roku player? How about if they buy a new player and gives the old one to his/her Mom? Or if player dies and is replaced under warranty with a new one. You should not do perma-lock to hardware address. Instead, the player has a small registry DB where you can store ID handed to you from the server once you figure out the account details. Resetting the player to factory deleted the registry, hence give-away player would be freed. Also your server can give the same ID to the multiple Rokus of the same person and treat them as one if seem fit to the business logic

Thanks for your input.

(1) You mention 'it will stay outside a Roku'. I'm assuming that means there is no direct access to network functions? Our binary has to run a few tests to our servers and would need to use some basic network tools like ping, a sort of traceroute and some udp ports. These are used to ensure that the service is not actually down but in some other temporary state to tell the client would know how to handle certain conditions. We would use http, https, udp and icmp.
You mention 'that's the app ("channel") that will run on Roku. This seems to imply that there is limited access to certain things but I'm not sure if that implies/includes networking functions such as above.

A small example of this would be windows. On a windows machine, you need admin level access to use network level tools. So I suppose I am saying that on the Roku, I would need that same kind of access.

(2) Thanks for clearing that up. As mentioned, this is preliminary information gathering so didn't yet know if this was still a function of the newer Roku devices.

(3) A registry ID might work, but so long as it can be based on some unique ID of the device. We don't need to keep track of the user, only the unique devices. Meaning, ownership doesn't matter, user doesn't matter, if it changes hands or how many players there are at the same location is not important for our application. We normally use the MAC address as a simple way to permanently identify a device so our server side app can know how to deal with it.

You also mention the 'app' ("channel") that will run on a Roku. The 'channel' part is how we would display the output but the 'app' part would be something that needs to run on the Roku, such as a binary which has access to networking. This is the 'client' part I was initially talking about.

This is mainly the part I am missing in terms of information right now.

At this point, I suspect that this is not possible and that only 'channels' are supported.
 

"rokooblues" wrote:
(1) You mention 'it will stay outside a Roku'. I'm assuming that means there is no direct access to network functions? Our binary has to run a few tests to our servers and would need to use some basic network tools like ping, a sort of traceroute and some udp ports. These are used to ensure that the service is not actually down but in some other temporary state to tell the client would know how to handle certain conditions. We would use http, https, udp and icmp.
You mention 'that's the app ("channel") that will run on Roku. This seems to imply that there is limited access to certain things but I'm not sure if that implies/includes networking functions such as above.

A small example of this would be windows. On a windows machine, you need admin level access to use network level tools. So I suppose I am saying that on the Roku, I would need that same kind of access.

Correct, apps run sandboxed on Roku. You won't get root shell nor anything else tutti-rooty. No ICMP but you can whip programmatically http/tcp/udp. On a side note, Windows does not require admin for ping/traceroute - just for packet sniffing (which you won't get on Roku either).

(3) A registry ID might work, but so long as it can be based on some unique ID of the device. We don't need to keep track of the user, only the unique devices. Meaning, ownership doesn't matter, user doesn't matter, if it changes hands or how many players there are at the same location is not important for our application. We normally use the MAC address as a simple way to permanently identify a device so our server side app can know how to deal with it.

Your "normal" behavior is wrong then! 😉 You shouldn't permanently identify a device, since they change ownership. I understand you don't need to "port" ID from one device to another or share it between devices - that makes your life easier.

How do you deal with your MAC "addiction" on iOS, where that's deprecated now?
Do you use IDFA (advertiser id) - and if so, you can use what Roku calls RIDA by calling GetAdvertisingId(). Alternatively you can just call GetRandomUUID() on first install, store that in registry and subsequently always send that to the server (that will allow device reset to factory to "unhook" from that ID)

"rokooblues" wrote:
You also mention the 'app' ("channel") that will run on a Roku. The 'channel' part is how we would display the output but the 'app' part would be something that needs to run on the Roku, such as a binary which has access to networking. This is the 'client' part I was initially talking about. This is mainly the part I am missing in terms of information right now. At this point, I suspect that this is not possible and that only 'channels' are supported.  

In Roku vernacular, "channel" is just a synonym for an app - nothing more, nothing less. It was done to be more TV-viewer-friendly, i imagine. There are no background tasks or daemons that can be run outside the app UI session.

Yes, you can run ping and tracert as a user but to get direct access to some network level functions using our own code, we had to deal with that issue. It didn't take much to get this resolved but it was an issue that we had to solve.

>No ICMP but you can whip programmatically http/tcp/udp.

We don't need root access but we do need access to those ports mentioned and icmp. I'll have to speak with the dev and see if we could get by without icmp if that's not possible.

>>Your "normal" behavior is wrong then! You shouldn't permanently identify a device, since they change ownership.

No, it's not wrong :). As I said, I didn't disclose what the service is but I'm sharing the facts that do exist. Of course, other ways could be explored and as you mentioned, there is a registry of sorts which might be a possible solution. In other words, when you build something, you realize that you might have to use different methods in different situations so, this is taken into account. It's just not the primary way we would prefer it.

>How do you deal with your MAC "addiction" on iOS, where that's deprecated now?

We don't have anything to do with mobiles.

>Do you use IDFA (advertiser id) - and if so, you can use what Roku calls RIDA by calling GetAdvertisingId(). Alternatively you can just call GetRandomUUID()
>on first install, store that in registry and subsequently always send that to the server (that will allow device reset to factory to "unhook" from that ID)

Obviously over my head at the moment since I've just started looking into this but I'll refer back to this thread.
In the end, we designed this in a certain way to be used in a certain way but now are looking at how we could modify as needed if/when using with other products so all of these things will of course come up.

Again, thanks for the leads, these are good starting points.

<lost during edit>

If app is not on screen, it is not running (public SDK). There are no background tasks on Roku, so you get only the current active app on screen. If it can stay live all the time, then it can poll 24/7

Yes, this is how we now understand it too.
Based on this limitation, we've come up with a super simple idea.

Thanks for the input and the help, it was appreciated.