Roku Developer Program

[destruk]

Thanks for that - It would still be a good idea to include that information in the DeviceRegistrationAndLinking.pdf. That uses the serial number during the linking process, which RokuKevin said to not do. "We do not advise linking via serial number and will ask you to change it if detected when you publish your channel." Linking can be done without using a serial number, it's just more of a pain in the butt.

[TheEndless]

"destruk" wrote:
Thanks for that - It would still be a good idea to include that information in the DeviceRegistrationAndLinking.pdf. That uses the serial number during the linking process, which RokuKevin said to not do. "We do not advise linking via serial number and will ask you to change it if detected when you publish your channel." Linking can be done without using a serial number, it's just more of a pain in the butt.

He's saying not to use the serial number as the actual link. You can use it to identify for linking. In fact, the example in the DeviceRegistrationAndLinking.pdf actually uses it, but it's used to generate a separate unique identifier for the actual link that gets stored on the box and your server.

Note in the below example XML, the "deviceID"/serial number is sent in with the request, but a new "deviceToken" is generated and returned. That "deviceToken" is what should be used for future authentication/identification with the server.

Request

<linkAccount> 
    <regCode> (current registration code from PreRegistration request) </regCode> 
    <deviceID> (unique id/serial number for the device) </deviceID> 
    <deviceTypeID>(opaque string identifying device type) </deviceTypeID> 
</linkAccount>

Response

<result> 
    <status> success/failure </status> 
    <deviceToken> (opaque encrypted string for future requests) </deviceToken> 
    <customerId> (optional customer ID if required by partner) </customerId> 
    <creationTime> (optional ISO8601 date/time value) </creationTime> 
</result>

[destruk]

ok, you're right. As long as the same packaging key is used for all channels then I can share the registry token between them, so that will work just as well as a serial number would have.

[destruk]

I truly apologize for my behavior here. I understand why they want it done this way, and it's not difficult to change.
I do have another question though - how can I prevent the screensaver from activating during the linking process? I left a roku on the link screen last night, all night, and noticed a logged request and registration code from it on the server today so I deleted the record. 30 seconds later the record reappeared in the table - so I checked and the screensaver was active on the box. I was under the impression if the screensaver turned on, processing of the channel code would be paused, so how can I prevent execution when the screensaver is active?

[kbenson]

"destruk" wrote:
I truly apologize for my behavior here. I understand why they want it done this way, and it's not difficult to change.
I do have another question though - how can I prevent the screensaver from activating during the linking process? I left a roku on the link screen last night, all night, and noticed a logged request and registration code from it on the server today so I deleted the record. 30 seconds later the record reappeared in the table - so I checked and the screensaver was active on the box. I was under the impression if the screensaver turned on, processing of the channel code would be paused, so how can I prevent execution when the screensaver is active?

The way I think most people deal with determining when the screen save is active is including a custom screen saver with the app, and writing/updating a file in tmp:/ when it starts. The main program can check for the existence and content (to make sure it's recent) of this to determine whether the screensaver is running. I haven't done much with this, but I'm pretty sure TheEndless and renojim have used this method.

If you really just want to stop something from happening in the main code after a set period (and it doesn't really matter whether the screensaver is running, per-se), create an roTimespan object and update it on every msg (or every msg that entails user input), and if you've been idle too long, don't do the stuff you don't feel like...

[destruk]

Do you think they'll allow you to just ignore the screensaver timeout for a channel? If the videoplayer is doing something then it never turns on the screensaver.

[kbenson]

"destruk" wrote:
Do you think they'll allow you to just ignore the screensaver timeout for a channel? If the videoplayer is doing something then it never turns on the screensaver.

I doubt it, and as a user I wouldn't want them to allow it. On display devices that can have burn in, I would rather not allow a poorly coded app to ruin my hardware. At least requiring a customer screen saver implies the coder has to actively try to replace the existing behavior, and hopefully pay attention to the results. It's not that hard to implement a blank black screen, which I would consider the bare minimum.

[destruk]

If you were linking the roku to an account and the end user got sidetracked, allowing a screensaver to run all night isn't much of a 'solution' as it continues to take server resources polling for the registration result. I'd rather have the program exit to the home screen than turn on any screensaver - so I'll probably need to add a return code -1 to the registration routine when it has sat for 4.5 minutes since the minimum screensaver time is 5 minutes.

[kbenson]

No need to exit, just back out to a failure screen, and offer them the chance to try again (generate new code, start over, etc.). That way they aren't polling you all night AND when they do come back they are reminded they still need to link your channel.

[destruk]

That is good thinking. 🙂 roAudioPlayer continues to work during the screensaver though, so I think it would be cute to have it say something every 5 minutes, like "ROKU needs you" 😉