Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Pushing Information to a Device

The fact that much of mobile device communications centers on mobile devices initiating conversations with servers is not by accident. After a connection with a server is established, it is easy to push data up to a server or pull data down from a server. Most communication with servers uses abstractions such as sockets or HTTP, which are built on top of Internet TCP/IP protocols. In TCP/IP communications, each device on the network has its own IP address. An IP address is like a phone number, with the caveat that some IP addresses are permanent, some are long lived, and some are far more transient. An understanding of the transient nature of some IP addresses is important to understand which communications models are practical for mobile device applications and which are not.

Internet servers have IP addresses that rarely change. In addition, there exist mechanisms for looking up the IP address based on friendly URL names. The most popular Internet name lookup service is called DNS, which stands for Domain Naming System; it translates friendly names such as www.microsoft.com or www.yahoo.com to IP addresses. These DNS servers maintain replicated databases that map names to IP addresses. This works well because the server IP addresses rarely change.

Things work in a fairly similar way inside intranets. A server, desktop, or laptop name is registered and associated with an IP address. Sometimes these IP addresses are fixed, but usually internal IP addresses are loaned to computers by servers known as DHCP servers. DHCP stands for Dynamic Host Configuration Protocol, and as you might imagine the DHCP server's task is to loan out IP addresses to client computers who ask for them. Again the assumption is that these IP addresses do not change very often. A server that changed IP addresses very often would be a burden on the network because its address would require constant updating and lookup by client computers. Devices that appear and disappear on the network often because they are constantly roaming between different parts of the network or being turned on and off often will end up changing IP addresses frequently.

If a mobile device is going to be confined to a specific network topology (for example, inside a single corporate network), the addressing challenge for mobile devices is relatively straightforward. In these cases, one of two solutions is possible: (1) simply assigning the mobile device a fixed IP address, which is the simplest but least-flexible solution, or (2) building a custom mapping server that gets called by devices to register their IP address whenever they change; other devices can query this server for the address of a given device.

For devices that roam through different networks, the problem is far more complex. A static IP address is not permissible because it relies on the consent of the operating network, which may have already handed out or reserved any given IP address that the device may want to use. The presence of proxy servers, NATs (Network Address Translators), and firewalls present additional problems. Proxy servers, NATs, and firewalls allow specific kinds of outgoing requests and route responses back to the computing devices that made the requests; they do not generally allow unsolicited incoming requests to devices inside the networks. A device inside a network making server requests does not need to be aware of these complexities, but any party attempting to access a device from outside the network does.

The net result of all this is that for roaming mobile devices it is very difficult to send requests down to the devices; there is no good generic model for accomplishing this. This results in an asymmetry; it is far easier to make requests from a device than it is to send requests to a device.

In some cases, it is useful to be able to push information down to a mobile device. As noted previously, for custom static network topologies this is not a large problem; the mobile device can have a fixed or specially registered IP address and simply open up a socket and wait for requests to come in. For general-purpose mobile devices that roam through different networks, this is a challenge. The challenge can be addressed in several ways:

Mobile phones can use SMS message reception
Most mobile phones today support the widely popular SMS (Short Message Service) mechanism for pushing short streams of data down to devices. SMS offers a convenient universal addressing scheme: the device's phone number. Usually these SMS messages are text messages for the user to read, but this need not be the only use. Because SMS messages are limited to about 160 characters of information, a good model for using SMS to push information to a device is "push to pull"; a specific SMS message's arrival triggers a local application to access a server and download a larger amount of information.

E-mail messages
Many rich mobile devices support receiving e-mail notifications either to a phone-specific e-mail address or to the user's regular e-mail address. Sending specific messages to a device that are intended to be interpreted by a local application is a powerful way to push data down to a device.

Polling
Polling is simply occasionally making a call from the device to a server to see whether new information intended for the device is pending.

Of the three mechanisms described above, polling is the least sophisticated and by far the easiest to implement. Only in cases where a polling-based solution proves to be inadequate should other mechanisms be looked at.

Presently when developing with the .NET Compact Framework v1.1 there is no built-in library support for intercepting or viewing incoming e-mail or SMS messages; to do this, native code will have to be written and fairly sophisticated operations will need to be performed. Accessing incoming e-mail and SMS messages is not infeasible, but it is a significant amount of work. This work needs to be justified by proving that a less-elegant but simpler solution is not sufficient to meet your mobile application's needs. Writing low-level messaging code is interesting work, but is hardly ever a high-productivity task; weigh the alternatives and choose wisely.