Add progress monitor support

[reinra]

Add a callback which gets events about the operation progress so users could update a progress bar e.g. Check other libraries for the same abstraction first.

[shelajev]

I see a full possible interface for ProgressHandler to be like:

interface ProgressHandler {
  void init(double totalWork);
  void increment(double step);
  void update(double done, double totalWork);
  void finish(boolean cancel);
}

A simple adapter could be used to make the interface simpler, like:

public abstract class ProgressHandlerAdaptor {
  protected double doneWork = 0.0;
  protected double totalWork = Double.NaN;

  public void init(double totalWork) {
    this.totalWork = totalWork;
  }

  public void increment(double step) {
    this.doneWork += step;
    notify();
  }

  public void update(double doneWork, double totalWork) {
    this.doneWork = doneWork;
    this.totalWork = totalWork;
    notify();
  }

  public void finish(boolean cancel) {
    // do nothing by default
  }

  protected asbtract void notify();
}

Well, maybe we also need getters for the state. I don't think any syncronization is needed. What do you think?
Finish is nice to have for all kinds of exceptions to notify that the work is done and handler is won't be updated any more. Maybe we even want to pass an optional exception instance there.

Moreover maybe update(double, double) is enough for all use-cases and others methods are not necessary :)

[toomasr]

Seems like a nice to have feature with lots of different ways how to implement this. Maybe we'll come back to this when we have solid use cases? @reinra @shelajev what do you guys think?

[shelajev]

Well, we could fire up a branch and implement it in some way. The idea is that when there is an implementation, someone might try it out. Maybe even we would do that inhouse. Then improvements to the API and discussion will come easier.
But there is no rush with this.

[toomasr]

Maybe you could propose a use case that we want to solve, right now "add progress monitor support" is too vague for me and I'm afraid that we might implement just a feature for a feature's sake. I'm in to try things out but would need some vision to follow.

[reinra]

I propose two cases - one with console and another with GUI. There's a nice
tutorial about GUI progress bars in Java:
http://docs.oracle.com/javase/tutorial/uiswing/components/progress.html

[pommedeterresautee]

@toomasr Hi,

I just tried your lib which is working perfectly.

You are asking for a use case of a progress monitor. I am using your lib in a not yet released update of my application OBackup. It s an Android application to make some kind of backup (called Nandroid, if you have an Android device, you may know what it is). Anyway, the point is that a backup can be huge, like several GB, and some devices are not rapid, so I have to display the progress of the task otherwise people can become made! A big zip can take like 10mn to compress.

With a monitor interface I can display the progress in the notification bar.

BTW, I have found a workaround, by just implementing the progress monitor through a decorator on the InputStream. But it means I need to use InputStream and I lost the simplicity of the API of this lib.

That's why a progress monitor correctly implemented in the lib would be very useful to me.

Regards

[toomasr]

Ok, great to see that there is interest for this. Quick chat with @shelajev produced the idea that maybe we can provide some counters. For example the number of files and/or bytes processed that we'll update as we go through the entries? For streams we wouldn't know the total numbers for a % but the user probably would. Does that sound like a plan?

@reinra what are your thoughts on this issue?

[pommedeterresautee]

Great to see you are interested in the implementation of this feature.

IMO we need three basic data : the number of file already processed including the one processed, the number of byte processed regarding the file currently processed and the total number of byte processed including all files already processed.

Even better is to provide total to processed too. Like number of file to process, number of bytes to process...

This second category can be guessed by the dev in the code but it may be easier to get it from the callback.

Another thing I noticed is missing is that we can compress a file or a folder but not several files from a folder (but not all). Not a big issue I am creating a temp folder and move files inside but would be cleaner if we would able to provide a list of files. I don't open a new issue as I am not sure it's an important feature to have. If you have time and search perfection...

[reinra]

Hi there,
quick question - should the API in your case return the current status -
you have your own separate thread running - or do you want to register
custom callback which would be invoked after each file or 1MB or etc - you
would use the original thread. In the first case I guess we need to provide
entire info (no of files, bytes) also atomically.

On Tue, Aug 13, 2013 at 9:36 AM, El Potaeto [email protected]:

Great to see you are interested in the implementation of this feature.

IMO we need three basic data : the number of file already processed
including the one processed, the number of byte processed regarding the
file currently processed and the total number of byte processed including
all files already processed.

Even better is to provide total to processed too. Like number of file to
process, number of bytes to process...

This second category can be guessed by the dev in the code but it may be
easier to get it from the callback.

Another thing I noticed is missing is that we can compress a file or a
folder but not several files from a folder (but not all). Not a big issue I
am creating a temp folder and move files inside but would be cleaner if we
would able to provide a list of files. I don't open a new issue as I am not
sure it's an important feature to have. If you have time and search
perfection...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-22545791
.

Rein Raudjärv
LiveRebel Architect
ZeroTurnaround

[pommedeterresautee]

I am not sure to understand.

Compression is done on a different thread that the one containing the UI.

So the call back is registered on the UI thread but is called during the compression in the other thread.

In every lib I used with a callback (like Dropbox Sdk or Gdrive one) it's always done like that. Also the the callback is called at every small step. Not one time per file but more more often. It should be called the more often possible. And it s up to the dev to use some condition to react to the change or not. If it s correctly programed by the user of the lib it should not make the compression slower.

I am not an Api expert at all. I am just sharing my humble opinion.

Regards

[reinra]

Sorry for the confusion. From your reply the answer to my question was
option 2 - our library should regularly invoke user code (a given callback)
not vice versa.

On Tue, Aug 13, 2013 at 11:15 AM, El Potaeto [email protected]:

I am not sure to understand.

Compression is done on a different thread that the one containing the UI.

So the call back is registered on the UI thread but is called during the
compression in the other thread.

In every lib I used with a callback (like Dropbox Sdk or Gdrive one) it's
always done like that. Also the the callback is called at every small step.
Not one time per file but more more often. It should be called the more
often possible. And it s up to the dev to use some condition to react to
the change or not. If it s correctly programed by the user of the lib it
should not make the compression slower.

I am not an Api expert at all. I am just sharing my humble opinion.

Regards

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-22549485
.

Rein Raudjärv
LiveRebel Architect
ZeroTurnaround

[shelajev]

Another thing I noticed is missing is that we can compress a file or a folder but not several files from a folder (but > not all).

@pommedeterresautee, I added an issue about filtering entries to add: #41

Currently, I've added it to fluent api, let me know what you think.

[toomasr]

Grooming the backlog, as there hasn't been much interest nor action the closing for now. Feel free to re-open.

[marcopenhacking]

I would be interested as well in that feature. Maybe you can retrieve it from the backlog.

[toomasr]

I tried to create a progress bar and this is how it turned out. See https://github.com/toomasr/zt-zip-progress-bar

It is a CLI progress bar. It generates 100 1mb files and then starts packing them. I'm using a NameMapper to hook into showing the progress bar on the console.

I'm using a file number approach. I have a 100 files and I show the percentage based on how many files have been processed. The other approach would be to do it based on how many bytes of the total bytes to be compressed have been processed.

I hope this helps.

[marcopenhacking]

Good starting point the nameMapper. Thanks a lot for the example!

[goxr3plus]

Great to have this feature in the library!!! :)

[AAChartModel]

Do you know how to get the Progress of Zipping and Unzipping the single file (not the folder ) ?

Refer to the issue #116

@reinra @shelajev @pommedeterresautee @marcopenhacking @goxr3plus Thanks🙂