See: Description
Package | Description |
---|---|
org.netbeans.api.progress |
This API allows to visualize tracking for progress of long lasting tasks.
|
org.netbeans.api.progress.aggregate |
Advanced progress manipulation, allowing to construct a single progress indication bar
from multiple, possibly independent sources.
|
The module will be autoload. There is an api module and a pluggable implementation. Progress
ProgressUtils
class with runOffEventThreadWithCustomDialogContent
and runOffEventThreadWithProgressDialog
methods were added.
ProgressUtils
class with runOffEventThreadWithCustomDialogContent
and runOffEventThreadWithProgressDialog
methods were added. These methods allow movement of operations out of AWT thread, showing the waint cursor after one second and a dialog when task is not finished in a three seconds.
Added methods to ProgressUtils for invoking a runnable or similar with a modal dialog blocking the UI and showing progress:
public static void showProgressDialogAndRun(Runnable operation, String displayName)
public static <T> T showProgressDialogAndRun(final ProgressRunnable<T> operation, final String displayName, boolean includeDetailLabel)
public static void showProgressDialogAndRun(Runnable operation, ProgressHandle progress, boolean includeDetailLabel)
public static RequestProcessor.Task showProgressDialogAndRunLater(Runnable operation, ProgressHandle progress, boolean includeDetailLabel)
Added interface ProgressRunnable for performing background work, and an SPI class ProgressRunOffEdtProvider which is implemented by the Progress UI module.
An internal SPI package was exposed. Normal modules should not need to access this package.
ProgressUtils
class with runOffEventDispatchThread
methods was added.
ProgressUtils
class with runOffEventDispatchThread
methods
was added. These methods allow movement of operations out of AWT thread while blocking UI.
ProgressHandle.suspend(String)
method for visual suspend of a running task.
Adding suspend(String)
to ProgressHandle
class.
Any progress event coming after this call wakes up the progress bar to previous state.
Currently running task can switch to silent suspend mode where the progress bar stops moving, hides completely or partially. The exact UI behaviour is undefined.
Useful to make progress in status bar less intrusive for very long running tasks, eg. running an ant script that executes user application, debugs user application etc.
There are 3 types of progress indication:
The default location of the progress indication is the status bar which aggregates all tasks running in the IDE that show progress. However it's possible to exclude the task from the default location and show the progress in one's custom dialog component. In such a case the same task should not appear in the status line component as well.
It's possible to request cancelling the task from status line progress aggregator if the task allows cancelling.
Progress tasks that get started as a result of explicit user action takes precedence in the status line docked component over tasks that are triggered by the system. (say filesystem refresh for example)
The most common usecase of the API looks like this:
ProgressHandle handle = ProgressHandleFactory.creatHandle("My custom task"); ... // we have 100 workunits // at this point the task appears in status bar. handle.start(100); ... handle.progress(10); ... handle.progress("half way through", 50); ... handle.progress(99); // at this point the task is finished and removed from status bar // it's not realy necessary to count all the way to the limit, finish can be called earlier. // however it has to be called at the end of the processing. handle.finish();
In case your usage of the API
then you should consider using the aggregating version of APIs which is similar to the simple APIs but has distinctive differences and additions that allow for more complex scenarios.
It allows to compose the progress bar from 1+ independent sources, all sharing proportional piece of the progress bar. Additionally you can monitor the task's overall progress from one central place and possibly add more contributing sources of the progress during processing.
// let's have a factory for client code that performs some part of the job to be done.. Lookup.Result res = Lookup.getDefault().lookup(new LookupTemplate(MyWorkerFactory.class)); Iterator it = res.allInstances().iterator(); ProgressContributor[] contribs = new ProgressContributor[res.allInstances().size()]; int i = 0; while (it.hasNext()) { MyWorkerFactory prov = (MyWorkerFactory)it.next(); contribs[i] = AggregateProgressFactory.createProgressContributor("Module X contribution"); MyWorker worker = prov.createWorker(contribs[i]); //... snip ... do something with the worker.. i = i + 1; } AggregateProgressHandle handle = AggregateProgressFactory.createHandle("My Task", contribs, null, null); // non-cancellable and with out output link. // calling start() at the time when the actual long running task starts processing handle.start("here we go"); // ...snip... // now the individual MyWorker instances log their progress. // possibly in other threads too.. // ... snip... // if (myConditionThatSpawnsAnotherContributor()) { ProgressContributor cont = AggregateProgressFactory.createProgressContributor("Additional exceptional contribution"); handle.addContributor(cont); // ... snip ... } // the task is finished when all the ProgressContributors finish..
|
Nothing.
Read more about the implementation in the answers to architecture questions.
Built on November 9 2014. | Portions Copyright 1997-2014 Oracle. All rights reserved.