TL;DR; I published my first Windows Phone application to get familiar with the tools. It is a visual Brainfuck interpreter. The code is published on GitHub. You can get the app from the Windows Phone marketplace. These series of articles detail my experience switching to the new development platform.

NOTE: THIS IS NOT A TUTORIAL. DO NOT COPY CODE BECAUSE IT IS LIKELY THAT IT DOES NOT FOLLOW BEST PRACTICES.


Part 0 - Visual Brainfuck for Windows Phone
Part 1 - The Interpreter
Part 2 – XAML and Tools
Part 3 - MVVM
Part 4 - Animations

The articles will not quote all the code they refer to. You can view the code directly on GitHub.

   For those of you who may not know MVVM is a design pattern of the MV* family of patterns. In addition to the Model and the View MVVM includes a ViewModel. Like the Presenter in MVP it can respond to events raised from the View. Like the Controller in MVC it has no knowledge of the View. This is achieved through two-way databinding mechanisms like dependency properties and observable collections.

   When I was dealing with databinding for the memory tape representation I had some issues because I did not use dependency properties. All examples on the Internet for that used MVVM so I decided to rewrite the front end logic using MVVM and started reading about the pattern. First thing I learned was that people are not exactly on the same opinion about what MVVM should be. The extremists go for Views with zero lines of code while others tend to wire parts of the ViewModel to the view in the page's code behind.

   The first issue I had with MVVM was calling methods on the ViewModel at some point. Many WP controls do not supports commands (in the MVVM sense) and even then I am not sure I like the concept of commands. Also I had some View logic (mainly related to annimations and the sucky AppBar) that was written in C# and not declared in XAML. I ended up calling methods on the ViewModel directly. Frankly I do not see what is wrong with this and why it is frowned upon. It seems to me that this does not introduce additional coupling, code duplication or create problems with unit testing but I may be wrong.

   Because this app is a Brainfuck interpreter when the computation starts the ViewModel needs to periodically raise events as the program executes that are not initiated by the user interface. What is more I could not handle many of the actions through databinding (mainly the animations) so I needed some way to push events (like the interpreter's step execution) to the View. One concept I came across was the concept of static event bus. The idea is to create a static class with static event where everyone can subscribe. I can see how this can be useful in WPF desktop applications where one window can update data shown in other windows but in my case this solution just seemed wrong. I ended up exposing events on the ViewModel and handling them in the View. I came across other suggestions on the Internet but I did not understand them and I already had direct method calls on the ViewModel so things could not get much worse if I had events.

   I am sure I will learn many more things about the databinding and the MVVM pattern in the future but I doubt I will like the "codeless" Views.

   In part 4 of the series I will discuss how the animations in BF for WP work.