Service Framework API/es

From Qt Wiki
< Service Framework API
Revision as of 16:58, 3 March 2015 by AutoSpider (talk | contribs) (Add "cleanup" tag)
Jump to navigation Jump to search
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.

h2. This is Work in progress - Articulo en progreso

Spanish English

Caracteristicas de Qt Mobility 1.1.x

Noticias :

"Qt Mobility 1.1.3 Release":http://labs.qt.nokia.com/2011/05/04/qt-4-7-3-and-qt-mobility-1-1-3-have-been-released/ actualmente disponible para desarrollo de aplicaciones comerciales para ser distribuidas en Ovi store "Qt Mobility 1.2.0 release":http://labs.qt.nokia.com/2011/05/12/qt-mobility-1-2-0-released/ actualmente disponible

Service Framework

El API fuera de proceso de Service Framework simplifica a IPC. Permite que las aplicaciones puedan escuchar las señales, llamar slots, acceder a las propiedades e invocar métodos en QObjects en otros procesos.

Características principales

  • Simplifica a IPC
  • Servicios de descubrimiento
  • Sistema basado en QMetaObject
  • Multiplataforma y optimizado para cada plataforma. En Linux usa dBus, en Symbian usa CServer2. Operación de reserva para QLocalSocket.
  • Se puede tener acceso compartido o únicos a objetos remotos. Los objetos compartidos son compartidos entre todos los clientes. Objetos únicos son exclusivos de esa sesión y el cliente.

Descripción detallada

Una característica de QMetaObject es la comunicación local con signals y slots. Service Framework fuera del proceso de comunicación extiende las signals y los slots en otros procesos. La señal es interceptada, serializada y se pasa al proceso remoto en el que se recrea y se comporta como si fuera una signal local. Esto simplifica el IPC desde el cliente y el servidor puede usar QObject::connect y emit que es conocido por todos los programadores Qt.

Junto con las signals y los slots el sistema MetaObject proporciona propiedades, llamadas a métodos a través de slots o Q_INVOKABLE y la identificación de tipos en tiempo de ejecución. Invoca funciones se serializa la solicitud, llama a la propiedad remota y devolver los resultados sin problemas a el proceso local.

El código del cliente para conectarse a un servicio remoto es:

// 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)));

Con 4 líneas de código IPC se ha establecido un servicio remoto. La primera línea crea una QServiceManager que gestiona descubrimiento de servicios. La segunda línea se busca la interfaz de nuestro objeto de prueba, y la tercera línea crear un nuevo QObject para el servicio remoto.

La última línea conecta las signal de los objetos remotos HelloWorld al slot local Hola. Cada vez que el objeto remoto emite una signal Hola se llamará. El argumento QString sera pasado con una copia de los datos remotos

Una vez que el QObject es creado puede ser tratado como cualquier QObject con respecto al sistema de meta objetos. Hay una diferencia importante, los servicios remotos puede fallar. Una signal especial es añadida a QObjects errorUnrecoverableIPCFault(QService::UnrecoverableIPCError) la cual es emitida cuando se produce un fallo en las comunicaciones. El objetivo entonces debe ser destruido.

Este lado del servicio requiere de dos partes, un archivo XML que describe el servicio y el registro con el servicio. A continuación un ejemplo del archivo XML:

<?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>

Mientras el archivo XML se explica asi mismo, el filepath es importante. Se debe comenzar con "localsocket" que describe un proceso fuera de servicio. Para registrarse con el administrador de servicios:

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()

Las 3 primeras lineas registran el XML con el administrador de servicios. Este sólo tiene que ser llamado una vez para registrar el servicio. Esto se puede hacer durante la instalación, por ejemplo.

Los siguientes 3 líneas registran el objeto a ser exportado.

In this case the QObject is SharedService, and is a shared instance meaning only one instance will exist for all clients.

El ifdef Q_OS_SYMBIAN es requerido temporalmente al arranque con la tech preview y sera removido en futuras versiones.

Luego de la registración QCoreApplication::exec() es llamado para comenzar a trabajar.

SharedService puede ser definido 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);
};

Eso es todo lo que hay que hacer!

Ejemplos completos

Un ejemplo completo con chequeo de errores esta disponible en "Qt Mobility examples: Echo Client":http://doc.qt.nokia.com/qtmobility/sfwecho.html que proporciona un servicio y un UI de ejemplo que demuestra las comunicaciones fuera de proceso de Service Framework.