| Multitasking Guide |    
|
| Multitasking Guide |
|
| C H A P T E R 4 |
|
Other Multitasking Issues |
Multitasking raises some issues related to the behavior of the Java Wireless Client software. This chapter describes the issues, how they are handled by the Java Wireless Client software, and possible alternatives.
Most of the issues discussed in this chapter relate to the implementation of the Java platform AMS. The same issues must be addressed by the Native AMS.
In a system that cannot run concurrent MIDlets, each MIDlet effectively runs alone and it potentially has access to all the resources available on the system. The entire runtime environment is shut down when the MIDlet exits. Multitasking environments work differently.
With multitasking, a MIDlet is not alone on the system. The MIDlet runs in its own environment (its task), but at most one MIDlet can have access to the device's display and to the device's input mechanisms, such as keypad and pointer events. No MIDlets have access to the device's display and input mechanisms if the user is interacting with a native application. Managing which MIDlet has access to the device display and input mechanisms necessitated the introduction of the foreground and background states:
The Java Wireless Client software supplies a default policy for how a MIDlet gains the foreground. It enables the user to switch to an application list screen at any time by pressing a hot key. By default, the hot key is the Home key found on many platforms. The application list screen shows a list of all running MIDlets. When the user brings up the application list, the MIDlet that had been in the foreground is moved into the background. The user scrolls through the application list and chooses the MIDlet to bring to the foreground.
Native code can request the application list to be shown by sending a SELECT_FOREGROUND_EVENT into the system. See the code in the file win32app_export.c for an example of how this event is generated in response to the pressing of the Home key. Use the same technique of sending a SELECT_FOREGROUND_EVENT to show the application list in response to some other external event.
Policies for switching foreground applications are highly dependent on a device's existing user interface. If your device already enables a user to switch between native applications in a particular way, use the same or similar policies for the Java Wireless Client software. Users expect consumer products, such as small devices, to be predictable, easy to learn, and easy to use. Making the policies of your Java Wireless Client software as similar as possible to the native policies users already know and use speeds acceptance of the new functionality. See the MIDP 2.0 Style Guide (Addison-Wesley, 2003) for more information.
The CPU is a shared resource that requires separate policy decisions. The foreground application has exclusive access to the display and the input mechanisms, but you can have a policy that enables it to share the CPU with the background applications. Your policy depends at least in part on the capabilities of your device.
By default, the Java Wireless Client software permits background applications to have some CPU time. A background application can also interrupt the foreground application under some circumstances.
Specifically, the CPU scheduling policy is fair share, which gives a higher proportion of the CPU to the foreground application. Background applications can still run, but their threads are scheduled less frequently.
This policy is implemented in the setForegroundMIDlet() method of the MIDletProxyList class. The MIDlet being put into the background is given minimal priority by calling the minPriority() method. The MIDlet being brought into the foreground is given normal priority by calling the normalPriority() method.
One alternative to giving limited CPU access to background applications is to give the CPU exclusively to the foreground application. This might provide better interactive performance on systems with slow CPUs. It can also be good for some applications, such as a game that displays graphics continually and requires constant user input. This type of application probably needs to be frozen when in background. The user loses the game if the game is placed into the background and still allowed to use the CPU.
On the other hand, a device that freezes background MIDlets cannot run service or daemon applications that do not interact with the user at all. An example of such an application is a MIDlet that listens on the network for information about critical system software updates.
Another alternative to the default fair-use policy is an open-for-competition policy, that gives all applications equal priority, whether they are in the foreground or background.
To implement an open-for-competition policy for the CPU, modify the contents of the minPriority() and normalPriority() methods of the MIDletProxyUtils class so that they do nothing, instead of changing the tasks' priorities or suspending or resuming them.
As you consider CPU policies, keep in mind that they interact with other policies for background MIDlets. For example, the policy interacts with your decisions on whether a background application is informed of its state change through a call to the pauseApp method, or whether it has access to shared resources such as sound. A uniform, correct answer does not exist.
Although a good user interface permits a user to interrupt applications at any time, it does not do the same to the user. Instead, it interrupts the user only when necessary. Unnecessary feedback, confirmation messages, and error messages that require a user response are distracting. See the MIDP 2.0 Style Guide (Addison-Wesley, 2003) for more information.
The default policies of the Java Wireless Client software interrupt the user only when necessary. For example, the system does not allow a background application to interrupt the user and regain the foreground of its own accord. If a background application requests the display by trying to set the current screen with a screen other than an alert, the foreground application is not affected. If a background application requests the display by trying to set the current screen to an alert, the foreground application remains in place, but an icon is placed on the status bar to let the user know that a background application needs attention.
The system does not interrupt the user for notification of most failures. For example, if a MIDlet fails because of an internal problem, such as receiving an out-of-memory error, the applications task exits, but the other application tasks are unaffected. The system does not interrupt the user with a notification that the application has exited. It simply removes the failed application from its list of running applications.
The Push system of the Java Wireless Client software, too, only interrupts the user when a pushed message arrives for an application that is neither running, nor allowed to be automatically started. If the application's user preferences require the user to give permission to start an application in response to the arrival of a pushed message or the firing of a Push alarm, then the Push system asks the user for permission. The user can also set the applications user preferences to permit the system to automatically start the application in response to the Push system. In this case, the Push system does not ask the user for permission.
| Multitasking Guide | 05-2007 |
|
Copyright © 2007, Sun Microsystems, Inc. All rights reserved. SUN PROPRIETARY/CONFIDENTIAL.