Skip to main content

iOS - Module Settings

As part of setting up module, you will be already configured with required settings for your module in settings.json. But if needed you can update configuration by following this documentation.

q2-demo-ios
├── Package.swift
├── q2-demo-ios
│   ....
├── Q2DevApp
│   └── Q2DevApp.xcworkspace
├── ....
└── settings.json

As understood earlier settings.json determines existence of your module and loading at run time if correct values are configured with "modules" node.

modules Sections in settings.json​

This is an array of objects, and it’s one of the most important parts of the configuration. It defines the modules that will be loaded into the DevApp. When you develop a new module, you will add it to this section. We will discuss how to configure this section in detail below.

Example of settings.json​

Below is an example of a typical settings.json file for DevApp:

{
    ...
    "modules": [
        {
            "packageName": "q2-demo-ios",
            "productName": "Q2Demo",
            "className": "Q2DemoModule",
            "identifier": "com.q2.mobile.module.demo",
            "enabled": true,
            "data": "{
                \"my_data_key\": \"my_data_value\"
            }"
        }
    ]
}

Understanding the modules​

The modules section contains an array of objects that define each module to be loaded into the Q2DevApp. Let’s break down the structure of each module:

Key Fields for Each Module in modules​

  • packageName This field will be the name of swift package module. Example: q2-demo-ios

  • productName This field will be the name of library product within swift package module. Example: Q2Demo

  • className This field will be the name of entry class of target specified in library product within swift package module. Example: q2-demo-ios

  • identifier This field is used by Tecton and other external sources to locate and call the module. It uniquely identifies your module. It is best to prefix it with the com.q2.mobile.module and should kept in sync with android. Ideally, avoid uppercase as this is case-sensitive.

    Example: com.q2.mobile.module.demo

  • enabled This boolean flag determines whether the module is active in the application. If set to true, the module is included in the build. If set to false, it will be excluded.

  • data This is an object where you can pass additional configuration data for the module. This is useful if your module requires custom build-time data.

    Example: If your module will be installed in several FI applications and you need to pass a key for each one, this is how you can do that.

When Creating a Module​

When you create a new module class, it must be added to the modules section for it to be loaded and used by Q2DevApp. You’ll also need to ensure that all necessary fields are correctly populated.

Key Considerations​

  • nativeLogin and push flags can generally remain set to true unless you are specifically told to disable them.

  • targetURLBase should ideally point to your sandbox environment to match your development setup. However, it can also point to other environments if needed.

Conclusion​

By understanding and configuring the settings.json file, you ensure that your Q2DevApp setup is correctly aligned with the Q2MobileApp environment. This configuration allows you to maintain a consistent development experience and ensures that your modules are properly integrated into the app.