File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Android and the fly likes Best packaging strategy for 'image apps' Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Mobile » Android
Bookmark "Best packaging strategy for Watch "Best packaging strategy for New topic

Best packaging strategy for 'image apps'

Johan Pelgrim
Ranch Hand

Joined: Jul 07, 2003
Posts: 105

Hi Jason,

I'm working on an app which displays various images. I want to optimize this for the various screen resolutions. The MultiResolution tutorial uses many resource qualifiers in the res folder to display the appropriate images for the various device resolutions, but how do you package this? I don't want to ship the images for all devices (or do I?). I want to keep the download size as small as possible, so I only want to package the ones for that particular screen resolution. Or, should I forget packaging images and put the images on-line somewhere?

Any opinions on this subject would be appreciated.



Johan Pelgrim, The Netherlands
SCJP 1.4, SCWCD 1.4, SCBCD 5.0
Jason Brent Morris

Joined: Mar 29, 2011
Posts: 10

Hi there Johan,

This is a really interesting question, and it's gonna have a bit of a long answer

First off: congrats for even taking multiple screen resolutions into account, theres nothing more frustrating than having the bottom half of a menu chopped off because your phones screen is tiny!

The resource selection is an awesomely powerful tool in Android, but also relies on the fact that all of the resource data is packaged with the application so that they can be selected at runtime. Files in the "res" directory receive special treatment from the packaging tool, so your images will automatically be compressed down (if they can be), see the Android docs here for more info. Any references from XML resources (@drawable/myimage) such as layouts or styles will also be resolved (or at least tested) during this process, so if a referenced image doesn't exist the packaging tool will fail with an error.

As you suggested: one solution is to put all the images in bundles online and download them when the application first starts. This is a great idea, but unfortunately has several drawbacks. Firstly you won't be able to reference your images from layout or style resources. Second, you'll need to figure out which images to use by yourself. This second issue isn't a problem as long as you don't have images dependent on configuration that can change (day / night, device orientation, etc.). Finally: you're then expecting your users to wait through a second "installation" while the images download, unless this happens very quickly it will lead to many frustrated users (especially if the download breaks due to bad cell-tower coverage or similar issues).

You could also use the Android API to automatically scale or adjust some of the images the first time the application is started, and store the resulting image on the device. However: you'll still loose the ability to reference the images as resources, since you can't write the images back into your "res" directory. A trick with this option would be to use string resources to determine how the images should be scaled.

Summary answer: I would say package all of the required images in the "res" directory. Not using the resource API in Android will make your development much more difficult. If you allow users to install the application onto their SD cards, it will help solve part of the problem (I find on-device memory to be a more limiting factor than download size, and I live in Africa ).

If the download does become what you consider to be over-sized, then consider re-scaling the images or downloading those that are more size-sensitive during the first run.

Hope this helps a bit!

Author of: Android User Interface Development
Available Here:
Johan Pelgrim
Ranch Hand

Joined: Jul 07, 2003
Posts: 105

Thanks Jason!

I was indeed thinking about rescaling the images the first time the app loads, but like you said, this avoids the great resource mechanism in Android.

I'll simply have to look into it further, experiment a bit and see what is usefull & acceptable as far as end-users, but also 'maintainability' goes. Thanks for thinking along!


I agree. Here's the link:
subject: Best packaging strategy for 'image apps'
It's not a secret anymore!