Mobile Information Device 2.0 (JSR-118) specification includes
support for the Generic Connection Framework (GCF), defined
in the javax.microedition.io
package of the Connected
Limited Device Configuration (CLDC) 1.0 specification. This package
allows you to use networking and push registry functions.
These networking functions include support for HTTP and HTTPS connections, as well as support for User Datagram Protocol (UDP), straight TCP, serial port, and Secure Socket Communication. In addition to those, with the support for push registry MIDlets can receive incoming communication requests and register for network connection events. UDP is only supported in Symbian.
The javax.microedition.io
package only provides very basic networking possibilities. However,
APIs such as Web Services, SIP, and Bluetooth have been created to
allow for more extended features.
The Java ME™ Web Services specification (including JSR-172 specification (RCP) and JSR-172 specification (XML) was created in order to allow support for XML parsing and the ability to invoke Web Services. The API contains two optional packages for XML processing and Web Services. These two packages are independent and thus a device may have either one or both of them.
The Session Initiation Protocol (SIP) is an IETF signaling protocol for establishing real-time calls and conferences over Internet Protocol networks. The SIP API for Java Micro Edition (JSR-180) specification defines a Java Platform Micro Edition (Java ME) Optional Package, that enables resource limited devices (referred to as 'terminals' in the following) to send and receive SIP messages. The API is designed to be a compact and generic SIP API, which provides SIP functionality on a transaction level. The SIP API is integrated into the Generic Connection Framework defined in Connected, Limited Device Configuration (CLDC). SIP is only supported in Symbian.
SIP in itself is an application-layer control protocol that can establish, modify, and terminate communication sessions. SIP can also invite participants to already existing sessions. SIP transparently supports name mapping and redirection services, which supports personal mobility - users can maintain a single externally visible identifier regardless of their network location (see RFC 3261).
The Java APIs for Bluetooth (JSR-82) specification defines APIs that can be used to exercise certain Bluetooth protocols defined in the Bluetooth specification volume 1, and certain profiles defined in the Bluetooth specification volume 2. For more information about these profiles, see the Java APIs for Bluetooth (JSR-82) specification. The Bluetooth API is defined in such a way as to make it possible for additional and future profiles to be built on top of this API. This assumes that future changes to the Bluetooth specification remain compatible with this API.
The Bluetooth technology itself is an industrial specification for wireless personal area networks (PANs). The Bluetooth technology provides a way to connect and exchange information between devices such as personal digital assistants (PDAs), mobile devices, laptops, PCs, printers, digital cameras and video game consoles via a secure, globally unlicensed short-range radio frequency.
The following table specifies the GCF Connections and the protocols used for implementing them in the Series 40 and Symbian platforms.
Connection interface |
Networking protocol used |
Notes |
---|---|---|
HttpConnection |
HTTP or WAP WSP protocol |
|
HttpsConnection |
HTTPS (i.e. HTTP over TLS) or WAP WTLS (WSP) protocol |
|
SecureConnection |
TLS or SSLv3 |
|
ServerSocketConnection |
TCP/IP (server side) |
|
SocketConnection (TCP) |
TCP/IP (client side) |
|
UDPDatagramConnection |
UDP/IP |
|
CommConnection |
physical RS-232 serial port, IrDA IrCOMM, USB, BT |
Supported port types (COM, IR, USB, BT) depend on device hardware. |
PushRegistry |
List of supported protocols in Series 40:
List of supported protocols in Symbian:
|
Network Destination or Internet Access Point (IAP) for connection is selected using the following criteria when the MIDlet opens a network connection:
Use IAP Info API and Generic Connection Framework
IAP Info API gives applications access to IAP and Network Destination related information. For more information, see IAP Info API description.
Use MIDlet suite default IAP if it is defined in Application Manager.
The end user can define the Access Point manually via MIDlet suite settings in Application Manager. This Access Point is then automatically used for all network connections.
Use device default IAP or destination, if specified. Normally “Internet” Network Destination.
Prompt user for Network Destination or IAP selection.
For further connections in the same application session the same Network Destination or IAP is used.
Note: Default Connection can only be used when there is network coverage available. Otherwise connection fails. It is advised to remove the Default Connection configuration if outside network coverage.
If the device default IAP is set, then the MIDlet uses the default IAP when making connections. If the IAP connection is not available, connection fails. Device default IAP is no longer supported in Symbian^3 and newer releases.
Note: Series 40 does not generally support IAP selection. In devices that support WLAN, IAP is prompted when WLAN is available and no WLAN tagged as "automatic" is found.
MIDlet default settings support setting of Network Destination ID via Application manager and using IAP Info API and GCF framework. User can also select a destination, when prompted for Access Points. The suitable IAP will be chosen by the platform based on the selected/configured Network Destination when a connection is opened.
If a network connection has been successfully opened and the operation on that opened connection fails (for example if the device is out of network coverage of the selected Internet Access Point), the user is not prompted to select Network Destination or IAP until the next connection is opened.
Caching of IAP/Network Destination by connection management is supported from Java Runtime 2.1 for Symbian onwards. During the MIDlet session, only the first connection prompts for IAP/Network Destination, then the selected Access Point is cached. Subsequent connections will not prompt for Access Point, instead the cached Access Point is used. If the connection fails (due to network being lost, or such), then the cache will be invalidated and the next connection opening will prompt the user for Access Point. Symbian^3 onwards, the first connection in home network or WLAN does not prompt, but in foreign networks the prompt is shown at the first connection.
From S60 3rd Edition FP 2 onwards, port numbering
for CommConnection
starts from 1 instead
of 0 as was the case in earlier devices. Legacy MIDlets using hard
coded port number 0 receive a SecurityException
when the 0 port is opened, and exit.
Java ME utilizes two output streams, System.out()
and System.err()
. They
have some notable characteristics:
In Symbian, the stream output is saved on log file vmconsole.txt
, which is located in directory \epoc32\WINSCW\C\logs\java
. On some occasions, the directory
needs to be created manually in order for the logging to function
correctly.
The log file uses UTF-8
encoding.
The Symbian platform buffers bytes written to the output
stream. If your application requires that bytes written to the output
stream, by sent immediately, then call the os.flush
method right after the os.write
method to ensure
that buffered output bytes are written out.
OutputStream os; ... os.write("hello".getBytes()); os.flush(); ...
In Symbian, InputStreamReader
uses an internal buffer to make conversion from InputStream effective.
It is not recommended to simultaneously read both InputStreamReader
and the InputStream
used in its creation, as
it can lead to unexpected behavior.
If a MIDlet registers a datagram connection, then the network connection is always on even when no MIDlets are running.
The following developer's guides are available on networking in this section.
The guide describes the J2ME™ Web Services Specification, which contains two optional, independent packages for XML processing and Web Services. The guide also provides an example MIDlet that uses the API.
The guide describes the basic capabilities and the architecture of the Session Initiation Protocol (SIP). The guide also provides step-by-step instructions on how to create a MIDlet that uses the API. Support for this API was removed from S60 5th Edition and later releases.
The guide describes the basic capabilities and the architecture of the Bluetooth protocol. The guide also provides step-by-step instructions on how to create two MIDlet examples that use the API.