Network Interface Considerations

Network Interface Considerations

MIDP devices must support the HTTP protocol, a rich, widely used protocol that can be implemented relatively easily over a variety of wireless networks. HTTP lets devices take advantage of the extensive server-side infrastructure already in place for wired networks. Furthermore, because no unrequested HTTP packets can arrive at the device, implementing the networking interface is easier.

Supporting the HTTP protocol does not imply that the device must support a particular Internet Protocol (IP). A device can implement HTTP using IP protocols such as TCP/IP, or non-IP protocols such as WAP or i-Mode. If a device uses a non-IP protocol, a computer called a gateway bridges the wireless protocol to and from HTTP servers on the Internet and provides IP-based network facilities such as server name resolution (for example, DNS).

Many wireless networks have evolved to support IP-based protocols, so the MIDP Specification version 2.0 defines the corresponding APIs and behaviors. The new MIDP 2.0 APIs are SocketConnection (Section 15.5, "SocketConnection"), ServerSocketConnection (Section 15.6, "ServerSocketConnection"), and UDPDatagramConnection (Section 15.7, "UDPDatagramConnection"). In addition, the CommConnection API (Section 15.8, "CommConnection") supports serial communications. Support for these protocols is optional, but most networks are expected to support them. They enable MIDlets using the protocols to run consistently across implementations.

Implications for application developers

When designing MIDP applications, it is important to keep in mind that many networking and communications API calls can be time-consuming and can potentially block the application thread. For instance, networking operations such as opening connections or receiving data from a server can cause the application thread to be blocked while waiting for the network activity to be completed.

Application developers should design their applications so that the applications do not invoke any time-consuming network operations in the callback functions that are invoked as a result of user interface actions. For instance, CommandListener functions should not generally invoke networking functions, as listeners require a separate thread to keep the user interface functionality from interfering with the responsiveness of the application. In addition, upon invoking time-consuming networking operations, the application should always display a progress screen, such as Gauge, and include a "Cancel" command to allow the user to escape from potentially indefinitely blocking network activity.