I am making an app for story books, i have my curlview animation for this app.
My problem is that i dont know what size of image and what resolution should i use for 3.5 inches to 5.0 inches screen.
I always reading on supporting multiple screen size but the problem is that i cannot get that.
All i want is the exact image size in pixel and what is the resolution should i use.
i always use 72 as resolution but i dont know what is the dimension should i use for 3.5 to 5.0 inches screen size.
did anyone knows what should i use? i dont want to read supporting multiple screen size because i already read it and i did not get it.
Thank you to someone who can give me the size i should use that will not get crash in my app.
Thanks again!
As it said in the Android style guide icon size scale for different screens should follow the 2:3:4:6 scaling ratio. Maybe you can use this ratio for other, not only icon, images too.
As you write you read the documentation, I assume you already read the Android Best Practices Chapter about Density Independence. If I got your question right, you're looking for the following part of it:
The system scales dp units as appropriate for the current screen density.
The system scales drawable resources to the appropriate size, based on the current screen density, if necessary
[...]
By default, Android scales your bitmap drawables (.png, .jpg, and .gif files) [...] so that they render at the appropriate physical size on each device.
So you basically need to provide an screen-size independent layout, and Android takes care of the rest. However it is encouraged to deliver multiple images for a better scaling quality.
If you can only afford a single size for the images, I'd decide on a target audience (e.g. how likely are Tablet users, what is the average device's screen size in my audience -> how many pixels will be available in the area you want to display the image) and then calculate the resolution of the images based on that. If a user needs a smaller or larger version, Android will scale the image up or down, given your layout is correct.
From what you write, it seems to me like you're targeting normal screen sizes, so you can have something between 470dp x 320dp and 640dp x 480dp. To get regular pixels, you must think about the screen density of your users, refer to a Question about dp/px conversion for details.
Related
Working on an Application that displays images in various sizes as grids, lists (Instagram like), images that take up the whole screen.
Ex. - you might have is a grid view image (not very big), but also this same image is shown in another screen that's almost the size of the entire screen. It's like a blown up version of this. There are also the smaller thumbnails of these images.
Working with the Backend team to come up with an optimal solution.
Questions:
What's the most optimal way to handle images for different screen sizes? I know instagram sends the URLs for high resolution low resolution and thumbnails.
Do we need multiple sizes for each image? example. grid view (do we need a 1x, 2x or 3x) for each image?. or can one size serve all phone screen sizes and we can just set the scale mode in code? Would this be ok even for smaller screen sizes? Would this be a poor experience for smaller phone sizes since they need images. To me this wouldn't be optimal since smaller phones like SE don't have the same processing power as iPhone 8 plus.
If we're using the same API to serve iPhone and Android - how can this api be leverage for android given that they have more image sizes to handle.
Any guidance would be greatly appreciate it.
PREMISE:
You are talking about images from web server. Not svgs, not interface
graphics. There's no official documents of this field, just
suppositions and results of experience. I'm sharing mine.
If you meant interface graphics, there are official documentations from Apple and Google. If you meant svgs, they're automatically scaled. If you intended to have answer for those, please edit the topic or open new ones
A solution could be, instead of acting only on images sizes, to change the quality of JPGs.
You can use a full quality ~200x~200 image for little thumbnails (avatars, photo icons), which could be ok for all devices sizes, resolutions and models, without being too heavy.
Then, for bigger previews/full image opened you could maintain the same size (the original one, or a maximum size you define) but, using two version of the image: one with little JPG quality (so that it can be loaded quickly, consume less bytes and show the image content) and the other with the original quality (which requires loading and bytes, but it's only shown by demand).
To choose the right value of the little thumbnail (the ~200px), check the bigger thumb size you have. If you have an avatar bubble which is 96x96 on smallest res, multiply it for 3 (96*3=288) and you have the size!
It is true that the smallest res screen will only require a 96x96 image, but, given that those are little numbers, the difference is not relevant (also, because we are talking about photos and not vectorial images, if you scale manually or if you leave the scaling to the device, the result is the same).
I've found some documentation from Google, which explains some things about image formats and how to reduce download sizes: https://developer.android.com/topic/performance/network-xfer.html
They say to use JPEGs, PNGs, or WebPs and show some examples and guidelines for choosing the right format
You can use svg resources(which is a vector-based-image) : By doing so, you don't need to generate a resource for each resolution, and just need 1 resource. In realtime, the svg image will expand to the resolution of the device.
According to the documentation, you have a lot to gain here :
Using vector drawables instead of bitmaps reduces the size of your APK
because the same file can be resized for different screen densities
without loss of image quality
I have used this in Android, and it solves your issue in Android.
I Haven't used this in iOS but, it looks like there's a similar solution as well.
Your all questions are nearly have same goal. So Basically save 6 versions of images like 50px 100px 200px 400px 800px and 1600px etc.
6 will be enough since you can cover nearly all screen sizes like google does in android. which is ldpi mdpi hdpi xhdpi xxhdpi and xxxhdpi
Use an API for picture requests, send your screen sizes to api as parameter then give back resulting images width and height. for ex: for a 800x600 screen send back 400px version of it.
If you not do so, you will have to resize them on client size which is bad for performance and also bad approach for auto layout in IOS.
You can use third party image managing solutions like Cloudinary.
https://cloudinary.com/
Cloudinary generates images of different aspect ratio which can be serve to all types of devices.
I currently have a note 4 which has a high resolution screen (2560x1440) that, when playing in the native resolution, doesn't perform well somtimes.
I have found apps on the play store that will allow resolution changes but all require root (at&t version is currently unrootable).
I can however change the density of the screen without root.
I'm curious if I would receive the same performance boost changing density as I would changing resolution?
Highly unlikely.
The resolution defines number of pixels displayed on the screen. When you change the resolution, the system changes the size of all image buffers used for rendering. It means that there is different numer of pixels to shade and draw.
On the other hand there's the density, which define, how much pixels you can fit on one inch of the physical screen. The density changes an internal matrix used for scaling images. The operation is always same. In apps with native Android UI you may gain a small boost, because by changing the density value you can change the density type of your screen (medium, high, xhigh, etc.). This will change the drawable folder used by the app to the (potentially) smaller one, which will result in faster image loading and messed up UI.
This trick won't work for the games, because in most cases games don't care about the drawable folders.
This is the typical area of supporting multiple screen sizes for android. Basically, in my cards game it was really too much to provide the setof 52 cards duplicated for the 3 folders (ld, md, hd). The reasion is the increased app size by quite a bit.
So I was wondering, if I only provide high density folder then would the device scale down the images to appropriate densities. I mean if all what I was doing before was resizing the images down then the scaling down by the device would be same. right?
If I do that (porviding only high density folder), will the image end up taking the same physical size on low density screen (I am using high density as it is generally to scal down than up).
Thank you
PS: Please don't give me the android website. I want your answer/experience
The answer is, it will scale them down for you, but the resulting images will be lower in quality than those provided at the correct density, depending on how it is downscaled and by what percentage. It may or may not be that noticeable depending on the type of graphics, but fine lines and single-pixel details will be most noticeably different.
I have a game card too and i have put all my high-res cards in res.raw.
It should be the same in drawable-nodpi.
On all the device tested, the cards render very good. The phone just scale the cards up or down depending on the screen size.
i am NOT an android developer and im trying to understand what they need in terms of graphical resources to make an app that functions across many android devices.
i have (tried to) read this page http://developer.android.com/guide/practices/screens_support.html , but find it somewhat bewildering. they talk as if screen density is the important thing "Supply alternative bitmap drawables for different screen densities" but then, if you dont know the size of the screen, you cant really think in terms of layout. is the idea to make buttons and logos that are the same size on all screens with the same density, such that on a large screen there is just a bunch of space, and on the small screen its all packed in tight? i dont understand how just thinking in pixel density gets me any closer to knowing what to provide.
are you supposed to create resources for every screen size AND pixel density? say it aint so.
anyway can somebody tell me... if you were developing an app what do you need for graphics? is it possible to provide graphics that are large and just let them scale down? is it inevitable that the devloper will have to mess with the graphics himself anyway? or can he be provided with sets of png files of certain sizes that will be ready to use?
thanks!
Here's what we do at my work place. Suppose we get a desing for the app. We make our designer create 3 psds versions for the same desing. the 3 psd's are for the 3 ranges of desnity. The size used for the psd are
240*320 (Low Density)
320*480 (Medium Density)
480*800 (High Density)
Most of the time when I write layouts, I use wrap_content which means a view must take the size of the content it wraps. Which works most of the time as I have a density specific version of the design so the image i use as background should be suitable. The thing to note is that, in android you can can put the 3 sizes of the same image in different folders such as drawable/ldpi, drawable/hdpi.
Eg: you have a bg.png and have a version for large phones and a version for small phones. You put the big bg.png into hdpi folder and the small png in the ldpi folder. Android will automatically select the appropriate image based on the phone density. But you need to make sure the file name is the same.
There are cases where you need to resize you background images without makeing the image looking too scaled. For this android uses the draw9patch tool. With this tool you can specify areas which can scale and areas that shouldn't scale.
9 Patch png's are your friend. Read up on them here:
http://developer.android.com/guide/topics/resources/drawable-resource.html#NinePatch
and here:
http://developer.android.com/guide/developing/tools/draw9patch.html
Those are your best bet for any kind of graphic that will stretch nicely (i.e. not gradients, they will come out slightly pixelated on some screens probably) The power of these types of images is that you can tell the system which pixels to repeat if it needs to stretch the graphic. This means that stretching can be done without loss of image quality (again depending on your image and how you choose to make the nine patch. The "show bad patches" button in the draw9patch program will show you potential problems. Hint: keep your repeatable pixels down to 1 on left and 1 on top and you'll have no problems with bad patches) Any graphics that can be made in to 9 patches will only need 1 size since the system can effectively make it whatever size it needs.
are you supposed to create resources for every screen size AND pixel density?
You may if you like. This would ensure that the application will look great across all devices. I understand that this is not feasible for all projects though. In general if you make separate resources for the different densities you'll get something that looks acceptable on most of the devices out there. All of the devices are classified as ldpi, mdpi, or hdpi (there may be an "extra high" level now too, I am not certain off the top of my head) So if you supply graphics for those 3 densities then the system will know where the device falls under and will pull the correct graphics.
is it possible to provide graphics that are large and just let them scale down?
Yes the system will scale down your graphics if needbe. But be aware there are consequences with this approach. First every time the system hast to scale a graphic up or down it is going to taking up CPU and memory to do so. This may not be an issue if you have relatively few things to scale, but if you have many it could cause noticeable lag time during on the lower power phones. Second, To my knowledge all of the graphics in android are raster, which means if you are letting the system scale something up or down image quality is going to decrease some. Again depending on the specific images this may be more or less noticeable on the actually device at runtime.
My best advice is supply them with resources of a few different sizes and run the app on as many different devices as you can. Once you see how your different resources look on the devices of different sizes you'll have a much better feel for which ones you need to supply to get the UI looking as consistent as possible across the largest swath of screen sizes and densities.
I'm writing an application where I will need a number of full screen bitmap backgrounds. Based on my naive reading of Supporting Multiple Screens in the Android documentation, to cover all my bases I should probably have 16 versions of each bitmap: all pairs of [ small, normal, large, xlarge ] and [ ldpi, mdpi, hdpi, xhdpi ]. This should reduce the work the CPU has to do for scaling the images, but will come at great storage cost.
However, this seems wildly inefficient for two reasons:
Not all of these combinations are found in practice.
As I'm just rendering vector art for each physical size (without respect for DPI), pairs like large/mdpi and normal/hdpi (which are both ~ 480x854 pixels) are duplicate files.
So, should I just provide really large images and let the system scale them down? Bite the bullet and provide a lot of duplicate images? Avoid the issue altogether and cobble some code solution with raw resources? Any other ideas? Thanks.
EDIT: Apparently you can create XML bitmap drawables which alias an actual bitmap. That solves the second inefficiency argument. Still, I wonder, what combinations of these do others provide in practice?
You would only provide images at different resolutions if you want that piece of art to be a constant size, regardless of the screen dpi it is displayed on. An icon or a button would be an example of this.
For the background images described here, you don't care what the image dpi is -- you only care what the x * y dimensions are. So you don't have to produce the cross-product of sizes vs. dpi. You only need consider the 4 screen size categories.
And within the 4 screen size categories, you only need store one of the larger sizes (xlarge or large) and let the framework scale that up or down as needed. You can also do the scaling programmatically, to ensure that you don't change the aspect ratio of your background, and you don't crop it.
See also Android game working on all screen sizes which will hopefully attract a better answer.
I would advise providing images for ldpi, mdpi, hdpi and optionally xhdpi (depending on your target users). That will allow you to cover the most commonly used resolutions just fine.
If you end up with the feeling that your application is getting too large (either by deciding to add all possible image sizes or other reasons), you can also look into allowing your application to be moved to an SD card. That way, storage won't be much of an issue anymore. (http://developer.android.com/guide/appendix/install-location.html)