La possibilità di interagire da remoto con un’applicazione apre scenari interessanti, come l’assistenza remota.

Descrizione del problema

Supponiamo di essere nelle prime fasi di sviluppo di un progetto in cui il team di sviluppo è lontano dal team di design, che non ha le competenze e il software necessario per fare una build dell’applicazione. Dobbiamo metterci in condizione di fare iterazioni veloci di review con il team di design, possibilmente senza spedire loro hardware o richiedere l’installazione di macchine virtuali o altri strumenti di sviluppo. Come possiamo fare?

Negli ultimi anni il framework Qt ha maturato una serie di opzioni per interagire con un’applicazione da remoto. Le opzioni disponibili oggi sono:

Sia VNC che WebGL sono plugin del framework QPA, per cui possono essere usate con qualsiasi applicazione esistente senza ricompilare.

Possiamo usare il plugin VNC con l’opzione -platform vnc. All’avvio, il plugin istanzia un server VNC a cui possiamo collegarci per interagire con la nostra applicazione.

Similmente, possiamo usare il plugin WebGL con l’opzione -platform webgl. Questo plugin lancia un server web minimale che fornisce una HTML che disegna la nostra applicazione tramite comandi OpenGL.

Infine, abbiamo l’opzione WebAssembly, che è sì un’opzione per rendere remota la nostra applicazione, ma non è un platform plugin e quindi richiede interventi abbastanza estesi sul codice.

Vediamo in breve quali sono i pro e i contro di ciascuna soluzione:

VNC

WebGL

WebAssembly

In questo articolo, ci concentriamo sulla soluzione WebGL perché permette di avere una remotizzazione dell’applicazione su un browser, consentendoci quindi di collegarsi tramite pc, smartphone o tablet senza software aggiuntivi.

Rendere il codice multi utente

Se avete già fatto una prova del plugin WebGL con una vostra applicazione (lanciandola con l’argomento -platform webgl), probabilmente avrete notato che il plugin webgl supporta solo un utente per volta. Questo non dovrebbe sorprenderci, visto che un’applicazione UI Qt supporta un solo utente per volta.

La chiave per superare questa limitazione, senza dover riscrivere in modo consistente il sorgente, è avere più processi, uno per ogni utente, il cui stato sia la replica di un’applicazione master.

Qt Remote Objects

Qt Remote Objects è un modulo di Qt che consente di replicare un qualsiasi QObject o QAbstractItemModel tra un processo e l’altro. Non è un modo generico per scambiare dati tra processi, ma è sufficiente per replicare lo stato di una qualsiasi applicazione Qt Quick.

I concetti fondamentali esposti dal modulo Qt Remote Objects sono:

Node

I processi che usano Qt Remote Objects formano una rete in cui sono presenti due tipi di nodi: i nodi Host contengono gli oggetti Source che vengono condivisi, i nodi Client acquisiscono una Replica di un oggetto Source.

Le reti così composte sono reti peer-to-peer, in cui ogni nodo Client deve avere una connessione con il nodo Host che ospita la sorgente richiesta.

Source

Le sorgenti sono istanze di QObject o QAbstractItemModel che vogliamo condividere con gli altri processi. L’istanza di un oggetto Source vive in un nodo di tipo Host e deve essere esplicitamente condivisa dal nodo prima di essere visibile sulla rete.

Condividere un oggetto è semplice:

ControlUnit *o = new ControlUnit; // create your object as usual
QRemoteObjectHost srcNode(QUrl("local:ControlUnit")); // set the node address
srcNode.enableRemoting(o, “MyControlUnit”); // set object name on the node

Replica

Gli oggetti Replica sono dei proxy per gli oggetti Source all’interno dei processi client. L’applicazione client li vede esattamente come gli oggetti originali e quindi possono essere usati all’interno del QML senza problemi.
Per acquisire una Replica di un oggetto possiamo usare questo codice:

QRemoteObjectNode repNode;
repNode.connectToNode(QUrl("local:ControlUnit")); // connect to host node
QSharedPointer<QRemoteObjectDynamicReplica> ptr; // hold the replica
ptr.reset(repNode.acquireDynamic("MyControlUnit")); // acquire object by name
// The replica is ready after initialized()
//connect(ptr.data(), SIGNAL(initialized(), this, SLOT(replicaReady()));

Mentre per acquisire una Replica di un modello usiamo questo codice:

QRemoteObjectNode repNode;
repNode.connectToNode(QUrl("local:ControlUnit")); // connect to host node
QSharedPointer<QAbstractItemModelReplica> repPtr;
repPtr.reset(repNode.acquireModel("MyModel"));

Cerchi un corso su Qt?

Scopri i nostri corsi per aziende

Corsi Qt Develer

Ottenere informazioni sulla API di un oggetto

Gli esempi sopra funzionano bene se esportiamo l’oggetto acquisito al QML, ma sono scomodi da usare in C++ perché non abbiamo accesso alla API dell’oggetto. Questo vuol dire che i modelli acquisiti tramite la acquireModel() permettono di accedere solo alla API di QAbstractItemModel; segnali o slot aggiuntivi non vengono visti automaticamente dalla replica. Questo è il prezzo che paghiamo per usare API generiche come acquireDynamic().

Per avere le informazioni di tipo dobbiamo usare un altro strumento, chiamato repc (REPlica Compiler), che genera un file C++ che contiene le informazioni sulla API del nostro oggetto.Ad esempio, supponiamo di voler aggiungere un metodo addItem(QString) al nostro modello. Il primo passo è creare un file .rep che descrive la API del modello:

class MyModel
{
	SLOT(void addItem(const QString &name));
};

Poi dobbiamo aggiungere questo file alla variabile REPC_REPLICA del nostro progetto QMake:

REPC_REPLICA = myModel.rep

Il compilatore repc crea una classe che usiamo per esportare la API del modello:
Source node:

srcNode.enableRemoting(&model, "ModelAPI")

Replica node:

QSharedPointer<MyModelReplica> ptr(repNode.acquire<MyModelReplica>("ModelAPI"));
engine.rootContext()->setContextProperty("modelAPI", ptr.data());

Abbiamo quindi due oggetti da esportare all’engine QML, l’oggetto che contiene il modello vero e proprio e l’oggetto che contiene eventuali API aggiuntive del modello.

Considerazioni finali

Abbiamo visto che è possibile sincronizzare QObject e modelli Qt tra due processi con poco codice e come replicare la UI su un qualsiasi browser mediante il plugin WebGL. Questo ci consente di interagire con l’applicazione remota come se fosse in locale.

Riguardo a Qt Remote Objects abbiamo soltanto scalfito la superficie di quello che è possibile fare. Ecco alcuni casi per cui vi rimando alla documentazione ufficiale:

Rimani aggiornato!

Ricevi novità su Develer e sulle tecnologie che utilizziamo iscrivendoti alla nostra newsletter.

Iscriviti alla newsletter