Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Search instead for 
Did you mean: 
tar
Level 7

Scene Graph: roRegistrySection and TaskNode

Hello everyone,

What is a correct way of using roRegistrySection inside scene graph components?
Per docs, roRegistrySection can be accessed from TaskNodes only.

Do I really have to create asynchronous task nodes and content node subclasses with my custom fields for each registry usage?
Is there a way to at least create a synchronous task node so I don't have to wire up all these observers and deal with multithreading complexity for such a simple task?

Are there any other synchronous persistent storage alternatives for scene graph?

Any help to simplify that out would be greatly appreciated.
0 Kudos
11 Replies
Veeta
Level 7

Re: Scene Graph: roRegistrySection and TaskNode

Yes, you need to create a Task node and read from the registry in its background thread.  It is a little verbose.
0 Kudos
tar
Level 7

Re: Scene Graph: roRegistrySection and TaskNode

Ok, bad news. Hope it will be easier in the future and developers will not have to suffer that much.
Thanks Veeta.
0 Kudos
EnTerr
Level 8

Re: Scene Graph: roRegistrySection and TaskNode

"Veeta" wrote:
Yes, you need to create a Task node and read from the registry in its background thread.  It is a little verbose.

I believe the right word is "verbogus"  :mrgreen:
0 Kudos
softworkz
Level 7

Re: Scene Graph: roRegistrySection and TaskNode

"tar" wrote:
Hello everyone,

What is a correct way of using roRegistrySection inside scene graph components?
Per docs, roRegistrySection can be accessed from TaskNodes only.

Do I really have to create asynchronous task nodes and content node subclasses with my custom fields for each registry usage?
Is there a way to at least create a synchronous task node so I don't have to wire up all these observers and deal with multithreading complexity for such a simple task?

Are there any other synchronous persistent storage alternatives for scene graph?

Any help to simplify that out would be greatly appreciated.

That's an incredibly stupid design decision that made me shake my head more than once.
Just consider: We're talking here about data with a size of no more than 16kb!! (more is not allowed for registry storage)
I solved it like this:

  • I'm storing my settings in my own AA

  • To make the data available everywhere in the channel, store this data as a field in the global node

  • To persist the data, I'm saving it as a JSON string in a single roRegistry string value

  • At app start, I load it with a task and wait for completion

  • Now all read operations can be performed synchronously by returning data from the AA

  • For write operations, I create a task to save to roRegistry, but I don't need to wait for the task to complete, because the AA already has the "latest" data

  • This way, all registry operations can be performed synchronously, just like before..
0 Kudos
EnTerr
Level 8

Re: Scene Graph: roRegistrySection and TaskNode

"softworkz" wrote:
I solved it like this:

  • I'm storing my settings in my own AA

  • To make the data available everywhere in the channel, store this data as a field in the global node

  • To persist the data, I'm saving it as a JSON string in a single roRegistry string value

  • At app start, I load it with a task and wait for completion

  • Now all read operations can be performed synchronously by returning data from the AA

  • For write operations, I create a task to save to roRegistry, but I don't need to wait for the task to complete, because the AA already has the "latest" data

  • This way, all registry operations can be performed synchronously, just like before..

Well done!
Except why run a task to read the registry on start? Just read it in main(), before getting in the event loop. 
0 Kudos
softworkz
Level 7

Re: Scene Graph: roRegistrySection and TaskNode

"EnTerr" wrote:
Well done!
Except why run a task to read the registry on start? Just read it in main(), before getting in the event loop. 

I wasn't sure I I'm allowed to modify "screen.getGlobalNode()" before calling "screen.Show()". I got some vague memory about a hint in the SDK docs about such a case. Setting it after "screen.Show()" is not an option because the scene's Init() process already needs the data.
Probably I've also been too tired of all that scenegraph stuff to actually try this...
0 Kudos
softworkz
Level 7

Re: Scene Graph: roRegistrySection and TaskNode

Found it: https://sdkdocs.roku.com/display/sdkdoc/roSGNode states:


Prior to creating an roSGScreen object and calling its show() function, creating roSGNode objects and using their interfaces is not guaranteed to work correctly.
0 Kudos
EnTerr
Level 8

Re: Scene Graph: roRegistrySection and TaskNode

"softworkz" wrote:
Found it: https://sdkdocs.roku.com/display/sdkdoc/roSGNode states:
Prior to creating an roSGScreen object and calling its show() function, creating roSGNode objects and using their interfaces is not guaranteed to work correctly.


Good point but... hmmm. Do you realize that Tasks are roSgNodes themselves? :twisted: 
In other words you mustn't create new tasks before you show the screen!

This was not a trap! Ok so it is a trap but it was put there by the Matrix Architect. Smiley LOL
0 Kudos
softworkz
Level 7

Re: Scene Graph: roRegistrySection and TaskNode

"EnTerr" wrote:
In other words you mustn't create new tasks before you show the scene!

And I'm not doing that.

I'm doing it as stupid as it's obviously meant to be:

  • HomeScene got 5 Tasks (as children)

  • On Init: Start Task1 (Task1 is reading the single registry string...)

  • On Task1Complete: Start Task2

  • On Task2Complete: Start Task3

Wow, isn't that impressive? A real revolutionary architecture...
0 Kudos