Service Framework API/es: Difference between revisions
No edit summary |
AutoSpider (talk | contribs) m (AutoSpider moved page Service Framework API Spanish to Service Framework API/es: Localisation) |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
= | {{Cleanup | reason=Auto-imported from ExpressionEngine.}} | ||
'''Spanish''' [[ | == This is Work in progress - Articulo en progreso == | ||
'''Spanish''' [[Service_Framework_API_Spanish|English]] | |||
[[Category:Developing with Qt::QtMobility]] | |||
[[Category:Spanish]] | |||
== Caracteristicas de Qt Mobility 1.1.x == | |||
= | == Noticias : == | ||
[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] actualmente disponible para desarrollo de aplicaciones comerciales para ser distribuidas en Ovi store | |||
[http://labs.qt.nokia.com/2011/05/12/qt-mobility-1-2-0-released/ Qt Mobility 1.2.0 release] actualmente disponible | |||
= | = Service Framework = | ||
* Simplifica a | 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 | * Servicios de descubrimiento | ||
* Sistema basado en QMetaObject | * Sistema basado en QMetaObject | ||
Line 21: | Line 27: | ||
* 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. | * 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== | == 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 | 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. | 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. | ||
Line 29: | Line 35: | ||
El código del cliente para conectarse a un servicio remoto es: | El código del cliente para conectarse a un servicio remoto es: | ||
<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> | |||
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 | 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 | ||
Line 35: | Line 55: | ||
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. | 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 | 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: | ||
<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> | |||
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: | |||
<code>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()</code> | |||
Las 3 primeras lineas registran el | 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. | Los siguientes 3 líneas registran el objeto a ser exportado. | ||
Line 51: | Line 95: | ||
SharedService puede ser definido así: | SharedService puede ser definido así: | ||
<code> | |||
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); | |||
}; | |||
</code> | |||
Eso es todo lo que hay que hacer! | |||
== | == Ejemplos completos == | ||
Un ejemplo completo con chequeo de errores esta disponible en [http://doc.qt.nokia.com/qtmobility/sfwecho.html Qt Mobility examples: Echo Client] que proporciona un servicio y un UI de ejemplo que demuestra las comunicaciones fuera de proceso de Service Framework. | |||
Latest revision as of 03:37, 12 April 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. |
This is Work in progress - Articulo en progreso
Spanish English
Caracteristicas de Qt Mobility 1.1.x
Noticias :
Qt Mobility 1.1.3 Release actualmente disponible para desarrollo de aplicaciones comerciales para ser distribuidas en Ovi store Qt Mobility 1.2.0 release 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 que proporciona un servicio y un UI de ejemplo que demuestra las comunicaciones fuera de proceso de Service Framework.