This is a bit long winded.... sorry!
The GUI is definitely the biggest pain for me, not to mention time consuming. I think a lot of it does have to do with how complicated the app is and what you are showing the user.
For my (so far only) app, I was initially creating new variants every time someone would complain or I would see new specs, but as Bluedude suggests, you can't keep up with it.
I don't know that you can tell which variant the app chose to use, but I suppose it may be possible somehow. One thing I noticed is if you are trying to determine the screen height, don't use LayoutVal because it is often not the same as the actual height which can be determined by Activity.Height. I'm by no means an expert on this stuff but here are some things I have learned or chose to do during a major overhaul to my app's GUI display:
First, I decided to go with the method
described here in order to come up with %x and %y values. For my app, I decided to just start over with 4 variants. 320x480, 480x320, 800x1280 and 1280x800. That is
phone and
10" tablet, portrait and landscape for each. I didn't care if it looked the same on a 7" and 10" tablet, and it will look nearly identical, just larger on the 10". Doing things this way works well for many different devices but it is not perfect. I had two problems in particular:
1) Height to Width ratio differs by device using that method. While everything "fills" the screen nicely, buttons will appear stretched on certain devices. In many apps this is probably not a big deal, but my app uses images for almost all of the buttons. Anyone who has worked with images knows that you cannot change the H/W ratio without it looking funny. Perhaps 9-patch images would have worked better in my scenario but I don't know much about them. My solution was to take the height the app gave the buttons (%y) and multiply that number by the correct ratio. Even one further, for certain buttons I took the %y and %x, did the math on each with the ratio, and used the one that would produce the smaller button (if it was different). My thought was that this SHOULD ensure that there won't be a device resolution where for some reason the buttons overlap. Even with using %x and %y though, I only used the top and left positions "assigned" to just a few key buttons of the app. Using those positions, I then fit the other buttons around them using DIP, which will ensure that overall they look nearly the same on all devices.
2) By using what is essentially a single layout for all phone sizes, I noticed that on many AVDs there was a lot of dead space in between buttons and at the edges, etc. The reason for this of course is because they come in many different (higher) resolutions. The way I found to somewhat fix this problem was that when designing my base phone variant (320x480) I designed the layout very tight. Buttons as big as I could go with very little empty space. This translated to much better looking GUIs on other device sizes, but maybe a bit cramped on the default (but how many phones use a resolution that small?).
For many other screens in my app (that didn't need to be "full"), I simply created one variant (320x480) so I could get my basic layout done, then I size it all in code using DIP. Depending on the height of the screen, I sometimes make it a bit bigger to take advantage of the extra room, but mostly they are all the same size on all devices. The buttons and other views were done on panels that I "center" through code on each screen. This is one thing I *still* don't have an answer to. I chose to somewhat limit screens like this on tablets. While I could show a listview of names as wide and tall as the entire tablet, this seemed ridiculous to me. So by using DIP as mentioned above, I keep them the same size overall from device to device. If you held them next to each other, the listview would be almost the same size physically on each device. Is this right or wrong? I have no idea. But that is how I did it.
Creating variants for all of the different devices is just too much work. If you are not too picky about H/W ratios, I'd say you could probably get by with a few and just be sure to build them on a panel so that you can easily center it on the device. This is not perfect, but it would work. Honestly I think that the %x and %y thing is the way to go, but coming up with the values (by entering T, L, H & W) for all of the views on all of my screens using the Excel sheet in the linked thread took a LONG time. It would definitely be nice to have the designer capable of generating this information. But it isn't necessarily one size fits all. For some views I wanted the exact %x and %y for top, left, width and height but for others I only wanted T & L or W or H. So even the Excel sheet couldn't prevent me from having to write a lot of code to get the layouts correct.
To Bluedude: Use DIP if you want to place or size a view EXACTLY the same on each device regardless of screen size or scale. The only thing, you have to make sure it will fit on the screen. So don't use 500dip height on a 480 high screen. While you may want to use DIP for height & width (such as for an EditText), I doubt you'd want to do this for top & left. If you want views to be relatively in the same position independent of the device size / resolution, use %x and %y, but realize that spacing in between views, their sizes and H/W ratios will vary across different devices. To fix this, you can use a combination of both, which is what I did. There is a little more empty space on some devices compared to others (especially the bottom) but I feel it is negligible. This is mostly caused by my limiting the height of certain views in order to maintain the correct H/W ratio to make sure I don't accidentally make the view too big to fit when I correct the H/W ratio .
I hope this helps, and remember everyone.... you are not alone in this problem!
