App Development Guide

Overview about the 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.

Content

App Services (C++)
Links to documentation needed to program an app service in C++
App Services (JavaScript)
Links to documentation needed to program an app service in JavaScript
Apps
Links to documentation needed to program an App
APIs for communication between components
APIs provided for Apps and used by the different modules themself

App Services (C++)

Overview

App Platform Libraries and Interfaces

Interfaces and Libraries for App Services

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.

Assynchrous programming environment

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.

PBX manager plugin

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.

App Services (JavaScript)

Overview

Interfaces for JavaScript app services

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.

Components

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.

PBX manager plugin

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.

Apps (Javascript)

Overview

Libraries for apps

innovpahone.lib1 Javascript library for apps
innovpahone.ui1 Javascript library for user interfaces

APIs for communication between components

Overview

API-Architecture

List of APIs

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