I am working on a Xamarin.Forms app and I need to identify the android screen/resolution is whether small, medium or large to adjust some content with the available space. For example, some labels (single line) are getting truncated in smaller devices. So I could make some adjustments if the resolution is smaller or not.
In iOS, when iPhone screen getting bigger, the resolution is also getting increased so it's easy to identify smaller resolution devices in iOS. But in android, this seems hard.
Android device resolution can be taken from
var resolutionH = Resources.DisplayMetrics.HeightPixels;
var resolutionW = Resources.DisplayMetrics.WidthPixels;
For testing, I have created the following emulators and run the app in them. Here's my result whether a label getting truncated or not.
Resolution Density Result
---------------------------
2560x1440 560 OK
1920x1080 400 OK
1280x720 320 Truncated
1280x720 280 OK
1280x720 240 OK
800x480 240 Truncated
800x480 160 OK
The problem here is a device with higher resolution and lower DPI won't cause any problem. Like a device with 1280x720 resolution and 240 DPI (or 280 DPI). Since there are tons of Android devices are available with different resolutions and densities this problem seems harder.
Is there a better way to categorized android devices (small, medium, and large)?
The reason where a label's text getting truncated (in my case) or an element doesn't get enough space in a particular device is, the actual pixel calculation for an element using the density (dpi/ppi) and the density bucket that screen falls into. This article gives a good idea about calculating the physical size of an element for different display densities.
After some exhausting research, I was able to categorize the device screen by taking the combination of screen width pixels and density. (I got the data from Android developer website Distribution dashboard and Support different screen sizes)
I have categorized the screen width pixels into 4 categories and then calculated the screen size for each display density using following formula:
sqrt((widthPixels x widthPixels) + (heightPixels x heightPixels)) / density
Then I have searched in the GSMArena to find devices with the screen configurations in the above table. Screen size lower than 3 inches is mostly smartwatches and more than 8 inches could be Tabs and smart TVs. So I have taken devices with the screen size between 3 - 8 inches as mobile devices (smartphones).
What you are looking for is easy to do in native android you can create a method and check for the DensityMetricsDensity something like below:
private string GetDeviceDensity()
{
var density = Resources.DisplayMetrics.DensityDpi;
switch (density)
{
case DisplayMetricsDensity.Medium:
return "MDPI";
case DisplayMetricsDensity.High:
return "HDPI";
case DisplayMetricsDensity.Low:
return "LDPI";
case DisplayMetricsDensity.Xhigh:
return "XHDPI";
case DisplayMetricsDensity.Tv:
return "TV";
case DisplayMetricsDensity.Xxhigh:
return "XXHDPI";
case DisplayMetricsDensity.Xxxhigh:
return "XXXHDPI";
default:
return "Unknown";
}
}
Related
My company has a Android app. Our clients view the app with a Lenovo Tab M8. I am a designer tasked with recreating the current app experience in Figma so that our design team can have a design system and make accurate mockups. But I'm struggling to capture basic measurements (my experience is in Web and not Native apps).
The first question is, what is the width and length of the screen in pixels? I'm trying to create a basic screen template in Figma. I know the Lenovo display is 1280x800px with 16:10 screen ratio. But when I create a 1280x800 frame in Figma it's significantly larger than the physical device. I'm a little lost.
The other question is, I'm trying to recreate font sizes but I know the app uses dp and not px. I found a site that convert them, but I don't know if the tablet is LDPI, MDPI, or whatever.
https://www.pixplicity.com/dp-px-converter
Thanks for any insights you have.
You shouldn't need to know what density the tablet is, the point of using dp (density-independent pixels) is that everything will look pretty much the same size in the real world. The baseline density is LDPI, which is 160 pixels per inch - so 160dp is one inch on the screen.
XHDPI is 320 pixels per inch, so double the density - but converting 160dp to pixels on XHDPI devices involves multiplying it by 2, so the result is 320 pixels - which again corresponds to 1 inch on a 320dpi screen. See how it works?
So the pixel resolution isn't important, a tablet will be large in dp terms because they're physically bigger than a phone, more inches and all that. But if you're curious, if your M8 is the 2nd-gen one, according to the tech specs it's 4.8" on the 800 px axis (the one with the smallest bezels), and that works out to 166.7 DPI without taking those bezels into account - so it's an LDPI device!
I don't know anything about Figma, but so long as you're using dp measurements it should work ok? You have to be aware of the size of your screen though - when you said you created a frame 800 high and it was too big, if that was 800dp then 800 / 160 is 5" and your screen is only 4.8" high. Ideally your layout shouldn't require a specific physical size though, it should be able to adjust since different devices (even very similar ones) are different sizes - but I don't know how Figma works with that! That's just the way it works for the standard Android stuff
Also ideally fonts should use sp which is like dp but it has an additional scaling step depending on the user's font size settings on the device - it lets them shrink or enlarge text to their preference and for accessibility (the latter is especially important). Sometimes you want a fixed size for something that's more of a graphic element, but generally text should be scalable
If you want to know how to convert, have a look at the Material Type System - there's a chart there for converting between different units (also 1sp = 1dp for the Normal text size FYI). There's also a tool on there to create a type scale but only for stuff on Google Fonts - just saves you doing it yourself!
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 trying to use DPI and touch input in my unity game to recognise gestures consistently across android devices of different sizes.
For instance, I want my virtual thumbstick to be two inches from "full left" to "full right". Given the DPI of the screen, I can convert touches from pixels to inches like this: inchesFromStickCenter = pixelsFromStickCenter/dpi.
To get DPI, unity offers Screen.dpi but I was getting inconsistent results across devices. Sometimes the thumbstick was way too big, sometimes way too small. Instead I went straight to Android's DisplayMetrics, where I could get xdpi, ydpi, and densityDpi. From this question Difference between the declared size in inches and the size obtained using DisplayMetrics I see that densityDpi is a rounded value, and I should probably be using xdpi or ydpi.
I tested things by trying to compute the width of the screen in inches (my is landscape, all these examples assume landscape). When I divide the screen pixel width (1280) by xdpi (195.4) on my 1st gen N7, it overestimates the screen width by half an inch (6.55 inches, compared to just under 6 when measured with a rule). When I divide by densityDpi (213), it's a much better answer. The wikipedia page for the N7 says dpi is 215, which would also give a great answer.
When I test on my Galaxy S2, the xdpi (217) gives a good screen size estimate, and the densityDpi (240) gives an underestimate by a third of an inch.
So I can't depend on either of these numbers! Why is neither N7 stat nothing like the wikipedia page? Is this a silly way of trying to convert pixels to real-world inches? What should I be doing instead?
Cheers!
is there any resources, such as tables or calculators, related to android devices, available on the mapping between physical screen dimensions (in inches) and their typical density independent pixel (dp) count? for example, what is the typical dp count on screens of sizes for 3.5 / 4 / 7 / 10.1 inches? this is handy as, in terms of size variations, most devices falls on one of the aforementioned dimensions (like 4 inches for phones and 7 inches for tablets) and it may probably help others too if such mapping exists. thanks in advance!
There is a website which collects information about viewport sizes (i. e. sizes in dp) of different devices:
http://viewportsizes.com/
Most phones have 320 and 360 dp width in portrait orientation, most 7" tablets have shortest width 600 dp in portrait orientation, most 10" tablets have shortest width 720 dp.
you can differentiate between device via device's status bar height,
`int resId = getResources().getIdentifier("status_bar_height", "dimen",
"android");
if (resId > 0) {
}
switch (getResources().getDimensionPixelSize(resId)) {
case 25: // small screen
break;
case 50:// for galaxy s3's status bar height
break;
case 75:
break;
case 38:
break;
default:
`
and here is the link , its gives you all information about display of all type of devices.
http://www.emirweb.com/ScreenDeviceStatistics.php
hope your problem got the solution.
Your Total Screen DP is Device Width * (dpi).
DPI varies based on Device Density. its 1 pixels for MDPI devices and so on. You can calculate the same for height as well for all devices. U can find online sites to do this calculation
The one I use is :
Angry Tools
You can find what you need and more in Material Design.
As we know Android coming with various device which having different
Features, Resolution, and Screen-size so while developing an Application which support
multiple (small and big) screen there is an obstacle of size and layout.
This leads to different combinations of screen sizes, resolutions, and DPIs and creates quite a challenge when designing and developing for Android devices. While some other Manufacturer (non Android) have different resolutions and DPI, they share the same screen size and the resolutions follow the same aspect ratio. Therefore, an image can be created to fit the non Android devices.
My question is that is there a proper flow or architecture that one should follow to meet the requirement?
Remember we do have Tablets of different Size and Resolution.
I'm aware that Android Developer contains this information but my view is from implementation.
From my knowledge what I understood is that for designing Android graphics even Programmer must know the designing concept.
Finally created a structure which handle layouts and icon for multiple screen.
Android generalises device displays into categories based on two parameters:
Screen size, the physical size of the display (measured diagonally)
Screen density, the physical pixel density of the display (in pixels-per-inch, or ppi)`
To determine screen size & density quickly, please install "What's my Size" app for Android.
Screen size
Android defines four generalised screen sizes:
Qualifier Size
small ~3 inches (approx)
normal ~4 inches (approx)
large Exceeds 4 inches
xlarge Exceeds 7 inches
Most phones are classified as small or normal (roughly 3 to 4 inches diagonally). But now, there are many phones with large screen such as Galaxy S4, HTC One, Xperia Z
A small tablet like the Samsung Galaxy Tab is classified as large (larger than 4 inches)
Extra-large applies to large devices, for example large tablets
Android defines four generalised screen densities:
Qualifier Description Nominal value
ldpi low density 120 ppi
mdpi medium density 160 ppi
hdpi high density 240 ppi
xhdpi extra high density 320 ppi
Typically:
screen size has most impact on your app layouts
screen density has most impact on your image and graphic resources
It is listed here the percentage difference of device screen
Ldpi- 75%
Mdpi- 100% (base according to Android developer site)
Hdpi- 150%
XHdpi- 200%
But as we know now most of device coming with 480X800 so I'm consider this as based device, so our new calculation will like this
Ldpi- 50%
Mdpi- 66.67%
Hdpi- 100%
XHdpi- 133.33%
which means that first icon and design will be created for 480X800 only and then for rest ones(i.e. Ldpi, Mdpi, Xhdpi).
There are images which are common for all layout and must uniform in color and shape(no complex shape, no curve) so for this kind of image we are creating 9patch which to be put in “drawable(no-suffix)” folder. To create 9Patch image you can either use DrawNinePatch or BetterNinePatch
Now just rename your images based on Android's standards and complete your application with hdpi and then just take drawable-hdpi folder and Open Adode Photoshop(recommended)
create Action of multiple size(just change the size according to percentage ratio) once Action created for all size then just do Batch Automate and give source(drawable-hdpi) and destination(drawable-ldpi, drawable-mdpi, drawable-xdpi).
The reason I insist you to use Photoshop because it will resize automatically your image with Actions and one more plus point is that you need not to rename the file(it will assign same name as original one).
once you completed with creation of all images, refresh your project and test it.
Sometimes there may be possibility that the layout which support screen(xhdpi, hdpi, mdpi) may be get cut in small screen(ldpi) so for handling this just create separate Layout folder(layout-small) for it and add ScrollView(mostly). Thats it.
Tablet
Tablets are categorized into two size.
7"(1024X(600-48(navigation bar))) = 1024X552 (drawable-large)
10"(1280X(800-48(navigation bar))) = 1280X752 (drawable-xlarge)
In this we need to create image for both the screen and just put them accordingly
So all in all we will have this folder in our application to support multiple screen.
drawable
drawable-ldpi
drawable-mdpi
drawable-hdpi
drawable-xhdpi
drawable-large
drawable-xlarge
will be more qualifier combination with Screen size and Screen density
drawable-large-ldpi
drawable-large-mdpi
drawable-large-hdpi
drawable-large-xhdpi
more qualifier with Screen density and Version
drawable-ldpi-v11
drawable-mdpi-v11
drawable-hdpi-v11
drawable-xhdpi-v11
and more qualifier with Screen size and Version
drawable-large-v11
drawable-xlarge-v11
and more qualifier with Smallest width concept(SW)
drawable-sw???dp
Further more in Android V3.0 Honeycomb they introduced new concept of SW(smallest width) in which device are categorized into screen width, so if we are creating a folder named drawable-sw360dp then the device with 720dp(either width or height) will use resource from the this folder.
for example to find the Samsung Galaxy S3 dp to suffix to drawable-sw?dp
With reference of DP Calculation, If you want to support your layout or drawable to S3 then the calculation says
px= Device's width = 720
dpi= Device's density= 320
formula given
px = dp * (dpi / 160)
interchanging formula because we have px's value
dp = px / (dpi / 160)
now putting value,
dp= 720 / (320/160);
dp=360.
so drawable-sw360dp will do the job
Get you Device configuaration from GsmArena
Sameway you can also create folder according to Device's Android API version i.e. drawable-hdpi-v11` so the device which is having API11 and it is Hdpi then it will use this resources.
Additional Tips:
Use relative layouts, dp, sp, and mm
dp units - device independent pixels normalised to 1 physical pixel on a 160 ppi screen i.e. medium density. Scaled at runtime. Use for screen element dimensions
sp units - scaled pixels, specified as floating point values, based on dp units but additionally scaled for the user's font-size preference setting. Scaled at runtime. Use for font sizes
you should always use RelativeLayout for layouts; AbsoluteLayout is deprecated and should not be used.
Use appropriate image formats - PNG versus JPEG
Android "prefers" PNG for bitmap image files, "accepts" JPEG, and "discourages" GIF.
However, PNG and JPEG are not equivalents. They have different quality trade offs, and PNG is not always best:
JPEG can offer up to 50% file-size reductions over PNG, which is significant if your app is image-intensive
A higher quality "lossy" JPEG may look better than a highly compressed "lossless" PNG, for the same file size
Add labels to your images and graphics for debugging
Use the supports-screens element
Configure your emulators with real device values
Conventionally, desktop systems display at 72ppi (Mac), or 96ppi (Windows, Linux). Compared with mobile, desktop displays are always low density.
Always configure your Android emulators to mimic real device values, and always set them to scale to emulate device density.
In Eclipse, it's easy to create multiple emulators (from the Eclipse menu bar, select Window > AVD Manager > New) configured with values for real devices:
Name the emulator for the real device it's emulating
Specify Resolution, don't use Built-in generic sizes
Set the device density to match the real device (in the Hardware pane set Abstracted LCD Property to the real density, always an integer value)
When you launch the device, always select Scale display to real size, and type in the real screen dimension in inches.
If you don't set the device density, the emulator defaults to low density, and always loads ldpi-specific resources. Resolution (pixel dimensions) will be correct, but your density-dependent image resources will not display as intended.
Of course, nothing you do will reproduce higher density image quality on a lower density desktop display.
Here is the Data collected during a 7-day period ending on October 1, 2012. To see the latest statistic about Android platform version, go to here
Based on Screen Size
Based on Screen Density
Designers should create base designs of
base size of mdpi devices * density conversion factor of highest supported density bucket
size.Base screen size is 320 X 480 px and density buckets are as follows:
ldpi: 0.75
mdpi: 1.0 (base density)
hdpi: 1.5
xhdpi: 2.0
xxhdpi: 3.0
xxxhdpi: 4.0
And to tackle extra available space on Android devices should use stretchable components in both the directions (horizontally and vertically). Detailed info is available here:
http://vinsol.com/blog/2014/11/20/tips-for-designers-from-a-developer/