Incremental updates from Tasks

[Richard Bair]

Hi Dan,

> I haven't had much time to look into this in detail, but I'm wondering if we really need to change the Task API at all for this (and we seem to be ignoring Service in the above no?)

Actually, I think we only have to solve this for Task, because a Service simply binds to the state on the task. So if you have a task which calls updateValue multiple times, the Service will likewise get its value updated multiple times. The only problem will be a Service which returns an ObservableList -- each reset would cause it to be null and then get a value again with the new Task (because every Task has its own ObservableList). It might be nicer to have an ObservableListService which has a single stable ObservableList as its value which then has its contents bound to the contents of the ObservableListTasks's list.

> Don't we just want a thread safe channel that we can publish data into, does it need to built into Task? If instead we had a separate generic/utility class for this then the Task and the View (or whatever handles the published data) could just share an instance of this and listen to it accordingly. 
> 
> final ThreadSafeEventChannel<DataType> channel = new ThreadSafeEventChannel<DataType>();
> channel.setConsumer(new Consumer<DataType>() {
>      void handle(DataType data) {
>          // handle published data
>      }
> }
> 
> Task t = new Task<Whatever>() {
>     Whatever call()  {
>          // do some stuff
>          channel.publish(new DataType(...));
>     }
> } 
>  
> 
> Possibly the channel could even be an 'ObservableQueue', similar to ObservableList (although need to be careful with the API and threading). Maybe there is a case for having 'thread safe' versions of all the collection classes, so you could create them like so: 
> 
>     ObservableList list = FXCollections.threadSafeObservableArrayList();
>     ObservableMap map = FXCollections.threadSafeObservableHashMap();
> 
> Where the calls/callbacks for them are all mapped into the FXT as needed. 
> 
> Could also be extended to properties (e.g. ThreadSafeStringProperty). 
> 
> The Task could then use several queues, properties, collections or whatever to publish its data in whatever way makes sense to it. 
> 
> Just some thoughts. 

Interesting idea. I think you still want "updateValue" on the Task for just setting what the value is -- having a channel or whatnot I think is overkill. And to do this right, you need to have some collection then which knows about the FX thread. So add a thread-safe ObservableList to the javafx.concurrent package, and then your Task can just use that instead of the standard ObservableList and all is well. I really like that idea. A lot. Gets rid of this gnarly ObservableListTask.

However, it doesn't help with the "ObservableListService" -- in that case you still would get new ObservableList guys all the time. Something else to think about.

Richard