Plugin Creation Guide
smartCARS 3 is an Electron-based application that hosts sub-web applications internally. The system is divided into three basic layers or systems. All of the default plugins and the main web UI are written in React JS.
The Core
The smartCARS core is the main process and is responsible for primary data storage, responding to and hosting various local APIs, and loading other systems. Plugin developers will only use APIs provided by the core; none of its code is accessible to plugins.
The core also loads and hosts the web code sponsible for the main smartCARS UI. The web code provides the application frame, profile, radio player, settings menu, plugin UI, and the main menu.
All other content and functionality is provided via plugins.
Plugins
A plugin may consist of one, or both, of the plugin components: the UI and the background. At its simplest, a plugin is essentially a small website that is loaded into the smartCARS interface when clicked. This allows a developer to provide any interface or functionality they'd like directly within smartCARS using only HTML, CSS, and JavaScript.
A plugin UI, however, is volatile, meaning that it is cleaned up and removed from memory the moment a user navigates to another plugin or system (profile, settings, etc.) within smartCARS.
To account for this, plugins can also provide "background" code. Background code is JavaScript code loaded by the core of smartCARS and retained throughout the duration of the application's lifecycle. The background is where flight tracking, the connection to the chat server, and other critical, system-wide functions exist in the default plugins.
By sending data from the UI to the background, data can be retained and accessed by your plugin, or by other plugins (if desired), at any time.
Using a different framework?
React JS is not required for plugins, but is recommended.
Application Lifecycle
The standard smartCARS application and plugin lifecycle are as follows:
- A user opens smartCARS
- The core checks for updates and other critical runtime variables
- The core loads the web code and primary UI
- The user is presented with the login and VA selector interfaces
- The user logs in
- The core generates a list of plugins that should load based on user preference and VA settings
- The core determines what plugins must be installed or updated and does so
- The core sequentially loads the background code of each active plugin that provides any
- The main UI is presented and the user may begin to use the application
Starting smartCARS in development mode replaces step 6 by instead loading all plugins that exist on the computer at that time. It also disables plugin installation, uninstallation, and updating. To start in development mode, the application must be started with the '--local' argument (implying that the 'local' plugin list is the authority, instead of secure TFDi Design plugin storage).
Development mode
Although an important feature for developers, development mode allows any code in the plugins folder to be run without confirmation and should never be used on a production device.
Folder Structure
The smartCARS folder structure is as follows. By default, smartCARS is installed to "%localappdata%\TFDi Design\smartCARS".
From that main folder, plugins exist in the "dist\plugins" folder, each in their own subfolder named after their package ID (in the format of "com.example.pluginname").
Within each plugin folder there can be a "ui" and "background" folder, as required. The "ui" folder must contain an index.html and associated web interface code. The "background" folder must contain an index.js that contains the entry point for the background code.
In the root level of a plugin folder, a plugin.json file must exist with the required fields.