SOFIE Implementation
Registration steps for third-party apps with the Sunbird platform
Each third-party app should be registered with Sunbird to enable integrations. Registration aims to verify the authenticity of the app providing integration/extension to sunbird and also allow policy-makers (of the sunbird instance) to do an appropriate review and accept the integration.
Following is the info/specification required for the registration
{
name: "", // Required. Name of the app. For ex: "Sunbird ReadAlong"
logo: "", // Required. Logo of the app. This is used to show the user to select the extension app he chooses to open with.
provider: {
name: "", // Required. Name of the company that has built the app
copyright: "", // Optional. Any copyright information to be shown
license: "" // Optional. License of the app.
},
osType: "", // Required. OS of the App. Android/iOS
osMetadata: { // Required. Metata of the OS
packageId: "", // Required. A fully qualified app name matching the play store app id. For ex: "com.sunbird.readalong.app"
appVersion: "", // Required. Version of the app. Sunbird uses this to check if the app is installed locally
urlScheme: "", // Required for iOS. The URL scheme of the app. Used for the app invocation.
compatibilityVer: "" // Required. Compatible with which version of sunbird app.
},
target: {
mimeType: [...],// Required. Supported mimeTypes
primaryCategory: [...] // Required. Supported primaryCategory
}
actions: [ActionData] // Actions to register with
}For example, suppose a third-party app called "ReadAlong" wants to integrate with Sunbird. So "ReadAlong" team can approach the Sunbird team and can provide the above info about "ReadAlong". On the mobile app side, the following form is used to fetch all integrated apps.
Once the form is updated the form should look like following
Technical Specification for third-party apps
Every app that registers with sunbird would register for the actions supported by the app. For ex: Let us assume that the sunbird app at the content level supports actions such as "open" and "share". Any extension app which registers for these actions would be shown as available options to the user when the corresponding actions are triggered.
The technical specification is broken down into the following sections:
Action Data Structure:- Structure of the action data
Integration specification:- Data specification of integration
Integration via intent:- Data specification for integration via intent
Integration via deep link:- Data specification for integration via deeplink
Action Data Structure
Following is the structure of generalized action data for which an app can register for.
Integration specification
Following is the specification of the integration, the data to be passed from one app to another
Integration via intent
Following is how the specification is transformed when integrated via intent.
Example
Integration via deeplink
Following is how the specification is transformed when integrated via intent.
Example
Last updated