Roku Developer Program

[greubel]

Question: Is there a way to detect if the App is sideloaded ?
I have a lot of tracing in my app and would like to be able to turn them off if running production.
I would like to skip them before actually formatting the print line.

Question: Is it possible to capture an error and do anything with it, other than just crashing ?
Makes it very difficult to debug a user's error, nothing to go on.
Couldn't we establish a contingency routine and get it called on an error with some info. If it crashes again, then kill it.

Question: What does Roku do with open sockets on an App crash ?
It appears, NOTHING.
When I restart the App from an error, I get all kinds of tcp interrupts before I can actually do anything.
Eventually they get cleared up. But, the longer I wait till I restart, the more interrupts get queued.

[gonzotek]

"greubel" wrote:
Question: Is there a way to detect if the App is sideloaded ?
I have a lot of tracing in my app and would like to be able to turn them off if running production.
I would like to skip them before actually formatting the print line.

Question: Is it possible to capture an error and do anything with it, other than just crashing ?
Makes it very difficult to debug a user's error, nothing to go on.
Couldn't we establish a contingency routine and get it called on an error with some info. If it crashes again, then kill it.

Question: What does Roku do with open sockets on an App crash ?
It appears, NOTHING.
When I restart the App from an error, I get all kinds of tcp interrupts before I can actually do anything.
Eventually they get cleared up. But, the longer I wait till I restart, the more interrupts get queued.

I'm not sure if you can detect if the app is sideloaded, but you could add 'sideload' to the app title or subtitle in the manifest, then check for that on program launch, and determine your app's behavior from there. Then you just need to remove 'sideload' from the manifest when you're ready to release.

Check out eval: http://sdkdocs.roku.com/display/RokuSDK ... tAsInteger

Eval can be used to run a code snippet in the context of the current function. It performs a compile, and then byte code execution. The runtime error is returned – these are the same error codes are returned by GetLastRunTuntimeError().
Eval() can be usefully in two cases. The first is when you need to dynamically generate code at runtime. The other is if you need to execute a statement that could result in a runtime error, but you don't want code execution to stop.
Print Eval("1/0") ' divide by zero error

I'm sure there's a performance hit for its use, so you want to use it as sparingly as possible.

Can't answer the third question, hopefully Joel or Mark have some suggestions or can log an issue for it.

[RokuMarkn]

Can you clarify what you mean by "TCP interrupts"? Do you mean you receive unexpected roSocketEvents?

--Mark

[greubel]

Yes, sometimes it sits there for 30 to 60 seconds on the telnet screen scrolling interrupts.

[Anonymous]

Two potential ways to tell if a channel is sideloaded:

The DevID (http://sdkdocs.roku.com/display/RokuSDKv48/ifHttpAgent) will be different for a sideloaded channel. If course, if you're using your DevID (generated when you do 'genkey') for authentication purposes, that might not be the best idea.

Also, if you have a sideloaded channel, then when you query the list of channels with ECP, you'll see a plugin id for "dev" (iirc) http://sdkdocs.roku.com/display/RokuSDK ... trol+Guide

[greubel]

Thanks ! Looks like the ecp approach should work fine.

[gonzotek]

The only problem with that is that it doesn't distinguish between side-loaded channels. If I'm understanding your need correctly, you want to leave in a bunch of debugging statements in a released channel, but only have them triggered when the channel is launched if the channel has been side loaded(so that you can debug, eventually release, and also continue to debug without having to go in and add/remove all the debugging statements for each subsequent release). So if the released channel checks for a 'dev' plugin id on the end user's Roku, and they have a different side-loaded channel on their Roku(because they're also a developer, for instance), your debugging code will get triggered. Maybe that's not important(it's not like the debugger port is accessible in released channels), but I thought it worth mentioning, just in case.

[greubel]

Thanks ! I was already checking for "dev" and my channel.
Works great ! Now I can skip the overhead of formatting the debugs but still keep them if the user turns on logging.

[TheEndless]

"gonzotek" wrote:
Maybe that's not important(it's not like the debugger port is accessible in released channels), but I thought it worth mentioning, just in case.

Dumping a lot of data to the console, whether it's accessible by the end user or not, can still have a significant performance impact on your channel.

"greubel" wrote:
Thanks ! I was already checking for "dev" and my channel.

Like gonzotek, I'm not clear on how this would work. Say, for instance, you have the public version and the side-loaded version of your channel installed, and you launch the public version. How would it know that it wasn't the side-loaded version, if all you're doing is checking for the existence of a "dev" channel named "Chaneru" via ECP? I guess it's probably safe to assume that 99.9% of your user base won't have a side-loaded version of Chaneru installed, but still...

[greubel]

Again, you guys are right !
I really didn't want to have to change anything but I guess I have to check the version number that comes back in the ECP data against my pkg manifest version.
Then I could have multiple levels of the app loaded and the "dev" should work in test mode. The only thing is I have to remember to change the version in the manifest.
You would think Roku could provide a flag or a value in the runtime call param.