Android and supporting multiple screens layouts
Asked Answered
O

3

9

I'm finishing off an Android app, all that remains is to adapt the UI layouts and graphics for multiple devices. I need particular elements placed in particular positions on the screen.

The Android docs explain how the multiple screen resolutions and sizes are classified, and explain the resource tagging system.

For example, both WVGA800 (480x800) and WVGA854 (480x854) are classified as normal high density screens. To cater for these you're asked to create a folder called "layout" (already present for "normal") and "drawable-hdpi".

The problem is this does nothing to differentiate two devices of the same classification, even if you use "dp" units. How can you provide layouts/drawables for WGA800 and for WGA854 separately?

The ratios are sufficiently different that the user easily notices bad scaling, and this is exacerbated by my need for things like a score and timer to appear in a particular place against a background image.

The same problem applies to the pairs {WQVGA400 (240x400), WQVGA432 (240x432)} and {WVGA800 (480x800), WVGA854 (480x854)}. How can you provide layout/drawables for WQVA400 and for WQGA432?

Osteomalacia answered 25/3, 2011 at 12:32 Comment(1)
Probably not the answer that you're looking for, but you can get the screen width and height and then can resize the image or put the scores and timer at proper place.Supen
M
15

I think you're on the road to hell.

Android runs on an enormous variety of devices, more every week, and many formats don't exist yet but will introduce new variables. So even if you succeed, one new device with a slightly different screen size, and your app will fail.

It's a mistake to design for Android using specific screen resolutions, and is similar to the issues you'd find if you forced all pages to be the exact same size on the web, it rarely works well (e.g. even a tidy fixed-width site will fail miserably on mobile devices).

Android has been designed to support all this variation, but if you try to get pixel-perfect absolute-positioned rendering on every screen size you are swimming against the tide. It is likely to be very painful, very time consuming and expensive, and likely to ultimately fail. Even if you succeed, how on earth will you test it on all these screen variants? It sounds like testing hell too.

I STRONGLY recommend you accept you cannot do everything as exactly as you need to, and instead look at how to use ways of rendering objects fluidly, relative to each other, so the app looks good in all the different variations, using the different layouts for each group of resolutions to improve the experience on different size screens.

Marilynnmarimba answered 25/3, 2011 at 12:40 Comment(5)
Feared as much. But I needed to be shouted at!Osteomalacia
An observation - the widths of all members of a given classification are equal. Is there any statement of intent to keep it that way?Osteomalacia
@SK9 I think it's best to assume Android can run on a device of almost any size, shape, orientation and with any features present or abesent (GPS, network, keyboard etc) and with the display follow the concepts provided and customise to them - portrait/land, ldpi/mdpi/hdpi/xhdpi, screen sizes etc. It's not easy, but in the long-run less painful, and a good chance the app will Just Work on most devicesMarilynnmarimba
I agree with that, my worry is that scaling anything - even slightly - comes out poorly in the simulator and on my device. It's a heavy trade-off for me. There may be a decent compromise in this... there's no way I'm willing to keep up with new devices, but keeping up with width seems reasonable given that there are only three to date. Until then this does get me a long way. It'll give me some time to come up with a better idea too.Osteomalacia
Thanks again for your response, it got me thinking about this the right way (nesting relative layouts and linear layouts, using constants for padding only where needed). The UI now looks good in all resolutions and screen sizes. Thinking of the android screen as a web page is a very useful philosophy.Osteomalacia
B
5

YES, that's possible:

First you have to create a instance of the display-class. After that you get the display's width and heigth. Then you can check each resolution in a loop, by using the if operator and set the image you want.

Example:

ImageView iview=(ImageView)findViewById(R.id.imageView1);
//here are the Bitmaps optimized for each screen resolution 
Bitmap[] bitmaps={BitmapFactory.decodeResource(getResources(), R.drawable.icwvga800),BitmapFactory.decodeResource(getResources(), R.drawable.icwvga854),(...)};
// In this list all supported screensizes are defined
int[][] possibleScreenSolutions={{480,800},{480,854},{240,400},{240,432},{480,800},{480,854}};
Display display = ((WindowManager) getSystemService(WINDOW_SERVICE)).getDefaultDisplay();
int[] ScreenSolution={display.getWidth(),display.getHeight()};
// Compare the real screen solution with the all supported ones
for(int i=0;i<possibleScreenSolutions.length;i++){
    if((ScreenSolution[0]==possibleScreenSolutions[i][0])&&(ScreenSolution[1]==possibleScreenSolutions[i][1])){
            iview.setImageBitmap(bitmaps[i]);// set the image
    }
}

I agree with Ollie C: It's too confusing to check all resolutions, but It's at least possible.

I've tested it allready: It works.

Bonine answered 16/3, 2012 at 10:59 Comment(0)
O
2

Further to the answer/comments elsewhere on this page, I'd like to post another answer to my own question drawing attention to the type of screen resources that can be introduced. I'm not convinced this is made clear in the Android docs, but so far as drawables are concerned you can add screen size tags to drawable files on top of the dpi tag.

For example, adding a folder called drawable-large-mdpi is valid and devices with large screens and medium resolution will pull resources from here if they can. Warning though, switching the order of the tags matters: declaring drawable-mdpi-large is an error.

Osteomalacia answered 1/4, 2011 at 2:45 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.