Devices

##Devices Class Diagram As explained in [Push-Snowboarding-Main-Page-(Start-Here)], 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 subclass of QVector<PushBurtonGenericDevice *> and it has two essential purposes:

• Assure that all generated data ([LogTicks]) are connected to [NPushTickDisposer] for proper disposition (garbage collection)
• Maintain the inter-connections in between all the devices (e.g. ptr->connect(dev1, SIGNAL(reading_ready(NPushLogTick*)), dev2, SLOT(incomming_reading(NPushLogTick*)), Qt::UniqueConnection);)
• Take care of properly deleting all devices.

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

##Log Ticks Class Diagram