Qt Remote Objects Source

De manière générale, vous pouvez choisir d’utiliser directement un type QObject comme source ; vous pouvez également définir l’API souhaitée dans un modèle .rep destiné à être utilisé avec le compilateur repc.

Si vous disposez déjà d’un objet « QObject » entièrement défini, vous pouvez l’utiliser comme source en le transmettant à la fonction QRemoteObjectHostBase::enableRemoting(). De cette manière, d’autres processus ou périphériques peuvent alors créer des « dynamics replicas » de cet objet afin d’interagir avec lui.

Pour plus d’informations, consultez la section « Interaction avec des objets distants ».

En laissant repc générer un fichier d'en-tête source pour votre projet, à l'aide de la variable REPC_SOURCE, vous disposez de trois options différentes pour implémenter l'API requise.

Supposons que le nom de votre classe soit `Foo` ; vous disposez alors des options suivantes :

• Héritage deFooSimpleSource
• Héritage deFooSource
• Utilisation de «FooSourceAPI » avec votre propre QObject

Pour plus de détails sur la création d’un fichier « .rep », consultez la section « Le format de fichier rep ».

Une classe <Type>SimpleSource est définie dans l'en-tête ; elle fournit les méthodes getter/setter de base pour chaque propriété et implémente les membres de données du type de propriété correspondant dans l'en-tête. « <Type> » représente ici le nom de la classe issu du fichier .rep; ainsi, si votre classe est de type « MyType » dans le fichier .rep, le fichier d'en-tête généré contiendra une classe MyTypeSimpleSource déclarée. Il s’agit d’un moyen rapide de se lancer dans l’utilisation de l’API. Pour utiliser cette classe, vous devez écrire une classe qui en hérite et implémenter tous les slots définis, qui sont marqués comme virtuels purs dans le fichier d’en-tête généré. Vous devez également ajouter à votre classe la logique nécessaire pour gérer les propriétés exposées et émettre des signaux.

Si vous avez besoin de masquer les détails de votre implémentation, utilisez la deuxième classe déclarée dans le fichier d'en-tête, la classe <Type>Source. La définition de cette classe ne fournit pas de membres de données et rend également les fonctions getter/setter pures virtuelles. Bien que cela puisse nécessiter d’écrire davantage de code, l’utilisation de cette classe vous offre une plus grande flexibilité dans votre implémentation.

La troisième classe générée dans l’en-tête est <Type>SourceAPI. Il s’agit d’une classe basée sur un modèle, destinée spécifiquement à la version modélisée de la fonction ` QRemoteObjectHostBase::enableRemoting()`, qui vous permet d’utiliser comme source n’importe quelle ` QObject ` prenant en charge l’API requise. Utilisez cette classe pour masquer ou convertir des propriétés ou des paramètres de signal/slot. Si votre implémentation ne fournit pas l’API appropriée, des avertissements s’afficheront lors de la compilation.

Identification des sources

Étant donné qu’un nœud hôte peut partager plusieurs sources, chacune d’entre elles doit disposer d’un nom. Tous les en-têtes générés par repc incluent un moyen permettant au nœud de déterminer le nom de la classe : Q_CLASSINFO pour les types replica, simplesource ou source ; ou une fonction statique name() pour le type SourceAPI. Si vous transmettez votre propre type QObject à la fonction QRemoteObjectHostBase::enableRemoting(), le nom est déterminé selon la logique suivante :

• Un nom peut être transmis de manière facultative à la fonction QRemoteObjectHostBase::enableRemoting(). S’il est fourni, ce nom est utilisé.
• Si l'objet ou l'un de ses ancêtres dispose d'un Q_CLASSINFO de type « RemoteObject Type » défini, ce nom de type est utilisé.
• Si l’ QObject`objectName` est défini, il est alors utilisé.
• Si aucune des options ci-dessus n’est disponible, l’appel à ` QRemoteObjectHostBase::enableRemoting()` échoue et renvoie `false`.