Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Add progress monitor support #26

Closed
reinra opened this Issue · 13 comments

4 participants

@reinra
Collaborator

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
Collaborator

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
Owner

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
Collaborator

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
Owner

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
Collaborator
@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
Owner

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
Collaborator
@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
Collaborator
@shelajev
Collaborator

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
Owner

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

@toomasr toomasr closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.