may01_ericg.txt

TechTips j2me的常用技巧. 网络功能

destination."

The problem with calling setCurrent as soon as the second alert 
triggers, is that the new alert immediately replaces the previous 
alert. Sometimes this is desirable, but in most cases, you want 
the user to read each alert in the order that they occurred. An 
alternative approach is to try chaining the alerts, for example:

Display     display = ...;
Alert       alert = ...;
Displayable next = ...;
Displayable current = display.getCurrent();

if( current instanceof Alert ){
    display.setCurrent( (Alert)current, alert );
} else {
    display.setCurrent( alert, next );
}

This doesn't work, however, because only one alert can be active 
at any time. The final destination, that is, the destination of 
the last alert, is also lost with this scheme.

What you really need is a way to keep a list of pending alerts 
and display each alert in turn. This would be simple to do if the 
alert had a dismissal event you could trap. Unfortunately, 
there's no direct way to know when an alert is dismissed.

There is an indirect route you can take, however. A Canvas object 
calls its showNotify and hideNotify methods whenever it is shown 
or hidden. These calls are normally used to start and stop 
screen-related operations that only make sense when the canvas
is visible. For example:

public class MyCanvas extends Canvas {
    protected void paint( Graphics g ){
        // do the painting here
    }

    protected void showNotify(){
        // canvas is being displayed, start
        // any timers, etc.
    }

    protected void hideNotify(){
        // canvas is being hidden, stop any
        // timers, etc.
    }
}

You can take advantage of this capability to solve the alert 
dilemma. Whenever you display an alert, make a Canvas object the 
alert destination. When the alert times out or is dismissed, the 
canvas is displayed. You then place logic in the canvas's 
showNotify method to display either a pending alert or another 
screen. The canvas doesn't even have to paint itself because it 
will only be briefly displayed.

Armed with the overall design, you can now build the Canvas 
subclass; let's call it AlertRouter. Here is the source code for 
AlertRouter:

package com.j2medeveloper.util;

import java.util.*;
import javax.microedition.lcdui.*;

public class AlertRouter extends Canvas {

    private Display     display;
    private Vector      pending = new Vector();
    private Displayable destination;
    private Alert       current;

    public AlertRouter( Display display ){
        this.display = display;
    }

    protected void paint( Graphics g ){
       // no painting
    }

    protected synchronized void showNotify() {
        if( pending.size() > 0 ){
            current = (Alert) pending.elementAt( 0 );
            pending.removeElementAt( 0 );
            display.setCurrent( current, this );
        } else {
            current = null;
            display.setCurrent( destination );
        }
    }

    public void showAlert( Alert alert ) {
        showAlert( alert, null );
    }

    public synchronized void showAlert( Alert alert, 
                                              Displayable next ){
        if( next != null ){
            destination = next;
        } else if( destination == null ){
            destination = display.getCurrent();
            if( destination == null ){
                destination = this;
            }
        }

        pending.addElement( alert );

        if( current == null ){
            display.setCurrent( this );
        }
    }
}

To display alerts, create an instance of AlertRouter when the 
MIDlet starts. You'll need to pass the MIDlet's Display 
object to the AlertRouter instance. Then whenever you need to 
display an alert, call the alert router's showAlert method. 
Here's a simple example:

import com.j2medeveloper.util.*;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class MyMIDlet extends MIDlet {

    private Display     display;
    private AlertRouter router;

    public MyMIDlet(){
        display = Display.getDisplay( this );
        router = new AlertRouter( display );
    }

    protected void startApp(){
        Alert alert = new Alert( "Started", "App started", null, 
                                                          null );
        router.showAlert( alert );
    }

    // other methods omitted....
}

Whenever showAlert is called, the given alert is added to a list 
of pending alerts. The first alert in the list is displayed if no 
alert is showing. Otherwise, each alert waits its turn. The final 
alert destination is the screen that was active just before the 
first alert in the alert chain was shown. A two-argument version
of showAlert lets you override that value with your own 
destination. The most recent call to showAlert determines the 
ultimate destination of the alert chain, which is normally what 
you want.

Here's a more complicated MIDlet that tests the alert router by 
using several timers to create alerts at different time 
intervals:

import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import java.util.*;
import com.j2medeveloper.util.*;

public class MultiAlert extends MIDlet {

    Display      display;
    Command      exitCommand = new Command( "Exit", Command.EXIT,
                                                             1 );
    Timer        timer1 = new Timer();
    Timer        timer2 = new Timer();
    Timer        timer3 = new Timer();
    MainForm     form = new MainForm();
    AlertRouter  router;

    public MultiAlert() {
        display = Display.getDisplay( this );
        router = new AlertRouter( display );

        timer1.schedule( new AlertTrigger( "Alert 1", 
                             "This is alert #1" ), 5000, 10000 );
        timer2.schedule( new AlertTrigger( "Alert 2", 
                              "This is alert #2" ), 5000, 7000 );
        timer3.schedule( new AlertTrigger( "Alert 3", 
                              "This is alert #3" ), 5000, 9000 );
    }

    protected void destroyApp( boolean unconditional ) {
        timer1.cancel();
        timer2.cancel();
        timer3.cancel();
    }

    protected void startApp() {
        display.setCurrent( form );
    }

    protected void pauseApp() {
    }

    public void exit(){
        destroyApp( true );
        notifyDestroyed();
    }
 
    class AlertTrigger extends TimerTask {

        public AlertTrigger( String title, String message )
        {
            this.title = title;
            this.message = message;
        }

          public void run(){
            Alert alert = new Alert( title, message, null, null );
            alert.setTimeout( Alert.FOREVER );
            router.showAlert( alert );
       }

        private String title;
        private String message;
    }

    class MainForm extends Form implements CommandListener {
        public MainForm(){
            super( "MultiAlert Demo" );
            addCommand( exitCommand );
            setCommandListener( this );
        }

        public void commandAction( Command c, Displayable d ){
            exit();
        }
    }
}

Run this MIDlet and wait a few seconds for the first alert to 
appear, then wait a few more seconds before dismissing it.  
You'll see another alert appear immediately after the first.  
Dismiss this second alert and any other alerts. Eventually, 
you will be brought back to the main screen, where the whole 
process starts again.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

- NOTE

Sun respects your online time and privacy. The Java Developer 
Connection mailing lists are used for internal Sun 
Microsystems(tm) purposes only. You have received this email 
because you elected to subscribe. To unsubscribe, go to the 
Subscriptions page (http://developer.java.sun.com/subscription/), 
uncheck the appropriate checkbox, and click the Update button.

As of May  22, 2001, Sun Microsystems updated its Privacy Policy 
(http://sun.com/privacy) to give you a better understanding of 
Sun's Privacy Policy and Practice. If you have any questions, 
contact [e-mail].

- SUBSCRIBE

To subscribe to a JDC newsletter mailing list, go to the 
Subscriptions page (http://developer.java.sun.com/subscription/), 
choose the newsletters you want to subscribe to, and click Update.


- FEEDBACK
Comments? Send your feedback on the J2ME Tech Tips to:

[e-mail]


- ARCHIVES
You'll find the J2ME Tech Tips archives at:

http://java.sun.com/jdc/J2METechTips/index.html

- COPYRIGHT
Copyright 2001 Sun Microsystems, Inc. All rights reserved.
901 San Antonio Road, Palo Alto, California 94303 USA.

This document is protected by copyright. For more information, 
see:

http://java.sun.com/jdc/copyright.html


- LINKS TO NON-SUN SITES
The J2ME Tech Tips may provide, or third parties may provide, 
links to other Internet sites or resources. Because Sun has no 
control over such sites and resources, You acknowledge and 
agree that Sun is not responsible for the availability of such 
external sites or resources, and does not endorse and is not 
responsible or liable for any Content, advertising, products, 
or other materials on or available from such sites or resources. 
Sun will not be responsible or liable, directly or indirectly, 
for any damage or loss caused or alleged to be caused by or in 
connection with use of or reliance on any such Content, goods or 
services available on or through any such site or resource.

J2ME Tech Tips 
May 29, 2001

Sun, Sun Microsystems, Java, Java Developer Connection, J2ME,
J2SE, and PersonalJava are trademarks or registered trademarks 
of Sun Microsystems, Inc. in the United States and other 
countries.

* As used in this document, the terms "Java virtual machine" 
  or "JVM" mean a virtual machine for the Java platform.