Kim told you all about us “eating our own dogfood” in her earlier blog article. Beta testing of the mobile app is going very well, and we’ve had great feedback from our small army of Codifiers turned fitness enthusiasts! This blog article aims to give you a flavour of the some of the things you have to think about when building an app such as RigRun.
Building apps for mobile devices is much more challenging than doing so for desktop or web. There are additional things you must take into consideration, and they can be hard to get right. Here are some examples:
You cannot guarantee that a mobile device is always connected to the internet. Furthermore, any connection can be limited or intermittent. A mobile app should expect this and still be usable when faced with poor connectivity.
The RigRun app caches all data on the device and synchronises with the server whenever possible. Care is taken to avoid transferring more data than is necessary by using an efficient serialisation format (compared for example with JSON, or even compressed JSON) and only sending “diffs” of what has changed. This speeds up synchronisation and respects that end-users may have to pay for data or have data quotas.
We also avoid frequent synchronisation while the mobile app is running in the background. To preserve battery and save data, mobile operating systems can be very aggressive at stopping apps from doing too much in the background. We use the built in iOS and Android features to allow background synchronization to be scheduled at the most appropriate opportunity.
Unlike other apps, network errors are everyday possibilities for mobile apps. Handling these is not just a simple case of “retry on fail”.
Consider what happens if the app sends new data to the server, the server saves the data and sends back a confirmation. If a network error prevents the confirmation from being delivered, then the app would assume the data was not saved and will retry later. The RigRun app anticipates this and can handle being sent the same data multiple times without crashing or getting confused.
This might sound obvious, but also needs special consideration for mobile apps. We save changes to local storage first and then immediately attempt to save to the server. This reduces the risk of data loss and means that users don’t have to wait around for confirmation that their data has been saved. Local storage is strictly treated as a temporary cache only and we assume it could disappear at any time (because it could!). All data is uploaded to a secure server as soon as practical.
App upgrades need very careful consideration. There’s nothing more annoying than a mobile app that loses your settings or logs you out after an upgrade. It is much harder to control the versions of a mobile app that are “in the wild” – users can choose not to upgrade if they wish.
This means we must support multiple versions of the mobile app simultaneously. This has two big technical implications:
a) When reading/writing cached data from device local storage we need to be able to read old versions of the data created by old versions of the app, and,
b) the service interface running on the server needs to be versioned carefully and multiple active versions may need to be available long term.
This also applies to desktop and web apps but is still worth mentioning since poor network connectivity is more likely. We take care to not block the user interface while network operations are completing since they may be slow or take minutes to time out. Users can continue to use the app while data is being uploaded or downloaded.
These are just some of the considerations that go into building an app such as RigRun. Mobile apps have additional constraints that you don’t often face with desktop or web apps. This makes them really interesting from a software engineering point of view – and at Codify we love the challenge!
We would love to hear from you. Email or phone us on 01224 976491
RSS