Roku Developer Program

[tiddy]

I have tried the get with retry and get with timeout, and it looks like after a successful link the second call to a second URL is unable to execute. My web service gets the HTTP request and completes but the application has exited by then. I've put in tons of debugging print statements and the second retry fails and the Roku returns to the home screen.

The next time the app runs, after this unexpected exit described above, the request executes perfectly and the channel list comes back.

I set m.Http.EnableFreshConnection(true) but it seems like the linking process does something to prevent later reuse of m.Http or something of that nature, but I'm gasping at straws. I can't get the debugger to break and let me step through and the console doesn't show and errors at all when the app exits, it just cleanly aborts back to the Roku home screen.

Anything I may have missed?

[tiddy]

So it turns out the problem is in returning from doRegistration...the app exits when doRegistration returns 0 indicating success. The next step in the calling method, in appHomeScreen, executes but the Roku is already showing the Roku home screen...

Do I need to garbage collect or close a screen?

[RokuJoel]

Just a guess here, but if you don't already have a screen open when you call your registration function, when the registration screen closes the channel will exit, although, sometimes, if you can open a new screen immediately afterwards you can prevent that. The best approach is to create your home screen, show it, but don't populate it with content unless registration is successful:

sub main()
screen=createobject("roposterscreen")
screen.show()
if doregistration() = 0 then 'registration failed
return 
end if
 
' registration is successful
screen.setcontentlist(getmyauthorizedcontent())
'do whatever your channel does, here
end sub

[tiddy]

That sounds really promising...I do proceed with the roPosterScreen which is my main UI *after* linking. I'll reorder that execution and see where that puts me.

Thanks again Joel, very helpful, as always. I'll confirm my results once I test.

** update ** that was it...I had not top level screen being shown, so returning from registration put the app into a free fall back to the main menu. Many thanks Joel. I'll finally get a good night's sleep.

[EnTerr]

"RokuJoel" wrote:
... if you don't already have a screen open when you call your registration function, when the registration screen closes the channel will exit, although, sometimes, if you can open a new screen immediately afterwards you can prevent that.

Huh, interesting - i was wondering when channel exits and after some experimenting seems that the criteria is that

• either BS code exits (RETURN or END)


• OR when the last open screen CLOSES

This explains why a script is able to run initially when there is nothing on screen - the screen stack might be empty but that does not get checked until window closing occurs - and when that happens if stack is empty, execution ends in a hurry.

The trick with showing screen right after closing previous does not seem to work reliably; for example there is not enough time to createobject() or sleep(1) - it has to be ready and waiting for show(), i suspect this is more of a bug than a feature

[TheEndless]

"EnTerr" wrote:

"RokuJoel" wrote:
... if you don't already have a screen open when you call your registration function, when the registration screen closes the channel will exit, although, sometimes, if you can open a new screen immediately afterwards you can prevent that.

Huh, interesting - i was wondering when channel exits and after some experimenting seems that the criteria is that

either BS code exits (RETURN or END)

OR when the last open screen CLOSES

This explains why a script is able to run initially when there is nothing on screen - the screen stack might be empty but that does not get checked until window closing occurs - and when that happens if stack is empty, execution ends in a hurry.

The trick with showing screen right after closing previous does not seem to work reliably; for example there is not enough time to createobject() and then show() it - it has to be ready and waiting, i suspect this is more of a bug than a feature

Per RokuKevin, from two years ago, the need for a "facade" screen is "well documented" (viewtopic.php?f=34&t=26350&p=162550#p162550). While I'd debate the use of the word "well" in that sentence, since I can only find a single reference to it in the SDK documentation, and that reference only suggests it as a way to prevent "screen flicker", Roku seems to consider it a feature rather than a bug.

[EnTerr]

"TheEndless" wrote:
Per RokuKevin, from two years ago, the need for a "facade" screen is "well documented" (viewtopic.php?f=34&t=26350&p=162550#p162550). While I'd debate the use of the word "well" in that sentence, since I can only find a single reference to it in the SDK documentation, and that reference only suggests it as a way to prevent "screen flicker", Roku seems to consider it a feature rather than a bug.

ah, you are the grand librarian of this forum, so resourceful!

actually it is ONLY NOW that i understand what the fly-by mentioning about "screen flickering" meant to say! it does not explain that the problem is much bigger - never mind some "flickering", when the last screen shown closes, the app gets killed within a few milliseconds! maybe that was not the case a few years back, quite possibly it was added later - but now it is relevant.

when saying bug-not-a-feature however i did not mean that - i meant doing scr1.close() and scr2.show() right after that and relying that this will work with no underlying "facade" - there is probably thread contention and this may stop working any day.

This "sudden-death syndrome" - killing the code when last visible screen is closed - i'd consider fair play IF IT WERE properly documented somewhere... which i haven't seen till now.