QRemoteObjectHostBase Class

Documentation des fonctions membres

void QRemoteObjectHostBase::addHostSideConnection(QIODevice *ioDevice)

Pour QRemoteObjectHost::enableRemoting() des objets Source sur des appareils QIOD externes, Qt Remote Objects doit avoir accès au canal de communication ( QIODevice) entre les nœuds respectifs. C'est l'appel addHostSideConnection() qui permet cela du côté de la source, en prenant l'adresse ioDevice comme entrée. Tout appel à enableRemoting() fonctionnera toujours sans appeler addHostSideConnection, mais le nœud ne sera pas en mesure de partager les objets source sans avoir reçu la connexion au nœud de réplique. Avant d'appeler cette fonction, vous devez appeler setHostUrl() avec une URL unique et AllowExternalRegistration.

Voir également addClientSideConnection.

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

Désactive l'accès à distance pour l'objet QObject remoteObject . Renvoie false si le nœud actuel est un nœud client ou si l'objet remoteObject n'est pas enregistré, et renvoie true si l'accès à distance est désactivé avec succès pour l'objet Source.

Voir également enableRemoting().

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

Cette surcharge de fonction modélisée permet à un nœud hôte de fournir un accès à distance à un site QObject object avec une interface spécifiée (et vérifiée au moment de la compilation). Les nœuds clients connectés au nœud hébergeant cet objet peuvent obtenir des répliques de cette source.

La meilleure façon d'illustrer ce principe est de donner un exemple :

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

Ici, la MinuteTimerSourceAPI est l'ensemble des signaux/emplacements/propriétés définis par le fichier TimeModel.rep. Des contrôles de compilation sont effectués pour vérifier que l'entrée QObject peut exposer l'API demandée, sinon la compilation échouera. Cela permet d'exposer un sous-ensemble de l'interface de object et autorise les types de conversions pris en charge par les connexions Signal/Slot.

Retourne false si le noeud actuel est un noeud client, ou si le noeud QObject est déjà enregistré pour être remotté, et true si le remotté est activé avec succès pour le noeud QObject.

Voir aussi disableRemoting().

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

Permet à un nœud hôte de fournir dynamiquement un accès à distance au site QObject object . Les nœuds clients connectés au nœud hébergeant cet objet peuvent obtenir des répliques de cette source.

L'option name définit le nom de consultation sous lequel l'objet QObject peut être acquis à l'aide de QRemoteObjectNode::acquire() . S'il n'est pas explicitement défini, le nom donné dans QCLASSINFO_REMOTEOBJECT_TYPE sera utilisé. Si aucune macro de ce type n'a été définie pour QObject, la macro QObject::objectName() est utilisée.

Renvoie false si le nœud actuel est un nœud client, ou si le nœud QObject est déjà enregistré pour le transfert, et true si le transfert est activé avec succès pour le nœud dynamique QObject.

Voir également disableRemoting().

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

Cette surcharge de enableRemoting() est spécifique aux types QAbstractItemModel (ou tout type dérivé de QAbstractItemModel). Ceci est utile si vous voulez avoir un modèle et l'IHM pour le modèle dans des processus différents.

Les trois paramètres requis sont l'adresse model elle-même, l'adresse name qui permet de consulter le modèle et l'adresse roles qui doit être exposée du côté de la réplique. Si vous souhaitez synchroniser la sélection entre la source et la réplique, le paramètre facultatif selectionModel peut être utilisé. Cela n'est recommandé que dans le cas d'une seule réplique.

Dans les coulisses, Qt Remote Objects regroupe les consultations de data() et prélève les données lorsque cela est possible afin de rendre l'interaction avec le modèle aussi réactive que possible.

Retourne false si le noeud actuel est un noeud client, ou si le noeud QObject est déjà enregistré pour être remotté, et true si le remoting est activé avec succès pour le noeud QAbstractItemModel.

Voir aussi disableRemoting().

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

Transférer des objets distants à partir d'un autre réseau

La fonctionnalité de proxy est utile lorsque vous souhaitez partager des objets Source sur plusieurs réseaux. Par exemple, si vous avez une cible intégrée qui utilise des connexions à la cible uniquement (comme locales) et que vous voulez rendre certains de ces mêmes objets disponibles à l'extérieur.

En guise d'exemple concret, disons que vous avez un ensemble de processus qui communiquent entre eux sur votre matériel cible en utilisant un registre, avec le registre à "local:registry" et des processus séparés utilisant un nœud à "local:MyHost" qui contient des objets Source. Si vous voulez accéder à ces objets, mais par tcp, vous pouvez créer un nouveau proxyNode comme suit :

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

Et à partir d'un autre appareil, vous créez un autre nœud :

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

Celui-ci créerait (en interne) un nœud dans proxyNode, qui se connecterait (toujours en interne/automatiquement) au registre fourni (indiqué par le paramètre registryUrl, "local:registry" dans cet exemple). Lorsque local:registry émet le signal remoteObjectAdded, QRemoteObjectSourceLocation est transmis à filter dans l'appel de proxy. Si cette méthode renvoie true (le filtre par défaut renvoie simplement true sans aucun filtrage), l'objet est acquis() à partir du nœud interne et enableRemoting() (une fois que la réplique est initialisée) est appelé sur proxyNode.

Si un hostUrl est fourni (ce qui est nécessaire pour activer reverseProxy, mais pas nécessaire autrement), le nœud interne sera un nœud QRemoteObjectHost configuré avec l'adresse fournie. Si aucun hostUrl n'est fourni, le nœud interne sera un QRemoteObjectNode (pas HostNode).

Renvoie true si l'objet est acquis à partir du noeud interne.

Voir aussi reverseProxy().

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

Transmet les objets distants à un autre réseau.

La fonction reverseProxy() permet d'étendre la fonctionnalité de proxy(), en reproduisant la fonctionnalité du proxy dans le sens "inverse". Ces fonctions sont distinctes, car la communication entre les nœuds n'est pas symétrique : un côté appelle enableRemoting() avec un objet source, l'autre côté appelle acquire() pour obtenir une réplique. L'utilisation de proxy() vous permet d'"observer" des objets sur un dispositif cible à distance via acquire, mais elle ne permet pas d'acquérir des objets Source hors cible à partir du réseau local:* du dispositif. C'est là que reverseProxy() intervient. Si un proxyNode est créé de cette manière :

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

Et à partir d'un autre appareil, vous créez un autre nœud :

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

Alors que la fonctionnalité proxy() permet d'acquérir des objets Source sur un autre réseau, reverseProxy() permet de "pousser" des objets Source vers un réseau autrement inaccessible.

Retourne true en cas de succès, false dans le cas contraire.

Voir aussi proxy().

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

Réimplémente : QRemoteObjectNode::setName(const QString &name).

Similaire à QObject::setObjectName() (que cette méthode appelle), mais cette version applique également name aux classes internes, qui sont utilisées dans certaines sorties de débogage.