Android resolution and layout problems

I Think I SpiderDuring the process of developing I think I spider we discovered various problems regarding Android’s different resolutions. Here you can see which problems we encountered and how we solved them:
We are being told that we should not use the AbsoluteLayout , but what if there is no other choice of implementing your layout except for using the AbsoluteLayout? What If the layout needs to have some views to overlay each other so that it fits nicely?
This was exactly the case for us this time.
In the layout for I think I spider there are a few ImageViews (with changing images) that simply have to be on top of others or even in the area of the tabs, and they also have to be at this EXACT position of the other image on every resolution. So we couldn’t help, but use the AbsoluteLayout to accomplish this.

dp or not dp?

It was some work, but after a little time, the layout fitted for each density – well, at least so it seemed…
It fitted only for the three default dpi values (120, 160 and 240).
If you used a larger / smaller screen with the same density, the positions didn’t match exactly any more.
The problem was, that we used (as we are also said to always use) dp to set the views. It’s true that its nice to do this, if you use the standard widgets and if you don’t have such a highly customized layout, but in our case it seemed like the wrong decision to use dp.
The solution to this was to use pixel values instead and to create the layouts for the different resolutions and not the densities. The new values were easy to calculate, because you only needed to take the values of the 480x320px resolution (exactly the same values as in dp) and multiply them by 0.75 for the 320x240px resolution and by 1.5 for the 854×480 one (and adjust the height a little here…).

Changing the layout in your code

The next problem was (even before we converted the values in px) to display the layout on the 800×480 and 854×480 resolutions, because you can’t declare layouts for both of them – they always take the same one.
We also didn’t want to have a black border for the bigger resolution, scaling the background to a bigger length was also no problem, so we decided to adjust the layout for this particular case in our code:

//called in onCreate()
if (getWindowManager().getDefaultDisplay().getHeight() == 800) {
 AbsoluteLayout.LayoutParams params;
 params = (LayoutParams) findViewById(R.id.someView).getLayoutParams();
        params.y = params.y - 7;
// more adjusting here...
}

Well, maybe it isn’t a good solution, but we didn’t find any other possibility here.

Using resource qualifiers for the different resolutions

A downside of this approach is that you have to add adjustments to every resolution that is available now and that comes out in the future, like the bigger ones for tablets.
Right now, you can support most of the resolutions by simply declaring different layouts by using different folders (except for 800×480 and 854×480), but I’m not sure how it is going to be with new resolutions.
The layouts we declare are seperated in the following folders:
layout-normal-mdpi -> 320×480
layout-normal-hdpi -> 800×480 and 854×480 (adjusted in the code)
layout-normal-ldpi -> 400×240
layout-large-mdpi -> 800×480 tablet (mostly the same as the layout-normal-hdpi layout, but needs to be in this folder)
layout-small-ldpi -> 320×240
Also one -landscape folder for each of them for the landscape layout for the widget (the rest of the app is portrait only)

Conclusion

If someone downloads the App with an unsupported resolution, it will not be displayed correctly. For such cases it could be helpful if you could declare the resolutions that your app supports, or at least the aspect ratios and to have resource directory qualifiers for this, so that you don’t have to adjust your layout in the code.
My conclusion of this is that the wide variety of different resolutions, densities and especially aspect ratios makes it really hard to create a good looking app that supports all of them. Google should really have put more restrictions to these terms to make it easier for the developers so that they can provide better quality apps for the users.