Looking for a way to build resolution independent layout xml?

by Videoguy » Fri, 06 Mar 2009 02:53:32 GMT

Sponsored Links
I am working on a screen that needs to look fine at HVGA-L resolution
as well as 640x480 resolution. Lets say I have a button that is 200
pixels wide and 50 pixels high on HVGA-L skin. When the same layout
xml is shown at 640x480 skin, I want my button size increase
proportionately. The hardware the app runs on supports both the

How do I do that?

None of the units that the android framework provides seems to have
this facility. If I use px, then the button size will stay same. dip
doesn't matter because it is the same hardware. sp is meant for fonts,
not for button width/heights.

Is there any trick to do this?


Looking for a way to build resolution independent layout xml?

by Videoguy » Fri, 06 Mar 2009 03:15:10 GMT

 I have lot of screens that need this. XML is a great prototyping

I am wondering whether it can be accomplished with xml layouts


Sponsored Links

Looking for a way to build resolution independent layout xml?

by Videoguy » Fri, 06 Mar 2009 12:38:28 GMT

 Hmmm...I am not sure Romain's solutions works in this case.
I dumbed down our problem. We are looking at Android to replace a
legacy kiosk type of application. The device is not a phone. We have
around 40+ different layouts (or Activities in android lingo) that
need to show correctly in half dozen resolutions. It is going to be
maintenance nightmare if we start creating resolution specific layout
files in layout_XXX/ and drawable_XXX/ folders. Everything works great
in first release, But it won't be long before the layouts in one
resolution going out of sync with their counterparts in other folders.

What would be great is if I can do something like:
   a) Specify the resolution in the layout xml (say 640x480)
   b) Build my xml that works in that resolution using whatever units
that work for the layout.

Then lets say I am showing that layout in 800x480 resolution, the
widget engine understands that the layout's native resolution
(specified in xml) is different from current system's resolution and
start scaling all the measurements, offsets to new resolution.
Basically one xml layout is used in multiple resolutions. It works
pretty good as long as you don't try 640x480 on 480x640 resolution.
This will make it even better if you combine it with layout_XXX/
method. The widget engine picks a match from layout_XXX/ folder and
doesn't do any scaling. If there is no match, it defaults to my
I understand you can achieve resolution independence with clever way
of using layout_width and layout_weight. When you have buttons with
drawables on left/right, you start using the padding attributes in px
or dip. They don't seem to position correctly when you change

If I have to implement a solution like above, what is the least
intrusive way (to the framework) of accomplishing it?
Do I need to create my own xml layout inflator and add the
translations like above?
Or did I go on a tangent?

Thanks for answering.



Other Threads

1. Browsing G1 from Windows

I have installed the Windows USB drivers, and I was expecting to be
able to access the phone like a removable disk from windows. However,
when I click on the removable drive (E:) I am told 'Please insert a
disk into drive E:' Am I the only one with this problem? Seems it
should be a lot easier to upload music and stuff from my PC. Sorry if
this is the wrong group from this question.


2. (Another) h/w accelerated OpenGL|ES question

I've seen the messages about Android not being ready for h/w
accelerated OpenGL|ES, etc.. We have an existing OpenGL|ES driver
(with an EGL implementation that supports full screen apps only) which
we've enabled Android's surfaceflinger to use. But we used a hack and
I'd like to know whether experts think we'd get into trouble in the
future for doing what we did.

What we did is basically create our opengles library under a new name
(e.g., libMyOpenGLES_CM.so) and had the Surfaceflinger link to it
rather than the software version. We had to resort to some other
hacks, like eliminate some android specific extesions, etc that we
don't have in our version. Obviously, this only works for the
surfaceflinger app since it's a full screen app using the whole
framebuffer chain owned by the FBDev. We also changed some flinger
code to use our NativeWindowType which is not the same as the one
provided in Android.

Next we will be enabling, non-flinger apps (i.e. apps that do not
"own" the FBDev buffers) . Again we will be using our own existing
NativeWindowType which supports this, and not the
EGLNativeWindowSurface type that android uses (and yes, we will have
to change some android code, like opengles JNI code etc...I know it's

Apart from the buffer copy from our driver's render target to the apps
surface on every eglswapbuffers, what other problems (as I know there
must be) do you see with this?


unsubscribe: android-porting+unsubscr...@googlegroups.com

3. service stops when phone goes idle

4. android browser and kml content

5. Permission problem in location base application

6. How to access native Application from a Java Application

7. Problem with ListAdaptor