The layout and functionality of apps and web experience sites can, to a great deal, be changed without the need of resubmitting the app to the app stores. This way, changes to the apps experience can be performed fast and cost-efficient.
The dynamic resources of an app consist of a repository tree. There is usually a "default" folder, which contain most resources.
There may be folders named after ISO-639-1 codes as siblings of the "default" folder. Files from these folders override their correspondent files, if the selected language of the app or browser corresponds to the folder name.
This is not working for web experience yet.
There may be folders named after the supported platforms (android, ios, web) as siblings of the "default" folder. These folders contain a folder structure similar to the original folder structure, thus beginning with another "default" folder and optional language override folders. Any files placed in the platform folders override the correspondent files in the "default" folder for the particular platform.
Given the following folder structure:
- a user on an English Android device would see the default menu,
- a user on an English iPhone would see a specialized menu for iOS and
- a user on a German Android device or iPhone would see the menu from the "de" folder (as there is no "ios" override for the "de" version of the file)
Dynamic resources for apps and web experience sites are stored in git repositories. The chosen git provider is AWS CodeCommit. There is one git repository per team.
Git is not yet the default to store dynamic resources. Most resources are still kept in zip files to be uploaded to the Purple Manager.
It can be enabled for an App on the dynamic ressources view of the Purple Manager.
In the team's git repository there are 2 branches per app, one release branch and one preview branch. We take care of deleting these branches when an app is deleted and moving them to another team's repository when the app is moved.
Committing to any branch leads to creation of new resource zip files for Android and iOS apps. Theses zip files are stored at the team's Amazon S3 and a reference is stored in the database. If web experience is configured for the app, all single resource files appropriate for the "web" platform are stored at the team's Amazon S3, references to the single files are stored in the database and a message is sent to a kafka topic, which contains the names of all provided resource files and the paths to load them from S3 via Cloudfront.
By tagging commits of these branches with version numbers, existing apps can be forced to load older versions of dynamic resources, while a new version of the app loads the current head versions of the resources.The tag name must follow this scheme: <app-id>_[preview|release]_[ios|android]_<version> e.g. e8fea93e-444f-4137-a96d-5a455150ffb0_preview_ios_1.2. It's easiest to create these tags in the Purple Manager by setting a "Max Version".
When an app is created, the preview and release branches are set up by copying the heads of the appropriate branches of the chosen template app. Thereby, the preview branch is branched from the release branch.
When an app is created by cloning an existing app, it's branches start at the current HEAD versions of the cloned app branches.
TODO: Check if this leads to problems if such apps are moved to another repository later. Will copied commit IDs clash?
Dynamic resources for apps are stored as zip files in the team's Amazon S3 bucket and delivered through Cloudfront. The path to the appropriate zip file (for platform and version) is provided on request by the GraphQL Catalog-API. Therefore the app requests the resources "last change" timestamp for it's platform and version at app start. If it differs from the previously stored timestamp, it requests the new zip file and stores the new timestamp. This means that old versions of resources can be delivered as well if they are tagged with the appropriate app platform and version.
Dynamic resources for web are stored in the team's Amazon S3 bucket and delivered through Cloudfront. The names and Cloudfront paths of all resource files are sent to a kafka topic, where the rendering engine can subscribe to receive them.
TODO: Describe how the localization works.