Hello,
I´m writing a Compact Framework Application for Windows Mobile 6.5. The Application will be sold in the Windowsphone Marketplace. To do so, I have to support the various Screen sizes and resolutions...but how do I do this? Is there a best practice or so? I use mainly standard controls but a Background Image in the Mainform...do I have to store it in any resolution and show it dynamically, depending on which device my app runs?
Thank you for your suggestions and help
Thomas
I'll start saying this is a controversial topic.
My personal take is you should identify significantly different resolution/sizes ranges and provide a different UI layer you can swap in when you detect a resize that goes from one range to the other (dynamically switching might not even be a requirement for you - in that case you just check at load time). This approach obviously doesn't make sense if the ranges you identify are very limited and similar to each other, as within the same range your app should be able to resize decently.
Trying to tackle all the possible resolutions with the same UI layer might sound like a great idea but it can be a recipe for disaster. You might get it working, but you'll very likely end-up with a ball of string, with a bunch of IF-ELSE and SWITCH statements looking at pixel sizes, resizing controls and moving things around.
If you think about it, Google Maps (for one, but think about any iPhone app) doesn't serve the same UI on mobile and on your desktop browser and so forth. If that's the difference in size we're talking about (mobile VS desktop-like resolutions) then you'll have to roll different UI layers as per my suggestion above.
The holy grail is the so called Liquid Layout - WPF could help on this but since you're on compact framework that's ruled out.
I recently asked a very similar question - you can have a look at it here if you wanna read different opinions.
This is a toughie. I've had reasonable results with the following low effort plan. (This is Winform oriented, btw)
The biggest issue is with resolutions that are smaller than expected. Therefore create your screens as small as possible and pay particular attention to your anchor and docking settings. When displaying each form set it to full screen and the anchoring properties should do a reasonable job of displaying things in a sane way.
This only starts to look silly if the resolution is MUCH larger than anticipated.
Note you can find the screen size of the current platform via the Screen.PrimaryScreen.Bounds call.
I recently built a small app, just for trying things out. I needed to display a background image, so I could not use the built-in controls like Label and so forth because they do not support transparent background.
I ended up drawing the entire interface in the Paint event of the form, using GDI+.
Handling different screen resolutions turned out to be quite simple: the interface is prototyped for a regular 96dpi screen (the smallest) then all sizes are scaled using a factor calculated as 96/actual_dpi. You can retrieve the actual DPI setting of the screen using the code found here (a bit old but still working). I then tested the application with all the resolutions provided by the emulators and found no issues.
Caveat: I "wasted" the lower part of the screen so that nothing special was needed to address square screens and landscape/portrait orientations.