Most mobile developers live in highly populated areas with excellent cellular signal for testing. Additionally, we carry the latest phones, have high (or unlimited) data caps, and we rarely worry about data charges on our phones. All of our friends have similar devices and similar usage patterns. Based on what we hear everyday – we come to assume that everyone has access to fast LTE network access and the latest fast mobile devices. In reality, our mobile phone usage is the outlier: we often forget that we live in a bubble. Most of the world does not have access to the technology that we do – and thus are unlikely to use our applications in the way that we do.
Statistics (from the GSMA) show that only 20% of N. America customers have LTE enabled handsets (here is an alt source). Globally, the LTE penetration rate is ~5%. In China, a report from 2013 (granted prior to the LTE rollout) estimated that of 270M Android users, 31% relied on 2G networks for data connections (that is 80M devices!) The same argument goes for devices. The top phones may sell millions each quarter, but we often forget that there are ~4.5 Billion phone users (with ~1.75B smartphone users) worldwide. The GSMA published a study this week corroborating this, estimating 35% smartphone penetration worldwide. So, even when the latest flagship device sells 10-20M in a year – it is really a drop in the bucket against the entire smartphone market. Our phones and usage patterns are really in the top 1% of consumers – and we need to remember this when we are developing our mobile apps and websites.
So, how does your app behave with no network availability? How does it run with limited (or slow) network? What is your performance like on low end devices? Testing your app with no network available is easy – we all have access to airplane mode. Try it out, and then make sure that your app degrades gracefully without a network connection: preferably with some cached data. Below, see an app that I started with coverage, then quit – placed the phone in airplane mode (elapsed time under 2 minutes), and upon restart – the application contains no data (I covered the app name for anonymity):
Two minutes ago, there was a 5 day forecast at the bottom, and now it is showing that there is no data available. While it is important to keep weather data timely, providing no data at all is (I think we can agree) somewhat worse. In poor network coverage, the same issues hold. Caching recent data, and populating that information will allow customers to interact with your application (at least in a limited fashion) while the current data is slowly populated.
Even so, I think we can do better. We may not be able to control the cellular coverage our customers are using, but we can work with the cellular coverage available. Much like responsive web pages change their interaction and views based on screen size, we can build apps to read the current network state and modify the content requested and downloaded to our customers. Applications that identify and change their interactions based on mobile network conditions are “Flexibly Network Aware” (FNA) – they determine the network connectivity, and then modify the requests and rendering based on the network pipe that is available to the device. Consider this simple Android example:
TelephonyManager teleMan = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE); int networkType = teleMan.getNetworkType(); switch (networkType) { case 1: netType = "GPRS"; NetworkSpeed = "slow"; case 2: netType = "EDGE"; NetworkSpeed = "slow"; case 3: netType = "UMTS"; NetworkSpeed = "medium"; // we'll leave out a few network types, but you get the idea. case 13: netType = "LTE"; NetworkSpeed = "fast"; }
This application has created 3 buckets for the different mobile network speeds that it expects to encounter. Now that it has created the buckets, the behavior of the app can change depending on the bucket. A simple example would be to change the image size based on network speed. A large image (143KB) may take 9s on EDGE, but compressing the image to 27KB – it only takes 3s. Customers expect slower downloads on EDGE, but a 3x improvement in download speed would be greatly appreciated by your customers, improve your engagement, and provide higher revenue for your application.
There are clearly markets that are eager for applications that run smoothly and quickly on networks our bubble would call slow. Case in point: one of the reasons that Facebook bought What’s App was due to its great UX on budget devices on slow networks. By adding a FNA architecture to your application, you can ensure a fast and awesome UX both inside “our bubble”, but also for the millions (billions) of users on slower networks around the world.
P.S. to web developers: You are not being ignored. There is a push for the netinfo API to include bandwidth ceilings for the various cellular connections inside the browser – so websites could be similarly FNA, and adapt to slower networks.