Structure of Dynamic resources
Dynamic resources are the core of each app. The dynamic resources are files based on web technologies, that can change some configurations (e.g. App Menu, Channels, Tracking, …). The app checks for updated dynamic resources on every app start and resume. This mechanism allows you to edit files on the fly, without submitting an app update.
Dynamic resources are accessible in the following ways:
- Via Purple Manager: They can be downloaded from the Purple Manager, where a Preview- and Live version of the resources exists. Learn how to edit Dynamic resources from Purple Manager
- Via Purple Experience Builder: Furthermore, they can be accessed via the Purple Experience Builder, which is a Web application in which the editing happens and doesn't require the down-and-upload of the files. Learn how to edit Dynamic resources in Purple Experience Builder
Learn more about the structure of dynamic resources.
Dynamic resources consist of files that aid in configuring both the app and the web experience. Changes to the app configuration (such as the App Menu, Channels, Tracking, etc.) within the dynamic resources do not necessitate submitting an app update. The app checks for updated dynamic resources each time it starts or resumes.
Web configuration elements (including views, custom JS and CSS files, etc.) are necessary for both the app and the web. They assist in constructing the entire logic of the app/website.
The minimal setup of the dynamic resources requires a default folder that contains the configuration files.
You may add platform-specific configurations. This is done by adding some platform folders such as 'android', 'ios' or 'web'.
If two folders contain the same file, then the more specific file overwrites the more generic one, e.g. some file in default gets overwritten by the same file from android.
Example
Let's imagine the following folder structure:
- default
- storefront
- assets
- file1.css
- file2.css
- web
- default
- storefront
- assets
- file1.css
When reading the path storefront/assets/file1.css from Android or iOS, for example via the URL resource://dynamic/storefront/assets/file1.css it will give you file1.css from the default folder. For Purple Websites, as a file of the same name is present in the folder, you will be served file1.css from web/default/storefront/assets/. At the same time, file2.css is not overridden in the web-specific folder and thus will be the same on all platforms.
Localization currently is only supported in apps! You still should set a locale for your website as well to ensure proper SEO indexation and accessibility.
It is possible to add translations by adding folders such as de, en, or de_DE, en_US next to the default folder. Depending on the device's preferred languages, the app loads the best-fitting configuration files from these folders. In earlier Android versions, only the device’s system language is used. The look-up happens in the following way:
For each of the system’s preferred languages, check if there is a folder that
- matches the exact locale (e.g. de_DE or en_US)
- matches the exact language (e.g. use en folder for en_US)
- uses the same language but a different region (e.g. use en_UK folder for en_US)
In the case that there is no matching folder, the configuration falls back to the contents of the default folder.
The app’s side menu can be configured using the app_menu.xml file. For a detailed explanation of all its features and configuration, see App_menu.xml.
It is possible to place a config.json in the dynamic resources. This is a simple key-value file which can be used by the app for some dynamic configuration.
The onboarding_version key is used by the app to determine the version of the current onboarding.
The tracking is configured by editing tracking_config.json. For further details about configuring tracking.
The feedback e-mail can be configured using the email_feedback_config.json, email_feedback_subject.mustache and email_feedback_body.mustache files.
Most of the web configuration files are situated under the path default/storefront/assets in the Dynamic resources. These files are divided into three categories:
- JSON files: These files contribute to constructing the entire app and its various components. Examples include views.json, url.json, and appbar.json.
- CSS files: These are intended for adding custom CSS to override the default styling of the experience components.
- JS files: Generally used to introduce custom features and interact with third-party elements (such as Zephyr).
It represents the list of configuration files (JSON files) that need to be imported into the app.
It contains a list of views. Each view is assigned to a path and represents the routing logic of the app. Each view has a root layout that may contain other layouts and components. The views.json is a JSON file located under storefront/assets where you can store all views.
Every view is expected to have an app bar. The appBar.json file assists in incorporating a collection of appBars that are utilized in conjunction with the views.json file within the app.
This file aids in configuring all advertisements within the app. Subsequently, you only need to integrate each ad into its appropriate position within the view.
assists users in overriding all default messages defined in the Experience. Additionally, it enables the creation of new messages that can be utilized in the views.json file. These messages will be translated according to the language set in the Purple Manager.
It enumerates all the tab navigation items intended for display within the app.
It assists users in configuring some of the basic actions of the Experience, such as LoginAction and SubscriptionAction.
It aids in configuring multiple widget libraries and widget elements for utilization in the views.json.
Its purpose is to establish certain global variables and properties that are currently absent in the Purple Manager for Experience.
It is a CSS file that gets injected directly into the Experience DOM during the view-loading process. This file is generated based on all the other CSS files listed in the index.scss.
This is a JavaScript (JS) file that is injected directly into the Experience Document Object Model (DOM) during the view loading process. Customers utilize this file to include custom functions and logic that aren't accessible to the current components and features of the Experience.
Experience components are the principal entities used to create a view. They represent the Experience UI widgets implemented in the Experience Project. Depending on the component type, you can find embedded components and views within it.