The Low Data Diet: Compression in Mobile Apps
Submitted by John Boxall on December 16, 2006 - 3:42pm.
Google recently released a slick mobile application for one of my favourite mobile pass times, checking my email. The Gmail mobile app (GmailM) is a beauty to use with intuitive controls, streamlined functionality and a polished finish. At first glance it appears to be an exemplar mobile application port, but GmailM has a dark secret, away from the users eyes lurks a hungry beast.
GmailM is a hog. It has an ravenous hunger for all your data. Used freely, single sessions with GmailM can easily consume hundreds of kilobytes of data. When you are paying Canada's exorbitant mobile data rates, every kilobyte counts. With emails showing no signs of getting shorter and carriers having the audacity to raise their data rates (cough Fido cough), is there anything Google can do to curtail its gluttonous ways?
For starters language based plain text, like an email, is the perfect candidate for compression. Try generating some random text, pasting it into Notepad (or your favourite plain text editor). Now save the file and check the size. Zip (compress) the file and check again. Big difference. And while compression certainly isn't a novel idea, its application across the web has been spotty at best. With the widespread proliferation of high speed connections, compressing web traffic on the desktop web doesn't seem necessary. Many a web developer (myself included) stand guilty of flinging outrageously sized javascript libraries across the web haphazardly. Even XML, one of the de-facto standards of web communication is a habitual offender. By explicitly encoding all data structural information along with data, XML files are understandable across heterogeneous group of hosts like the internet. This makes XML great when you aren't sure who is going to using your data, but all that extra structural information comes at a cost in file size. XML are significantly larger than traditional implicitly encoded data.
In a mobile application scenario such as GmailM, the application developer is in control of the data at both ends of the connection. When you know who is going to be using your data then it is possible to structure it implicitly, making assumptions that the other side knows what to do with the data when it arrives. This means that structural information need not be included with the data. Secondly and most importantly, since you are control of the data on both sides, there is no reason why you can't compress the data as it travels between the two ends and then decompress it to present it to the user.
Perhaps the best success story of mobile data compression is the Opera Mini mobile web browser. Like GmailM, from the outside Opera Mini presents a clean interface with functional mobile web browser. Unlike GmailM, Opera Mini has its code ducks in a row under the hood. When you use Opera Mini to request a web page the request is not routed directly to the server the page resides on. Instead, a remote request is made to Opera's servers which in turn fetch the page you are after. Before returning the requested page to you, Opera's server optimize and compress it for mobile browsing. While this extra step means you'll be waiting a little longer to receive your page the result of the page compression is a significant decrease in the data traffic. And when you're paying by the kilobyte, less traffic means better application. Consequently I use Opera Mini to check my email by pulling up the Gmail web page which really is a shame because the GmailM application with its specific email functionality is better.
The lesson for developers to take home is clear: keep mobile application data traffic to a minimum. If you control the data at both ends of the connection then consider not using standard web communication methods that were developed with unlimited data traffic in mind. Don't rely on what worked on the web to work in the mobile space. Minimize data traffic by defining your own message passing protocol utilizing data compression.
For the vast majority of users, the mobile web is still pay as you go. In designing your application to minimize data traffic, the average user may not appreciate the technological genius of your data compression strategy. But they will appreciate a lower phone bill. If you can keep using your app affordable for your users they will reward you by continuing to use it.
-jb
GmailM is a hog. It has an ravenous hunger for all your data. Used freely, single sessions with GmailM can easily consume hundreds of kilobytes of data. When you are paying Canada's exorbitant mobile data rates, every kilobyte counts. With emails showing no signs of getting shorter and carriers having the audacity to raise their data rates (cough Fido cough), is there anything Google can do to curtail its gluttonous ways?
For starters language based plain text, like an email, is the perfect candidate for compression. Try generating some random text, pasting it into Notepad (or your favourite plain text editor). Now save the file and check the size. Zip (compress) the file and check again. Big difference. And while compression certainly isn't a novel idea, its application across the web has been spotty at best. With the widespread proliferation of high speed connections, compressing web traffic on the desktop web doesn't seem necessary. Many a web developer (myself included) stand guilty of flinging outrageously sized javascript libraries across the web haphazardly. Even XML, one of the de-facto standards of web communication is a habitual offender. By explicitly encoding all data structural information along with data, XML files are understandable across heterogeneous group of hosts like the internet. This makes XML great when you aren't sure who is going to using your data, but all that extra structural information comes at a cost in file size. XML are significantly larger than traditional implicitly encoded data.
In a mobile application scenario such as GmailM, the application developer is in control of the data at both ends of the connection. When you know who is going to be using your data then it is possible to structure it implicitly, making assumptions that the other side knows what to do with the data when it arrives. This means that structural information need not be included with the data. Secondly and most importantly, since you are control of the data on both sides, there is no reason why you can't compress the data as it travels between the two ends and then decompress it to present it to the user.
Perhaps the best success story of mobile data compression is the Opera Mini mobile web browser. Like GmailM, from the outside Opera Mini presents a clean interface with functional mobile web browser. Unlike GmailM, Opera Mini has its code ducks in a row under the hood. When you use Opera Mini to request a web page the request is not routed directly to the server the page resides on. Instead, a remote request is made to Opera's servers which in turn fetch the page you are after. Before returning the requested page to you, Opera's server optimize and compress it for mobile browsing. While this extra step means you'll be waiting a little longer to receive your page the result of the page compression is a significant decrease in the data traffic. And when you're paying by the kilobyte, less traffic means better application. Consequently I use Opera Mini to check my email by pulling up the Gmail web page which really is a shame because the GmailM application with its specific email functionality is better.
The lesson for developers to take home is clear: keep mobile application data traffic to a minimum. If you control the data at both ends of the connection then consider not using standard web communication methods that were developed with unlimited data traffic in mind. Don't rely on what worked on the web to work in the mobile space. Minimize data traffic by defining your own message passing protocol utilizing data compression.
For the vast majority of users, the mobile web is still pay as you go. In designing your application to minimize data traffic, the average user may not appreciate the technological genius of your data compression strategy. But they will appreciate a lower phone bill. If you can keep using your app affordable for your users they will reward you by continuing to use it.
-jb
- John Boxall's blog
- Login to post comments
Submitted by Richard Smith on December 16, 2006 - 10:21pm.
Great analysis, John. Don't you think - with all of google's resources - that they could create a "diet" version of GmailM? Perhaps by taking a page from OperaMini's cookbook? It would be even easier for them, because there aren't a million random servers out there, just their own.
I know data rates are falling elsewhere in the world, but compression also brings other advantages - speed, for one. Who doesn't want to get their email more quickly?
Perhaps they are worried that they cpu power on the remote devices (millions of phones) won't be up to the compression task, but the opera people seem to have that problem licked.
Let's hope we see an improvement in this regard!
- Login to post comments
