Electrode Native workflow
There are three main stages in the Electrode Native workflow:
- Stage 1: Create MiniApps
- Stage 2: Add or Update MiniApps
- Stage 3: Integrate MiniApps in a mobile application
Each stage requires different developer roles and expertise. Depending on the size of your organization or how your teams are structured, some developers may play a key role in one or more stages.
Please note that the worfklows described below are for illustration purposes only, and can serve as a basis to create your own workflow.
Everything starts with one or more MiniApps.
Experienced React Native developers won't notice much difference compared to their familiar React Native application development workflow. The Electrode Native workflow is very similar to the React Native workflow and most of the Electrode Native CLI commands are the equivalent to React Native commands.
Workflow for MiniApps development
- Create a new MiniApp project using the Electrode Native
ern create-miniappcommand. This command is equivalent to the React Native
ern addcommand. This command is equivalent to the
- Launch the MiniApp inside the Electrode Native platform runner mobile application. The runner allows you to develop, debug, and test the MiniApp standalone, using the
ern run-androidand/or the
ern run-ioscommands. These commands are the equivalent of the
react-native run-ioscommands. Ideally you should also test your MiniApp in isolation, using this runner project.
- Propagate your MiniApp releases to the mobile client application(s). You can either publish your MiniApp releases to npm or just let Electrode Native pick the changes from git branches or tags.
- Optionally, debug and test your MiniApp within the target mobile applications and not on its own in the platform runner. Since your MiniApp may co-exist with other MiniApps in the same mobile application, you will use the Electrode Native
ern unlinkand the
ern startcommands to help you in this use case.
Actor(s) Release Manager(s) / Mobile Application Lead(s) / DevOps
At Stage 2, you choose the MiniApps (and their versions) that you want to add to your mobile application.
Depending on your organizational structure and development operations, Stage 2 might be handled by a dedicated Release Manager or Mobile Application Lead. In some cases, Stage 2 could also be handled by MiniApps Developers.
This stage also includes shipping updated versions of MiniApps using Over The Air (OTA) updates through CodePush.
Most of the dependency versioning control of the platform takes place in Stage 2. This is also when the cauldron, manifest, and container generator also work hand in hand.
Stage 2 involves interacting with the Electrode Native cauldron commands.
Workflow for adding or updating MiniApps to/in a mobile application version
- Create new mobile application versions in the cauldron using the Electrode Native
ern cauldron add nativeappcommand. This command needs to be potentially issued for each new mobile application version.
- Add, Remove, and Update MiniApps for a target in-development mobile application version (shipped in a container) using the
ern cauldron [add/del/update] miniappscommands.
- Add, Remove, and Update native dependencies for target in-development mobile application version using the
ern cauldron [add/del/update] dependenciescommands (shipped in a container)
Note Native dependencies that MiniApps directly depends on are automatically added to the container when adding or updating a MiniApp version to a given mobile application version. This workflow item is therefore limited only to native dependencies that no MiniApps are actually depending upon--usually to add standalone native API implementations.
- Update the release status of mobile application versions using the
ern cauldron update nativeappcommand.
- Add or update MiniApps versions using OTA CodePush updates using the
Actor(s) Mobile Application Developer(s)
At Stage 3, Mobile Application Developers interact with the Container library only--which is shipped as an AAR file for Android, and as an umbrella Framework for iOS.
Also included in the container are the MiniApps assets (images and fonts mostly) and the initialization code-- to call from your mobile application to initialize the container and get access to the MiniApps stored within.
Stage 3: Workflow for integrating MiniApps in a mobile application
- Add a dependency to your container library in your mobile application.
- Add the required code to properly initialize the container.
- Bump the container version every time it gets regenerated--that is any time a new MiniApp (or native dependency) is added, removed, or updated.
- Launch the MiniApps when needed in your mobile application UX flow.
- Implement APIs in the mobile application itself if necessary--this is not the recommended way for implementing native APIs, but might be necessary in some use cases.
APIs facilitate secure interaction and communication between your MiniApps and your mobile application:
- For MiniApps, a native API can be consumed to access data or functionality from the native side or it can be used to trigger actions on the native side.
Workflow for generating and implementing APIs
- Create a new API using the
- Update an existing API using the
ern regen-apicommand. This should be done if you are adding new requests, events, or models to your existing API. Simply update the Swagger schema accordingly and invoke the command. You can then publish this new version of the API to npm.
- Implement an API. Because API generation and implementation are decoupled, the developer generating the API might not be the developer actually implementing it. You can kickstart an API implementation project using the