Many mobile applications can get by without ever having to exchange information over the web, but if you’re looking to build data-driven mobile applications, sooner or later you’re going to have to communicate with a remote server. There are many different ways of accomplishing this goal. Some approaches are succinct and lightweight, while others are woefully inefficient and data-heavy. For mobile devices, which may be bound by a monthly data cap and slow connectivity speeds, we want to be as lightweight and efficient as possible.
Problems with HTML
In a perfect world, we’d have web services for every bit of data we’d ever want to consume, but sadly that’s not the case. In one particular project here at Segue, we were reduced to having to submit form posts and scraping the HTML result. Imagine the impact this has on a mobile device. The string manipulation involved in parsing down the resulting HTML required a solid amount of coding. HTML can be heavy; it contains data we don’t need, including images and markup language that are of no significance to us as pure data consumers. HTML is long because it contains many characters other than pure content, which translates to slow transfer speed and eats into monthly data transfer limits. It’s is also dynamic and prone to change (as if you haven’t already discovered this), and will eventually destroy your parsing routine, which is the process of whittling down the entire HTML string into its useable components using string manipulation functions.
The Advantages of Web Services
A way to overcome the limitations of HTML is to use web services. For those who don’t know, a web service can be thought of as a function call to a remote server and offers very specific functionality. Web services exist all over the web and many are open to the public. If you’re fortunate, you might find one that meets your data requirements. If not, you could always build and host one yourself. The advantage of web services is that they are focused on a particular set of data, so you don’t have to filter out information that is of no use to you. For example, say you wanted a weather forecast. You could call a web service and pass in a date and expect to get a resulting forecast for the date you submitted. This means we are dealing with a small set of data specifically focused on our need, which equals a smaller data size and faster transmission speed. However, not all web services are created equal. The breadth of various technical differences between web service types is too broad to tackle in a single blog post, but we will discuss the difference in return formats, because they can have a measurable impact on speed.
Return Formats
In my experience, I’ve encountered two primary web service return formats: XML and JSON. Extensible Markup Language (XML) has long been a popular way to structure data using familiar markup language. It is both human and machine readable and is very similar in appearance to HTML. It follows a set of standards for data communication over networks between devices and is iteratively parseable. One advantage of consuming data in this format is its structure. Data can be added or removed from the result set, but it will often exist in a predictable format so you don’t have to worry about your parsing routine breaking when the data changes over time. Despite its advantages, one drawback of XML is its size, because it contains many characters strictly related to formatting. When downloading data to a mobile device, it would be ideal to just obtain the relevant content instead of data related to content formatting. This is where JSON comes in.
JavaScript Object Notation (JSON) is a text-based data interchange format derived from the JavaScript scripting language. It is formatted as key-value pairs and is often lauded as being a lower-overhead to XML because it focuses more on content and less on formatting. This works to our advantage when we want to keep data interchange packets as compact as we viably can. Now to be fair to XML, it is possible to format it in specific ways or use compression to make it comparable in size to JSON, but generally I find JSON to be much smaller in size and therefore preferable to XML.
One final observation (geared toward iOS since that is the particular platform for which I develop) focuses on how we process the two formats on the device once information has been returned from the web service. Parsing XML in iOS can be a bit tedious as it involves implementing a handful of NSXMLParserDelegate methods to iterate through the XML code. This can require a significant amount of coding. On the other hand, if a JSON object is returned from a web service we can convert it directly into native objects such as NSDictionary or NSArray. These objects can be archived and we can access data elements as key-value pairs without having to implement any delegate methods or iterate through the result data. This equates to a measurable increase in speed and efficiency. For my money, JSON is absolutely the way to go for mobile device data consumption.
What to Read Next: