Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Design Your Mobile User Interface Code to Allow for Easy Testing and Iteration

User interface design is an iterative process. You should be prepared to revise your user interface several times during the application's development and testing process as you learn things about how the application is getting used. If your mobile application's user interface code is tightly coupled with its application logic, it will be very difficult to do this; user interface changes require laboriously searching through the application logic and finding all parts that affect the user interface. This makes behavioral changes very difficult. In highly interdependent user interface code, bugs introduced by user interface changes are difficult to track down and robustly eliminate because they are scattered rather than concentrated and well encapsulated.

It is highly beneficial to design your application logic to be decoupled from the user interface. The two should interact only through a small and well-defined set of interfaces. As Figure 13.5 shows, this can be accomplished by using two mechanisms.

Using a state machine to manage controls
A state machine is perfect for managing the user interface needs of a mobile device application. The mobile application's screen is a scarce and valuable resource and it needs to be managed effectively. It must be utilized effectively as the user navigates through the different states of your application. Having a state machine that shows, hides, and repositions controls as needed on the screen is a very effective way to do this. Having all of the user interface modes abstracted into a single state machine allows you the maximum flexibility in changing the onscreen display model without needing to search through and modify a lot of code distributed throughout the different functions and event handlers of your user interface.

Using indirect functions to update the user interface
There are two ways to go about modifying information displayed on the mobile device's screen: (1) directly and in-line (for example, Label1.Text = newText), or (2) indirectly (for example, UpdateDownloadStatusText(newText);). The advantage of the indirect approach is that it allows your code to decouple the actual control you use from the update you want to make. The indirect function UpdateDownloadStatusText(newText); might update Label1 today, but tomorrow you might decide that what we really want to do is paint this text onto a bitmap that is being displayed or show it as scrolling text on a ticker on the screen. Figure 13.5 shows an arrow coming down from the user interface to the UI Update Functions block as well as up from the application's logic. The arrow coming down from the user interface represents display update code that is run as a result of handling events generated by the user interface. For example, a common response to clicking a button may be to update the text in a label or list box. Instead of performing this update inside the button's event handler, it is far more flexible to call a generic UpdateXXXXXXX();) function to do the work. Having an intermediary function removes the tight coupling between the two controls and allows the control implementations to be switched as needed. In your mobile application's user interface design, you want to avoid tight coupling both in between the application logic and the user interface controls as well as in between the individual controls that are part of the user interface. A single level of indirection avoids tight coupling.

Not only does using state machine and indirect functions to update user interface controls enable you to easily iterate on your mobile application's presentation layer design, it also allows for much better portability of your application between device classes. A tight coupling between user interface code and application logic makes it very laborious to port an application to another form factor, which requires different user interface controls and layout. Conversely, a well-defined set of functions that manages the interactions between your application logic and the presentation layer makes it much easier to adapt your application from one device class to another. This is an important consideration if you want the flexibility of supporting new device types in the future. As discussed earlier in this chapter the concept of "write once, run anywhere" does not work particularly well for allowing a single binary application to provide a rich experience on different classes of devices, but this does not mean that you cannot design your mobile application to make portability easy. You can and you should.