diff options
Diffstat (limited to 'src/ivicore/doc/src/examples-qface-ivi-remote.qdoc')
| -rw-r--r-- | src/ivicore/doc/src/examples-qface-ivi-remote.qdoc | 123 |
1 files changed, 17 insertions, 106 deletions
diff --git a/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc b/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc index a652c36..651c7c7 100644 --- a/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc +++ b/src/ivicore/doc/src/examples-qface-ivi-remote.qdoc @@ -57,22 +57,11 @@ contains a single interface with a single property and a single method. First we need to define which \e module we want to describe. The \e module acts as a namespace, because the IDL file can contain multiple interfaces. -\code -module Example.IVI.Remote 1.0; -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/example-ivi-remote.qface 0 The most important part is the definition of the \e interface. -\code - -interface ProcessingService { - - string lastMessage; - - int process(string data); -} - -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/example-ivi-remote.qface 1 In this case, we define an \e interface named \b ProcessingService consisting of a single property and a single method. Every property and method definition needs to contain at least a type and a @@ -90,10 +79,7 @@ change the behavior implementations. In order to call the autogenerator for our shared library, the qmake project file needs to use the \e ivigenerator qmake feature. The following snippet shows how it can be added: -\code -CONFIG += ivigenerator -QFACE_SOURCES = ../example-ivi-climate.qface -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/frontend/frontend.pro 1 By adding \e ivigenerator to the \e CONFIG variable, the \e ivigenerator feature file will be loaded and interpret the \e QFACE_SOURCES variable similar to \e SOURCES variable of normal qmake @@ -102,10 +88,7 @@ Activating the qmake feature using the \e CONFIG variable has the disadvantage t report any errors if the feature is not available. Because of this, it is encouraged to use the following additional code to report errors: -\code -QT_FOR_CONFIG += ivicore -!qtConfig(ivigenerator): error("No ivigenerator available") -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/frontend/frontend.pro 0 The other part of the project file is a normal library setup which is supposed to work on Linux, macOS and Windows. @@ -119,11 +102,7 @@ plugin here will work as a client that connects to the server using the Qt Remot integration works in the same way, but it is using the \e QFACE_FORMAT variable to tell the ivigenerator to use a different generation template, \e backend_qtro: -\code -CONFIG += ivigenerator plugin -QFACE_FORMAT = backend_qtro -QFACE_SOURCES = ../example-ivi-climate.qface -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/backend_qtro/backend_qtro.pro 2 The generated backend plugin code is usable as is, and doesn't require further changes by the developer. As we want to generate a plugin instead of a plain library, we need to instrument qmake @@ -132,9 +111,7 @@ to get the backend interface header from the previously created library. As this generated, it is not part of our source tree, but part of the build tree. We do this by adding it to the include path using the following construct: -\code -INCLUDEPATH += $$OUT_PWD/../frontend -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/backend_qtro/backend_qtro.pro 1 Most of the code in the backend plugin is generated by the IVI Generator, but some of it is generated by the Qt's remote object compiler (repc). This is achieved by IVI Generator producing an @@ -149,9 +126,7 @@ plugin in a folder where our application searches for plugins. By default Qt eit application. For QtIvi plugins to be found, they need to be provided within a \b qtivi sub-folder. This is achieved automatically by adding the following line to our backend project file: -\code -DESTDIR = ../qtivi -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/backend_qtro/backend_qtro.pro 0 \section1 RemoteObjects Server @@ -161,14 +136,9 @@ backend and hence needs to have most of its implementation written by the develo the generator produces some code to simplify the development. We can generate server side code by using the IVI Generator with \e server_qtro template: -\code -TEMPLATE = app -QT -= gui -CONFIG += c++11 ivigenerator -... -QFACE_FORMAT = server_qtro -QFACE_SOURCES = ../example-ivi-remote.qface -\endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/server_qtro.pro 0 +\dots 0 +\snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/server_qtro.pro 1 To use the generated remote source, we need to inherit from one of the classes defined in the generated rep_processingservice_source.h file. In this example we implement our servers logic in the @@ -176,16 +146,8 @@ ProcessingService class and use the ProcessingServiceSimpleSource as the base cl \code // server_qtro/processingservice.h -#include "rep_processingservice_source.h" - -class ProcessingService : public ProcessingServiceSimpleSource -{ -public: - ProcessingService(); - - int process(const QString & data) override; -}; \endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/processingservice.h 0 Please notice, that the base class contains already the definitions for property accessors, but any custom method or slot needs to be overridden and defined by the developer. Our implementation of the @@ -194,17 +156,8 @@ property: \code // server_qtro/processingservice.cpp -ProcessingService::ProcessingService() -{ - setLastMessage("Service online."); -} - -int ProcessingService::process(const QString & data) -{ - setLastMessage("Processed data \'" +data+"\'"); - return data.length(); -} \endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/processingservice.cpp 0 In order to make the class \b ProcessingService accessible remotely, we need to share it. This is done with the QRemoteObjectNode::enableRemoting() function. The generated Core class provides a @@ -215,21 +168,8 @@ the start of the main event loop: \code // server_qtro/main.cpp -#include <QCoreApplication> - -#include "processingservice.h" -#include "core.h" - -int main(int argc, char *argv[]) -{ - QCoreApplication app(argc, argv); - - ProcessingService service; - Core::instance()->host()->enableRemoting(&service,"Example.IVI.Remote.ProcessingService"); - - return app.exec(); -} \endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/server_qtro/main.cpp 0 Implementing a service that is accessible remotely is as simple as that; use the properties as usual and provide the method implementations. The QtRemoteObjects library takes care of the communication. @@ -251,20 +191,9 @@ QML item. \code // demo/main.qml -import IviRemote 1.0 - -Window { - -... - - UiProcessingService { - id: processingService - } - -... - -} \endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/demo/main.qml 0 +\dots 0 Every method call that is made through a generated API, is asynchronous. This means, that instead of directly returning a return value, a \c {QIviPendingReply} object is returned. @@ -273,33 +202,15 @@ that are called when the method call has been successfully finished or if it has \code // demo/main.qml -Button { - text: "Process" - - onClicked: processingService.process(inputField.text).then( - function(result) { //success callback - resultLabel.text = result - }, - function() { //failure callback - resultLabel.text = "failed" - } - ) -} \endcode +\snippet ../../../../examples/ivicore/qface-ivi-remote/demo/main.qml 1 In case of properties, we just use bindings as usual: \code // demo/main.qml -Row { - Text { text: "Last message: " } - Text { - id: serverMessage - text: processingService.lastMessage - } -} \endcode - +\snippet ../../../../examples/ivicore/qface-ivi-remote/demo/main.qml 2 \section1 Running the Example |