Incremental updates from Tasks
Daniel Zwolenski
zonski at googlemail.com
Wed Jan 11 19:12:50 PST 2012
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?)
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.
On Tue, Jan 10, 2012 at 9:12 AM, Richard Bair <richard.bair at oracle.com>wrote:
> I've attached the latest full patch with tests to the issue (
> http://javafx-jira.kenai.com/browse/RT-18820). I'll retarget it to 2.2
> unless somebody is available to do an in depth review and let me know what
> you think. I think it is all set and ready to go, the only thing that kind
> of bothers me is the name ObservableListTask and the "process" name, since
> I have used "update" for the same functionality in Task / TaskBase.
>
> Thanks
> Richard
>
> On Jan 6, 2012, at 3:40 PM, Richard Bair wrote:
>
> > I tried the following. I created a TaskBase, and moved almost everything
> from Task to TaskBase. Task now extends TaskBase, and adds:
> >
> > updateValue(V value);
> > abstract V call() throws Exception;
> >
> > It is entirely compatible with the previous version and all the unit
> tests still pass. The only difference is that the method we expose (call)
> returns a value and is declared on Task instead of TaskBase. Also, the
> updateValue is only on Task.
> >
> > ObservableListTask also extends TaskBase, and adds:
> >
> > protected abstract void call() throws Exception;
> > protected void publish(E... items);
> > protected void publish(Collection<E> items);
> >
> > I just used the SwingWorker name "publish", but there is no process.
> Whatever you publish gets added. We could add a process with a default
> implementation if we wanted to (allowing some users to filter results or
> whatnot, but I'm not sure there is a reason you want to do that on the FX
> thread instead of the background thread, so I would propose leaving it off
> for now).
> >
> > This call() method returns no value, just the way it should be. You just
> call publish to put add items. Since the Task is a one-shot deal, there
> isn't really a compelling reason to add other methods like clear() (you
> could also do your own runLater() if you needed to do something tricky).
> >
> > What do you think? Here is an example of usage (complete with fading
> rectangles :-)):
> >
> >
> > ObservableListTask<Rectangle> task = new
> ObservableListTask<Rectangle>() {
> > @Override
> > protected void call() throws Exception {
> > for (int i=0; i<900; i++) {
> > Rectangle r = new Rectangle(10, 10);
> > r.setFill(Color.color(Math.random(), Math.random(),
> Math.random()));
> > r.setOpacity(0);
> > FadeTransition tx = new
> FadeTransition(Duration.seconds(1));
> > tx.setToValue(1.0);
> > tx.setNode(r);
> > tx.play();
> > publish(r);
> > Thread.sleep(20);
> > updateProgress(i, 900);
> > }
> > }
> > };
> >
> > Richard
> >
>
>
More information about the openjfx-dev
mailing list