Dealing with low Internet bandwidth, in India

In India, Internet bandwidth is limited, and the more you want, the more expensive it is.  We know that carriers in the U.S. are going in this direction too.

I got myself what is known as a “data card” (essentially a barebones phone, which plugs into your USB port, and allows you to dial out to the internet) with a pretty high band-width plan.  The promise is 3 GB per month, at more than decent speeds, and after I go past the 3 GB limit, the speed is throttled down significantly.

3 GB per month seemed adequate when I signed up.   In the U.S my mobile plan only has a 2 GB limit, and I barely use half of it each month.   I had that in mind when I took the 3 GB plan.   However, in the two weeks since I got the data card, I have used up close to 2 GB already.  I did not stream any video, or audio.  All I have been doing is reading news, and trying to get some work done online.  Needless to say I was shocked.   It appears that I forgot that most of my usage in the U.S happens over my landline, and through my work.   Now, I am forced to pay attention to how I use the Net.

This morning, I was paying some bills through my bank’s online bill payment service.  For the first time I noticed how I heedlessly waste bandwidth.   I would enter the amount for one bill, submit that, which took me through a couple of pages, and then start my next bill, which would take me through those pages all over again.  In fact, my bank allows me to enter payments for several bills at the same time, which would take me through those same two or three confirmation pages, but I would be visiting these pages only once.

I was reminded of how my mother gathers several errands together before she ventures into the city.  Any trip from our home in the southern outskirts of Chennai, a place called Kelambakkam, into the city and back, burns through a whole day.  It simply is not practical to expect to travel into Chennai two or three times a week.  Nothing else would get done at home.   You have to try and get a lot of work done on any one trip.

Another thought occurred to me while I was at my bank’s web site.  All I really want to do is specify a biller, a payment amount, perhaps a payment date, and say, go.   If the bank had a RESTful API, which it exposed to me, I could get this done in 3 lines of script.  Pick your poison – Javascript, Python, Groovy, PHP, whatever.  Imagine how little bandwidth that would require.

However, this will work only for the geeks.   Regular folks need a UI.

Ah, and suddenly, mobile apps make sense.   With mobile apps, presentation happens completely at the client.   None of the artifacts (images, bloated Javascript, CSS, etc.) that make up the presentation will travel between the client, and the server.   Rather, only the data, and a command or two will, just like with an adhoc script I might cook up to talk to a RESTful API.

I should find out exactly what is eating up the bandwidth.  I wonder how much the damned advertisements consume.

How to avoid sending null/empty fields between a RESTful service, and a client?

By it strictest definition, a RESTful service sends and receives ‘resources‘, which when seen from an object-oriented perspective, are largely the objects of your domain model.  An insurance policy, a bill, a payment, a car, a truck, a driver, a patient, a nurse, a clinic, etc.

Often, an instance of the object that you are putting on the wire has null fields.   Here is a patient at a clinic, whose middle name and date of birth, we don’t have.

       "patientId": "THX1138",
       "firstName": "John",
       "middleName": null,
       "lastName": Patient,
       "dateOfBirth": null,
       "address": "1,  Illness From,  Bankruptcy, HA-00000, USA"

In the mobile world, where we now pay for data usage, and where connections can be slow, it might be useful to minimize the amount of data we throw on the wire.   When the mobile app retrieves the above person, John Patient, I want to drop the fields (middle name, and date of birth) that are null, and send just this.

       "patientId": "THX113",
       "firstName": "John",
       "lastName": Patient,
       "address": "1,  Way Ticket To,  Bankruptcy, HA-00000, USA"

Further, I want the mobile app to be similarly discriminating when it sends data back to the RESTful service at the server.

In effect, the marshalling mechanism at both ends should be able to create the patient object with just the data that is available, and leave the rest of the fields null.

Javascript works that way natively.   If I was running Javascript at both endpoints, the core language itself would pretty much give us this behavior (Ah, node.js!).

I expect this is possible in other environments too.   In particular, I will need to look into this for the following.

  • RESTful service in Java, talking to 
    • Android App in Java
    • iOS App in Objective-C
    • Javascript MVC

68 dollar question

Is this really worth the trouble?   Will this really produce a lot of efficiency?

Is it even worth pursuing this question?

When data usage costs money, and connections can be slow, and intermittent, why would you want to carry unnecessary baggage?  Even in the best of circumstances, why would you want to?  This sounds like it ought to be a first principle for any mobile app.

But, we do want to watch out for ‘premature optimization’ – getting clever too soon, or even unnecessarily.

Hence, we will need to know how to test for this?  How do you simulate, and test spotty mobile connections?

Related questions

  • What other techniques exist for dealing minimizing the data usage of your mobile app?
  • What other techniques exist for dealing with intermittent, or slow connections?

These just seem a more severe variation of a problem that has been around for longer than the mobile world – how to build a UI around large-grained, stateless APIs.   So there are answers out there …..