Overview about the the structure of app services (C++) 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 recurringly needed using App Platform interfaces. |
| Standalone Libraries (3) | This is a very portable libray 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 completly work in an asynchronous, non-blocking way. Each IO operation is asynchronous. Same for timers and exec callbacks, used to 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 informations 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 nexxt part. Doing this helps to have non blockng operations. The same is for Recv(), wich 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, wich 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.
| 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 |