Building Dynamic Apps

Today I will talk about how you should always try to make your mobile apps as dynamic as possible. This actually applies to all IT solutions, but is especially relevant for apps as they often need to support multiple platforms and are not possible to update instantly.

First of all, when you’re about to implement some new functionality in an app, you should always ask yourself if it can be implemented on the server side instead. As the probability is increasing that there will be more than one type of device (or channel) providing the same functionality, anything that can be implemented on the server side does not have to be duplicated on each platform. Duplication does not only create extra efforts (in development, test, maintenance, etc) and cost, but will also increase the risk that the implementations will be different, which could be very serious. Another reason for putting as much as possible on the server side is that the processing power is many times higher than on a mobile device. This will become even more significant with the increasing number of very simple devices that form the Internet of Things.

The next thing you should ask yourself when implementing something static in an app is whether it can be made dynamic instead. A typical example is when entering a string of text in your code that will be visible to the user, like a label or error message, and it’s often a minimal effort in any mobile development tool to put that string in a separate file that can be translated. A nice detail when building native apps for iOS is that the only thing a developer needs to do is add the NSLocalizedString macro to each string, and the separate file for translation can be automatically generated with a tool (that even avoid abstract constants). Doing it during the initial development doesn’t add any significant effort, but to add this support later could take considerable time. Another example is when you are implementing a status flag, which should have two values, and it therefore seems obvious to choose a true/false (Boolean) data type. But you should ask yourself if there could ever be another status, even if the requirements are clear that there are only two statuses. If so, you could use an integer data type instead, and be prepared for the future. In this example it would be even better if each status had an enumerated value.

This becomes even more important when you have something that seems like a static range of values, but that will probably change over time. An example is a number of categories in a news feed, like “Breaking”, “Politics”, “Sports”, etc. These categories should probably be retrieved from the server, and then be used to populate the user interface. However, you probably don’t want to get these categories all the time, only when they change, so it’s a good idea to use something like Conditional GETs. More importantly, the adding and removing of categories may affect the user interface, and therefore it’s necessary that the implementation is made so that it can handle any number of categories, and still both look and function well.

A final example is when you have longer static formatted texts that are to be read by the user, like terms, instructions, and general information about the app. Such texts are probably best to put as a web page on the server, and presented to the user in a web view. The web page should preferably have a responsive design, so that it adapts to different screen sizes.

So that’s how you can make your mobile apps as dynamic as possible.