.KEYWORD autopc
.FLYINGHEAD AUTO PC DEVELOPERS CORNER
.TITLE Understanding the Auto PC’s Running Application Model
.OTHER
.SUMMARY The Auto PC, like a Palm-sized PC or Palm device, can be characterized as a cross between a computer and a consumer appliance. If you’re interested in developing software to run on the ever-so-cool Auto PC, and you want to create a rich, expandable feature set without burdening the user with the need to know how things work internally, this incredibly helpful article is a must-read for you!
.AUTHOR Mark Moeller
Have you noticed that the applications running on the Auto PC don’t have any sort of Exit command? If you haven’t noticed, then don’t waste your time looking for one because an Exit command simply doesn’t exist in your Auto PC’s applications. The reason for this is that the Auto PC software is written using a new launch/exit paradigm called the Running Application Model. This model is one of the least understood issues for Auto PC software engineers, so I want to shed some light on the issue.
.H1 The consumer experience vs. the PC experience
When was the last time you had to use an Exit command on a car stereo to stop the CD player? The answer is probably "never". Consumer appliances, such as car stereos, are designed to allow the user to simply switch from feature to feature without giving a thought as to what’s happening inside the product to make the switch happen. The consumer can store presets, CD titles, etc., without concern as to how the function happens. It’s the duty of the appliance to handle internal housekeeping and to do whatever else is necessary to make the features of the product work.
On the other hand, consider some of the major elements a personal computer user must know about. The user must know that the personal computer has memory, what it is and how much it has. They must know that it has a mass storage device, what it is and how much storage it has. They must be responsible for saving their work to the mass storage device so they can retrieve it later. The user must also know how the mass storage is structured or organized, because it’s the user’s responsibility to choose an appropriate location for storing information. When the user runs out of memory or mass storage, they must know how to take corrective action to remedy the problem. It doesn’t take much observation to see the stark contrast between the consumer appliance experience and the PC experience.
.H1 The quest for the consumer appliance PC experience
The Auto PC, like a Palm-sized PC or Palm device, can be characterized as a cross between a computer and a consumer appliance. The objective is to give the rich, expandable feature set of a PC, while at the same time not burdening the user with the need to know how the device performs its features internally. Achieving the consumer experience requires removing the responsibility for managing the systems resources from the user. The illustration I gave regarding the PC experience can be boiled down to the simple fact that the PC makes the user responsible for resource management.
Consumer appliances typically do not burden the user with much of this. Yes, a consumer must know things like how much video tape is left before recording a program with their VCR, but it doesn’t go much beyond that. Obviously, the PC experience has been maturing over the last 20+ years. Computers are much easier to use than they were even five years ago. However, with all the advancement in programming practices, increased memory, storage, and CPU power, the user is still left to manage the system resources. Leaders in the PC industry,such as Microsoft, have come to realize that it is time to fold this responsibility into the software. The Auto PC is one of the first products that attempts to take responsibility for its resource management. A cornerstone of that effort is the Running Application Model.
.H1 Guidelines for implementing the Running Application Model
On any computer, a running application knows when the user is interacting with it. The Running Application Model requires each application to take that knowledge and make use of it in managing its resource usage. For instance, if the application is not in the foreground (i.e., it doesn’t currently own the display, keypad, Speech Recognition), then it should free up as many resources as it can until the user needs it again. For some applications, this can mean simply exiting when the user switches away and restarting when the user switches back. For others, this might mean freeing up memory used for caching information and providing fast user feedback when the application is in the foreground. Still, others might not be able to free up any memory but can drastically reduce their CPU usage. The following guidelines can be used to help an Auto PC software developer make his or her software a good citizen by participating in the Running Application Model.
.H2 Exit strategy
Generally speaking, applications should always try to exit when the user switches away from them, either immediately or after some period of idle time, if at all possible. Obviously, applications that do background processing like the CD Player or Navigation can’t do this until they are no longer doing their background processing.
.H2 Implement Fast App Start
When an application is launched on the Auto PC, it has about 1.5 seconds to call RegisterStartedApplication before it gets put on the Auto PC’s suspicious behavior list. After 20 seconds, if the application has not registered, the Auto PC will terminate the application. The goal here is that all applications give the user either a visual or auditory response before 1.5 seconds expires. This can mean that your main application initialization doesn’t happen for some time after the 1.5 seconds, but getting the splash screen up is important. Fast application startup is especially important if your application exits each time a user switches away from it.
.H2 Fully implement WM_CLOSE support
When your main application message loop gets a WM_CLOSE message, it’s from the Auto PC requesting that your application save its state and shut down immediately. If your application is requested to close but cannot because it’s busy, at least have it go into some form of WM_HIBERNATE until the application is activated again. It’s important to keep in mind that an application that chooses not to close down or does not close down in three seconds may simply be terminated by the Auto PC. This forced termination usually happens when the user is installing an upgrade to your application.
.H2 Fully implement WM_HIBERNATE support
The WM__HIBERNATE message is sent to your application when system resources are running low. Wparam and Lparam will be equal to 0. Your application should attempt to release as many resources as possible upon receiving this message by unloading forms, deleting drawing objects, or freeing up as much memory as possible without killing the internal state. If wParam equals 1, then the application has been in the background for more than ten minutes with the system in the power on state. Your application should exit if no longer in use.
.H2 State saving and restoration
Design your applications so they are able to save their state at most any time and exit. When they start they should restore their state quickly. This will be instrumental in implementing WM_CLOSE and WM_HIBERNATE.
.H2 Memory allocation
When possible, allocate all the memory and storage you will need entirely up front. If that isn’t reasonable, try allocating it in large chunks rather than each time a user operation needs a little more memory. The idea behind this is to avoid getting into a situation where your application can’t save the user’s data because storage is gone, or the user can’t proceed with some operation because there isn’t enough memory. This usually means not giving the user the ability to create an unlimited number of data items, but restricting them to a fixed count. An example is limiting radio station presets to 20 versus an unlimited amount, or available contacts to 500 versus an unlimited amount. This will also simplify your code because you don’t need to deal with as many resource allocation failure errors. Again, this protects the user from having to know about resource management.
.H2 Time measurement
Use GetIdleTime and GetTickCount to measure how much free time the CPU has before beginning an intensive operation. You can use these two values to determine what the processor load is by dividing the delta of two GetIdleTime values taken at a period of some fixed number of milliseconds, measured by using GetTickCount. The delta divided by that period is the percent utilization. Your application can use this information during runtime to determine how CPU intensive of an algorithm it might be able to use at any given period. For instance, if your application is displaying animation along with MP3 playback, maybe it reduces the animation frame rate when the CPU is relatively saturated.
.H2 Avoid the background blues
Avoid using tight polling loops, elevated priorities, or any unnecessary computing, such as painting, when your application is in the background. Remember, you are sharing the computing power, so do everything within reason to reduce the load your program places on the CPU, memory and storage.
.BEGIN_KEEP
.H1 Conclusion
By implementing the Running Application Model, your application will have taken a major step toward being fully compliant with the Auto PC programming model. This will help give the end user a more consumer-oriented experience. Your application will work more cooperatively with the other applications and, thus, the system as a whole will perform better for the user. It’s a real shift in thinking for many programmers to start hiding the complexities of resource management issues from the end user. With today’s powerful processors, abundant memory, and advanced programming methods, it’s time application developers start shielding the user from this sort of burden. The Auto PC provides an ideal environment to flex your programming muscle and provide software that delivers a consumer level experience.
Do you have questions or comments? Please email me at markmo@autopcware.com.
.BIO
.END_KEEP
