I have developed an android app and its working fine in my mobile of resolution 240*320.But if I install in another mobile some like 240*400,480*800, etc all the view components are changing according to the screen resolution.
I also created a sub folders under the res like layout-small,layout-large,layout-xlarge this procedure is also working according to the screen resolution the xml files are been read by particular folder.But this is not working on a 240*400,240*432,etc.., these type of screen resolutions are not supporting by the above procedure
What should i do for achieving all the view components to be look same for all screen sizes.
Thank you
This stuff is hard. You may have read the documentation, but you haven't understood it.
Basically, you have to distinguish two important things.
Layouts (XML) are determined by the dp size of the device. Forget about 'resolution' and just think about device independent pixels (dp). The dp size of a device is roughly equal to its size in inches, if it had 160 dots per inch. So a 10" tablet is about 8"x160=1280 dp long, while a 4" phone is about 3"x160=480 dp long. Approximately.
Drawables (PNG and JPG) are determined by the pixel resolution of the device. To produce the identical icon on a device that is 320 dpi and for one that is 160 dpi you need twice as many pixels. A 64x64 icon on the first is only 32x32 on the second.
So you need to produce a range of XML files (layout or dimen) that scale according to the desired dp size and put them in folders with names like sw600dp (shortest width 600 dp) and sw320dp. (Search SO or the web for sw600dp and you'll find lots to read).
And you need to produce a range of PNG or JPG files that scale according to the pixel resolution and put them in folders with names like mdpi and hdpi (search for that too).
Simple enough, but hard to do well in practice. We can only hope that eventually Android will fix this mess but for now this is what we have.
First off, stop using the term resolution. That term is ambiguous.
In Android, one could easily have a phone with a small screen with very high pixel density and a large tablet screen with very low pixel density, and the so-called resulting resolution on both devices could still end up being equal.
i have read that many times and implemented according to that but read
my question properly. – user3851899 3 hours ago
I'm sorry, but believe us, we've parsed your question very thoroughly.
http://developer.android.com/guide/practices/screens_support.html
You've mentioned the term "resolution" five times and yet in the document you've read many times, below is the only part where resolution is even mentioned, and even then, it's to tell us that you should "not directly work with resolution".
Resolution
The total number of physical pixels on a screen. When adding support for multiple screens, applications do not work
directly with resolution; applications should be concerned only with
screen size and density, as specified by the generalized size and
density groups.
Furthermore, can you count the term density is mentioned in that document. It's mentioned 171 times! The fact is, you've missed the main key take away concept from that document.
The term resolution is not very useful for Android development. The concept of size is important for a large background image taking the entire width or the entire height of the screen and it's important for layout issues that take into account the entire height of the screen or the entire width of the screen, but it's not very important otherwise. And what's really important for developing on multiple screens (aside from the scaling font size) is really the density of the screen.
So I implore you, please read that document again. Hopefully, you'll begin to understand it, now that I've reset some of your assumptions.
Related
I've created my app but I decided to test it on all screens to be adaptive. Maybe testing it in
MDPI(160dpi), HDPI(240dpi), XHDPI(320dpi), XXHDPI(480dpi) and XXXHDPI(640dpi) which corresponds to all screen sizes. However I tested my app on two devices support 320dpi. I thought that I get the same result but it don't. so don't know how to test my app on all screens. I'm confused.
I used Genymotion for emulators:
one with 720 * 1280 320dpi
screenshot
and other with 1200 * 1920 320dpiscreenshot
Please help me with that or if there's another way to do it let me know.
thanks in advance
(Bunch of explanation about why this is happening, I put my suggestions in the last section)
DPI isn't the same as size, it's just about how many pixels are packed into a certain area. The higher the DPI, the more pixels there are, meaning they're a lot smaller. So you can get fine detail, but it also means you need more of them to cover a physical distance or area on the screen.
Which is why Android uses dp instead of raw pixel sizes most of the time - the standard minimum touch-target size is 48dp, but how many actual pixels that is depends on the pixel density of the display. For mdpi displays it'll actually be 48 pixels, for xxxhdpi it'll be 4x that amount
It also means if you're doing your design work in dp, the pixel density of the screen doesn't matter - elements with a fixed size will always be broadly the same size on every screen (the mdpi etc buckets are like a "close enough" grouping, the devices in each group won't all have exactly the same DPI) because it's getting translated to the equivalent number of actual pixels. What testing does help with is checking your drawable assets look ok on different screen densities
So you have two devices with the same DPI right?
720 x 1280
1200 x 1920
Because they're the same DPI, those dimensions are converted to dp by the same factor. Let's work it out to be precise (but the exact numbers aren't important): 320 DPI is xhdpi according to that link up there, so 1dp = 2px. Let's convert those screen sizes to dp
360dp x 640dp
600dp x 960dp
It's the same situation but hopefully having those sizes expressed in dp helps you see the problem - when you're designing a layout, you're working with dp, right? The available space you have to work with is defined in dp, and one of those has a whole lot more space than the other! Putting a 300 dp-wide TextView in the layout would almost fill the first one horizontally, but it would only cover half of the second. That's gonna look pretty different!
This is why phones and tablets look so different - even if you have a relatively new phone, and an old Nexus 7 with a much lower resolution, the Nexus 7's screen is going to feel "bigger" and more "spacious". It's a physically larger device, so even though it's low-res, it's also low-density which means those pixels are spread across a larger area. Lower DPI means those pixels translate into more inches. And in the density-independent pixel (dp) system, that means you get way more dp to work with, more space for your layout. Which is what you want on a tablet, you don't want it to look and feel like a massive phone!
That's why it's different - basically one of your devices has more space to work with than the other, because it has more pixels, and the same DPI so those pixels aren't just used for finer detail.
As for testing, you need to look at different screen sizes - which is dependent on the resolution and the DPI. Basically pixels / DPI = size in inches. Do that for your two 320 DPI examples and you'll see one is a fair bit larger, physically, while having the same density
Probably the easiest way to do this, really, is to look at your layout in the design view, and change the Preview Device setting at the top. Some of the Phone devices are more "spacious" than others, newer ones are taller, so go through them and see how your layout changes. Try a Tablet one and see what a lot of extra space does. And if you go down to the Generic Phones and Tablets section at the bottom, there are a bunch of reference devices in there, some of which will be very cramped!
Once you've found a few useful ones, you can set up your emulator / virtual devices with each of their screen resolution / density combinations. I don't know about Genymotion, but the built-in AVD manager gives you a lot of those device definitions as templates when you create a new virtual device. You should at least be able to enter those settings yourself
Also when you publish an app on the Play Store, they'll automatically run it on a bunch of reference devices and give you access to a bunch of screenshots, so you can see if there are any problems with certain screen sizes and fix them before you launch
I'm developing a watch face for wear os. I was trying to figure out why the layout is messed up on different screen sizes and resolutions - I was using "dp" for all dimensions so I thought it will be "density independent", yes?
I made few emulators with different dpi and sizes and could not figure out why bigger change id dpi makes my layout look good again, but smaller changes introduce offset. I found out that:
One note about dp/sp that isn't totally obvious: The scaling that occurs for these depends not on the devices real density (dpi) but on which "bucket" of densities it falls into: available buckets are: 120,160,240,320. (...)
Note that pt should give you equivalent results as dp
So are there any truly display independent(proportional to screen) units I can use to position my elements?
I have read on this forum that the answer is to split the image in different resolutions and put it in different folders and the other way is to put the image in one folder without splitting it up so that android doesn't resize it.
My question is in which folder exactly do we put it on so it doesn't resize itself and shows as it is?
My res folder looks like this
Based on your updated question with the image and the clarity.
You are asking how to avoid scaling. You can either use the drawable directory or the drawable-nodpi to avoid prescaling. Either one will work for you.
I made a document on this once for the UI team I was working with, so this document is a little specific to their request and that app, but it might help you.
https://drive.google.com/file/d/1gJjT-F5AU57TCAr5I18l0jAvNG5-vLUb/view?usp=sharing
For vector drawables just use "drawable" standard directory. Make sure you are not violating any of the unsupported tags such as gradients and linear tags or you will have issues.
Next the -24 -26, etc.. folders are used for version specific. For example, let's say you have one type of image for pre 24 Android, but a different type for post 24, you can use -24 for the post image, and all others will check standard folder for it. This sometimes happens when you use something bleeding edge that isn't supported back far enough for your app's minimum SDK. You are not likely to use this for images, I can't even think of a problem where this would arise in the image buckets, but it's there all the same.
For deciding what resolution you need for each bucket, there are a couple of options here. First you could simply do the math. Decide how many inches you want it to take up and determine how many pixels are needed to accomodate that size and label that MDPI, than scale from there using the multipliers. Another less mathematical solution would be to open a preview on Android select an MDPI device and start playing with width = 100px height = 100px and adjust until you like the size. Write that down, it is MDPI, and begin your scaling from there.
As for a rough estimate of pixels to size, you can see what an app icon looks like and see what Android uses for that below.
So even though each bucket has a different pixel by pixel resolution, they will be identical sized and pixels per inch resolution on all devices due to bucket placement.
Hopefully that all makes sense.
--I'll leave the below from the original answer in case it helps someone--
You may have gotten some bad information.
https://developer.android.com/training/multiscreen/screendensities
Android is a widely dispersed resolution and size market.
In order to accommodate this they allow for DP and Buckets.
There are buckets for languages, screensizes, orientation, and resolutions.
You are looking for resolution support.
drawable-ldpi -.75 multiplier on size (1dp = .75px)
drawable-mdpi -baseline 1dp = 1px
drawable-hdpi -1.5x multiplier on size (1dp = 1.5px
drawable-xhdpi -2x multiplier on size (1dp = 2px
drawable-xxhdpi -3x multiplier on size (1dp = 3px
drawable-xxxhdpi -4x mulipvlier on size (1dp = 4px
each bucket has a multiplier associated to help the image look the same approximate size on each device. So even though it is 1 inch by 1 inch on one mdpi phone with your 100px x 100px image (pseudo size, don't calculate it ;)
it will need to be 150px x 150px on the hdpi to have the same quality and resolution of pixels per inch.
Now if you put all your images in the drawable bucket. Android will just ignore the scaling of these and you end up with varying space consumption depending on the device which will be very inconsistent on how much space it takes up on each type of phone.
If you put all your images in the correct folder you will at least have better quality. For example, let's say you have maybe 750px x 750px image that is meant to fill up a 1 inch area. You would be better suited to put it in the XXHDPI folder or XXXHDPI folder so Android knows to scale it DOWN rather than UP. This will give you better resolution for each device resolution that it scales for.
However, this is still poor practice. You are relying on Android operating system which can be very slow and weak on many cheap devices to do your scaling for you. I would recommend using GIMP and scaling to each multiplier on your own, then putting it into the respective resolution buckets.
This way Android decides based on the device which bucket resolution image it needs which decreases the amount of scaling exponentially.
Now, if you have Vector Graphics that you have imported, those will end up in the drawable folder which tells Android to ignore the resolution, and just draw these as vector graphics. This is the best option in my opinion as you only need one set of images per image. Although, Vector graphics aren't quite as fast at loading as a JPG or PNG, but it keeps your package size down quite a bit and development maintenance is so much nicer.
Hope that helps.
Happy Coding.
I would like to create a adaptive UI for both mobile and tablet devices. I would like to know for example for mobile devices if I give android:textsize="2dp then how much I should give for tablet devices. I know I should give them in values-w820dp and appropriate folder but how to calculate the difference of this dp. I couldn't find any resource for this. Help me out.
(1) For most text, it's best to size it in sp units so it scales automatically relative to the user's text-size preference. Folks with lesser vision can pick larger text and then be able to read your app without eyestrain.
(2) If you need some text to appear in a fixed size, e.g. a big headline, then use dp units so it scales automatically relative to the screen's pixel density. (Pixel density is independent of the overall screen size. It's a high vs. low density thing, not a phone vs. tablet thing.)
But don't use size 2dp! That'd be unreadably tiny -- the height of 2 physical pixels of a 160 dpi screen.
(3) If you need some text that uses approximately a fixed proportion of the screen size, then it makes sense to either define screen-size-dependent parameters, e.g. in values-w820dp, or to size it in code.
(4) If you need some text in a fixed number of pixels tall even when the pixels are really tiny, e.g. to draw into a raster image, then use px units.
See Supporting Multiple Screens - best practices.
There are no strict rules here. You can have android:textsize="2dp on your tablet as well if you wish so. You can have a look at the following android developer page which tells how to support tablets and contains chapter called: 5. Adjust Font Sizes and Touch Targets
and i would like to have a nice high resolution background for it.
If i mind galaxy S4 and galaxy Note3, they have 1080 x 1920 px screens.
That means my 1080 x 1920 px background will be 3 MB.
What!?? Yes. My whole app should be 3 MB not only one drawable piece.
So my question is, how developers solve this? I would like to have a nice textured well designed background, if it would be flat design, there wouldnt be problems like this.
And okay.. lets say Galaxy S4 and Note3 have really big amount of memory and fast processor and i use that 3MB background, but... what happens when somebody would like to use my app with a low budget device? Maybe its cannot even show that big image.
Any ideas about this?
If you are worried about other devices you should simply define different resources along with the correct size qualifiers, like stated in the Android guidelines.
smallestWidth sw<N>dp
Examples: sw600dp sw720dp
The fundamental size of a screen, as
indicated by the shortest dimension of the available screen area.
Specifically, the device's smallestWidth is the shortest of the
screen's available height and width (you may also think of it as the
"smallest possible width" for the screen). You can use this qualifier
to ensure that, regardless of the screen's current orientation, your
application's has at least <N> dps of width available for it UI.
...
Basically you can define a drawable-sw<N>dp for each family of screens you want to support, putting in there targeted pictures as you need.
I think you need to change the resolution of your image. I created a 1024 x 768 PNG background image and its size was only around 300kb.
Check your image resolution. I recommend 72 pixels/inch. I'm not sure if there's any other softwares, but you can check and change your resolution on Adobe Photoshop if you go to Image -> Image Size. You might need to uncheck 'Resample Image' I think.