feb01_ericg.txt

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

 J 2 M E    T  E  C  H    T  I  P  S

                      TIPS, TECHNIQUES, AND SAMPLE CODE


WELCOME to the Java Developer Connection(sm) (JDC)
Java(tm) 2 Platform, Micro Edition (J2ME(tm)) 
Tech Tips, for February 20, 2001. This issue covers:

         * Making Connections With the CLDC
         * Record Management System Basics
         
The J2ME Tech Tips are written by Eric Giguere
(http://www.ericgiguere.com), an engineer at iAnywhere 
Solutions, inc, and author of the book "Java 2 Micro
Edition: Professional Developer's Guide."

You can view this issue of the J2ME Tech Tips on the Web at
http://java.sun.com/jdc/J2METechTips/2001/tt0220.html

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
MAKING CONNECTIONS WITH THE CLDC

As you can tell from its name, the Connected Limited Device 
Configuration (CLDC) is designed for connected devices.  
A connected device has the ability to connect to the outside 
world, whether the connection is serial, infrared, wireless, 
or something else entirely. How then do you take advantage of
this connectivity in your Java(tm) applications?  The answer 
is: through a set of classes called the Generic Connection 
framework, or GCF for short.

The GCF consists of a single factory class, an exception class, 
and eight interfaces, all part of the javax.microedition.io 
package. The interfaces model six different types of 
connections, ranging from simple one-way connections to stream 
and datagram connections. These abstractions are central to the 
GCF, and are very similar to the way in which the JDBC abstracts 
access to a database.

To obtain any kind of connection -- HTTP, socket, infrared, 
serial -- you use the static methods of the Connector class. 
For example, you call one of the open methods, which takes a URI 
(uniform resource indicator -- a more general form of URL)
and returns a Connection, the base interface for all six 
connection types. Here is how to open an HTTP connection:

import javax.microedition.io.*;

ContentConnection conn = 
   (ContentConnection) Connector.open( "http://www.yahoo.com" );

Opening a read-only file requires a slightly different syntax:

import javax.microedition.io.*;

InputConnection conn = 
    (InputConnection) Connector.open( "file:/autoexec.bat",
                                      Connector.READ );

There is also a third form of the open method that indicates 
whether or not the connection should throw exceptions on 
timeouts. 

If all you're interested in is an input or output stream, you 
can also use the convenience methods openInputStream, 
openDataInputStream, openOutputStream and openDataOutputStream.

The URI you use to obtain a connection is of the general form

    <protocol>:<address>;<parameters>
    
where protocol specifies how to connect, address specifies
what to connect to, and parameters are connection
parameters. While the protocol is a simple string like
"http", "mailto", or "ftp", the syntax of the rest of the
URI depends on the protocol being used. The Connector class 
uses the protocol part of the URI to dynamically find and load 
a class that parses the URI, makes the actual connection, and 
returns the appropriate Connection object.

It's important to note that the CLDC only defines the classes 
and interfaces that make up the GCF -- it doesn't require an 
implementation to support any particular protocol. Profiles 
that are built on top of the CLDC define which protocols an 
implementation must support. For example, the Mobile Information
Device Profile (MIDP), requires support for the HTTP protocol.  
Implementations are free to add support for other protocols if 
they want, however, as long as they fit within the framework.  
Sun's reference implementation of the CLDC includes support for 
a number of protocols, including "datagram", "socket", and 
"file", but they are all meant to be examples for CLDC 
implementors. For an application to be portable, it must use 
only the protocols defined by the profile, or else restrict 
itself to running on a specific J2ME implementation.

The six connection types supported by the GCF are defined by 
the six extensions of the Connection interface. The Connection
interface itself is very simple: it defines a single close method.  

The InputConnection interface is used for raw input streams, 
such as those to read from a socket or a file. The interface 
adds two methods to the basic Connection, one for opening a raw 
InputStream and another for opening a DataInputStream. Here is 
a simple example:

import java.io.*;
import javax.microedition.io.*;

public class TestInput {

    public static void main( String args[] ) {
        try {
            String uri = "file:c:/autoexec.bat";
            InputConnection conn = (InputConnection) 
                     Connector.open( uri, Connector.READ );
            InputStream in = conn.openInputStream();
            int ch;
   
            conn.close(); // doesn't close input stream!
   
            System.out.println( "Contents of [" + uri + "]" );
   
            while( ( ch = in.read() ) != -1 ){
                System.out.print( (char) ch );
            }
   
            in.close();
        }
        catch( ConnectionNotFoundException e ){
            System.out.println( "File could not be found!" );
        }
        catch( IOException e ){
        System.out.println( e.toString() );
        }

        System.exit( 0 );
    }
}

You should run this example using the CLDC reference 
implementation on your desktop computer because it assumes 
the existence of the "file" protocol. As mentioned earlier
in this tip, the reference implementation supports this 
protocol, but in general, CLDC does not require an 
implementation to support any particular connection protocol. 
Also note that the URI format shown, "file:drive:path" is 
specific to the Windows platform. Unix/Linux users should use 
a URI of the form "file:path", as in "file:/usr/lib/foo.txt".

Notice that the program can safely close the connection after 
it obtains the input stream. In fact, you need to close all 
streams obtained from before the Connection enters the closed 
state.

One other note about the program: if it were a MIDlet (that is,
an MIDP application), it could not use a System.exit call to 
terminate. A MIDlet indicates that it is complete by calling 
MIDlet.notify.Destroyed.

Of course, the opposite of InputConnection is OutputConnection, 
which you can use to write to a stream:

import java.io.*;
import javax.microedition.io.*;

public class TestOutput {

    public static void main( String[] args ){
        try {
            String uri = "file:c:/hah.txt;append=true";
            OutputConnection conn = (OutputConnection)
                     Connector.open( uri, Connector.WRITE );
            OutputStream out = conn.openOutputStream();
            PrintStream print = new PrintStream( out );
   
            conn.close(); // doesn't close output stream!
 
            print.println( "Hah hah hah!" );
  
            out.close();
        }
        catch( ConnectionNotFoundException e ){
            System.out.println( "File could not be created!" );
        }
        catch( IOException e ){
            System.out.println( e.toString() );
        }
 
        System.exit( 0 );
    }
}

Again, run this example with the CLDC reference implementation.
Remove the ";append=true" parameter from the URI to reset the
file to empty before the writing starts. 

What if a particular protocol, such as the "socket" protocol,
supports both input and output streams? In this case, use the 
StreamConnection interface, which extends both InputConnection 
and OutputConnection. Here's an example:

import java.io.*;
import javax.microedition.io.*;

public class TestInputOutput {

    public static void main( String[] args ){
        try {
            String uri = "socket://www.ericgiguere.com:80";
            StreamConnection conn = (StreamConnection)
                     Connector.open( uri );
     
            // Send HTTP request...

            PrintStream out = new PrintStream( 
                                conn.openOutputStream() );
            out.println( "GET /index.html HTTP/0.9\r\n" );
            out.flush();
   
            // Get raw HTTP reply...

            InputStream in = conn.openInputStream();
            int ch;

            while( ( ch = in.read() ) != -1 ){
                System.out.print( (char) ch );
            }

            in.close();
            out.close();
            conn.close();
        }
        catch( ConnectionNotFoundException e ){
            System.out.println( "Socket could not be opened" );
        }
        catch( IOException e ){
            System.out.println( e.toString() );
        }

        System.exit( 0 );
    }
}

The TestInputOutput example opens a socket connection to a web 
server and sends an HTTP GET request. It then waits for the 
server to respond. A simpler way to do this is to use the
ContentConnection interface and the "testhttp" protocol. That 
protocol is a simple (and incomplete) implementation of the HTTP 
protocol. Here's an example of the ContentConnection and 
testhttp approach;

import java.io.*;
import javax.microedition.io.*;

public class TestHTTP {

    public static void main( String[] args ){
        try {
            String uri = 
                   "testhttp://www.ericgiguere.com/index.html";
            ContentConnection conn = (ContentConnection)
                     Connector.open( uri );

            InputStream in = conn.openInputStream();
            int ch;
   
            System.out.println( "Content type is " 
                                            + conn.getType() );

            while( ( ch = in.read() ) != -1 ){
                System.out.print( (char) ch );
            }

            in.close();
            conn.close();
        }
        catch( ConnectionNotFoundException e ){
            System.out.println( "URI could not be opened" );
        }
        catch( IOException e ){
            System.out.println( e.toString() );
        }

        System.exit( 0 );
    }
}

The ContentConnection interface extends StreamConnection and adds 
three new methods for accessing some of the basic HTTP response 
data: getType, getEncoding and getLength. By itself, 
ContentConnection isn't particularly useful. The Mobile 
Information Device Profile (MIDP), for example, subclasses 
ContentConnection to define a new connection interface called 
HttpConnection that includes full support for the HTTP protocol. 
This is covered in the December 18, 2000 J2ME Tech Tip "Making 
HTTP Connections with MIDP."

The final two Connection interfaces are very specialized and
only worth a brief mention. The StreamConnectionNotifier
interface is for writing server applications and has a single
method called acceptAndOpen. An application calls this method
to wait for a client to connect to it. The method then returns 
a StreamConnection that can be used to communicate with the 
client. The CLDC reference implementation supports the 
"serversocket" protocol for opening server sockets using this 
mechanism. There is also a DatagramConnection interface for 
sending and receiving datagrams, using the related Datagram 
interface to pack and unpack the data. A DatagramConnection is 
modeled after the java.net.DatagramSocket class in the J2SE(tm)
platform.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
RECORD MANAGEMENT SYSTEM BASICS

The Mobile Information Device Profile (MIDP) defines a set of 
classes for storing and retrieving data. These classes are
called the Record Management System (RMS). With the RMS, it's
possible to make data persist across invocations of a MIDlet
(an MIDP application). Different MIDlets in the same MIDlet 
suite can also use the RMS to share data. (A MIDlet suite is 
a set of MIDlets packaged together into a single JAR file.)

The basic storage mechanism used by the RMS is referred to as 
a record store. A record store is a collection of records, and 
a record is basically a byte array of arbitrary data. The size 
of the byte array can vary for each record. The RMS doesn't 
understand the contents of a record and doesn't place any 
restrictions on what goes into the record. The RMS does do some 
rudimentary bookkeeping, however, such as assigning each record 
a unique identifier that is valid for the lifetime of the record 
store.

A record store is represented by a 
javax.microedition.rms.RecordStore object. The only way to obtain 
a RecordStore object is to use the openRecordStore method, as in:

import javax.microedition.rms.*;

RecordStore rs = null;

try {
    rs = RecordStore.openRecordStore( "mydata", false );
}
catch( RecordStoreNotFoundException e ){
    // doesn't exist