A quick recap

In log 01, I introduced this personal ambition of learning how to write Windows/Windows Phone apps and my journey so far, including some pain points. I said that the plan forward is to tread down the MVVM road prescribed by Microsoft.

Progress

First, happy to report that I’m over the hump of some initial troubles and have a basic bare-bones model in place which paves the way for future additions!

Here are some pain-points and other misc notes I had to deal with (in no particular order).

MVVMLight is my framework of choice as of now

MVVM is a great pattern for parallel development and it does make a lot of sense to me on an intuitive level. However, it requires a one-time investment in some plumbing code to pass update notifications, commands, conversions around. One can write some base classes that do the obvious common stuff and re-use throughout ones’s projects to make life easier. But…since this is such a common need, a few people have already done the work and put their libraries out for sharing and re-use! I picked up MVVMLight since it seems to have a fairly large user community (well, at least as far as Windows Store apps are concerned ;)). The person who maintains this framework (Laurent Bugnion) is pretty deeply plugged into the development of XAML frameworks themselves so reading his blogs is very informative.

I am not entirely sure why these frameworks aren’t built in to the SDK, but I suppose they want developers to implement the interfaces as needed, oh well.

Turns out, commands don’t work that easily with events

MVVM has this notion of commands which are different from events in that they are not as closely coupled as events are with event handlers. Again, sensible idea that I couldn’t wait to get behind! However, even with all the big talk about MVVM, XAML doesn’t seem optimized for it yet (it’s much easier to write code-behind style projects…you have to work harder to go MVVM at every early stage). Even though the ‘button’ control has a built in field call ‘Command’ that you can simply point to a method in your code, most other events are bubbled up as, well, events; and they can’t point to a command right away. They need a conversion layer in between and you have to either write that on your own or find in some other assembly somewhere. Luckily, MVVMLight was on the ball.

SDK/Target version differences continue to be a problem

I spent a significant amount of time trying to make things work according to this blog (which was a very good write-up, btw) but after a long cycle of Visual Studio complaining and me trying to fight with it, I realized that the technique described by the blog is now outdated. It was good for WP 8.0, but in the Windows/Windows Phone 8.1 Microsoft have now included some of the Event-to-Command plumbing within the SDKs and one needs to use a different namespace (in a different assembly) and some minor differences in usage as well. So, once I came across this blog entry, things finally began to make some sense.

Some assemblies needed to be pulled in explicitly

Even after I read the aforementioned blog entry, things continued to error out with Visual Studio complaining that it couldn’t find ‘Behaviors’ in the namespace ‘Interaction’. Well, I downloaded some sample code from Laurent’s blog and I finally found out the missing link. Apparently you need to explicitly include two assemblies tucked away in some arbitrary corner of the framework’s installation and then everything pops into action. Here is the golden path: “C:\Program Files (x86)\Microsoft SDKs\WindowsPhoneApp\v8.1\ExtensionSDKs\BehaviorsXamlSDKManaged\12.0\References\CommonConfiguration\Neutral”.

Frankly, I have no idea why the f*ck I needed to do this. MVVM is supposed to be the shiznit and the bee’s knees but MS makes you jump through hoops to get it to work. Fine, once you know it it’s probably all obvious but as a first timer this has been an exercise in frustration.

Design-time code didn’t load without some tinkering

I knew that Blend is not a ‘dumb’ parser for XAML; that it does some amount of code evaluation for the editor to be useful. I also knew that it cannot get past authentication checks and some other network calls, but currently I’m just putting in dumb random data generated in a loop. Given that, I expected the DataTemplates to show up rendered in Blend when I opened up my file. However, that didn’t happen. I screwed around for a while, until I figured out that I needed to build the project from within Blend first. Again, nothing that any manual has mentioned yet…not sure why or what’s up. I also couldn’t get my debugger to attach to Blend and load the symbols, but more about that in a later post when it’s more critical. Anyhow, once I built the project using Blend, data was rendered properly and I was able to adjust the layout in a MUCH more intuitive fashion. Finally beginning to feel the payoff for the MVVM pain.

Pivot control is not supported on Windows

I wanted my pages to be universal. I also wanted to use the pivot control to show different activities for different days. But well, the Pivot control is exclusive to the Phone…so I had to split my Home.xaml up between Windwos and Windows Phone. Oh well…understandable. I might have to look into what design paradigms I can use to replace pivot on Windows but that can wait. The phone is a better platform for this app.

I still find it challenging to find the right help articles

I have a better idea of what to look for now, but I still think it’s challenging to find the right help articles for Windows/Windows Phone development. Fair bit of churn in suggested development practicies from SDK to SDK and the differences aren’t easy to spot. Plus, help/blogs are scattered and it takes some scrutiny to make sure you’re looking at the proper write-up.

TL;DR

First of all, I don’t blame you. I am not putting in too much thought on how I structure these because I’m afraid that might make me too lazy to write altogether. So…here is a condensed version of my learnings:

1. The built-in MVVM support is different between Windows/WP 8.0 and Windows/Windows Phone 8.1. So, if you search for help or support, make sure you include the version numbers.
2. 8.1 SDKs have some amount of built-in support for event-to-command but you need to include two assemblies on a golden path: C:\Program Files (x86)\Microsoft SDKs\WindowsPhoneApp\v8.1\ExtensionSDKs\BehaviorsXamlSDKManaged\12.0\References\CommonConfiguration\Neutral.
3. If you are trying to get code executed in Blend, you might have to first build the project from within Blend.
4. Be aware that there are some control that are not universal by nature.