Mobile Device Development Issues

only for RuBoard

When developing mobile-device applications you must take the following into account:

• Screen size ” A mobile device needs to be small enough to be easily transported and, ideally , it should fit in the palm of your hand or in your shirt pocket. For this reason, the available screen size is much smaller than a PC's screen size.

• Physical display ” A mobile device's display is rarely in color and its size and ability are limited.

• Data input ” Mobile devices typically do not have keyboards. If they do, the keyboards are limited in size and practicality. Therefore, data entry is more challenging for the user than it is for a PC-based system.

• CPU ” In a mobile device, the CPU is not nearly as powerful as a PC's CPU, and it is almost certainly of a different architecture.

• Memory ” Mobile devices tend to have a small storage capacity compared to PC-based systems. This is due to handset and PDA manufacturers being overly cost-sensitive because of the competition in the market place and their subsequent reluctance to add any additional components unless it's absolutely necessary. Note that some mobile devices do not have a persistent storage of their own (certain mobile phones fall under this category).

• Battery ” Mobile devices are almost always battery powered . The need to have devices available for long periods of time between charges generally means that the CPU's processing cannot make significant demands on the battery.

• Reliability ” A wireless network is different than a fixed-wire network. The bandwidth of the network is much smaller.

The reliability of a connection can vary considerably, especially when users move in and out of wireless network coverage areas, such as tunnels, certain buildings , and so on.

Other additional factors are latency and the large number of mobile network standards used around the world. These standards do not interoperate well. Some countries even have incompatible standards in different regions .

It is important to realize that, for wireless applications, the market is different. Applications that are suitable for use on mobile devices are different than those that are popular on fixed-wire environments.

For example, users of mobile applications are likely to be a broader selection of the population than PC users. Even the context in which applications are used is different. This highlights the most important part of mobile-device application development: making the application easy to use.

So What Does WAP Do to Help?

WAP was designed specifically to address all the issues mentioned in the previous section. The WAP standard defines a Wireless Application Environment (WAE) , which has been designed to maximize the developmental potential of mobile devices.

The WAE specification includes a microbrowser (a markup language browser). A microbrowser defines less control than most PC-based browsers in relation to specifying how a User Interface (UI) element is rendered. Instead, it concentrates on the functionality that's available.

Some directions can be given to the microbrowser, but it is the microbrowser itself that selects the onscreen representation of the UI element on the devices display area.

WAP defines a limited Virtual Machine (VM) for a simple scripting language to execute in, which is designed to operate in the limited environment of mobile devices.

The network issues are addressed through an optimized protocol stack, which was designed to take bandwidth limitations into account. It was decided to maintain compatibility with existing standards wherever possible. This is why WAP operates over standard Internet Protocol (IP) networks and uses the User Datagram Protocol (UDP) over IP whenever possible. (WAP is also capable of operating over non-IP networks.)

To help address the issue of restricted bandwidth, the content that's transmitted through WAP is encoded and compressed to reduce overall data volume. Most devices can only receive a small amount of data at a time; after compression, the actual amount of data varies depending on the device being used.

As previously mentioned, a microbrowser has its own scripting language; the standard language developed by the WAP Forum is Wireless Markup Language (WML) . WML is adapted to the constraints of mobile devices and wireless networks.

HTML is oriented towards the visual aspects of document rendering: what the specific UI elements should be and what they should look like.

This is good news for devices that are capable of complex rendering and have the ability to enable the user to interact with elements, such as push buttons and framesets. It's not appropriate for most mobile devices (mobile phones are a prime example).

Because of this, a smaller and more elegant markup language was required that's more appropriate for the wireless environment.

WML and its XML Origins

WML was derived from XML. It contains elements that are more useful to mobile devices than standard HTML elements.

For example, WML defines an <anchor> element, which a microbrowser renders in any way that's equivalent to the HTML <a> element.

Also, a scripting language called WMLScript is derived from the standard, ECMAScript. Again, compatibility has been maintained wherever possible.

How Does WAP Work?

The WAP protocols are similar to the World Wide Web's protocols (IP-based ones). WML is a dialect of XML and it uses the same tag-based format as Hypertext Markup Language (HTML) .

Most World Wide Web servers communicate with their clients by using an ASCII-based protocol called the HyperText Transport Protocol (HTTP) . HTTP is a simple protocol that consists of field names and field contents separated by carriage returns and line-feed characters .

HTML and HTTP are transported by using the Transaction Control Protocol/Internet Protocol (TCP/IP) . TCP/IP guarantees that data sent is either properly delivered or triggers an error condition back to the sender.

Although the WAP protocol is based on and uses Internet standards, it paradoxically is almost incompatible with them. This incompatibility means that WAP-enabled devices cannot directly communicate with WWW servers.

To do this, the WAP protocols must first be translated from their initial format to those of the protocols used by the WWW. This is why every WAP device needs access to a WAP gateway in order to request WML pages (or decks as they are referred to in WML) on a web server.

The WAP gateway's purpose is to translate the WAP binary-based protocol into one that's compatible with the HTTP text-based protocol.

The actual WAP protocol is a hierarchical set of layers , some of which are optional. The lowest layer is the WAP Datagram Protocol (WDP). It moves WAP data from the client to the server and back again.

WDP is based on the User Datagram Protocol (UDP) . Unlike TCP/IP, UDP makes no guarantees about the delivery of data. It is known as a best-effort delivery service. This means that some data can be lost or corrupted during its transportation. UDP is generally used on the Internet for data that's not affected too much if a few pieces are missing, such as audio and video streams.

UDP was chosen as the basis for the WAP transport (WDP) because of its compactness and simplicity. Like UDP, WDP is just as unreliable.

The next protocol layer is the WAP Transaction Protocol (WTP) . WTP was designed to replace the pieces UDP lacks compared to its bigger brother, TCP/IP. WTP is responsible for making sure that packets sent through WDP arrive at their destinations. This is done by waiting for an acknowledgement , or ACK, data back from the server. This means that any data that's sent between the client and server must be specifically acknowledged using WTP.

If an acknowledgement is not received for some data within a time window, WTP resends thee data. This happens a certain number of times. If all are unsuccessful , an error is generated. WTP is an optional protocol, however, and isn't present on all WAP gateway servers.

The next layer is the WAP Session Protocol (WSP) , which is responsible for two different modes of functionality. The first is the creation of a session between a WAP client and a WAP gateway server. Each session has a unique ID and must be explicitly started, stopped , resumed, or disconnected.

This mode, known as connected mode WSP , is always used in conjunction with WTP. A WAP client explicitly creates a session, and each part of data sent to a WAP gateway server is sent and acknowledged through WTP, which guarantees either delivery or an error condition. But, again, WTP is an optional protocol, as is using WSP connected mode.

The second mode of WSP is the same as HTTP session management. WSP's functionality, in this case, is not optional and is present in every WAP gateway server. If WAP is operating with just the WSP protocol, no sessions are created and communication becomes a simple request-response pairing .

only for RuBoard