Details
-
User Story
-
Resolution: Out of scope
-
P3: Somewhat important
-
None
-
None
-
None
Description
Overview
There will be a FIFO inside each sensor.
The backend supplies readings to the FIFO. The application pulls items out of the FIFO.
void MyClass::onNewSensorData() { while (sensor->readingsAvailable()) do_something(sensor->takeReading()); }
Implementation Plan
Remove the reading() method. Add a takeReading() and a readingsAvailable() method.
The readingChanged() signal will be replaced with a newSensorDataAvailable() signal.
The actual FIFO should be a class that's visible to QSensor and to the backend.
Notes
A source-compatible implementation could possibly be done if we use some policy. This would enable the feature to be rolled out to existing users without requiring them to port to a new library. The existing reading method would point to the front of the queue, the queue would replace old with new values and would default to a depth of 1.
Research Questions
Maybe some better method/signal names can be found?
What does example app code look like?
How can we unit test this (should be easy if it's a self-contained class)?
How can we document this (should be mostly private, just document the methods that are exposed in QSensor)?
Does this hold pointers (for polymorphism) or a concrete class (in which case how to we expose per-sensor data)? Should the API be in the sub-classes of QSensor?