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.
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.
Let's craft delightful digital experiences together.
Tell us more about your vision.