For example, React Native itself will be a native dependency of the mobile application. It contains some native code that is going to be compiled and shipped within the binary of the application. Given that it is a native dependency, there can be only one version of it included in the mobile application at any given time. An iOS or Android mobile application cannot include two versions of the same native dependency. To illustrate this, A mobile application cannot contain React Native 0.42.0 and React Native 0.43.0 at the same time. This is not a restriction of Electrode Native, nor React Native, but just the way mobile applications work regarding native dependencies.
On top of React Native itself, other native dependencies used by MiniApps can be either third-party React Native native modules supported by the platform (
react-native-maps for example) or can be platform-generated APIs or API implementations.
Because of this constraint and the fact that the Electrode Native platform allows you to package multiple MiniApps from different repositories into a single native library, Electrode Native offer support to help align the native dependency versions across all MiniApps as well as guarantees that no MiniApp with a non-aligned native dependency version will make its way into your mobile application.
This support is provided through two modules of our platform: the Electrode Native manifest and the Electrode Native cauldron.
The manifest is a GitHub repository containing data used by Electrode Native. The data can be updated at any time without having to wait for the next platform release.
This section describes the
manifest.json file that is stored in the Electrode Native manifest repository.
manifest.json file contains a list of native dependencies along with their versions that are supported by a specific Electrode Native platform version. When you use the
manifest.json file--otherwise it's not supported yet. If the dependency is declared in the manifest, Electrode Native installs the specific version listed in the
Electrode Native also queries the manifest repository when you use the
ern create-miniapp command to know which version of React Native to use.
Thus any MiniApp developed using a specific Electrode Native version will be properly aligned to the same native dependencies versions.
If you are a MiniApp developer intending to release open source MiniApps, then you'll want to make sure that you use the
ern add command instead of the
yarn add or
npm install command--and that you upgrade the native dependency versions of your MiniApp to any new release of the platform. Use the
ern upgrade-miniapp command to easily upgrade the native dependency versions to a new platform release.
Electrode Native allows you to override the master open source manifest with your own private manifest. This is helpful if you work with private, non-open sourced native dependencies or if you want to stick to a specific React Native version for a while. Indeed, with each new release of the platform, the master manifest will be aligned with the latest available version of React Native, which might not be what you want.
The Electrode Native cauldron is also a GitHub repository and at its core is the
cauldron.json file. However, unlike the manifest, the cauldron should not be updated manually. The cauldron should only be accessed and updated using the
ern cauldron subcommands. The cauldron repository will also be your own, as a cauldron is bound to a mobile application.
The cauldron is a simple document database, which doesn't come with the downside of having to install and set it up on a dedicated box, as it is just hosted in a git repository.
For each mobile application version, there will be a corresponding entry in the cauldron database. For example,
Walmart iOS 17.14 or
Walmart Android 17.10.0.
The cauldron stores specific information pertaining to each version of your mobile application:
A list of all the MiniApps (and their versions) that are part of any given version of your mobile application(s))
A list of all native dependencies (and their versions) used by these MiniApps
This is mostly all what's needed to generate a container library.
Every MiniApp that needs to be added to your mobile application will first need to be added to the cauldron. The cauldron, in addition of keeping track of what is included in your mobile application versions, also acts as a "gatekeeper" to verify native dependencies versions before adding a MiniApp version to a Container (or deliver it through an OTA update).
Because the cauldron verifies which MiniApps versions and native dependencies versions are part of any given mobile application version, it can perform necessary version control checks whenever a MiniApp needs to be added to a mobile application version. Before allowing entry of the MiniApp in the cauldron, checks are performed to ensure that the versions of the native dependencies used by the MiniApp do not conflict with current native dependencies included in the targeted mobile application version. This should not happen often if MiniApps are correctly created based on a manifest--but this can happen, so we prefer to be extra cautious and perform final checks at the cauldron level.
All OTA MiniApps updates move through the cauldron first as well so that Electrode Native verifies whether or not it contains any conflicting native dependencies versions with the targeted mobile application version.