How does QML interact with C ++ through WebSocket ?, Qmlwebsocket

How does QML interact with C ++ through WebSocket ?, Qmlwebsocket
Preface

As a full-duplex network communication protocol, WebSocket is gradually accepted by various development frameworks and languages.

Among them, a large amount of data is transferred between the browser and the program, that is, WebSocket.

Today, let's talk about how QML interacts with C ++ through WebSocket.

Signal and slot? WebSocket

Generally, QML is used to develop programs that interact with C ++ through signals and slots.

At this time, the problem arises. If the requirement is to be cross-process or cross-device, then this traditional method is not feasible.

Ps: Qt Remote Object is not discussed here

Generally, we write an interface in C ++ to encapsulate the communication protocol, such as TCP or message queue, and then register a class to QML, then, call the registered class and interface in QML.

This process is cumbersome and involves many interfaces, causing a lot of troubles and inconvenience.

In addition, if you develop the application layer Wheel Based on some underlying protocols, such as the transport layer's TCP, there are more problems. I believe everyone who has created the wheel will feel it.

Even if HTTP is used, problems such as performance, network latency, and reverse notification (the server actively notifies the client) occur.

Therefore, WebSocket has emerged to solve this series of problems within a certain range.

Use

Directly go to the Code to show how to use WebSocket

C ++ code (server ):

QWebSocketServer server ("MyServer", QWebSocketServer: NonSecureMode); // instantiate a WebSocket server QObject: connect (& server, & QWebSocketServer: newConnection, [& server] () // connection signal. lambda is used here to simplify code {// auto webSocket = server when a new connection is received. nextPendingConnection (); qDebug () <"newConnection:" <webSocket; QObject: connect (webSocket, & QWebSocket: textMessageReceived, [webSocket] (const QString & message) // connection signal. lambda is used here to simplify code {// qDebug () <"server textMessageReceived:" <message; webSocket-> sendTextMessage ("Please enjoy WebSocket") ;}); qDebug () <"listen:" <server. listen (QHostAddress: Any, 18546); // start listening

These lines of code can implement a simple WebSocket server response mechanism.

Similar to QTcpServer, QTcpServer extends some interfaces and attributes.

QML code (client ):

WebSocket {id: webSocket url: "ws: // 127.0.0.1: 18546" // url indicates the target address, port, path, and query: true // active indicates that onStatusChanged: {// listener socket status change if (status = WebSocket. open) {// Open status indicates that the connection has been opened. Send a "Hello WebSocket" print ("WebSocket is opened"); webSocket. sendTextMessage ("Hello WebSocket") ;}} onTextMessageReceived: {// the data received by the listener. print the received data to the console using print ("onTextMessageReceived:", message );}}

You can simply operate WebSocket in QML to complete one sending and receiving operation.

If it runs normally, after C ++ and QML run in sequence, the console will print the following:

qml: WebSocket is openedqml: onTextMessageReceived: Please enjoy WebSocket

Path & query

Like HTTP requests, WebSocket can add path and query to URLs to make requests more standard and concise.

For example, if a WebSocket request from a chat room is sent to chat room 1 and all types of messages are received, the url can be written as follows:

Ws: // MAID: 18546/chatroom/1? Filter = all

On the C ++ side, you can resolve the problem as follows:

qDebug() << "path:" << webSocket->request().url().path();qDebug() << "query:" << webSocket->request().url().query();

C ++ end, the printed content is as follows:

path: "/chatroom/1"query: "filter=all"

Summary

Compared with common HTTP and TCP, WebSocket combines the advantages of both. It is convenient and convenient to use, and can maintain long connections, low latency and two-way communication.

However, WebSocket cannot be a 10 thousand protocol. It does not mean that when it appears, HTTP and TCP will be killed directly. In the end, the technical selection should be based on the actual needs of the project.