How to deal with multiple screensizes + dynamic controls in Android?

Question

Hi

I am learning how to program on Android phone. However I am unsure how to make my application work for the different screen sizes and resolutions.

I read the tutorial on the android site and still unsure how to do it.

First I know there are different files so could make a layout for each of the sizes but my problem is most of the screen needs to be dynamically created so there would not be much to put in these files.

So I am not sure how to android to re size dynamic controls based on the screen size.

I have also read it is bad practice to make controls in anything but the xml file as it separates view logic and programming logic. However they never talk about if you need to make these controls dynamically what you should do.

So is there some other way to do it that is considered good practice?

Edit

I get this error when I try to run the switcher application.

[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: Error type 2
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: Error: Unable to connect to activity manager; is the system running?
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: usage: am [start|broadcast|instrument|profile]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: am start [-D] INTENT
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: am broadcast INTENT
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: am instrument [-r] [-e <ARG_NAME> <ARG_VALUE>] [-p <PROF_FILE>]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: [-w] <COMPONENT>
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: am profile <PROCESS> [start <PROF_FILE>|stop]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: INTENT is described with:
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: [-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: [-c <CATEGORY> [-c <CATEGORY>] ...]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: [-e|--es <EXTRA_KEY> <EXTRA_STRING_VALUE> ...]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: [--ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE> ...]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: [-e|--ei <EXTRA_KEY> <EXTRA_INT_VALUE> ...]
[2010-04-27 12:06:41 - ViewSwitcherTest] ActivityManager: [-n <COMPONENT>] [-f <FLAGS>] [<URI>]

To your question: It's dynamic because the buttons in my example grow and shrink depending on one of the 3 possibles sizes, because they use scaled pixel (You probably know that you don't have to deal with screen sizes itself). So a scaled pixel compared to a real a pixel has a size of 0.75px, 1.0px or 1.5px. Android automatically and dynamically adjusts it to the actual size. So you don't have to care about this in your code.

So if I use scaled pixels then I don't have to worry about different screen sizes?

At the moment I don't know an example except in games where you have to deal with "real" pixel. But if you want use it, multiply it with the value of the current density. This is your "ratio". I don't have the example with the ball anymore but I have another which uses the same technics. You can run it on different screen sizes and you will see that the buttons will always fit into the layout. You could use the same technics for your intents. In this example you can scroll with the "Scrn" buttons from one view to another of 4 views. (At the moment they all have a black background so you don't see that they are different views). The "Enter" button exits the test. It's an Eclipse project. You can download

So if I want to deal with ratio then I use real pixels and not scaled pixels? What advantage does this give me?

will scaled pixels work with changing from portrait to landscape( ie will it fill up the new found space)?

Finally should I make the controls now through code or is there another way? As I said I am getting data from a webservice that must look like this

checkbox label label

It can be one record or 10,000 records I don't know so these have to be appended to something that is like a window panel( the controls in there get a scroll bar).

Thanks♠

Answer 1

I've never used different files or directories yet although I always handle all possible screen sizes. How you deal with the 3 different sizes depends on what you plan to do. I think that scaled pixels in your xml are everything you need for your application. Look at the last thread of one of my postings. I think it will give you a hint to solve your problem:

Handling correct pixel ratio on different screen sizes

When you need to know the density too (e.g. to calculate the right pixel movement ratio in games, you could combine "scaled pixel" in your layout with the density you get from the DisplayMetrics class:

public class YourActivity extends Activity {

private DisplayMetrics metrics = new DisplayMetrics();
private float density;

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    requestWindowFeature(Window.FEATURE_NO_TITLE);
    getWindowManager().getDefaultDisplay().getMetrics(metrics);
    density = metrics.density;  
    ....

}

Density could only be 0.75, 1.0 or 1.5. So you can use these values for your needs e.g. for the "pixel wise" movement of graphics. This is the approach I use.

Answer 2

To your question: It's dynamic because the buttons in my example grow and shrink depending on one of the 3 possibles sizes, because they use scaled pixel (You probably know that you don't have to deal with screen sizes itself). So a scaled pixel compared to a real a pixel has a size of 0.75px, 1.0px or 1.5px. Android automatically and dynamically adjusts it to the actual size. So you don't have to care about this in your code. At the moment I don't know an example except in games where you have to deal with "real" pixel. But if you want use it, multiply it with the value of the current density. This is your "ratio". I don't have the example with the ball anymore but I have another which uses the same technics. You can run it on different screen sizes and you will see that the buttons will always fit into the layout. You could use the same technics for your intents. In this example you can scroll with the "Scrn" buttons from one view to another of 4 views. (At the moment they all have a black background so you don't see that they are different views). The "Enter" button exits the test. It's an Eclipse project. You can download it from here: http://android.pithax.net/ViewSwitcherTest.zip

Answer 3

So if I use scaled pixels then I don't have to worry about different screen sizes?

In my opinion I would say yes. At least this is my approach to handle different screen sizes.

So if I want to deal with ratio then I use real pixels and not scaled pixels? What advantage does this give me?

Every pixel value in your code is a "real" pixel. e.g. in my example view1.setHeight((int)(350*density)); If I would not multiply it by the density, it would always be 350px and not 350sp. There are no methods to deliver different kinds of pixels, eg sp, dip or px. The unit is always pixel. And if you use a dynamic layout (with scaled pixel) you must take care that all your pixels you set in your code must have the same ratio. Android knows what the ratio is (density), so you always have to multiply it with the density to make sure that you always have the right ratio, in every screen size. That's the advantage you gain with this method. It will probably be clear for you get my example running.

will scaled pixels work with changing from portrait to landscape( ie will it fill up the new found space)?

Scaled Pixels will take care that the ratio in every size is the same. That means that your landscape design you defined will look in every screen size the same.

Finally should I make the controls now through code or is there another way? As I said I am getting data from a webservice that must look like this

checkbox label label

It can be one record or 10,000 records I don't know so these have to be appended to something that is like a window panel( the controls in there get a scroll bar).

Now I understand what you mean. These are 2 different topics. The one is that your results will look in every screen the same. That is what we are talking about all the time.

I guess the problem with these dynamic records is not solvable with a predefined xml. I would this do by code in any case (In my example I also added the views by code). I'm not sure which approach could be the best but maybe a table layout where you add as many rows as you need by code. I'm not very experience with that yet but I think this is not very difficult. I think there is even a similar example in the Android samples.

To my app: What does "./adb logcat" say? If you can't get in running, create a new Android project with API level 4, change the file structure as it is in my project (acutually you only have to delete drawable-ldpi and hdpi and rename the 3rd to "drawable"). And you have to use the same package name. Otherwise it will crash. Actually it's better to create a new Android project. Maybe it crashed because you didn't set the right package name (net.pithax.viewswitchertest). In the zip these are folder so you can't run the zip anyhow.