This article explains the strategy that an app developer can adopt for working with different server configurations, without having to create multiple builds of the app pointing to different servers.
Almost every mobile application that is being developed nowadays has a server backend involved (unless you are using ready made backend frameworks such as Parse, App Engine etc). Most often, there will be multiple servers such as testing server, staging server that the server development team uses during their development life cycle before deploying it on the production servers.
For a mobile app developer it’s a hassle to create multiple builds with each one pointing to different servers. Besides it’s a nightmare for the various stakeholders to keep track of which build they are using. This often leads to invalid testing configurations wherein a tester might be testing a feature of the app on a server which may not have that feature deployed. This creates endless conversations between the development team and the testing team leading to reduction in productivity, not to mention the frustration involved in such discussions. A lot of these woes can be avoided by using a concept of customisable server settings in the mobile application.
The idea is to provide an option for the user to choose a server configuration when testing the application. A server configuration in its simplest form can be just a string that specifies the server URL. You can use a dictionary object instead of a string to encapsulate a server configuration to specify additional parameters such as custom headers to be passed to different servers. A property to indicate which server configuration is the production one can also be specified in the dictionary.
Multiple server configurations can be specified using an array or a dictionary. A corresponding data model can be used to encapsulate this configuration and a controller can be implemented to select a particular server configuration at launch time. This selection can be done in the form of an action dialog after the launch of the application and before any server calls are made. After the user chooses a server configuration all network calls to the server APIs should use the selected server configuration as the host for the url.
For instance, say you have 3 different servers that are used for the server development. Staging1, Staging2, Production.
- Create a property list file that contains an array or dictionary of server configurations. If you are sensitive to exposing the urls in a plist that becomes part of the app bundle, you can hardcode it in the app. This example uses a dictionary to hold the configurations.
- Implement a server configuration model to represent this plist. You can implement methods to get the production server configuration using the isProduction property.
- Implement a simple controller or a method that will present this model in the form of a dialog allowing the user to choose a single server configuration. You can either use a action dialog or present it as a list if there are many server configurations to choose from.
- Bring up the dialog during the first launch of the application. If your application does not server configuration persistence then you can bring it up every time the app is launched. Otherwise you can store the selected configuration in a preference and then avoid this dialog from being shown every time the app is launched.
- Make all server endpoint creation logic to make use of the selected server configuration. You can either use the array index or a dictionary key to determine the server configuration that the user has selected.
- You can also use the server configuration to specify additional parameters such as Authorization header or other custom headers as required by your server.
- To identify which server configuration the app is currently using, display the server configuration information in some part of the app such as the About screen or the Settings screen. This will help the testers identify which server the app is currently pointing to.
- Make sure that you don’t present this dialog in the production version of the app. Also you can choose the production server configuration by default in the production version of the app by iterating the server configurations and selecting the one with isProduction set to true.
By using strategy you can easily switch between the various server configurations without having to create multiple builds. Changing, adding, deleting servers will also be easier.
