Service Framework API: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
(Decode HTML entity numbers)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:Developing with Qt::QtMobility]]
[[Category:Developing with Qt::QtMobility]]


== Qt Mobility 1.1 Features ==
== Qt Mobility 1.1 Features ==


* Note : &quot;Qt Mobility 1.1.3 Release&amp;quot;:http://labs.qt.nokia.com/2011/05/04/qt-4-7-3-and-qt-mobility-1-1-3-have-been-released/ is available now for commercial app development and deployment on Ovi store.<br />&quot;Qt Mobility 1.2.0 release&amp;quot;:http://labs.qt.nokia.com/2011/05/12/qt-mobility-1-2-0-released/ is available now.
* Note : [http://labs.qt.nokia.com/2011/05/04/qt-4-7-3-and-qt-mobility-1-1-3-have-been-released/ Qt Mobility 1.1.3 Release] is available now for commercial app development and deployment on Ovi store.
[http://labs.qt.nokia.com/2011/05/12/qt-mobility-1-2-0-released/ Qt Mobility 1.2.0 release] is available now.


== Service Framework ==
== Service Framework ==
Line 21: Line 24:
One feature of the QMetaObject is local communication with signals and slots. Service Framework out of process communication extends this to signals or slots in other processes. The signal is intercepted, serialized and passed to the remote process where it is recreated and behaves as it were a local signal. This simplifies IPC since both the client and server can use QObject::connect and emit which are known to all Qt programmers.
One feature of the QMetaObject is local communication with signals and slots. Service Framework out of process communication extends this to signals or slots in other processes. The signal is intercepted, serialized and passed to the remote process where it is recreated and behaves as it were a local signal. This simplifies IPC since both the client and server can use QObject::connect and emit which are known to all Qt programmers.


Along with signals and slots the MetaObject system provides properties, method calls through slots or Q_INVOKABLE, and run time type identification. Invoked functions will serialize the request, call the remote property and return the results seamlessly to the local process.<br />Client code to connect a remote service is:
Along with signals and slots the MetaObject system provides properties, method calls through slots or Q_INVOKABLE, and run time type identification. Invoked functions will serialize the request, call the remote property and return the results seamlessly to the local process.
Client code to connect a remote service is:
 
<code>
// Create a service manager
QServiceManager manager;
 
// Get the interface descriptor
QList<QServiceInterfaceDescriptor> ld = manager.findInterfaces("Service");
 
// Get a local object
QObject '''obj = manager.loadInterface(ld[0]);
 
// Connect to a sample signal
connect(obj, SIGNAL (HelloWorld(QString)), this, SLOT (Hello(QString)));
</code>
 
With 4 lines of code IPC has been established to a remote service. The first line creates a QServiceManager which manages service discovery. The second line fetches the interface for our test object, and the third line create a new QObject for the remote service. The last line connects the remote objects HelloWorld signal to the local Hello slot. Every time the remote object emits the signal Hello will be called. The QString argument will be passed in with a copy of the remote data.
 
Once the QObject is created it can be treated like any other local QObject with respect to the meta object system. There is one important difference, remote services can fail. A special signal is added to QObjects, errorUnrecoverableIPCFault(QService::UnrecoverableIPCError)
which is emitted if there has been a communications fault. The object should then be destroyed.
 
The service side requires two parts, an XML file describing the service and registration with the service. An example XML file is:


<code><br />// Create a service manager<br />QServiceManager manager;
<code><?xml version="1.0" encoding="UTF-8"?>
<service>
<name>IPCExampleService</name>
<filepath>localsocket:qt_sfw_example</filepath>
<description>Example XML file</description>
<interface>
<name>com.nokia.qt.example</name>
<version>1.0</version>
<description>Descriptive text</description>
<capabilities></capabilities>
</interface>
</service></code>


// Get the interface descriptor<br />QList&amp;lt;QServiceInterfaceDescriptor&amp;gt; ld = manager.findInterfaces(&quot;Service&amp;quot;);


// Get a local object<br />QObject '''obj = manager.loadInterface(ld[0]);
While the XML is fairly self explanatory, the filepath is important. It must start with "localsocket" which describes an out of process service. To register with the service manager:
<br />// Connect to a sample signal<br />connect(obj, SIGNAL (HelloWorld(QString)), this, SLOT (Hello(QString)));<br /></code>
<br />With 4 lines of code IPC has been established to a remote service. The first line creates a QServiceManager which manages service discovery. The second line fetches the interface for our test object, and the third line create a new QObject for the remote service. The last line connects the remote objects HelloWorld signal to the local Hello slot. Every time the remote object emits the signal Hello will be called. The QString argument will be passed in with a copy of the remote data.
<br />Once the QObject is created it can be treated like any other local QObject with respect to the meta object system. There is one important difference, remote services can fail. A special signal is added to QObjects, errorUnrecoverableIPCFault(QService::UnrecoverableIPCError)<br />which is emitted if there has been a communications fault. The object should then be destroyed.
<br />The service side requires two parts, an XML file describing the service and registration with the service. An example XML file is:
<br /><code>&amp;lt;?xml version=&quot;1.0&amp;quot; encoding=&quot;UTF-8&amp;quot;?&amp;gt;<br />&lt;service&amp;gt;<br /> &lt;name&amp;gt;IPCExampleService&amp;lt;/name&amp;gt;<br /> &lt;filepath&amp;gt;localsocket:qt_sfw_example&amp;lt;/filepath&amp;gt;<br /> &lt;description&amp;gt;Example XML file&amp;lt;/description&amp;gt;<br /> &lt;interface&amp;gt;<br /> &lt;name&amp;gt;com.nokia.qt.example&amp;lt;/name&amp;gt;<br /> &lt;version&amp;gt;1.0&amp;lt;/version&amp;gt;<br /> &lt;description&amp;gt;Descriptive text&amp;lt;/description&amp;gt;<br /> &lt;capabilities&amp;gt;&lt;/capabilities&amp;gt;<br /> &lt;/interface&amp;gt;<br />&lt;/service&amp;gt;</code>


<br />While the XML is fairly self explanatory, the filepath is important. It must start with &quot;localsocket&amp;quot; which describes an out of process service. To register with the service manager:
<code>QServiceManager manager;
<br /><code>QServiceManager manager;<br />const QString path = QCoreApplication::applicationDirPath() + &quot;/xmldata/exampleservice.xml&amp;quot;;<br />m.add(path);<br />QRemoteServiceClassRegister::registerType&amp;lt;SharedService&amp;gt;(QRemoteServiceClassRegister::SharedInstance);<br />QRemoteServiceControl''' control = new QRemoteServiceControl();<br />control-&gt;publishServices(&quot;qt_sfw_example&amp;quot;);<br />#ifdef Q_OS_SYMBIAN<br /> RProcess::Rendezvous(KErrNone); // will be removed after tech preview<br />#endif<br />app.exec&amp;amp;#40;&amp;#41;</code>
const QString path = QCoreApplication::applicationDirPath() + "/xmldata/exampleservice.xml";
m.add(path);
QRemoteServiceClassRegister::registerType<SharedService>(QRemoteServiceClassRegister::SharedInstance);
QRemoteServiceControl''' control = new QRemoteServiceControl();
control->publishServices("qt_sfw_example");
#ifdef Q_OS_SYMBIAN
RProcess::Rendezvous(KErrNone); // will be removed after tech preview
#endif
app.exec()</code>


The first 3 lines register the XML with the service manager. They only need to be called one time to register the service. This can be done during installation for example. The next 3 lines register the object to be exported. In this case the QObject is SharedService, and is a shared instance meaning only one instance will exist for all clients. The Q_OS_SYMBIAN ifdef is required temporarily for startup with the tech preview, and can removed in future versions. After registration QCoreApplication::exec&amp;amp;amp;#40;&amp;amp;#41; is called to start doing work.
The first 3 lines register the XML with the service manager. They only need to be called one time to register the service. This can be done during installation for example. The next 3 lines register the object to be exported. In this case the QObject is SharedService, and is a shared instance meaning only one instance will exist for all clients. The Q_OS_SYMBIAN ifdef is required temporarily for startup with the tech preview, and can removed in future versions. After registration QCoreApplication::exec() is called to start doing work.


SharedService could be defined as:
SharedService could be defined as:
Line 43: Line 81:
<code>
<code>


class SharedService : public QObject<br />{<br /> Q_OBJECT<br /> Q_SERVICE(SharedService, &quot;IPCExampleService&amp;quot;, &quot;com.nokia.qt.example&amp;quot;, &quot;1.0&amp;quot;)
class SharedService : public QObject
{
Q_OBJECT
Q_SERVICE(SharedService, "IPCExampleService", "com.nokia.qt.example", "1.0")


public:<br /> SharedService(QObject* parent = 0)<br /> : QObject(parent)<br /> {
public:
SharedService(QObject* parent = 0)
: QObject(parent)
{


}
}


Q_INVOKABLE QString doSomething(int input)<br /> {<br /> // do something<br /> }
Q_INVOKABLE QString doSomething(int input)
{
// do something
}


Q_SIGNALS:<br /> void HelloWorld(QString string);<br />};<br /></code>
Q_SIGNALS:
void HelloWorld(QString string);
};
</code>


That's all there is to it!
That's all there is to it!
Line 57: Line 107:
== Complete Examples ==
== Complete Examples ==


A complete example with error checking is available in the &quot;Qt Mobility examples: Echo Client&amp;quot;:http://doc.qt.nokia.com/qtmobility/sfwecho.html which provides both a service and example UI that demonstrates Service Framework out of process communications.
A complete example with error checking is available in the [http://doc.qt.nokia.com/qtmobility/sfwecho.html Qt Mobility examples: Echo Client] which provides both a service and example UI that demonstrates Service Framework out of process communications.

Latest revision as of 16:04, 13 March 2015

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Qt Mobility 1.1 Features

Qt Mobility 1.2.0 release is available now.

Service Framework

The Service Framework out of process API simplifies IPC. It allows applications to listen to signals, call slots, access properties, and invoke methods in QObjects in other processes.

Key Features

  • Simplifies IPC
  • Service Discovery
  • QMetaObject system based
  • Cross platform, and optimized for each platform. Linux uses dBus, Symbian uses CServer2. Fall back operation to QLocalSocket.
  • Can access Shared or Unique remote objects. Shared object are shared between all clients. Unique objects are unique to that session and client.

Detailed Description

One feature of the QMetaObject is local communication with signals and slots. Service Framework out of process communication extends this to signals or slots in other processes. The signal is intercepted, serialized and passed to the remote process where it is recreated and behaves as it were a local signal. This simplifies IPC since both the client and server can use QObject::connect and emit which are known to all Qt programmers.

Along with signals and slots the MetaObject system provides properties, method calls through slots or Q_INVOKABLE, and run time type identification. Invoked functions will serialize the request, call the remote property and return the results seamlessly to the local process. Client code to connect a remote service is:

// Create a service manager
QServiceManager manager;

// Get the interface descriptor
QList<QServiceInterfaceDescriptor> ld = manager.findInterfaces("Service");

// Get a local object
QObject '''obj = manager.loadInterface(ld[0]);

// Connect to a sample signal
connect(obj, SIGNAL (HelloWorld(QString)), this, SLOT (Hello(QString)));

With 4 lines of code IPC has been established to a remote service. The first line creates a QServiceManager which manages service discovery. The second line fetches the interface for our test object, and the third line create a new QObject for the remote service. The last line connects the remote objects HelloWorld signal to the local Hello slot. Every time the remote object emits the signal Hello will be called. The QString argument will be passed in with a copy of the remote data.

Once the QObject is created it can be treated like any other local QObject with respect to the meta object system. There is one important difference, remote services can fail. A special signal is added to QObjects, errorUnrecoverableIPCFault(QService::UnrecoverableIPCError) which is emitted if there has been a communications fault. The object should then be destroyed.

The service side requires two parts, an XML file describing the service and registration with the service. An example XML file is:

<?xml version="1.0" encoding="UTF-8"?>
<service>
 <name>IPCExampleService</name>
 <filepath>localsocket:qt_sfw_example</filepath>
 <description>Example XML file</description>
 <interface>
 <name>com.nokia.qt.example</name>
 <version>1.0</version>
 <description>Descriptive text</description>
 <capabilities></capabilities>
 </interface>
</service>


While the XML is fairly self explanatory, the filepath is important. It must start with "localsocket" which describes an out of process service. To register with the service manager:

QServiceManager manager;
const QString path = QCoreApplication::applicationDirPath() + "/xmldata/exampleservice.xml";
m.add(path);
QRemoteServiceClassRegister::registerType<SharedService>(QRemoteServiceClassRegister::SharedInstance);
QRemoteServiceControl''' control = new QRemoteServiceControl();
control->publishServices("qt_sfw_example");
#ifdef Q_OS_SYMBIAN
 RProcess::Rendezvous(KErrNone); // will be removed after tech preview
#endif
app.exec()

The first 3 lines register the XML with the service manager. They only need to be called one time to register the service. This can be done during installation for example. The next 3 lines register the object to be exported. In this case the QObject is SharedService, and is a shared instance meaning only one instance will exist for all clients. The Q_OS_SYMBIAN ifdef is required temporarily for startup with the tech preview, and can removed in future versions. After registration QCoreApplication::exec() is called to start doing work.

SharedService could be defined as:

class SharedService : public QObject
{
 Q_OBJECT
 Q_SERVICE(SharedService, "IPCExampleService", "com.nokia.qt.example", "1.0")

public:
 SharedService(QObject* parent = 0)
 : QObject(parent)
 {

}

Q_INVOKABLE QString doSomething(int input)
 {
 // do something
 }

Q_SIGNALS:
 void HelloWorld(QString string);
};

That's all there is to it!

Complete Examples

A complete example with error checking is available in the Qt Mobility examples: Echo Client which provides both a service and example UI that demonstrates Service Framework out of process communications.