Is internal use of IProgressMonitor in an Eclipse plugin bad practice? [message #1692008] |
Sat, 11 April 2015 23:16 |
Tjalling Ran Messages: 1 Registered: March 2015 |
Junior Member |
|
|
Main question
Note: this question applies to plugin development.
Is it good practice to use the IProgressMonitor interface for internally keeping track of progress, or is that interface purely meant for giving progress feedback to the user?
Context
I'm developing a number of Eclipse plugins. One of these spawns a thread to do some processing (of external data, storing it in a database). Additionally, there is a Job that is run whenever the user wants to get a range of data from that database.
There are classes in the plugins that need to monitor the progress of the processing and / or the Job, for internal bookkeeping. More specifically, they need to keep track of the tasks' progress and state, such as the percentage of work done, whether they are completed and, in case of the thread, whether it is running or paused (suspended).
Approach
In other words, some kind of listener / publisher-subscriber -like behaviour is required. Because (1) we need to keep track of the amount of work done and (2) the fact that the Jobhas a monitor by default, I thought of creating an implementation of IProgressMonitor for this purpose. All interested classes should then attach a monitor instance to the task (/ Job) they are interested in.
For the Job, this would require something like an addMonitor method, to be able to add multiple monitors. To update all of its monitors at once, they could be wrapped in a single ProgressMonitorWrapper, as is done in an example on this page of the wiki.
A (slightly adapted) copy of the example:
Job aJob = new Job("My long-running operation...") {
protected IStatus run(IProgressMonitor monitor) {
IStatus status = Status.OK_STATUS;
IProgressMonitor wrappedMonitor = new ProgressMonitorWrapper(monitor) {
// override everything so that you can report it locally, too
@Override
public void beginTask(String name, int totalWork) {
super.beginTask(name, totalWork);
for(IProgressMonitor someLocalMonitor : monitors) {
someLocalMonitor.beginTask(name, totalWork);
}
}
// Override the other methods in a similar manner
};
wrappedMonitor.beginTask("foo", 100);
try {
// Execute, update amount of work done, etc.
}
finally {
wrappedMonitor.done();
}
return status;
};
});
Question
Again, the question is: is this approach laid out above (i.e. internal behind-the-scenes plugin use) proper use of the IProgressMonitor? Or should its use be restricted to displaying progress to the user, allowing the user to cancel ,etc..
|
|
|
Re: Is internal use of IProgressMonitor in an Eclipse plugin bad practice? [message #1692131 is a reply to message #1692008] |
Mon, 13 April 2015 18:14 |
Eclipse User |
|
|
|
I'd be wary of using IProgressMonitor for a couple of reasons.
First, as you noted, IProgressMonitor is meant to provide information to a user on a UI such as the Progress view or on a progress dialog. So the messages on beginTask() are generally meant to be meaningful for end-users. You'll likely have code trying to interpret those messages to determine state.
Second, the interface is not a good fit for your needs. IProgressMonitor is a reporting interface: it provides no facilities for querying the current state (e.g., how far along is this job?). What happens if a listener wants to join in mid-stream (e.g., after the beginTask() has already been done). So you'll need to re-play messages for late-comers.
Third, IProgressMonitor is defined in a package with a host of other interfaces (org.eclipse.core.runtime), bringing in a lot of baggage. That's fine if your code is tightly enmeshed with Eclipse, but if it's DB-related processing then I wonder if you really want to be so enmeshed. It makes it difficult to retarget this code at a later point.
I wouldn't recommend pursuing your approach. I'd instead define a machine-consumable interface and instead provide a wrapper that can use your custom interface to drive a IProgressMonitor.
Brian.
|
|
|
Powered by
FUDForum. Page generated in 0.03315 seconds