When asked to create a mobile app, often a version of an existing web site or desktop app, the designer responds by leveraging the existing server, often a series of URL calls returning either XML or JSON, and creating a flow of screens and controls to invoke these URLs and display the resulting data. Just like the existing web site or application in fact. And for many applications, this works just fine. The customer gets a nice native app, and no drastic changes have had to be made to the existing server architecture. Someone may have had to learn who to use a new language to implement some UI widgets but beyond that the effort was pretty straightforward.
But when the app is downloaded and used by customers, complaints start coming in. It’s slow. It crashes. The data doesn’t refresh in a timely manner. Then the crash reports come in. An engineer looks, says that the problems are caused by bad networks. He shrugs his shoulders – nothing can be done.
In reality of source there is a solution. It isn’t a popular one, because it involves a lot of work. On both the client and the server. The solution involves throwing away all the TCP-based network code and replacing it with UDP. This is hard. UDP doesn’t guarantee that data will be delivered, or in what order it will be delivered. It can’t even tell you if the data has been corrupted en route. All that work has to be performed at the application layer. But solving all those problems is absolutely necessary if you want your application to handle mobile network situations.