views:

252

answers:

2

An Android app I'm writing involves quite a lot of downloading of content (think podcatcher/RSS).

I would like to be able to give the user an indication of how many bytes they've downloaded, so they can make the decision whether they want to use Wifi or not.

To this end, I have found a way of counting the number of bytes read by the app, by wrapping an InputStream in a simple CountingInputStream.

However, this does not take into consideration basic things like packet headers and HTTP headers. More importantly, it does not take into consideration any compression that content may be encoded with.

So, how many bytes did my application download over the network? I'm not so interested in the number of bytes uploaded, but if know how, don't be shy.

I have gone down a fairly low level approach as I am feeding the input stream into an XML PullParser. I will also be needing to do a similar exercise with dumping bytes (images in this case) straight onto the SD Card.

Is this the best approach? What am I missing?

+1  A: 

ufff... I think this is pretty transparent to underlying protocol, so you can't count all these bytes used in session or link layer, and operators like to charge even for control bytes which are not in any way visible to end user. Also they count traffic in both directions (your reqest to server takes also some), so - good question is: how to measure needed traffic/money for downloading that picture... ?

ante.sabo
Good points re: control bytes, and money.
jamesh
+1  A: 

This isn't a direct answer, but you could try asking someone who has solved a similar problem before, e.g. a data counter application. I've used NetCounter by Cyril Jaquier (http://www.jaqpot.net/netcounter/), and he claims his software is open source. I couldn't get his download link to work, but there's a contact email address. If you got his source code, you should be able to use the same method as him.

Steve H
This uses /sys/class/net/${interface}/statistics/rx_bytes which is: system wide (I need application specific); and platform specific - there are porting issues which the app you cite have had to work around. All in all, a good suggestion, but probably a layer too low for my purposes. Thanks.
jamesh