I am about to launch my first Android App (yey…) but I am now having troubles rethinking about one of the major Android headaches: designing for multiple screen sizes.
I have read a lot about the subject, I have my multiple drawable folders, however I have some doubts.
This is my ListView Row Layout (the imageViews have fixed size)… I have been playing around with image sizes and I cannot grasp one thing: why to use multiple drawable folders, instead of using one image with great resolution (i.e. a nice displaying xxhdpi image) and let Android scale it down by itself?
Also how do I decide which size to use for the icon when creating it in Photoshop? I am thinking of using a technique I saw somewhere: creating a canvas in Photoshop with HDPI common resolution, placing the icon and get the aproximate dimensions (and resize for each density), but at the moment I have a large image (256×256) which I download using Universal Image Loader and everything works fine (I just change the ImageView dimensions in the tablet layout) – is there any downside to this approach? The only one I can think of is the increased download time.
Finally, as I am using Universal Image Loader to download my images, should I host 4 images(corresponding to each screen density)? Once again, I only host one 256×256 image and it works flawlessly. Once more am I sacrificing loading times to increase quality and decrease implementation effort?
I would be much appreciated for any thoughts on the subject, as I am a bit lost.
EDIT: I recently tested my application in an MDPI Tablet and the Team Icons are of poor quality (they are 36×36 in mdpi – given that an mdpi launcher icon is 48×48, per the Google Guidelines, and that my images occupy a smaller space, it should be sufficient to get a nice displaying image, but no…) If I use the xxhdpi or xhdpi images the image is much much nicer. So how do I know the correct resolution for my bitmaps??
EDIT2: The same problem applies to my background image: In my LG Tab 7 (MDPI) the resolution for the image should be around 800×1280, but for a an mdpi phone it might be 320×480…so the same drawable folder could be two completely different resolutions, how is that? Do I have to place a combination of drawable-“size”-“density” for each background?
3
Answers
(this is a partial answer to your original question. I don’t really know about Edit1 and Edit2 so can’t comment on them)
There are two things to consider here:
In general, in Android, the reason most people worry about the asset sizes is their memory usage and not the size/space taken by the image nor the download times.
Given the very small amount of RAM allocated to your process (unless using large heap), it’s highly recommended, by the guidelines, that you do not load more than you actually need. This means, for devices with lower resolutions, do not load high quality images since they can’t take advantage of them anyway. You can obviously always scale the images down on the fly but this solution is not cheap (in terms of processing power) so if you can avoid it, you probably should if the performance of your app is important (it’s not that huge though so I wouldn’t worry about it unless you were doing this to hundreds/thousands of images). How you generally go about doing this for static assets (such as icons) is by putting your assets in their appropriate asset folders (drawable-dens).
Your situation is however different. You’re downloading the images on the fly and providing 4 different asset sizes for such a case can be quite cumbersome and managing it could be quite painful, so, as long as you’re ok with what I’ve already written (in terms of performance and memory usage and you don’t have a bottleneck here), you should be ok with your approach, i.e. download a single “high-res” image and then scale it down according to your needs. If however you find that this solution is not working for you, you can take the more “extreme” approach of providing different DPIs for your images on your webserver and downloading them according to the hardware specs of the device they’re running on.
Let’s start saying there is not a standard procedure and size for your bitmaps, i don’t understand if you fetch them from the server or you store them into your res folders, but in the second case the advantage of have multiple images for different screen densities is to avoid the system to scale them every time but in the other hand your apk size will be bigger, also notice i said screen density and not size because
res
folders include differnt images for different screen densities.Rather if you download each image from the web i suggest you to use some caching system and in this case i think there is no a specified size to use, it obviously depends on your app and which kind of images you want to show.
I would say your images should have a resolution enough big to be displayed nice across differnt screen sizes and densities and small enough to don’t overload your server.
Also could be a good practice download images which have been resized yet instead of download them and scale into the app.
In your last edit you asked “how is that? Do I have to place a combination of drawable-“size”-“density” for each background?”, density indicates the number of dots (or pixels) contained in one inch of screen.
Now think at
res
folders as buckets where for examplexhdpi
can contain different screens which are consider to be at an xhdpi density (320 dpi) but they don’t have the same resolution sincexhdpi
is just a range containing screen which have a density close to 320dpi.Screen size instead is the real size of the screen.
Obviously the best thing to do is start developing your app with a clear concept on how android works, but i think in the end you should also try your app on different screen sizes and densities.
The answers here cover some common image concerns, but I think they’re still missing some pieces to the appropriate answer. First, someone mentioned the difference between “pixels” and density. In your 2nd EDIT, you talk about the number of pixels on the screens, not the densities. You may need a larger image on a large screen, but that is not the same as a higher resolution image. If you want the backgrounds to display the same content, then it will probably be a higher resolution, but a small image that is “scaled up” adds pixels without adding resolution. That is the key difference.
On your first EDIT it is unclear what your problem really is. The same image at different densities scaled to the same number of “pixels” displaying with different clarity can be the result of a couple of things. First, the OS may have an operational screen density of MDPI, but physically have more pixels allowing the higher resolution image to appear more clearly. Also, your sampling algorithm for creating the lower resolution image may not be appropriate (or may not be optimal for the device). And the device may have a more optimal sampling strategy than you can use because the manufacturer tuned it. All of those factors can lead to what you described – and support using higher resolution images in some cases.
That said, here are the core concepts for determining the approach:
I will agree that download times might be a concern when downloading images. I will also add that for mobile data plans, you should be concerned about usage on the plan. Many developers forget that not everyone is connected to WiFi or has unlimited budget or unlimited data plans.
For dynamic downloads, you should have the app detect the screen density/size and then go to an end point (web folder) where it gets the appropriate image. You should create images in each size, but remember that each device only needs 1 image to do its job. So just download the appropriate image, just as Android would only use 1 image from the appropriate
res
folder.Performance can actually be a concern, depending on your app features.
res
images of the proper size/resolution and properly sized images that do not have to scaled improves your app performance. This is definitely not a concern for only a couple images. But if you are using the images in aListView
or another place when it will be displayed repeatedly, you should not just use a high resolution image and scale it down each time.If you have users on lower density device (MDPI or LDPI) those devices also usually have less memory overall and much lower performance. Your “awesome” test device might be fine, but their experience could be horrible. Be sure to test for “real world use” if you decide to not follow guidelines.
Last but not least, if you have a large library of images, it may not be cost effective to create several copies of those libraries. Using a higher resolution image infrequently does not really impact performance, usability or in other ways deteriorate the user experience. In other words, most of the time, you don’t have to worry about this. But, to be good at your job, you should know when to worry!