diff options
Diffstat (limited to 'src/interfaceframework/doc/src/extending-qtif.qdoc')
| -rw-r--r-- | src/interfaceframework/doc/src/extending-qtif.qdoc | 108 |
1 files changed, 0 insertions, 108 deletions
diff --git a/src/interfaceframework/doc/src/extending-qtif.qdoc b/src/interfaceframework/doc/src/extending-qtif.qdoc deleted file mode 100644 index bca6d955..00000000 --- a/src/interfaceframework/doc/src/extending-qtif.qdoc +++ /dev/null @@ -1,108 +0,0 @@ -// Copyright (C) 2021 The Qt Company Ltd. -// Copyright (C) 2019 Luxoft Sweden AB -// Copyright (C) 2018 Pelagicore AG -// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only -/*! -\page extending-interfaceframework.html -\title Extending Qt Interface Framework - -\section1 Introduction - -Qt Interface Framework provides a pattern for extending Qt with more features -in a way that suites the automotive use-case. - -A key aspect is the separation between the front end that defines the API, from the -back end that implements the functionality. This separation makes it possible to have -multiple implementations of the same API which can be used to interface various hardware -configurations, but also to provide stubbed or simulated implementations for early -development and testing purposes. - -\section1 The Big Picture - -Qt Interface Framework consists of three types of building blocks. The core module provides base -classes and common code for all the more specific modules and API definitions like a climate API or -a media player API. Each of these APIs is the second building block called \e Feature, which -defines the API used by the application developers. The last block consists of a back-end interface -and one or more \e back ends implementing it to either connect to the underlying service or to a -simulation of it. - -\section2 Features - -A feature is a set of classes for working with a specific function. It defines the interface -towards application developers, but it does not implement the complete functionality. Instead, it -defines a back-end interface to be implemented by a back end providing the actual functionality. - -For easy deployment, Qt Interface Framework extensions should be built as Qt modules. This makes it -easy to install and find headers, shared libraries, and plugin modules from app projects. - -By using the module system the developer can easily enable the inclusion of his -module in the following way: - -\code -QT += <module> -\endcode - -In addition, your module is properly set up to work with qdoc and auto test. - -\code -make tests -\endcode - -When creating a new Qt Interface Framework module, it is recommended that you pick a name such as -\e {PlatformFeatureName}, where \e {Platform} is the name of the platform or product, and -\e {FeatureName} is the name of the feature(s) of the module. In addition to the name, a reverse -domain name prefix is needed for prefixing back-end interface names, for example \e {com.example} - -Features are based on the QIfAbstractFeature base class, or QIfAbstractZonedFeature for -zoned features. These classes provide the basic functions expected by users, e.g. back end -loading. - -Features define the back-end interface to be implemented by the back ends providing the -functionality. The back-end interface is commonly based on the QObject class. It is important -to keep this API as unbiased as possible, as there might be multiple back-end implementations -relying on different technological solutions. - -Some key rules to keep in mind are: - -\list -\li Keep everything asynchronous to avoid blocking the main loop. -\li Avoid call-to-signal sequences and try to keep signals independent from calls, For example, -when a value change is signaled, it must not be due to a call to change the value from -the feature (and visa versa). In other words a call to change a value is not required to always -result in a value changed signal. -\li Implement stateless APIs whenever possible as the back end may be replaced at any time. -\endlist - -It is common to provide a stubbed back-end implementation and a testing back end with each -feature. - -\section2 Back ends - -A back-end class is derived from the (commonly QObject-derived) back-end interface -class specified by a feature. Instances of the back-end class are called \e {service objects}. - -Back ends are implemented as an ordinary Qt C++ plugin project that depends on -\l {QtInterfaceFramework}{Qt Interface Framework Core} and the corresponding feature module. - -The back ends are loaded by Qt Interface Framework Core when the features request them. -Each back end has to provide a Qt Interface Framework plugin that exposes a \e factory to the Core. -This is what is used to load and create back ends. The plugin interface is called QIfServiceInterface. - -\section2 Service Manager - -In most cases, the back-end loading is handed over to the Qt Interface Framework Core. -In some cases QIfServiceManager can manually search for plugins with a specific -BackendInterface. The discovery and loading of the back ends takes place in this class. - -The QIfServiceManager class can also be used to register back ends which are part -of the same application and shouldn’t go into a plugin. This is especially useful -for automated testing as you need to control the back end and the feature at the same time. - -\section1 Common Practices - -The reference APIs provided as a part of Qt Interface Framework introduce some common concepts. If -implementing the same functionality, it is recommended to use these already defined patterns and -it is encouraged to add API additions back to the Qt Interface Framework repository to create more common ground -for future APIs. - -*/ |