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

To XML or Not to XML?

With all the momentum behind XML, it is easy to assume that it should be used to meet all data-exchange and storage needs. This is not the case. XML is powerful because it is flexible, but it is wasteful in size. If a relatively small amount of data is to be exchanged, XML is an excellent choice. For example, if 20 rows of rich database data need to be downloaded, the XML file may approach 20KB in size, whereas a binary implementation for transmitting that data may be able to squeeze the data into 2KB or perhaps an even smaller size. The time difference in downloading 20KB of data versus downloading 2KB of data is usually negligible compared to the time spent establishing a connection with a server, passing necessary credentials, and doing other setup work for communication. In either case, the absolute user wait time for transferring the data is relatively small, so the difference in storage size is not an overwhelming design factor in choosing a storage format. For relatively small amounts of data, the use of XML is justified because of the benefits of having a flexible data-interchange format. However, what if the data were 10 times larger and the design question was between transferring 200KB of XML data or 20KB of binary data? At this point, the user's wait time for data transfer between the device and server would start becoming significant, and measurements would need to be taken to weigh the impact of each implementation.

The speed of the communications network being used by your mobile application is an important factor to consider. Wi-Fi speeds may make the transfer time a nonissue for some data, and GPRS mobile phone networks may make transfer time and cost important factors to consider. If the size of the data to be transferred was another order of magnitude larger and the question was between transferring 2MB of XML data and 200KB of binary data, the choice of data format would be very significant because connection latency times would likely be dwarfed by the actual time spent transferring the data. Add on top of this the probable fact that parsing the XML data will take longer than parsing binary data that is optimized for reloading.

For small amounts of data, the use of XML is usually a clear choice. As the data sizes get larger, significant design consideration and real-world measurement and testing must be done to ensure that the benefits of XML usage are greater than the communications and processing overhead that is incurred. Like any verbose format, XML documents can be compressed before transmission and decompressed after to reduce transfer size, but this is additional processing work and binds the client and server to a common compression format; it can be done but is not a panacea. It is important to make a knowledgeable decision based on clearly elaborated facts and an assessment of the end user's experience. In some cases it may make sense to use XML for communication between servers but then perform binary communication between servers and devices. Each situation is unique and based on the user's needs, the nature of the communications networks being used, and the engineering costs associated with binary and XML-based communication. Experiment, measure often, and choose wisely.