Devices

##Devices Class Diagram As explained in Main-Page, this "devices" are the core of the communication model the app uses underneath. In short, the class diagram shows how the different sorts of devices all share their core functionality 

All this devices share PushBurtonGenericDevice's interface:

#include <QObject>
#include <QString>
//#include <QVector>
#include "npushlogtick.h"
#include "npushgenreport.h"

/* This is the base class for all devices.
 * This adds to all its subclasses the following functionalities
    * Adds QObject basic functionality for all devices (emit/slots/signals)
    * Periodic timer for sensor pooling (subclasses assign period value to timerPeriod variable)
    * defines the common interface for all sensors
 */
class PushBurtonGenericDevice : public QObject
{
    Q_OBJECT
public:

    PushBurtonGenericDevice(QObject * parent = 0);

    virtual ~PushBurtonGenericDevice() = 0;

    virtual QString get_description() = 0;

    virtual void start_readings();
    virtual void stop_readings();

    virtual bool is_online() = 0;

    virtual void disconnect_from_backend();

    virtual bool start_run();
    virtual bool end_run();

    virtual bool subscribesToAny();
    virtual bool subscribesTo(PushBurtonGenericDevice* deviceType);

protected:
    int timerId;
    int timerPeriod;

public slots:
    virtual void incomming_reading(NPushLogTick *);

signals:
    void reading_ready(NPushLogTick *);
    void report_ready(NPushGenReport *);
    void connected();
    void disconnected();
};

Further down the inheritance tree you can note that the sensors get more and more specialized. PushN8BtDevice, for example, embeds all Bluetooth related code and some functions that process/parse the incoming data to assure it is valid (just "validity" checking.. CRC should be implemented in the future, any simple one should do it). It is important to note that Devices are not exclusively interfaces to physical devices; if you reimplement subscribesTo(PushBurtonGenericDevice* deviceType) (and subscribesToAny() accordingly), the output of the selected devices will be connected to your incomming_reading(NPushLogTick *) slot as soon as they are available. This capability was built to help the implementation of Devices on higher abstraction levels. Good examples of such are PushN8AbsNormFeetDevice and PushN8AirTimeDetector.

This devices are handled by the application through two modules: PushDevicesHolder and DevicesManager.

• Pushdevicesholder is a managed list of all running (created) devices.
• Devicesmanager serves to aid the creation/management of created devices. This is essential for, for example, bluetooth devices where there are earlier steps (search/pairing) than that of the actual device creation.

What hasn't being explained so far is how actual sensor/Device data/output is represented and how it is managed; sensor (either from a physical sensor or from a abstract sensor/estimator) data is represented by NPushLogTicks . A LogTick is the minimal part of data (log) from a sensor acquired during a "clock tick" (hence the name).