Roku Developer Program

[EnTerr]

So we have the main thread that is "halal" for all ro-components -
and we have render one that is "haram" for some -
is there a 3rd state like Tasks that are are, whatchamacallit... "hamal"? :mrgreen:
(wordplay for the win!)

[belltown]

"EnTerr" wrote:
So we have the main thread that is "halal" for all ro-components -
and we have render one that is "haram" for some -
is there a 3rd state like Tasks that are are, whatchamacallit... "hamal"? :mrgreen:
(wordplay for the win!)

I don't know exactly what you're asking here. But yes, there is a 3rd state.

From https://sdkdocs.roku.com/display/sdkdoc/Task:

"A Task node also allows you to run functions that cannot be run in Scene Graph node or component".

Also, you cannot "run functions in a Scene Graph application for operations that are functionally the same as Scene Graph nodes and components, such as playing videos".

The documentation is poorly-worded. Taken literally (assuming run functions refers to running functions within a Task node), it indicates that you can do things in a Task node that you cannot do in a Scene Graph component, and that you cannot do things in a Task node that you can do in a Scene Graph component. By applying an inductive leap, I come to the conclusion that there must be a 3rd state.

[EnTerr]

"belltown" wrote:
I don't know exactly what you're asking here. But yes, there is a 3rd state. ...

Yes - you got it what i was asking.

Hmm, i was musing last night when going to sleep - albeit it hasn't crystalized when i woke up, so need more brain power: can we come with some "pattern" if you will, some code/contraption atop Tasks, that can be used to handle "haram" functionality? So that one does not have to write a separate Task for every little method but instead maybe there is only one task^ with magazine of methods under it - and those get invoked function-call like, the behavior handled by a framework. The calls in general being asynchronous^^, either doing callback at the end or passing result message back to a common queue. And each "call" does not have to necessarily spawn a new thread - there could be a pool of waiting threads, or a new call-message may just wait till a worker thread is available. That could all be built using the primitives, the question is the result being more usable/intuitive than the current er, paradigm...

PS. see viewtopic.php?f=34&t=98722 for continuation

(^) task "factory" of sorts; <task/> is already a factory: tickling its .control forks threads
(^^) I am also musing about synchronous option, like wrapping in `await()` call, which to take care of collecting the async result and only then returning - but unsure if this is not counterproductive, in defeating the purpose of the "haram" list

[Corgalore]

"belltown" wrote:
Here's a very simplified example that illustrates the concept...   ...

Given the example code in the previous posts showing use of the Task Node, how would one then send data from the Task Node back to the Scene? Register another observed field ??

I'm thinking, some data pulled from a server, or a command to pause a video.

[belltown]

"Corgalore" wrote:

"belltown" wrote:
Here's a very simplified example that illustrates the concept...   ...

Given the example code in the previous posts showing use of the Task Node, how would one then send data from the Task Node back to the Scene? Register another observed field ??

I'm thinking, some data pulled from a server, or a command to pause a video.

Yes, use an interface field in the Task node, which the Task can set when it has data to go back to the Scene. In the Scene, use an observer on the Task's field to detect data passed back from the Task.