P3: Somewhat important
This task is a feasibility study.
BT LE server advertises its services so that clients are able to connect to it (or in some cases just the advertisement data itself is adequate).
Currently the advertisement state is quite strongly coupled with the connectivity state of the server. The initial startAdvertising() readies the server to accept incoming client connections, and as long as the server considers itself connected, it keeps on advertising. This is a sensible default as it allows other clients to connect to it after the first client too.
However the advertisements cannot be controlled; they can't be stopped after the initial advertisement has concluded, and if they could, they could not be resumed without restarting (disconnecting) the server first.
This task explores the feasibility of making advertisement on/off control orthogonal/decoupled from if a client is connected or not.
The initial suggestion is something like:
// QLowEnergyController // new API: bool isAdvertising() const; signal: void advertisingChanged(); // existing API would be used to control the advertisement on/off void startAdvertising() void stopAdvertising()
And deprecation of the "Advertising" state in Qt6 and ultimate removal in Qt7.
The task is untrivial, and the notable concerns include:
- The internals of the Qt backend implementations are built on the assumption of having the "advertising" state as part of the state flow
- Developer's application may depend on the "Advertising" state and hence it needs to be preserved for functional compatibility in Qt 6
- The behaviour of advertisement when having multiple controllers in the same application needs to be tested to ensure "controller A" does not interfere with "controller B" advertisements
In addition it should be understood if this change could be able to meet also the needs in QTBUG-46008