Browse DevX
Sign up for e-mail newsletters from DevX


Master Networking in J2ME for Well-connected Mobile Apps : Page 2

J2ME supports a Generic Connection Framework that provides a variety of standard network connectivity options. Find out how to take advantage of J2ME networking in your applications.

J2ME Configurations
Currently, there are two J2ME configurations that support networking: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The CLDC is designed for more limited devices that require a smaller API footprint. MIDP is based on the CLDC. The CDC is designed for devices with more power and API footprint but are still too small to support standard Java. The Personal Profile is based on the CDC.

In order to enhance the upward compatibility of J2ME applications from the CLDC range of devices to the CDC range of devices, the CLDC and CDC have a strict superset-subset relationship. Figure 2 shows the relationship between the CLDC, CDC, and J2SE. Note that the CLDC and CDC contain APIs that are unique to J2ME and not part of standard Java. Libraries that are unique to J2ME exist in the javax.microedition.* packages.

Figure 2. Concentric Circles. The CDC and CLDC have a strict subset-superset relationship. Note also that J2ME configurations contain APIs that extend beyond what standard Java (J2SE) provides.
Configurations and Connectivity
The GCF is implemented in the CLDC, thereby making it available to any J2ME application since, by definition, the CDC must include everything defined by the CDLC. This has the effect of standardizing network connectivity throughout the J2ME environment, regardless of the profile or the device—a big advantage for J2ME developers.

Creating Network Connections using the GCF
Before discussing the architecture any further, I want to look at some code. At the heart of the GCF is the Connector class and a set of interfaces that are defined in the javax.microedition.io package. The Connector class is a factory that creates connection instances. The interfaces define the types of connections supported. How the implementer actually provides the network connectivity is not of concern, to either the GCF or the application developer, as long as the connection returned supports the behaviors defined by the GCF interface. An example of an HTTP connection is shown below.

HttpConnection c = (HttpConnection)
  Connector.READ_WRITE, true);
The Connector class figures out what type of connection to create by parsing the connection string ("http://www.gearworks.com" in this case). The connection string is composed of three parts: the scheme, target, and parameters. The scheme is required but the latter two are optional. All connection strings follow the pattern noted below.

{scheme}: [{target}] [{parameters}]
In the HTTP example the scheme is "http" and the target is "www.gearworks.com." There are no parameters.

Although the connection string looks a lot like a URL, it can be used to create many different types of connections, not just HTTP connections. Table 1 shows examples of different types of connections that may be created using the GCF. Note however, the actual support for a specific connection is subject to the J2ME profile requirements and what a vendor chooses to implement. If the connection is not supported by the J2ME implementation a ConnectionNotFoundException is thrown.

HTTP http://www.host.com: 8080
Socket socket://host.com:80
Socket Listener socket://:1234
Datagram Sender datagram://host.com:9001
Datagram Listener datagram://: 9001
File file:/myfile.txt
Comm Port comm:com0;baudrate=19200;parity=odd

Table 1. Examples of different types of connections that may be created using the GCF. Support for the actual connection type, however, is implementation dependent.

Thanks for your registration, follow us on our social networks to keep up-to-date