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

Summary

Writing code to ensure a user interface's responsiveness will not make your application's algorithms perform faster. It will not speed your application's march to "feature complete." It may even add complexity to your mobile device application's code. The only reason to do responsiveness coding and performance tuning is to offer the end user a more comfortable experience; but isn't this the point? If you want the end user to have a high-quality impression of your mobile application, you must spend time on fit and finish issues such as responsiveness. As with other aspects of performance, this work cannot be back loaded to the tail end of your development process. At the end of your design process, you may be able to apply some Band-Aids such as showing wait cursors at points where your application's user interface stalls, but this is like putting a nice coat of paint on a house that is shoddily constructed; it is better than nothing, but it is not much. Keep responsiveness in the top of your mind and make it an exit criterion for every development milestone. The right time to fix responsiveness problems is when they are created and before they have cemented themselves into your application.

Good user interface performance comes from actively managing the end user's experience with your mobile device application. As the user navigates thorough the application's functionality, your mobile application's goal should be to ensure a responsive and anxiety-free experience. User interfaces cause complicated interactions between your application's code and the runtime libraries the application is built on top of. Controls are created and populated into forms, events are triggered, and many levels of interaction are possible between your code and that of the framework. Good performance is achieved by utilizing the performance-oriented features in the framework, by structuring the application's user interface code to keep the user a participant when long-duration tasks occur, and by aggressively measuring and instrumenting your user interface code to get a clear understanding of what goes on under the hood of your user interface.

Examine the properties and methods of the controls you use. Often there are specific features put into controls to allow for performance optimizations. Keep a close eye on the events that your application is responding to. It is specifically worth understanding and experimentally verifying when each of the events you are responding to gets triggered. Events seem simple and understandable by inspection of code, but they are an area where you, as the application developer, have given up control to the system. The operating system and user interface framework determine when your event handling code is going to run; this could occur more often than you anticipate or could occur in unexpected ways when message processing occurs by the system. Subtle interactions between events, properties, and methods of controls can arise that you may not be aware of. Extra and unneeded execution of user interface events is a source of both performance problems and complexity. Be specifically mindful of cases where events can be re-entrant.

When working with bitmaps, size does matter. Today's high-resolution digital images take up an enormous amount of space both on disk and especially in memory. Digital photographs and also desktop-generated bitmaps can provide images of a resolution far beyond what mobile devices are capable of displaying. Be acutely aware of the screen size of the devices you are working with and the size of the bitmaps you are bringing down to the devices; they should be of a similar magnitude. For images of any significant size, it is a good idea to use a compressive data format. JPEG is recommended for images that can tolerate lossy compression, and PNG files are recommend for images where exact fidelity is required. Be aware that regardless of the efficiency of the compression algorithms you are using, once a bitmap image is loaded into memory it takes up a size governed by its dimensions and not by its compressed file size.

Graphics work should be thought of separately from higher-level user interface coding and optimized in its own right. Optimizing graphics drawing code requires different techniques than tuning higher-level user interface code; it is a specialized art. Because graphics images your mobile application generates are usually indented to coexist with higher-level user interface elements, some thought must be given to how your graphics code will interface with the user interface; there are several different models for this. It is a good idea to use the highest-level of abstraction appropriate for this interaction. If you are generating static images, creating an in-memory bitmap and assigning that bitmap to the Image property of a PictureBox is a good and conceptually simple way to go. If continual updates of an image are required, consider having the application draw the image offscreen and copying frames onto the surface of a form periodically like a movie projector. Building a custom control is a good way to go if you require high user interactivity within the graphics you have drawn, such as in a graph that allows the user to visually drill into specific parts of the data drawn on it. Custom controls can also generate custom events for your application to hook into. Each of these user interface integration strategies is appropriate for a specific kind of interaction; it is important to be explicit about what the goals of graphics in your mobile application are and to choose the appropriate strategy to achieve these goals.

When working with graphics code it is important to have a systemic view of how your mobile application will accomplish its rendering. It is important not to be "penny wise and pound foolish" with resources. If there are Bitmaps, Graphics objects, Pens, Brushes, Fonts, or ImageAttributes, you will need throughout your drawing, you will need to come up with a system for creating and caching these resources. Prebuilt bitmaps can take up valuable memory but they are extremely useful in speeding up drawing; using them judiciously will result in a rich and well-performing application. Take care not to have two identical resources loaded at the same time, this is just wasteful. Think also about whether your application can be separated into different states, which states need which graphical resources, and when cached resources should be disposed of because they are not needed in the near term.

Rich graphical experiences are possible on mobile devices and can add a great deal to the overall experience users have with your mobile application. It is important to think creatively, analytically, and systematically when building your graphical experience. The creativity of an artist to see what is possible, the problem-solving analytics of an engineer, and the shrewd eye for wasteful practices of an accountant are required to build a great-performing and rich graphical experience. Working with graphics on mobile devices can be challenging and fun; make sure you keep a close eye on performance, and then the sky is the limit!