cdthompson
commented
7 years ago I think it would be good addition to the library. It originally came from a non-SceneGraph implementation, so assumes 'm' is the GlobalAA reference. It wouldn't be difficult to refactor that part out and wrap the whole of the library into a Task.
The open issue is which Task pattern to use... I've implemented both short-lived Task threads which launch and exit, as well as long-lived Task threads that have a messageport and while loop. I've even implemented events going from SceneGraph UI thread to the main BrightScript thread. Also, there is a question of whether to have a global instance of the Task, perhaps referenced by m.global, or to give each component a local instantiation of the task. There are pros and cons to each approach.
Perhaps the most flexible would be a long-lived thread listening to field events from a messageport. Tracking events would be serialized by the firmware and sent off one at a time. This will reduce the task management overhead and risk of garbage collection before a finished tracking request.
siekermantechnology
Are there any plans to get this to work in SceneGraph, where all network traffic has to happen in Task nodes, instead of messageport while loops?
Although quite a bit can be reused, it would require significant re-architecturing, so I can imagine that you might not be inclined if you don't have a specific need for it yourself.