Now I'm making wallpaper image for android tablet devices like Motorola Xoom or Galaxy Tab.
In android phones, typically wallpaper image size is 2 * screenWidth x screenHeight, but in Motorola Xoom it doesn't seem right because it automatically centered and scaled in weird way.
Is there anyone who knows about the exact image size for these devices or mechanism of wallpaper manager?
Thanks
If you have a Super TFT screen like the newer HTC phones, your phone has good (not great) black levels, sharp lines, and fairly good colors. Something with some black will be good, but don’t overdo is as you might notice some bluish tones when the brightness is cranked up. You can however do more intricate images thanks to the high sharpness of the screen. For regular LCDs, just avoid a lot of black and it should look fine.
Ideally,
the Height of the wallpaper should match with the height of the device (or some multiple)
the width can be anything more than the width of the device (keeping the aspect ratio and point 1 in mind)
The android launcher will automatically center the image and then divide the image across all its home screens, let us illustrate this with an example:
Say if there are 3 homescreens, the screen will focus at the center right away and if you flick towards the left or the right, it will scroll to that screen. In other words it the homescreen wallpaper will move 2 times.
(Taking that logic forward, if we have 5 screens, we will be able to move 4 times, if there are n screens, one is able to move n-1 times!)
This is how the formula works:
device_screenwidth + (number_of_homescreens - 1) x distance_moved =
image_width
Say we have an image with height = 800 pixels and width 1280 pixels, applying the formula
=> 1280 + (3-1) x distance_moved = 2000
=> distance_moved = (2000-1280)/2 = 720/2 = 360
in other words, the central 1280 pixels of the walpaper are displayed first, but every time you flick left or right the walpaper shifts by 360 pixels at a time.
This is how the wallpaper is displayed over the 3 screens:
screen 1: 0 to 1280 pixels
screen 2: 360 to 1640 pixels (1280 + 360) (This is the default home screen)
screen 3: 720 to 2000 pixels (1640 + 360)
That is how an image/wallpaper with a width of 2000 pixels and a height which is the same as that of the device (800) is mapped across 3 home screens on a device with a resolution of 800x1280 pixels
Related
Let's say I have a 100px x 100px button defined in Flutter. The size is hardcoded, and not a percentage of screen size. I then created an apk, viewed the app screen on my phone, took a screenshot and transferred it to my laptop to check the actual size of the button. It's 263px x 263px.
My phone's screen size is 1080px x 2160 px, and the resolution is 401 ppi. Am I correct in assuming that scaling from code to app should happen by a factor of 2.5 (401/160)?
Or does scaling happen based on device pixel ratio, which for my device is 3.375?
In actual case, the scale factor I am getting is 2.63. How does this work? Moreover, how do I create an app with pixel perfect layout?
I would like to get size of the Android Phone but size in mm and not in pixels.
I know how to get size in pixels, however I would like to do some RND and for that I want to get width of the screen in mm.
Like here Galaxy S4 size is Dimensions 136.6 x 69.8 x 7.9 mm (5.38 x 2.75 x 0.31 in)
136.6 x 69.8 x 7.9 mm (5.38 x 2.75 x 0.31 in)
^^^
Does any one knows what is this size for?
Though I am iPhone developer BUT I am beginner (1 day baby) for Android. Well below is what I want to do as RND.
Let's say designer gives me design for the app of size 1080*1920 and have title of size 30px (which covers 80% exactly) of the screen size.
That means 10% space on left side, 80% text and 10% space on right side.
I know in Android we have something called sp or android:textAppearance="#android:style/TextAppearance.Large", but that won't give the 10% spaces.
What I want to achieve is regardless of size, design should go same.
Considering design to fit with width, if height increases, I would have scrollview and I am okay with that.
"Pixel density" is the number of pixels per inch. So dpi gives you the scale factor you need so that the number of pixels is consistent across devices.
Another way of saying this is that if you have a 480 pixel screen with hdpi, then a 360 pixel screen at mdpi is about the same physical size. While the screen sizes may vary some, it generally is not that important. Even so, as mentioned, see this post about doing the actual calculation:
Is there a way to determine android physical screen height in cm or inches?
However, you are talking about percentages of screen size in your example. If you know the screen size in pixels, then the physical size doesn't matter, just do your calculations using pixels. If you have 480 pixels, 10% is 48.
You cannot do this in XML, which it sounds like you might be wanting to do. You can use "weighted linear layouts" for runtime calculations of the screen size. You can also use different res folders depending on screen size (like res/layout-hdpi).
You may want to read this from Google regarding supporting different screen sizes: http://developer.android.com/guide/practices/screens_support.html
Use DisplayMetrics. The API is: http://developer.android.com/reference/android/util/DisplayMetrics.html
You can perform a calculation on the given fields and obtain the height and width in inches, then convert that to mm.
I have one problem with UI widget sizing, see 2 devices below as an example,
1.) Samsung Galaxy Tab 2 7"
- Pixels : 1024x600 (mdpi)
- DPI : 160
- Density : 1.0
2.) Samsung Nexus 10 2013
- Pixels : 2560x1600 (xhdpi)
- DPI : 320
- Density : 2.0
If I place a widget with 50dp, by using px = dp (DPI / 160), it would be 50px for Tab 7" and 100px for Nexus 10. But in term of percentage, 50px is equal to 4.88% of screen width on Tab 7" while 100px is 3.9% of screen width on Nexus 10.
But, I need this widget to appear with same width percentage. So, I came up with 2 options.
A. Calculate at run time by getting the physical pixels and apply percentage, then resize the widget.
B. Calculate size and place in < dimen > in different xml file (sw600dp and sw700dp for my case).
As of now, I'm using option A to calculate size and set at runtime. It works well but I'm afraid that the calculation could affect the performance. If I choose option B, I will need to calculate size for every widget in every screen (50dp for Tab 7" and 62.5dp for Nexus 10 will result as 4.8% on both). But, if I want to change this value later or some manufacturer introduce new device with difference DPI or pixels (imagine, 7" tablet with hdpi resolution, 1.5 density, 240 DPI), I will have to redo all the calculation and update or provide new xml again.
So, my question is, is there an option C which will not slow down the performance and not taking a lot of manual calculation into account in future?
P.S. Sorry, I forgot to mentioned that I also using weight approach with my static widgets already, but my question is about dynamic-generate widget. For example,
a gridlayout that showing 5 columns on Landscape Tablet
a scrollview to show 4 rows per page on Phone
an ImageView with 5% padding
an ImageView with an aspect ratio on every device.
dp are almost equal on all devices in size, not in screen %
If you need same screen % then just get display size & calculate desired % of it. Then dynamically apply to your widget
This is a problem of supporting multiple Android device screen resolutions. The App is fixed in portrait orientation and there are three parts of the App,
A top bar (fixed height, say 100px at full HD 1080 resolution)
Main body (dynamic height)
My approach is to build the App with 1080 x 1920 natively, and let the app scale down for the target device screen.
** Since the main body is having dynamic height, the scale would be simply (target width/1080)
* I have also worked out the height for the main body in different resolutions, whether there is a soft home button bar or not, I can work out the exact height to use in px.
I have tried two ways doing the scale, but both of them got some problems.
=== Method 1 ===
- Scale the top bar and put at the top (no prlblem, 50 px in this case)
- Let the main body to auto fill with "0dip" + "weight = 1" (problem described below)
Problem: If doesn't matter the order of applying the parameters, the scale is always applied after the 0dip and weight is set and to fit the screen size, so in a non-1080x1920
situation, the main body would actually be scaled down further. e.g. say if the device is 540 x 960, and the main body part is supposedly occupying a 490 x 960 area. Having the
"0dip" + "weight = 1" with a scale factor of 0.5 in this case supposedly to scale from the 1080 size, the actual main body would actually shown as a 245 x 480 area in the main of
the 490x960 space allocated for it. In a full HD case, whether it is 1080 x 1920 (without the soft home bar) or 1080 x 18xx (with the soft home bar), since the scale factor is "1"
(no scale), the auto fill is working perfectly across different screen height. When it is not 1080, the scale is applied at the
(You may like to say, then, just don't scale the main body part, then the screen occupying is perfect, however, then items are shown at the 1080 size, so you only see part of the
content, 25% top left part in this case)
This then lead me to my 2nd method
=== Method 2===
- Scale the top bar and put at the top (no prlblem)
- Set the main body area to be 1080 x 1920 at layout, then at run time, work out the actual target width and height, set the area to the size for scaling, scale it accordingly then
calculate a margin to bring the part in correct position
Say if the target screen is 800 x 1205 (1280 - 75 the soft home button bar)
The scale = 0.74074074 (800/1080)
Top Bar will take 74 px in this case
Main body would supposedly have 1131 px
After scale before the margin was applied, the main body is only partially shown with a black padding on the left and top, I was assuming it was center placed in a 1080 x 1920
space, so to work out the margin to bring it in cirrect position, i got the fomula below
Left moving px = (1080 - TargetWidth) / 2 => always working correctly with different screen res
Up moving ps = (((1920 - TargetHeight) / 2) - TopBar Height ) => not working, got a weird padding from screen to screen Note that the TargetHeight is the full height including the TopBar to be occupied
I did a screen pixel analysis first, I found that in this 800 x 1205 case, the black space at the top between the top bar and the main body was 306
That obviously has something to do with the top bar 74 pixels, together the top space was 380
However, consider the full target height was 1205, with 2 x 380, that is 1965 pixels, and i can make the formula work for this screen if I add 45 pixel to the calculation.
BUT, when the resolution changes, the gap is different, that amount of extra pixel is just random....
=========================
My questions
Are there better ways to achieve what I am intended to achieve?
Is there a way to use "0dip" + "weight = 1" + apply a scale which doesn't cause 2x shrink?
What is the mystery margin amount there, or maybe i have missed something and could have get it right with some correction?
Thanks, any help would be very much appreciated.
I'm trying to make an Evolus Pencil template for Android. My device has a 1.75x2.5625" screen, and I would like to emulate these exact physical dimensions. From reading this post:
Android multiple screen sizes with same density
I see Physical Size = Pixels / Density. So if I create an image that is 168px wide, on a 96dpi screen, should I not get a physical image of 168/96=1.75" wide?
Because I get one about 1.5" and I'm lost. I am running Ubuntu and confirmed my screen dpi with xdpyinfo as being 96x96. So what is a formula I can use for this? I was thinking one could get the pixels needed by multiplying the inches we want on the screen by the dpi of the screen, but this gives me the 168 mentioned above and obviously gets me no where.
Can anyone point me in the right direction, I'm honestly terrible with numbers and math so my apologies if I'm missing something simple or obvious.
Are you sure that the display is actually 96 ppi? Going by the specs, and my own calculations, your Lenovo S10e actually has a density of ~116.36 ppi, which is probably where your difference is coming in.
Assuming these specs are correct:
10.1" diagonal
1024 x 576 resolution
16:9 screen ratio (taken from above resolution)
Using some geometric formulas, you can get the actual width and height of the monitor as:
Width: 8.8"
Height: 4.95"
Dividing 1024/8.8 and 576/4.95 gives you 116.36 pixels per inch, rather than 96.
Using this instead, a 168 pixel image should display as 168/116.36, or ~1.44", which is consistent with your results. I wouldn't put too much faith in the xdpyinfo results. :)