Concepts & Architecture

EXP App Config

9min

While primarily intended for pre-built NativeWaves experiences, it is important to note that if you develop your own custom experiences, you can still make use of the same EXP app config and the token and design system employed by NativeWaves. This allows you to harness the existing features and seamlessly integrate your custom experiences within the NativeWaves ecosystem.

The EXP app config enables remote configuration and control of pre-built NativeWaves experiences. It handles theming, customization options, and more, providing a centralized platform for easy management.

The term "app config" refers to the configuration of the EXP system within an application powered by NativeWaves EXP rather than a general application configuration.

For example, if you want to integrate NativeWaves EXP into your own app that runs on multiple platforms e.g. iOS, Android, Web, Samsung Tizen, LG webOS you would usually setup just one EXP app config that is used on all platforms.

Here are some key components found in the EXP app config:

  1. Design Sets and Themes: changing color, typography, and more as described in the Theming & Customization section
  2. EXP Handlers: define the logic on how experiences are being handled based on a defined ruleset
  3. Branding: adding customer logos as well as other branding-related customizations
  4. Features: enable/disable features that should or should not be used in the experience, e.g. Live Chat, Second-screen Sync

The system's flexibility is further enhanced by the configuration ruleset associated with most components, enabling the activation of specific configuration sections based on metadata in the EXP manifest.

The core of this flexibility revolves around matching specific tags found in the EXP manifest called "EXP Tags". These tags can be manually assigned to an SMEP event, which then seamlessly carries over to the EXP Manifest. Additionally, the event worker is equipped with the ability to detect relevant tags based on metadata. For example, if a football data Id is linked, the event worker automatically adds the "football" tag to the manifest.

For a full ExpAppConfig JSON Schema please check out our EXP API definition: https://exp.api.nativewaves.com/swagger/index.html -> Schemas (in the bottom of the page) -> ExpAppConfig

1.) Design Sets and Themes

Design Sets containe multiple token values for various configuration options. These token values are used in the experience to substitute color values, typography, and other design-related elements. The implementation of these design sets is specified in themes, where rule logic determines the conditions under which each design set should be activated.

Design sets and themes are completely optional, and the NativeWaves "default theme" serves as the baseline. Therefore, every token definition within a design set is optional, as the EXP system defaults to a predefined value if a token is not explicitly defined.

Design sets and themes can cater to various use cases, illustrated by the following examples:

  1. Adjusting the NativeWaves "default theme" to align with the style of my existing app by overriding specific values.
  2. Addressing specific needs for particular event types through the utilization of a dedicated theme. Additionally, leveraging ExpTags in theming rules enables support for special use cases, such as loading a theme when a specific football team tag is present in the EXP manifest for e.g., a special sponsorship deal.
  3. Enhancing flexibility by combining multiple design sets. For instance, establishing a foundational design set that aligns with the overall app style, while also defining sets tailored to specific event types. These sets are then combined in a separate theme, loaded exclusively for those event types through the rule system.

Here an example of an EXP app config that defines design sets and themes:

Design Sets and Themes Example


The following defines how the rule logic operates in the case of themes, however this is also applicable to the rule logic of other elements in the config:

  • Themes at the bottom of the list are evaluated first and then the list is processed backwards.
  • Only one theme will be selected, if a match is found, evaluation is stopped and this theme is used.
  • Multiple rules can be defined for each theme
  • Per default, if any of the rules matches, then the theme is selected (= OR)
  • Depending on the element, rules can have different properties. In this case, the theme rule has the property includesExpTags. The rule will match if all tags in the specified list (= AND), will be present in the tag list of the EXP manifest.
  • If includesExpTags is empty it won't match against anything
  • Wildcards, such as "football*", are supported, enabling matches with tags like "football," "football-bundesliga", ...

For instance, in this scenario, "theme2" will be chosen if an EXP manifest includes both the "tennis" AND the "custom-tag-01" tags. In the case where the EXP manifest only contains the "football" tag and no other tags, "theme1" will be the selected theme. If the EXP manifest incorporates all three tags - "tennis," "custom-tag-01," and "football" - "theme2" takes precedence as it is evaluated first and matches the criteria.

A single theme can load multiple design sets, with sets positioned at the bottom of the list exerting precedence over those at the beginning. For example, if "theme2" is selected then the token value for "Button/Navigation/Primary/Fill/Active" in design set "set2" overrides the token value in "set1".

2.) EXP Handlers:

EXP Handlers represent a logical abstraction of the underlying code logic designated to manage a particular experience. Based on the integration, specific code logic can be applied, for instance, tailoring the logic for a football experience as opposed to a racing experience to optimize for each specific event type.

This distinction becomes particularly beneficial when integrating with data providers that exclusively support specific event types, with designated EXP handlers aligned to support those providers.

It also facilitates variations in the user interface and its elements. Consequently, the timeline section of a football experience may exhibit a distinct appearance from that of a motor race, and the sidebar options might differ, with a motorsport experience emphasizing a ranking list, while a football experience shows general match and team information.

Here an example of an EXP app config that defines EXP handlers:

Design Sets and Themes


The rule logic is the same as the one used for themes. The EXP system assesses each EXP handler entry, beginning from the bottom, attempting to find a matching handler to utilize. Subsequently, the system activates the corresponding code logic based on the "id," identifying the EXP handler and associated with its implementation. This flexibility accommodates the incorporation of custom handlers for the implementation of a custom experience.

The specification of EXP handlers is entirely optional, and the system defaults to a default EXP handler, offering a generic feature set not specifically optimized for any particular experience type.

3.) Branding

Currently work in progress, please contact our support if you have questions.

4.) Features

Currently work in progress, please contact our support if you have questions.