Appdome is a mobile integration platform as a service (iPaaS) that allows users to add a wide variety of features, SDKs, and APIs to Android and iOS apps.
This Knowledge Base article provides details on one of the core elements of the Appdome platform; the Fusion Adapter.
We hope you find this knowledge base useful and enjoy using Appdome!
About The Fusion Adapter
The Fusion Adapter is a user-defined, user-driven software adapter that is added as part of a newly compiled app binary, created when you fuse an app.
Each Fusion Adapter is unique and is dynamically generated based on the service integration choices a user makes on the Appdome platform. As the user selects feature sets, the system assembles the Fusion Adapter and fuses the adapter to the mobile app(s) chosen by the user.
Each Fusion Adapter has static and dynamically generated parts as shown in the schematic below.
In the center is what we call “User Defined Service Engines.” A service engine is added only if a user selects a service to be integrated (aka fused) to an app. For example, only if a user selects features from the Appdome Mobile Security Suite will a Security Service Engine (shown above) be added to the adapter. If the user selects an EMM SDK from the Appdome Platform, only then will a Mobility Management Service Engine be added to the adapter. This is a core design principle for Appdome. When you fuse an app, YOU are in control. With Appdome, you get exactly what you ordered, nothing more and nothing else. The end result is not only a model that is driven by choice but also efficiency.
When more than one service engine is present in an adapter, the Appdome platform adds a set of code called the DFS, or Dynamic Function Scheduler. This unique codebase manages conflicts, interactions, and priorities between each service engine. For example, it evaluates features a user selects and compares them to native OS functions that perform the same functions. Conflicts can also be exposed to allow users to set priorities during the fusion process.
In order to communicate with the mobile app, the Runtime Integration Module interacts with the app on a runtime basis, substituting intermittent commands based on the app’s native logic. The Appdome platform does not change the app binary or inject code into the app binary. The app’s native functions are preserved, conforming the SDK to the way an app works instead of forcing the app to conform to the SDK. The commands are semi-permanent, meaning they exist only as long as necessary to perform the function requested.
Above and below the Fusion Engines in the diagram, there are the Fusion Service Layer and the PosixMAP layer. The Fusion Service Layer encrypts and protects the fused app. It also has basic account identifiers, fingerprints, and other features that communicate with our Service. The PosixMAP Layer allows the Fusion Adapter to communicate with the OS independent of the app, to ensure the app behaves and performs as expected, thereby preserving a great user experience.
Bear in mind that the “your app binary” shown here to the left, is just a binary. There is no source code needed. Interested? Awesome!
How Do I Learn More?
If you have any questions, please send them our way at firstname.lastname@example.org or via the chat window on the Appdome platform.