A quick update on the status and health of the CueDeck project:
As you may have read in previous blog posts, CueDeck is an evolutionary product, in that it’s codebase has grown organically since the development of the original concept software, FXPerformer almost three years ago. “Organic” software development sounds exciting, but in reality – particularly when it involves skipping and jumping between different UI technologies such as WinForms, and now WPF – the organic nature in which the software has developed has resulted in a mess of unmanageable code! Thats why I made the choice to see the launch of CueDeck as an opportunity to wipe the slate clean and begin again: Putting into place all the best features of the software, and losing the worst – and also creating a maintainable piece of software. Maintainable is a good thing, since it means fewer bugs – and a far greater possibility of frequent upgrades to the software.
In order to force that change of design, I opted to completely rewrite CueDeck using the C# language – and utilising the latest .NET framework. For the end user, this means stability and performance – particularly when it comes to the user interface, which has been built entirely using Windows Presentation Foundation (WPF).
Switching from WinForms (the original Windows user interface model), to WPF was a challenge, and at first I didn’t get it all right. The alpha version of CueDeck – although written using WPF – made numerous fundamental mistakes in is design, and those mistakes lead to greater and greater merging of business and user interface logic. At the point where I stopped, the two elements of the application were inseparable! I needed a new approach, and with my recent shift into iOS development I’d become a big fan of the MVC design pattern.
If you’ve not heard of design patterns before, in a nutshell, it’s a method of defining a structure to your code that ensures – in most cases – that the logical blocks of code you have are only concerned with and aware of the elements of the software they need to in order to do their job. This ‘separation of concerns’ notion has lead to countless patterns being defined, with one of the most popular undoubtedly being the Model-View-Controller (MVC) pattern. This defines that the Model portions of your software (the parts that define the entities within your code, and the logic they should follow), should be separated from the View (the user interface, such as buttons and sliders). These two parts of your software should not be aware of each other, and should only ever communicate with each other via the use of a ‘Controller’ – a piece of code that bridges the two. In the case of CueDeck, the model can be thought of as being the individual tracks and playlists, and the methods that are used to play the audio files; the Views are simply the snazzy user interface, and the controllers are the decks themselves. Each deck defines the unique way it should tie the model with the user interface. Its in this way you can easily translate a common underlaying model between the different types of visual decks. At the end of the day, each deck simply represents a collection of audio files that need to be played. How they’re displayed, and what logic applies to that deck is defined by the controller.
The problem with MVC is that it doesn’t quite work with WPF. Or at least, it’s not the way WPF was designed to be used. Instead, Microsoft – in their usual manner – defined a completely new model they rather confusing called the Model-View-ViewModel pattern, or MVVM for short. In this case the definition of a controller is replaced with that of a ViewModel – which is simply that: It’s a model of the view you wish to attach it to. It still contains all the logic that defines, in CueDeck’s case, a Deck – but the VM presents that data and logic in a very different manner, through use of Dependancy Properties and a Routed Command structure. This ingenious approach means that there isn’t actually any direct connection between the view and the controller. The two parts of your program are unaware of each other, and are attached to each other dynamically at runtime. It took a while to get my head around this approach, but I’m glad I did. The MVVM pattern, once setup, really does enforce the separation of concerns. It becomes very clear when you’re trying to do something that breaks the pattern, and you’re forced to rethink what you’re doing. Chances are, you’re trying to implement something in the wrong place. In that sense, choosing to base the new version of CueDeck on MVVM has resulted in much cleaner, tighter code – and a fantastically simple approach to designing and tweaking the user interface. If you chose to use this pattern, you’ll find Microsoft’s companion UI design software Blend becomes your best friend. Never before have I designed a user interface that presents me with live data!
Hopefully all this will lead to a much quicker development time, and refinements to the user interface – one of CueDeck’s defining features – will be a joy to look forward to.
CueDeck is currently wrapping up it’s alpha testing stage, and will be available for beta testing very soon. Subscribe to our RSS feed to keep up to date with announcments and news.
Thanks for your support!
Oli.
