Overview about the structure of app services (C++ or JavaScript) and apps (JavaScript) and the libraries and APIs that are provided by the SDK for building them.
For the implementation of app Services, to enable communication between App Services or the App Services and system components of the App Platform (without any need for Linux knowledge) and also to support recurring and complex tasks this SDK provides you with a bunch of interfaces and libraries listed below:
| App Service Interfaces (1) | The App Service Interface is fundamental to implement your own App Services. |
| App Platform Libraries (2) | App platform libraries provide access to complex functionality that is recurrently needed using App Platform interfaces. |
| Standalone Libraries (3) | This is a very portable library for some fundamental features, like string manipulation, json encoding/decoding, binary trees and much more. It is a library also used within the innovaphone firmware. |
| App Platform Interfaces (4) | These libraries provide easy access to core components of the App Platform, such as Webwerver, Database, Sockets. |
The innovaphone SDK is designed to completely work in an asynchronous, non-blocking way. Each IO operation is asynchronous. Same for timers and exec callbacks, used to call a function asynchronous. All of that is controlled by the IIoMux instance of an AppInstance. Because of this, the IIoMux instance must be passed to nearly all interfaces on creation. The interface will take care of registering and unregistering itself to the IIoMux instance.
So each apps needs to be design with the same manner, too. That means, that the app must implement good flowcontrol to not loose control of what is going on. Because of this, each nearly Interface has also a User class (generally with the same name as the interface, only starts with 'U' instead of 'I' - e. G. ISocket and USocket). The app must provide classes that will be subclasses of an user class and pass an instance of that user to the Interface when creating. So for example, if an application creates an instance of IHTTPClient, it must pass an instance of a subclass of UHTTPClient. That subclass needs to implement all callback functions that are of interest for the app. More information of what functions must be overwritten and what functions having default implementation, can be found at the description of the interfaces.
Generally, each asynchronous function will lead in an result callback function (e. G. Send() -> SendResult()). If an app calls Send() of an interface that provides a Send() function, the app should wait until the SendResult() callback had been called before sending the next part. Doing this helps to have non blocking operations. The same is for Recv(), which will call a RecvResult() callback function if data had been received. While waiting for data to receive, the application can still handled other stuff (e. g. Recive a Websocket message). Each application instance has an IIoMux instance, which finally will handle each type of connection, inform each interface of data that is available, handles timers and Execute-Callbacks, which can be used to call a function asynchronous.
Each app service should provide a plugin for the PBX manager that is used for the configuration by the admin. It can be used to change the settings of an app instance and to maintain the corresponding app objects in the PBX. See PBX Manager plugin for details.
For JavaScript app services all the source code and the web files are packed into an archive (httpfiles.zip). The archive is uploaded to the App Platform together with the JavaScript Runtime - a generic app binary provided as part of the SDK. The runtime reads the files in the archive, hosts your web app and runs your app service scripts using a JS interpreter.
See JavaScript Runtime for details.
| config.json (1) | The manifest for configuring the app service. |
| plugins.json (2) | The manifest for configuring the PBX Manager plugins of the app. |
| Own app code (3) |
The app and its structure does not differ depending on the used language for the app service. It can use the regular libraries for apps. Additionally the runtime provides common workflows that can be used from the app by sending pre-defined AppWebsocket messages to the app instance. |
| Own app service code (4) | Additionally you can script your own app service flows with the library provided by the runtime. |
Each app service should provide a plugin for the PBX manager that is used for the configuration by the admin. It can be used to change the settings of an app instance and to maintain the corresponding app objects in the PBX. See PBX Manager plugin and plugins.json for details.
| innovpahone.lib1 | JavaScript library for apps |
| innovpahone.ui1 | JavaScript library for user interfaces |
| Client APIs and Launcher Services (1),(2) | Client APIs are used for communication between (web-)apps running in the myApps Client. |
| PBX APIs (3),(4),(5) | PBX APIs are available on all websocket connections to the PBX (PBX App -> PBX, App Object->App Service) |
| Service APIs (6) | On the App Platform, Service APIs are used for communication between app services |