Coding recommendations

Table of Contents

• Use the Introjucer
• Namespaces and library-(in)dependency
• Interfaces

Of course, you are free to modify the code as you like. However, this page is meant to explain a few design concepts behind the code, hoping whoever uses the code might find this useful.

Use the Introjucer

Use the Introjucer for any changes to the project (e.g. adding new source files). That way, those changes affect both the Windows and the OSX projects.

Namespaces and library-(in)dependency

A lot of the code was written to be independent of any third party library. This is reflected by the different namespaces (and the corresponding source code structure). Have a look at the Namespaces page for details.

Please try to stick to this system and do not include third party libraries in namespaces that were meant not to rely on third party libraries. Also, it is recommended to make use of the Interfaces that were provided to be able to switch third party libraries where they are needed.

Interfaces

Within the main namespace wonder, wherever functionalities from third party libraries are needed, interfaces are defined to allow free choice of which library is used. These interfaces are:

• wonder::OscSender An interface for sending WONDER-related OSC messages. Several Liblo-based implementations can be found within namespace wonderlo.
• wonder::OscSenderThread An interface adding thread capabilities to the wonder::OscSender interface. See wonderlo::WonderOscServerSenderThread for a Liblo-based implementation.
• wonder::VisualStreamReceiver An interface for a thread that listens to the incoming OSC messages that are sent by cWONDER as the "Visual Stream", along with a listener interface for corresponding callbacks. See wonderlo::VSReceiver for a Liblo-based implementation.
• wonder::ConnectionTimer An interface defining a cyclic timer. See wonderjuce::JuceConnectionTimer for a JUCE-based implementation.
• wonder::XmlParser An interface for parsing the "xmlDump" XML string that is sent from cWONDER. A JUCE-based implementation is contained as a private class within wonderjuce::XmlFactory and can be accessed via the singleton-getter wonderjuce::XmlFactory::getParser.

These interfaces also define factory interfaces (as internal classes). If you inject these factories into your classes via the constructor and use them to create new instances, you can keep you code decoupled from the actual implementations of those interfaces. For an example, have a look at the constructor code of wonder::SourceController or wonder::PingControl.