Tag Archives: Java

Issues to POST streamed data to a webservice

Recently I had quite some issues with sending data via POST to a webservice from an Android app.

Let me quickly set the stage: I needed to upload data to a webservice via HTTPS. This data were dynamically generated PDF files created in the app. Since the files can become potentially large, I wanted to make sure that data would be streamed byte-wise to the webservice. I already had Volley and were using the HurlStack (which uses HttpUrlConnection).

In order to up-stream data would one needs to explicitly call either setFixedLengthStreamingMode() or setChunkedStreamingMode() on the UrlConnection. Without that the data that will go up would actually be stored in memory first. As I didn't want to take the risk that 3MB (or more) big files could blow my app with an OutOfMemoryException (especially on low-end devices, which are always short on memory!), I needed to take the safe road.

Setting up the workflow in the applications architecture was done quickly. Add some callbacks for preparing the data, counting data length and finally streaming data with an OutputStream. Worked perfectly! The problems kicked in, as I started to actually send data. I tried with fixed-length and chunked streaming mode. For fixed-length streaming mode one needs to the length of the full request body that is about to be sent. Contrary to the chunked streaming, were the connection would buffer up a certain amount of data and send it in (you guessed it!) chunks.

Unfortunatelly, chunked streaming mode wasn't supported by the webservice, so I had no alternatives left but use the fixed-length mode. But this resulted in exceptions complaining that the connection "expected 0 bytes but got 1 byte". Though, I was pretty sure that the content length used wasn't 0. Also going plain HTTP without SSL wouldn't be a real solution, I hoped maybe it's just the SSL connection causing problems. But it wasn't.

After lots of fiddling around with parameters, stepping through code and reading hidden platform classes, I came to the conclusion: something must be wrong with the HTTP(S) stack implementation in Android.

What came first to mind was OkHttp: an HTTP client with up-to-date TLS, SNI and SPDY support. No hesitation: get the library and its dependency Okio and drop everything into the project. To fully integrate OkHttp I needed to tell Volley to not use the platform's implementations. All that's needed is a subclass of HurlStack:

Without changing anything else of my implementations, the fixed-length upload streaming suddenly worked (which I take as a proof that indeed something is wrong with the platform implementations).

FPU Boost

I'm kind of thrilled right now.

I just updated JavaCV to the latest version (2011-07-05) which includes OpenCV 2.3.0 and some precompiled code for Android devices with an FPU (armeabi-v7a). Just by replacing JavaCV I gained an enormously computation boost. Well, of course I knew that an FPU is better for heavy number crunching than a CPU. Nevertheless I'm surprised that this makes such a big difference even in the tiny smartphone (HTC Desire HD).

My current implementation detects Shi-Thomasi corners and then tries to track them in following video frames. Where yesterday (without "FPU-code") my detector needed around 3 to 4 seconds to detect about 50 corners (even though it didn't much matter if I detected 50 or let's say 250) now it needs about 170 milliseconds and very often even less. My tracker needed about 1000 milliseconds to find known corners in new frames -- now 20 milliseconds. The detector is about 18 times faster.

I know, I know ... this is kind of supposed to be like that 😉 . But I'm just surprised to see this working. As result from that I will just target on devices with an FPU. I'm not quite sure yet if a certain Android version requires an FPU, so could just say e.g. from 2.3.0 and up my program will work or if I need to actually check this during runtime.