Unlike desktop machines which all have large screens and pointer mechanisms, mobile devices come in a wide range of shapes and sizes and have a variety of input mechanisms. As much as possible, we would like to write applications that run well on any kind of mobile device. Note that there is a big difference between just running on a device and running well. Usability is a vital concern for mobile devices where environments vary and expectations for ease of use are very high.
eSWT and Mobile Extensions attempt to normalize devices so that the application programmer does not have to do a lot of work to handle the differences among devices. It does this in two ways: implicitly, by providing a device's native look and feel that a user is familiar with, and explicitly, by providing mechanisms that abstract input and output through the actual device hardware.
Implicit normalization automatically provides some level of device adaptation by giving applications indirect access to a device's native widgets. Since eSWT widgets are implemented using a platform's native widgets, eSWT widgets appear and behave similarly to widgets in native applications. The end-user can recognize and interact with these widgets as they are used to do. The programmer gains these benefits simply by using eSWT widgets.
Explicit normalization is provided via specific mechanisms that a programmer is encouraged to use. These generally fall into two categories: organizing output on a display and handling different input mechanisms.
- Use of flow based layouts is strongly encouraged. Layouts like RowLayout and GridLayout position widgets independently of screen size.
- Use of absolute coordinates is highly discouraged. Display sizes and aspect ratios can vary considerably. To guarantee that widgets are fully displayed, the programmer would have to calculate proper coordinates for each different display size.
Even though layouts help considerably in adapting to different screen sizes, a program that is desired to run well on all devices should also perform the following:
- Check if the computed layout is larger than the available screen size, and if so add scroll bars to allow scrolling the content.
- Check for high aspect ratios which may restrict layout or allow for additional content. For example on a mobile device with a long, narrow landscape display, content may be better displayed in two columns or in side by side panes.
- Use of the Mobile Extensions Command feature is highly encouraged. Commands are an abstraction that the Mobile Extensions library maps to a specific mechanism depending upon the device capabilities. This will usually be pointer driven menus or soft keys.
- Use of buttons is discouraged. Many devices do not have pointer devices. Therefore, buttons on these devices must be navigated to using jog controls or arrow keys and then selected. Jogging through numerous widgets is more time consuming and may also be cumbersome depending on the device controls. If buttons are highly desired, then the application can check via the MobileDevice class to see if the screen is a touch screen. This allows use of buttons when they can be easily selected and use of Commands or some other mechanism otherwise.
- Use of menus is discouraged. Of minor consideration is that the width of the menu bar may be may be quite limited on some devices. It is difficult for your application to determine how many top level menu items can be supported. Menus may also be somewhat difficult to navigate on non pointer devices. However, a more important reason not to use menus is that you may be bypassing the device's most natural or efficient input mechanism.
Understanding platform constraints
- On Windows Mobile Professional devices, JSR 179 (Location API) is provided in the Java Runtime Environment (JRE).
Parent topic: Application design considerations: XPD622