• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Best packaging strategy for 'image apps'

 
Ranch Hand
Posts: 105
Android Mac Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Cheers,

Johan
 
author
Posts: 13
Android Google Web Toolkit Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
Jason.
 
Johan Pelgrim
Ranch Hand
Posts: 105
Android Mac Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!

Cheers,

Johan
 
Who among you feels worthy enough to be my best friend? Test 1 is to read this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic