This library uses standard HttpClient, so I don't know if it's possible, but if it is, I would be very interested too.

I managed to do it but it was a bit tricky. I'll update this post in a bit with an example.

I've detailed the way to do this when uploading files (it could be adapted to other post calls as well) here (bottom, read uploading large files and progress callback): https://github.com/voidberg/Android-Drupal-Sdk/blob/master/README.md

You can grab the CustomMultiPart.java file here: http://android.svn.wordpress.org/trunk/src/org/xmlrpc/android/CustomMultipartEntity.java

Hi @voidberg ... the link is broken. Can you please update it.
Thanks

I updated the name of the repository, sorry. Here's a correct link: https://github.com/voidberg/DrupalDroid/blob/master/README.md

I think this issue should be opened again. It would be a great feature to give users the possibility without a bunch of boiler plate code. I'm willing to implement it and send a pull request if it's likely to be accepted.

One of my main concerns is that this feature will increase the size/complexity of the library. If you think this can be implemented in a simple way, I'm open to discussion.

I think it can be very simple. I'll give it a try and let you know the result.

I am beset by the question ，Now.

@nadam ma man!!!!!
@loopj almost perfect lib but my clients wanted a progress bar, this was the only reason i couldn't use this. I have some commercial apps in-line, hopefully would use this lib again. Cheers great work.

I've analyzed the code now. Not as simple as I thought, but I think I can solve it and make it pretty simple.

@loopj as you probably know there are issues with the whole files being read into memory in SimpleMultipartEntity causing OutOfMemory. I think I can solve that at the same time with pretty small changes.

However, the number of open issues, pull requests and printStackTrace() statements makes me a bit worried. Not sure if I should spend time cleaning up this project or find some fork of it or other alternative. I'm open to suggestions and recommendations. Thanks.

Would it be reasonable to deprecate the methods that add files as input streams in favor of similar methods using File objects?

How about using FileBody instead of InputStream?

FileBody is part of httpmime that we don't want to include because of the size, but I'm implementing something similar. I mean when adding a File object it will be read as a stream later when it's sent on the socket.

hi @nadam . Hope your still working on this. Eagerly waiting for a merge.
Cheers

I realized that I can't deprecate the stream methods. One example is if you read an image from disc and scaling it down etc. Now you have a new image in memory that you want to send to the server. No file or file object.

But a stream can only be read once, so it has to be read into memory. Otherwise the retry functionality won't work. Some streams can be reset() but it's not obvious when/where to close() the streams.

So I will focus on implementing it for files and leave the stream implementation in it's current state. The first part, solving the memory problem, is almost ready for testing. Hopefully, the upload progress is pretty easy after that.

This small patch works fine for me:
jensh@256ec9425b4

To get notifications every 64kbytes override onProgress of AsyncHttpResponseHandler:

RequestParams params = new RequestParams();
params.put("image", imageStream, "image.jpg", "image/jpeg");
client.post(url, params, new AsyncHttpResponseHandler() {
            @Override
            public void onProgress(int position, int length) {
                Log.d("progress", "pos: " + position + " len: " + length);
            }
})

What do you think? Comments welcome!

Thanks @jensh. That's similar to what I had planned. I finally pushed my changes and merged yours over at https://github.com/nadam/android-async-http, so now it contains both upload progress and minimal memory allocation. I haven't had time to test it though. I hope someone else wants to do that.

Hi @nadam , thanks for your contribution of course Progress callback is a great feature, is your changes are in the loopj JAR already ?

It's not merged into loopj's repo yet. I never got the time to test it so I never sent a pull request or anything. Would be awesome if you could test it for us. I can send you my jar-file or you can build it yourself from https://github.com/nadam/android-async-http. Thanks.

Yes I just add it on my project, 5 min to import and use it. Work nicely, I can see my progress bar filling well, thanks you ! (I am using Php as backend, with Nginx as HTTP server. Tested on my Wiko under Android 4.0).

Cool! Thanks @ebuildy! Now I just have to figure out how to make a pull request properly. I forgot to create a topic branch for my changes and I've also included one unrelated bug fix. Not sure if it's good enough to just create a pull request anyway or if I need to do something first. I don't know what it takes to get a pull request accepted by @loopj and my time is quite limited too at the moment.

+1

+1 waiting for merge

+1 hoping to see this merged, it's the last thing I need from this library!

+1

+1

No manual/docs yet but it's pretty straight forward, just override onProgress() in AsyncHttpResponseHandler. The code is over at https://github.com/nadam/android-async-http.
A pull request is waiting to be approved at #269.

Is that branch up to date with the main repository?

+1 works perfectly.

hmm I also see #302 by @jensh

#302 is included in #269. Additional @nadam improved the file and stream handling. I opened #302 because @loopj asked for smaller pull requests.

So this is now provided by linked commit.

Hi @nadam I am using the onProgress() of BinaryHttpResponseHandler class to get the upload progress. The total content size was 315197 bytes and the progress jumps from 0% to 98% (315161 bytes copied) all of a sudden. How can I achieve the smoothness of the progress report? Can I control how many bytes will be written each time so that the progress looks smoothly incremental throughout the process?

@hilloldebnath Normally 4096 bytes are written each time except the first and last parts that are smaller. However, this is only if you add File objects. If you use streams you will currently see the progress jump like you describe.

@nadam , thanks for the clarification. I have couple of byte[] contents. So, I have added them as ByteArrayInputStream() to the RequestParams object. What would be your suggestion if I want to achieve a smooth upload progress in this situation?

@hilloldebnath you would need to change SimpleMultipartEntity.writeTo() where out.writeTo(outstream) is called. Another option would be to write the data to files first and then use File objects.

I think this can be considered a bug so feel free to write a separate issue for it and I (or someone else) can have a look at it.

@nadam

At first Thank you for awesome library,Secondly I have a problem,
I uploaded a file to server 'PHP' using this code:

AsyncHttpClient client = new AsyncHttpClient();
AsyncHttpResponseHandler httpResponseHandler = createHTTPResponseHandler();
File file =new File(filePath);
RequestParams params = new RequestParams();
params.put("data", file);
client.post(context, url, params, httpResponseHandler);
This is work fine WITH PROGRESS,

But when I used this code to upload a file to server '.NET'
NOT WORK, I solved it by put a file in HttpEntity like this

HttpEntity entity = new FileEntity(file, "multipart/form-data");
client.post(context, url, entity, "multipart/form-data", httpResponseHandler);

It's worked file WITH NO PROGRESS JUST ONE FLUSH,.

I need to show progress when starting upload.
Thanks

@hmedat2008 I can't see how the server side platform could affect the behavior. Sounds like a bug in .NET or in the code running in .NET. I don't know enough about .NET to help you with that. Sorry.

@hmedat2008 @nadam Highly possible that the server doesn't give a proper "Content-length" value in the headers ? I had the same issue with a varnish in front of an apache that was removing some headers by misconfiguration...

@sizrar if you have issue please open new ticket, this one is back from 2014
Closing for obsoleteness