I am developing an android application which displays an image as background. I have read the documentation and it says that Mdpi should be the base line and all other dpi's should be relative to it. But I am not able to decide what should be the resolution of background image in pixels I should for all the dpi's?
Any suggestion?
The best approach depends but, to save space and retain resolution at all densities, include only a single image in your app. When your activities load, use a scaled load based on the the DisplayMetrics of the device. If you aren't worried about resolution, then scaling up from MPDI is fine (but I'm pretty sure you're asking because resolution at the higher densities is a concern, and based on your background image size).
The advice for "starting" with MDPI has to do with the numeric scaling that is needed and being able to conceptualize it. In other words, it is easiest to "think" about how scaling works on Android when you start with MDPI. After that, your use-case is far more important.
There are many examples for scaling images based on your needs. Do not forget to use caching whenever possible, if your application loads several.
Another thing to consider is the extended heap memory, if you encounter OOME because of iamge handling issues.
Related
Regarding Android's call to provide multiple versions of a bitmap/image, why can't only the highest resolution image be used?
E.g if the xxhdpi image is available - will that be able to scale down to all lower density versions or will it just mean it will scale bigger than the allocated size (View)?
PS: If I'm using a background image, does scaling matter? E.g. should I still provide multiple versions of 1 image to fit different pixel densities?
Usually image scaling operation is resourceful and the outcome might be worse than using pre-scaled image.
It has already been answered several times, but I will answer it again. Btw I'm not myself a big pro in Android, but I will try to answer in the best way possible.
Automatic scaling is a thing in Android, but using that is a waste of resource, we already know that using a PNG Graphic asset is a waste of CPU/GPU power when we can use XML for basic designs (which uses less resources), so why waste more power for downscaling it (which increases app opening time and makes it laggy), simply creating multiple sized images for different display sizes is the best option.
A simple and convenient option is to use a free software like Adobe XD which supports export into different sizes.
Simple answer: Avoid using PNG(or other image format), but when you don't have other options do create multiple sizes to save resources.
When I started learning Android, the course that I took mentioned about screen densities in a very early stage.
And it encouraged me to generate image resources for HDPI, XDPI, XXDPI and XXXDPI.
Whenever I get an image from designer, it is a XXDPI image and I will generate other versions using a plugin of Android Studio.
Later I started to doubt if this is really necessary.
As far as I can observe, the only benefit of having different resources for different screen density, is that I can use wrap_content for ImageView and the image will keep the same size in different screen densities.
But this can be completely replaced by using a dp value for the ImageView.
On the other hand, I observed quite a number of drawbacks:
Since multiple images are included, APK size increase (not 100% sure, may someone confirm?)
This approach can sometimes increase memory usage, if you unnecessarily used a very high resolution image (e.g. a fullscreen background image). See this post for example.
Extra effort of generating different images
It is a nightmare if you need to have different drawable resources for another product flavor
So I start to think that why not just put a high resolution image in nodpi folder and let Android scales down for you? I never observed any observable drop in image quality. Will this cause any memory issue in a device with lower screen density?
I am in the process of creating an android app. However, supporting multiple screens seems to be an issue in app development. The ways I have seen that Android says to support multiple screens, is to provide duplicates of icons/logos of different sizes. However, I find this to be an inadequate solution and am convinced that there has to be a better way.
I am storing my icons/logos in a folder on my server. These images will be 1024 by 1024 images. I want to be able to retrieve the logo/icon from the server and scale the images at run time to the screen being supported. I know there has to be a way to do this.
Solutions?
I allways scale my bitmaps depending on the Width and Height of the SurfaceView I am drawing to. The Bitmap class has some methods to provide such functionality.
Either you load your images into Bitmaps and scale them afterwards or you can use Bitmap.Options and load directly from the assets in your desired sizes!
Check the Bitmap, BitmapFactory , SurfaceView and Canvas API's
Here's an example out of one of my apps:
playTable.dotSymbol=Bitmap.createScaledBitmap(origDotBitmap,playTable.symbolSize,playTable.symbolSize,true);
it's just an icon that i scale from a given bitmap i have loaded before:
origDotBitmap=BitmapFactory.decodeResource(res,R.drawable.dotobject);
Also:beware of OutOfMemory Exception...on my note 4 i can Load 28 or so bitmaps of the size of 1024x1024 before OOM
Following the described paradigm of providing multiple images in buckets (ldpi, mdpi, hdpi, tvdpi, xhdpi, xxhdpi, xxxhdpi and etc.) is perhaps the safest and simplest bet.
However, providing drawables only for some buckets, let's say only for xxhdpi, will do the trick and rescale images for other non-xxhdpi devices. But note, there is no guarantee that images will appear in exactly the same way as they are supposed.
Considering the solution on pulling images from the network and rescaling them (assuming based on computed width of the screen), please consider the following potential issues:
1. will the quality of the provided image guarantee proper scaling on extra large devices?
2. pulling images from network is an expensive call which shouldn't be run on a main thread, so you'd have to pull them asynchronously
3. To my knowledge, the exact width of the screen will be known only once the layouts are placed on the screen, therefore, you'd have to observe OnGlobalLayoutListener. This, in conjunction with the asynchronous request to pull the image from the network, potentially creates a race condition you'd have to take care of.
Issue 2 an 3 can be somewhat simplified by using Volley's ImageLoader and NetworkImageView (https://developer.android.com/training/volley/request.html) or any other similar library.
I have designed an in-app keypad for my Android application and I need to provide an image for every key. Currently I've only loaded one large image for each one that is being scaled down to adjust to the layout. Also, this looks nice in every resolution.
Is this approach acceptable or should I provide different images for different screen densities? Currently I've placed those inside the generic drawable directory.
You should. Some mobiles with lower resolution, usually won't have much memory. Loading large images in small screen takes too much memory, which might end up crashing. So if you give different images, then according to density it will take appropriate images. check this out.
It's acceptable in some cases but certainly not optimal.
For best memory performance and the least amount of artifacts I would still recommend to provide alternative bitmap resources for different densities, like the Android documentation recommends.
I'm quite new to Android development. My understanding is that you can create several versions of the same image with different sizes and put them into the folders drawable-ldpi, drawable-mdpi, drawable-hdpi.
It seems obvious to me that you can handle this problem "the lazy way" by just resizing one image depending on the device's pixel density. For this I programmatically find out what density the device has, like ldpi. The implementation itself is not the problem. I'm just afraid of any drawbacks (that prevent me later from running the app on different devices).
So, are there any (major) drawbacks of scaling images automatically ?
In which of the three folders do I put the image so that the compiler can find it?
You would put the image in your regular drawable folder. That way any phone can find it.
While you can programatically shrink images, shrinking usually has the effect of reducing image detail and causing jaggies.
Adding in smaller assets will also reduce memory usage on smaller phones. Keep in mind that some Android phones are notoriously bad with memory (see: HTC Status), so any and all savings help.
I would recommend just photoshop scaling images down large images yourself. For smaller images, it is not as big a deal.
Android does auto-scale and it works fine in some cases, but it doesn't work for many, notably small images with important details like text. Scaling a larger image down blurs those details. Scaling a smaller image up is worse. This is why icons files have been multi-resolution since the very early days of GUIs. To wit, text scaling is hugely complicated. Ask any font designer, and note Adobe built a company on algorithms to do it automatically.
it's on mdpi folder. It'll change the size automatically. But is not recommended since the image quality drops.