Things I’ve learnt about being data efficient when developing apps for Africa.

I’ve noted, from online forums (and interactions with) that developers are quite the say-it-right-or-don’t-say-it-at-all kind of people. Whenever someone makes a remark, observation and especially a comment that leans to the not-so-correct side or if someone explains a concept but leaves out a thing or two, they flame! So I’m going to get some things out of the way right off the bat. I’m am not a veteran developer and I don’t know everything. In light of that, what I write here is not the gospel but what I as an individual have learnt.

So, about being data efficient when developing apps. The first and foremost thing, is to please the user by reducing as much as possible the amount of data our apps use and battery drain. Data is not cheap here in Africa. There’s no “free” WiFi everywhere and anywhere, with the result that our data hungry apps are frowned upon by users who hate apps that will hog their hard earned data. I do too, when I’m the user.

To keep the users happy and smiling, and ensure my app isn’t getting uninstalled every so often here’s what I do:

Firstly I use libraries, a lot. Libraries such as OkHttp, Retrofit, Picasso and others not only help in ensuring I don’t reinvent the wheel, but also that I don’t spend valuable time resolving a problem someone has already solved (and frustrations someone has already had. These libraries are tried and tested, have community support and fewer bugs. I know of developers who have been at it for years, and would rather write their own code than use someone else’s because they’re not “lazy”. But then again, that’s personal preference.

Secondly I use compression (more on compression:Compressor head, Wikipedia). Most servers have compression enabled or one can configure it themselves (provided you have access to the server). Gzip compression, which I have found is most common, can reduce the size of uploaded or downloaded files by up to 80% or more. Gzip is supported by Android so compressing and decompressing isn’t much of a pain.

Thirdly, I have observed that the best way to save data and access it quickly is to not download at all. Caching reduces access time and ensures I don’t need to download files I’ve already downloaded. A plus is if the user is offline they can still use the app. Cache control from server will make sure I don’t serve the user expired data. What if the server never sends any cache-control headers at all? Well, there’s interceptors for that. OkHttp and Retrofit have interceptors (dangerous interceptors) that will rewrite the server response and ensure caching.

Fourthly, for me Connectivity type, coupled with a Preferences page, is a useful way to work well with a user’s preferences. If the user prefers to only download or sync data when on WiFi or when on 3G, only then the app will provide flexibility. Add prefetching into the mix and you have a winning recipe. You can prefetch data while on WiFi for later use. Prefetching is additionally powerful when on a slow network by ensuring that my app is not sluggish or unresponsive when the user opens it because I have already downloaded the data needed by the app. With prefetching you may end up downloading data that is never used. However, given the fact the user is happy, I for one certainly can live with that.

Fifthly, batching connections makes sure my app plays well with the battery through using a single burst to load a number of requests as opposed to loading them individually. GcmNetworkManager can do all this for me. The back-off pattern is another useful practice that I am yet to use. The idea is to increment exponentially the amount of time between pinging the server asking for new data. We get the same results as pinging at fixed intervals except we reduce radio chip wake time, straining the battery less and making the user happy.

Last but not least is the Google Cloud Messaging/Firebase Cloud Messaging approach, which I haven’t tried yet. This allows us to wait for the server to signal our app when there’s new content. So effectively there’s no need to keep waking the radio chip to ask if there’s new data and consuming battery as well as data. We save on data by not connecting to the server unnecessarily. Plus the fastest way to get through all of the above here.

I’m sure someone is ready to flame now, you’re welcome to do so. Talk to me, whether you’re a veteran developer, newbie, just curious or any other. Lets chat and teach each other a thing or two.