QRemoteObjectHostBase Class

Documentación de las funciones miembro

void QRemoteObjectHostBase::addHostSideConnection(QIODevice *ioDevice)

Para QRemoteObjectHost::enableRemoting() objetos Fuente sobre QIODevices Externos, Qt Remote Objects necesita acceso al canal de comunicaciones (un QIODevice) entre los respectivos nodos. Es la llamada addHostSideConnection() la que habilita esto en el lado Fuente, tomando el ioDevice como entrada. Cualquier llamada a enableRemoting() seguirá funcionando sin llamar a addHostSideConnection, pero el Nodo no podrá compartir los objetos Fuente sin que se le proporcione la conexión con el nodo Réplica. Antes de llamar a esta función debe llamar a setHostUrl() con una URL única y AllowExternalRegistration.

Véase también addClientSideConnection.

[invokable] bool QRemoteObjectHostBase::disableRemoting(QObject *remoteObject)

Desactiva el acceso remoto para el QObject remoteObject . Devuelve false si el nodo actual es un nodo cliente o si el remoteObject no está registrado, y devuelve true si se ha deshabilitado con éxito el acceso remoto para el objeto Fuente.

Véase también enableRemoting().

template <template <typename> typename ApiDefinition, typename ObjectType> bool QRemoteObjectHostBase::enableRemoting(ObjectType *object)

Esta sobrecarga de función permite a un nodo anfitrión proporcionar acceso remoto a QObject object con una interfaz especificada (y comprobada en tiempo de compilación). Los nodos cliente conectados al nodo que aloja este objeto pueden obtener réplicas de esta fuente.

Esto se ilustra mejor con un ejemplo:

#include "rep_TimeModel_source.h"
MinuteTimer timer;
hostNode.enableRemoting<MinuteTimerSourceAPI>(&timer);

Aquí el MinuteTimerSourceAPI es el conjunto de Señales/Slots/Propiedades definidas por el archivo TimeModel.rep. Se realizan comprobaciones en tiempo de compilación para verificar que la entrada QObject puede exponer la API solicitada, de lo contrario fallará al compilar. Esto permite exponer un subconjunto de la interfaz de object y permite los tipos de conversiones soportados por las conexiones Signal/Slot.

Devuelve false si el nodo actual es un nodo cliente, o si el QObject ya está registrado para ser remotado, y true si se ha habilitado con éxito el remotado para el QObject.

Véase también disableRemoting().

[invokable] bool QRemoteObjectHostBase::enableRemoting(QObject *object, const QString &name = QString())

Permite a un nodo anfitrión proporcionar acceso remoto de forma dinámica a QObject object . Los nodos cliente conectados al nodo que aloja este objeto pueden obtener réplicas de esta fuente.

El parámetro opcional name define el nombre de búsqueda con el que se puede obtener QObject utilizando QRemoteObjectNode::acquire() . Si no se define explícitamente, se utilizará el nombre indicado en QCLASSINFO_REMOTEOBJECT_TYPE. Si no se ha definido dicha macro para QObject entonces se utiliza QObject::objectName().

Devuelve false si el nodo actual es un nodo cliente, o si el QObject ya está registrado para ser remotado, y true si el remotado se habilita con éxito para el QObject dinámico.

Véase también disableRemoting().

bool QRemoteObjectHostBase::enableRemoting(QAbstractItemModel *model, const QString &name, const QList<int> roles, QItemSelectionModel *selectionModel = nullptr)

Esta sobrecarga de enableRemoting() es específica de los tipos QAbstractItemModel (o cualquier tipo derivado de QAbstractItemModel). Esto es útil si se desea tener un modelo y la HMI para el modelo en diferentes procesos.

Los tres parámetros requeridos son el propio model, el name por el cual buscar el modelo, y el roles que debe ser expuesto en el lado Réplica. Si desea sincronizar la selección entre el origen y la réplica, puede utilizar el parámetro opcional selectionModel. Esto sólo se recomienda cuando se utiliza una única réplica.

Entre bastidores, Qt Remote Objects agrupa las búsquedas en data() y precarga los datos cuando es posible para que la interacción con el modelo sea lo más ágil posible.

Devuelve false si el nodo actual es un nodo cliente, o si el QObject ya está registrado para ser remotado, y true si se ha habilitado con éxito el remotado para el QAbstractItemModel.

Véase también disableRemoting().

bool QRemoteObjectHostBase::proxy(const QUrl &registryUrl, const QUrl &hostUrl = {}, QRemoteObjectHostBase::RemoteObjectNameFilter filter = [](QStringView, QStringView) {return true; })

Reenviar objetos remotos desde otra red

La funcionalidad proxy es útil cuando se desea compartir objetos Fuente a través de múltiples redes. Por ejemplo, si tienes un objetivo incrustado usando conexiones sólo de objetivo (como local) y quieres hacer que algunos de esos mismos objetos estén disponibles externamente.

Como ejemplo concreto, digamos que tienes un conjunto de procesos hablando entre ellos en tu hardware de destino usando un registro, con el Registro en "local:registry" y procesos separados usando un nodo en "local:MyHost" que contiene objetos Fuente. Si quisieras acceder a estos objetos, pero sobre tcp, podrías crear un nuevo proxyNode así:

// myInternalHost is a node only visible on the device...
QRemoteObjectHost myInternalHost("local:MyHost");
myInternalHost.enableRemoting<SomeObject>(&someObject);

// Regular host node, listening on port 12123, so visible to other
// devices
QRemoteObjectHost proxyNode("tcp://localhost:12123");

// Enable proxying objects from nodes on the local machine's internal
// QtRO bus
proxyNode.proxy("local:registry");

Y desde otro dispositivo creas otro nodo:

// NB: localhost resolves to a different ip address than proxyNode
QRemoteObjectHost nodeOnRemoteDevice("tcp://localhost:23234");

// Connect to the target's proxyNode directly, or use a tcp registry...
nodeOnRemoteDevice.connectToNode("tcp://<target device>:12123");

// Because of the proxy, we can get the object over tcp/ip port 12123,
// even though we can't connect directly to "local:MyHost"
SomeObject *so = nodeOnRemoteDevice.acquire<SomeObject>();

Esto crearía (internamente) un nodo en proxyNode, que (de nuevo internamente/automáticamente) se conecta al registro proporcionado (dado por el parámetro registryUrl, "local:registry" en este ejemplo). Siempre que local:registry emita la señal remoteObjectAdded, la QRemoteObjectSourceLocation se pasa a la filter dada a la llamada al proxy. Si este método devuelve true (el filtro por defecto simplemente devuelve true sin ningún filtrado), el objeto es adquirido() desde el nodo interno y enableRemoting() (una vez inicializada la réplica) es llamado en proxyNode.

Si se proporciona un hostUrl (que es necesario para habilitar reverseProxy, pero no es necesario en caso contrario), el nodo interno será un nodo QRemoteObjectHost configurado con la dirección proporcionada. Si no se proporciona hostUrl, el nodo interno será un QRemoteObjectNode (no HostNode).

Devuelve true si el objeto se adquiere desde el nodo interno.

Véase también reverseProxy().

bool QRemoteObjectHostBase::reverseProxy(QRemoteObjectHostBase::RemoteObjectNameFilter filter = [](QStringView, QStringView) {return true; })

Reenvía objetos remotos a otra red.

La función reverseProxy() permite extender la funcionalidad de proxy(), en efecto reflejando la funcionalidad proxy en la dirección "inversa". Son distintas, porque la comunicación entre nodos no es simétrica, un lado llama a enableRemoting() con un objeto Fuente, el otro lado llama a acquire() para obtener una Réplica. El uso de proxy() permite "observar" objetos en un dispositivo de destino de forma remota a través de acquire, pero no permite adquirir objetos Fuente fuera del objetivo desde la red local:* del dispositivo. Aquí es donde entra reverseProxy(). Si un proxyNode se crea así:

// myInternalHost is a node only visible on the device...
QRemoteObjectHost myInternalHost("local:MyHost", "local:registry");

// RegistryHost node, listening on port 12123, so visible to other
// devices.  The node must be a RegistryHost, so the Sources on
// the "outside" network can be forwarded to the inner network.
QRemoteObjectRegistryHost proxyNode("tcp://0.0.0.0:12123");

// Enable proxying objects from nodes on the local machine's internal
// QtRO bus.  Note the hostUrl parameter is now needed.
proxyNode.proxy("local:registry", "local:fromProxy");
proxyNode.reverseProxy();

Y desde otro dispositivo se crea otro nodo:

// Listen on a local port, and connect to "proxyNode" as the registry.
// NB: localhost resolves to a different ip address than proxyNode
QRemoteObjectHost nodeOnRemoteDevice("tcp://localhost:23234",
                                     "tcp://<target device>:12123");

// Because of the reverseProxy, we can expose objects on this device
// and they will make their way to proxyNode...
nodeOnRemoteDevice.enableRemoting<OtherObject>(&otherObject);

// Acquire() can now see the objects on other devices through proxyNode,
// due to the reverseProxy call.
OtherObject *oo = myInternalHost.acquire<OtherObject>();

Mientras que la funcionalidad proxy() permite adquirir objetos Fuente en otra red(), reverseProxy() permite "empujar" objetos Fuente a una red inaccesible de otro modo.

Devuelve true en caso de éxito, false en caso contrario.

Véase también proxy().

[override virtual] void QRemoteObjectHostBase::setName(const QString &name)

Reimplementa: QRemoteObjectNode::setName(const QString &name).

Similar a QObject::setObjectName() (que este método llama), pero esta versión también aplica el name a las clases internas también, que se utilizan en algunos de la salida de depuración.