This is one of those annoying cases where things are working but I don't know why. Based on the Android API docs and this site, I expected to have to do pixel density conversions on my layout parameters (shown here in their original state):
LayoutParams lp = new LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);
lp.width = 60; // the following three should be pixels, right??
lp.height = 80;
lp.setMargins(1, 5, 1, 5);
In other words, I expected the above to not work well across different screen densities since they're specified in pixels. The "problem" is that it works fine on all of the simulators I've tried, from a lowly QVGA on up. To try to understand why, I used Hierarchy Viewer to inspect my app and found that the width of the view (from getWidth()) was always 320 when my app had focus. Go back to the home screen, say, and now HV reports the screen width as 480.
Any idea what's going on?
The values are indeed specified in pixels. It sounds like your app is running in compatibility mode?
According to http://developer.android.com/guide/practices/screens%5Fsupport.html , if you don't declare support for multiple densities in your Manifest, then it will report medium resolution and the application will behave as such. Says:
If the application states that it does
not support different screen
densities, the platform auto-scales
any absolute pixel coordinates, pixel
dimension values, and pixel math used
in the application (such as might be
used for specifying the width or
padding for a view). It does this to
ensure that pixel-defined screen
elements are displayed at
approximately the same physical size
as they would be at the baseline
density of "medium" (160). The
platform handles this scaling
transparently to the application and
also reports scaled overall pixel
dimensions to the application, rather
than physical pixel dimensions.
For instance, suppose a given device
is
using a WVGA high-denisty screen,
which is 480x800 and about the same
size as a traditional HVGA screen, but
it's running an app that states that
it does not support multiple
densities. In this case, the system
will "lie" to the application when it
queries for screen dimensions, and
report 320x533. Then, when the app
does drawing operations, such as
invalidating the rectangle from
(10,10) to (100, 100), the system will
likewise automatically transform the
coordinates by scaling them the
appropriate amount, and actually
invalidate the region (15,15) to (150,
150). The same thing happens in the
other direction, if the application is
running on a lower-density screen,
coordinates are scaled down.
This is something I have also been working on recently. Is it the anyDensity tag that you are talking about within ?
If so, where is it suppsed to appear in the Manifest?
Regards,
Oliver
Related
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
I've developed an interface and everything has used dp settings so I thought it should have been good for most screen sizes. However when testing it gets messed up on most screen sizes, bigger and smaller. I get the icons not showing right since I only have one set for Nexus 4 size and density as they are only placeholders until I build the proper icons at the proper scales.
What is going wrong? Is dp the wrong way to go about designing it for scale? I've considered designing specific layouts for various screen sizes but I'm not sure where to begin in regards to what to target.
Here is what is should look like. (Nexus 4)
Smaller Screen (Nexus One)
Bigger Screen. (Nexus 5) - See how the text collides with the vertical divider.
dp - an abstract unit that is based on the physical density of the screen. which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use.
It doesn't mean that image can scale automatically. It works in the specific density devices well.
Generate ur icons with http://romannurik.github.io/AndroidAssetStudio/icons-generic.html and place the icons and check.
For text don't use dp : instead use sp
I am developing an Android application where the server sends all the values corresponding to dimensions in pixels for 1920*1080 resolution device.I need the app to be supported on multiple screen resolutions.I went through Android documentation on supporting multiple screen resolutions.It suggests to convert pixels to dip and then render.I did that in my application but the views are not rendered as required.So I tried applying simple unitary method by dynamically getting the screen width and height and then scaling all dimensions based on current screen width and height.
Say my current screen width is X and height is Y.So what I did was
Scaling factor in horizontal direction = New Screen Width/1920.
Scaled dimension in horizontal direction = Scaling factor in horizontal direction * Dimension from server in horizontal direction.
Similarly for vertical direction.
The application is now looking fine on my device.But is it a reliable way of doing things ? Should I be dealing with density of display too ?
DP is probably the better approach, if you elaborate a bit on what you mean by 'not rendered as required' I can try to help.
I can think of two main issues with your current method:
Different aspect ratios of devices. Using your method you will end up with distorted imagery. For example a square in 'server dimensions' is 400x400. In a 800x480 phone, that square will be 162x177 - no longer a square. Depending on your visuals and purpose of your app, this may or may not be an issue. If it is an issue, you need to account for that.
Physical views' size. One of the purposes of the DP method is to ensure a view will have (almost ) the same size across different devices, mainly never too small to handle for the user. So using the DP approach, a 100dp button will be 200px on a high density device, and 100px on a medium density device. This way the button is physically the same size on both devices.
But your method ignores that. Take the square from the first example - it will always be a fifth (400/1920) of the width of the screen. This can be either huge or tiny, depending on the device dimensions. Again, depending on your needs this may or may not be a problem.
Your method can work, as long as you account for these (and maybe more) problems. But it does require special care and probably more coding and work to make it work perfectly compared to simply using DP.
I am looking for a robust way to scale my AIR for Android app up, or down, for different screen sizes.
The app is going to be published privately, and will only likely ever sit on devices with a very small range of resolutions (720 or 1080p typically)
Now, firstly, I read that you cannot change the stage height and width dynamically and can only be set once in the application settings. So first off, do I set my app to have the largest resolution, 1080p, and scale down. Or do I set it to a mid ground between 1080 and 720 and let it scale up and down?
Secondly, how should I scale it? Should I use Stage.scaleMode and if so, which mode?
How do I scale the app if I cannot resize the stage directly?
I have looked at the following pages, but they don't seem to work very well, if at all, for some odd reason?
link 1
link 2
link 3
link 4
You can do everything dynamically!
use:
stage.scaleMode = StageScaleMode.NO_SCALE;
stage.align = StageAlign.TOP_LEFT
and handle it yourself when the application starts. By useing relative values instead of fixed pixels, to position your items
To get the devices dimensions and DPI use:
Capabilities.screenResolutionX;
Capabilities.screenResolutionY;
Capabilities.screenDPI;
If you're useing Bitmaps dont let them scale too much, and rather down then up.
Also checkout .smoothing attribute for Bitmaps.
its best to have different size bitmaps ready and replace them according to your screensize in some startup method.
the second link u postet acutally explains all this very well
I have a two questions.
First: I am looking at the Android compatibility definition document (CDD 4.0) and it states:
Devices MUST have screen sizes of at least 2.5 inches in physical diagonal size
Devices must report one of these densities: 120dpi, 160, 213, 240, 320
The aspect ratio must be between 1.3333 and 1.85
Must have minimum screen size of 460dp x 320dp (dp = density-independent pixel)
Suppose I have screen of 2"x3", with density of 120dpi, the screen would have:
Diagonal: 3.61" = good
Screen size: 320x480 dp = good
This is nicely compatible with Android CDD
If I change the width from 2" to 1.7", I get
Diagonal: 3.45" - still good
Screen size: 272x480dp - NOT COMPATIBLE
My first question is, why specify a diagonal value, when the WIDTH is really what affects compatibility? The width must be 2" minimum.
Second: If I don't need to be Android compatible and stick with the 1.7" screen size, will applications that were built for the smallest compatible display be able to run on my device? Will the UI of this application be cropped when run in my device?
Thanks much for any insight.
It's probably just an easy way to specify the requirement. If you have a portrait device, the width is smaller than the height. If you have a landscape device, the width is the large dimension. It's just easier to say "the diagonal" than "the smaller of the two screen dimensions when the device is laid flat" or something like that. There are lots of ways to say essentially the same thing.
If your device is smaller than the CDD requires, you will probably want to still report in Android that your device is of screen size small, so I imagine apps will run but layouts for many of them will likely not fit well as people will tend to test on CDD-conformant devices. It very much depends on what layouts people used, but I wouldn't be surprised if you saw some cropping.