Roku Developer Program

[NB_]

"TheEndless" wrote:
Now, consider you have a ContentNode that provides the content for multiple grid components (grid1 and grid2).  Each grid component may want to register an observer on the ContentNode to monitor for any changes to the data, so it can update its UI.  If unobserveField() were nuclear, then grid1 would have no way unregistering its observer when its ContentNode (or visibility) changes without also unregistering grid2's observer.

... except that is exactly what unobserveField() does. Putting the record straight, unobserveField() is the "nuclear option" and will annihilate all observers on that component field.

Which is why in 7.5 another set of methods - observeFieldScoped() / unobserveFieldScoped() - was added, which maintains list of observer fn/ports local to the caller, so the flushing would be local in scope. Likewise, it does not provide individual opt-out - if the same component has set two observers on another component.field, both will be removed with unobserveFieldScoped().

[tim_beynart]

So I am going to implement a library by a vendor, and they require that we pass a reference to our SG Video node. In their documentation, they state the following:

During CreateSession(), the [Vendor Name Redacted] Roku Library will first unobserve and later observe for the change in the content of the Video node fields - streamInfo, position, state, duration, streamingSegment, errorCode, errorMsg. Below is a sample code snippet from CreateSession(...) 

video.unobserveField("streamInfo")
video.unobserveField("position")
video.unobserveField("state")
video.unobserveField("duration")
video.unobserveField("streamingSegment")
video.unobserveField("errorCode")
video.unobserveField("errorMsg")
 
video.observeField("streamInfo", port)
video.observeField("position", port)
video.observeField("state", port)
video.observeField("duration", port)
video.observeField("streamingSegment", port)
video.observeField("errorCode", port)
video.observeField("errorMsg", port)

Does this mean I can expect all my app's observers to get nuked when I implement this library?

[destruk]

Yes Tim. 😞  But it would make sense that their library simply wants to set up its own observers after they unobserve every possible field to be able to ensure theirs are the only ones running.  So just like they did, you can add yours back in, or comment theirs out.  Since you can have the same field observed to run an infinite number of callbacks....

[tim_beynart]

The fun never stops!

[NB_]

"destruk" wrote:
Yes Tim. 😞  But it would make sense that their library simply wants to set up its own observers after they unobserve every possible field to be able to ensure theirs are the only ones running.  So just like they did, you can add yours back in, or comment theirs out.  Since you can have the same field observed to run an infinite number of callbacks....

It may have made sense before, when there was only ObserveField(). Now (7.5+) that there are -Scoped methods, said vendor would do better using ObserveFieldScoped() with their own component and perhaps a separate port. It depends on the exact API needs really, i cannot state with a 100% certainty