3

If I read a file until it hits a null line and want to create a somewhat accurate JProgressBar for when the reading will be finished, how would I do this?

The reason I ask is because some files are read within 200ms where as others take between 2500ms and 10000ms.

I'm doing something simple for reading the file

boolean completed

while(!completed) {
    //read file
    if(reader == null) {
        completed = false;
    } 
}

So is there a way to make a progress bar accurate for a situation like this? (by the way, the size of the file doesn't necessarily mean it will take less time to read in this case)

WilliamShatner
  • 926
  • 2
  • 12
  • 25
  • 2
    If you cannot accurately predict when the task is going to finish, how do you expect to accurately display that information in a progress bar? – Sergey Kalinichenko Apr 19 '12 at 16:01
  • 2
    That's why there are indeterminate modes for progress bars. – Thomas Apr 19 '12 at 16:03
  • @dasblinkenlight That's basically what my question was. I just wanted to confirm that there wasn't a way to do so before moving on. @ Thomas thank you for the response, I'll probably resort to using indeterminate mode then! -- Thanks guys – WilliamShatner Apr 19 '12 at 16:10
  • Can you get the size of the inputstream to read before? If you can't set a maximum ratio to your progressbar, you can't make an accurate one. – alain.janinm Apr 19 '12 at 16:15

1 Answers1

6

Use the size of the file -- it's your best measure.

What you display has to have meaning that the users can understand. That's the most important part. If the progress bar means the percent of the file that has been processed, that's very easy to understand, easy to quantify, and easy to calculate and display. This makes your progress bar transparent, and that is what's important.

Think about how this is to be viewed by users. You don't need to program some sort of predictive intelligence because the users have brains and they can draw their own conclusions. So if they see the progress bar run fast for the first half and then slow down, they know that the it's processed half of the file, but the second half is taking longer. That's all they need to know! They can draw their own conclusion that since the progress bar slowed down, that it may take longer to finish the file than the time indicated in the first half.

In fact, the users may already know something about the file being processed. For this particular file, they may know that the useful (or long-processing) data is all in the second half. So when they see the progress bar slow down, it is expected to them. This gives the transparency needed for the users to know that the software is working like it should, and they can draw their own conclusions about how long they need to wait.

Of course, it could also still be useful to show a generic estimation "25% of the file processed in 3 seconds, so we estimate an additional 9 seconds to completion." This is also a very general basic equation that is transparent, so the users can know how to use it and adjust it for the specifics of the file they are processing.

Erick Robertson
  • 32,125
  • 13
  • 69
  • 98
  • I won't be able to make use of the file size, however you made some really good points in your answer. Thank you for the good read and simplifying what I should be aiming for. – WilliamShatner Apr 19 '12 at 20:59