The reality of mobile development (especially if you're creating a product) is not so different to that of Web development: the clients that will be using the application may not be under your control, and they may support different sets of features and capabilities. In the ASP.NET world, this was solved by the set of mobile-enabled controls, that basically rendered different markup depending on the device. Even in ASP.NET 2.0, this solution, the so-called control adapters architecture, is still in its infancy and not fully completed in its integration with the "standard" controls.
In the mobile development world, the problem is not even in its infancy. Up to now, that is.
In the devices world, the critical difference between clients is not on the platform (as in the web, where you have different browsers supporting different standards, etc.). When you decide to develop your application using .NET Compact Framework (CF), you're already filtering the range of devices to Windows-based (most probably Windows Mobile 5.0 if it's a brand new one) Pocket PCs or SmartPhones. In this scenario, your most challenging issue is how to support the different so-called form factors (or resolutions, such as VGA, QVGA) and screen orientations (can be landscape or portrait).
The Microsoft .NET Compact Framework 2.0 introduces some features that certainly help alleviate the problem, specifically in the WinForms area, where you can use the familiar docking and anchoring funcionality to have your controls automatically resize according to screen size. However, this falls short for most applications. For example, say you're displaying a purchase order in a vertical QVGA screen (240x320). Most probably you have laid out the controls so that each value you want to show is displayed in a s...
To continue reading for free, register below or login
To read more you must become a member of SearchWinDevelopment.com
ingle "line." Well, if the screen is rotated, you probably don't want to simply make your fields wider. That may be a waste of valuable space, and result in a poorer user experience by the requirement to constantly scroll the screen. In this case, it may actually be better to lay out controls differently, so that you can for example display two values per "line."
Of course, the logic of the user control/form (hereafter simply referred to as "control," which is even technically correct as the Form class inherits from Control too) is the same -- the data binding, event wiring, the controller/presenter logic, etc. So in an ideal world the layouts would be sort of "skins" for the control, that are applied dynamically depending on the current device form factor and orientation.
If you think for a moment on the problem at hand, and how the ideal solution would look like, you may realize that the .NET Framework (and therefore the CF too) already provides a mechanism that allows applying "skins" to WinForms controls: localization. Making a form localizable allows you to completely re-arrange the layout for each supported language, including size, location, text, etc. Basically any property that has been "tagged" with [Localizable] can participate in this "skinning."
Good news is that the Mobile Client Software Factory (MC-SF) from Microsoft's Patterns & Practices group makes this ideal solution a reality with the introduction of a custom user control that you can use as the base class for yours. I've been working for the past few weeks on this feature, and I think it's an absolutely revolutionary simplification of the way you will author UIs for multiple devices. In future posts I will discuss its features and implementation, but in the meantime, here are a number of screenshots that should speak for themselves.
[IMAGE]
CLICK TO ENLARGE IN SEPARATE WINDOW
In this picture you can see the new Rotate verb on the context menu of a derived control, and also the new dependent file TeamView.resources, which I'll explain in future posts and is the key to the multiple resources design. You can also see the new Orientation property in the Design category, as well as the Localizable property which is now read-only and forced to True. I already hinted that our solution leverages the localization features of .NET, and therefore relies on that property being True.
[IMAGE]
CLICK TO ENLARGE IN SEPARATE WINDOW
Here you can see that the horizontal layout for the very same control has a completely different design. The labels and textboxes are now on the right side, to take advantage of the extra space available in landscape mode, and to avoid unnecessary scrolling.
[IMAGE]
CLICK TO ENLARGE IN SEPARATE WINDOW
This is a screenshot of the emulator running the application with the orientation aware control. In a future post I will link to the download of this sample, so that you get to know the team behind the Mobile Client Software Factory . (That's what the data on the list is).
[IMAGE]
CLICK TO ENLARGE IN SEPARATE WINDOW
Finally, you can see that when the user rotates the screen, the control automatically re-applies the corresponding layout. Pretty cool, right? Stay tuned.
For more information, check out Daniel Cazzulino's blog.
