In order to improve usability of my RCP application I decided to manage all the “long” operations using Jobs. This post will introduce several solutions to handle “composite” tasks progress reporting across a concrete example I faced this morning.
Having already used the Job API I felt confident on the time needed to implement this. I was right about the time needed to use the Job’s API but I was wrong about the way to organize several related operations into several (or one ??) job(s).
Lets describe the context. The user is performing a “File->Open” action and want report on the progress of this action. Progress report is needed because opened files are big and a lot of computation has to be done on these files. This “File->Open” action is composed of 3 sequential “subtasks”: parsing, analyse and display. I am able to easily report accurate progress for each one of these tasks, but unfortunately I am not able then to have an accurate estimation of each task time in the global process composed of the 3 tasks.
Today I have 2 solutions in order to report
what is happening behind the scene how many time is happening behind the scene (this IS really what the user cares !!!).
First solution: Use 3 distincts Jobs.
This solution can be easily implemented using IJobChangeListeners. A first Job is created for the parsing tasks. This Job is scheduled and thanks to Job listeners I am able to be notified when it’s completed in order to create and schedule the analyze Job. The same process is apply between the analyze Job and the display Job. This solution present the 3 tasks to the user with an accurate estimation time for EACH ONE of these tasks. As I mentioned before, this is the best I can do because I am not able to estimate each task time in the global process. Here the new user may think that the global “File Open” action will be completed at the end of the first Job ….??!!! Another drawback of this solution is that the user is prompted with 3 UI progress dialogs (all my Jobs are user Jobs so there is successively: “Parsing File dialog”, “Analyze File dialog” and “Display Dialog” ) for only one “File->Open” action.
Second solution: Use one main Job and 3 Submonitors inside this Job.
I came to this solution in order to try to fix the second drawback of the first one (3 UI dialogs for oen action). I’ll not step into implementation detail here but lets analyze the result. Why ? We have a unique UI progress dialog NOT accurate: we can clearly distinct the 3 stages stepping each one at a different speed. What is better: only one UI dialog not accurate or 2 “surprise” dialogs that appear after the first accurate one ?
An other solution would be (I didn’t find anyway to implement it for now):
Third solution (not sure this can be done .. any ideas ??): Have one Job with 3 Submonitors inside this Job but reporting the 3 Submonitors as 3 X 100 %. What I mean here is to have only one UI progress dialog called “Opening File” that will be “filled in from 0% to 100%” three times (one for each sub-task). This solution is the same as the first one but it will fix the problem of having 3 separated UI dialogs.
In all of these solution the end user “will” have on the first usage a “wrong” first estimation time …. Thus I would be interested to know how you handle such situations, so feel free to leave comments on this topic.