Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Here's a scheme that just came to my mind:</p> <pre><code>interface WorkProcess void setWorkUnits(int units) void setArguments(Object obj1,...) void execute() </code></pre> <p>So you encapsulate all your tasks with an interface that does <code>execute</code> as per the classic command pattern; it's also told (see below) how much work that job will probably take. You'll probably want some mechanism to pass data into these tasks for them to work with.</p> <pre><code>class WorkProcessFactory static WorkProcess makeWorkProcess() static int getTotalWorkUnitsAllocated() static synchronized int reportWorkDone(int units) static void addProgressListener(ProgressListener xxx) </code></pre> <p>When you have a job to do, you ask the factory to churn out one of these processes for you. In doing so, it does the estimate on work units and passes that to the WorkProcess it just created. It also keeps a tally of the total of those units for setting up the top of the progress indicator. One cool side effect of this is that you don't have to wait for all your jobs to be prepared: You can increment the maximum value for your progress report every time you add a job even as jobs are being processed and newly created; your bar will always show a realistic ratio.</p> <p>You can stuff your WorkProcesses into a queue of some sort. <code>ExecutorService</code> comes to mind if your WorkProcess also implements the <code>Runnable</code> interface (which is a good idea). You'll be at liberty to process those jobs sequentially single-file or concurrently - whatever your execution queue machinery supports.</p> <p>The WorkProcess' <code>execute()</code> method basically wraps the <code>run()</code> method (or maybe the other way around, since ExecutorService expects a run() method but our work unit magic is in <code>execute()</code>); but when that's done, it conscientiously calls back to <code>reportWorkDone</code> with the number of units it was told its job was worth. Upon receiving these reports, the factory has an updated value for units of work done, which it can report back to the snooping ProgressListener. That, in turn, updates the bar in the GUI. </p> <p>Done. (I think). Probably needs some refining.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload