Multiple Backend Environments #6
diegolavalledev
announced in
Posts
Replies: 1 comment
-
|
This very comment will be picked up and counted by the Discussions Sample App 🤯 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Originally published on diegolavalle.com.
In this article we are going to discuss the solution implemented by the Discussions sample app written with SwiftUI. The app was created for the single purpose of devising a practical yet powerful mechanism for controlling which API environment the data will be loaded from.
Sample app functionality
Discussions fetches the comments made to this post over the network and displays the total on screen. The footer tells us which specific endpoint this information is being retrieved from.
Network settings
We will specify the API endpoint as part of a
NetworkSettingstype which serves as a descriptor format.This allows us to group the sets of URLs which conform the different backend environments. The available environments are:
Controlling the environment
The primary way in which we will control the API endpoint is through an environment variable in the scheme. By creating a scheme for each backend we can easily launch the app with the desired setting.
To keep the setting in between app launches we will simply save its value in app storage – a.k.a. user defaults – and this will also allow us to test while detached from Xcode.
A basic settings bundle can give developers and QA engineers more control by allowing them to change the environment on-the-fly.
Default environment
To make things more interesting we are going to define different environment settings for each of the standard build configurations.
Release– which is use for archiving and distribution – will obviously hit production servers.Debugon the other hand will point the app to the testing version of our API.Note that this does not require to replicate or create non-standard configurations or targets, nor it utilizes Xcode configuration files. We simply achieve this functionality by adding a user-defined value to our project's build settings which we will later pick up from the information property list (
Info.plist).Conclusion
This way our solution is complete leaving us with a great tool that does not sacrifice any other aspects of our developer experience.
Let me know in the comments whether you were able to implement this technique in your own project.
Beta Was this translation helpful? Give feedback.
All reactions