With many Android apps, there often seems to be little correlation between the size of the package and the value it provides. Multi-megabyte apps that do almost nothing leave me wondering, “what’s in there?”
Unpacking with dex2jar and JD-GUI often provides answers, and frequently it just means the developer forgot to enable Proguard when building. An overabundance of ill-compressed drawables are another common source. But beyond these, the habits of server-side re-use (freely expanding POMs and dropping in FOSS JARs) are a key source of bloat.
I try to be stingy when it comes to Android app libs, often taking a tougher route to avoid bringing in large JARs that might otherwise be useful. Such was the case recently when I needed to do a multi-part post to a REST web service that consumed a mix of binary image data and JSON. Multipart HTTP is conceptually simple, but the markup is obscure enough to make generating it directly from a business app just wrong.
Fortunately, though, Apache HttpMime is just 26K, and makes the process simple. For example:
MultipartEntity entity = new MultipartEntity(); entity.addPart("request", new StringBody(request)); entity.addPart("image", new ByteArrayBody(image, "image/jpeg", filename)); ... mpEntity.writeTo(connection.getOutputStream()); |
To avoid duplicate class errors at Proguard time, exclude the dependent httpcore in your pom.xml, like so:
<dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpmime</artifactId> <version>${httpmime.version}</version> <exclusions> <exclusion> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpcore</artifactId> </exclusion> </exclusions> </dependency> |
I don’t always add JARs to Android apps, but when I do, I prefer light ones.