Right now, one of the big differences between Windows Phone and Windows 8 is what third party components you can use. For Windows Phone you have a huge selection of components that you can choose from to get help with anything from MVVM to animations. We used several when implementing Reseguidens sista-minuten application. One we used quite extensively throughout the application is ServiceStack.Text to parse JSON.
If we had been lucky we would have been able to re use the same libraries in Windows 8. If we had been smart we would have isolated all third party libraries so we easily could swap them.
Since we where unlucky and did not isolate third party libraries properly, we are now writing a blog post about the importance of isolating external components and how to use the built in JSON parser in .NET 4.5.
This post is a part in a series – you can find the full index here.
To be perfectly clear – the problem is not third party components by themselves. The problem is that we end up with dependencies to libraries that is not built as a Windows 8 library. This is a problem because even if we can reference them in our project, we won’t get it accepted in Windows Marketplace.
In other words – it is futile to cling on to components not built for Windows 8 if you ever want to distribute your application.
Since we cannot use the JSON parsing provided by ServiceStack.Text (since it is not built for Windows 8 ) we need to replace it with something else. Here we got three alternatives.
JsonObject has been available as a NuGet package before but has now, much like HttpClient, merged with .NET 4.5. The big advantage of using JsonObject is that it’s similar to ServiceStack.Text in how you use it.
// working with ServiceStack.Text
var departures = json.ArrayObjects("departures").ConvertAll(x => new DepartureIVM(x));
// working with JsonObject
var departures = jsonObject.GetNamedArray("departures");
for (uint i = 0; i < departures.Count; i++)
var departure = departures.GetObjectAt(i);
JsonObject is perhaps somewhat chattier, but you could easily get the same syntax with som extension methods.
So, what did this mean for us? Well, basically to go through the entire application and replace all JSON parsing (spread through the entire application) with a Windows 8 compatible version. Not a lot of work, but a lot of time could have been saved if we would have isolated the actual JSON parsing and usage of ServiceStack.Text.
There are many, many libraries out there that you can use to enhance the user experience or the development experience when creating a Windows Phone application. You got MVVM frameworks, serialization frameworks, Silverlight toolkit, cache frameworks and many more. They all add something (also complexity and another layer of abstraction), but they can also get in the way when porting your Windows Phone application to Windows 8.
If we, for example, had choose to use a MVVM framework, and then not been able to find a Windows 8 compatible version, we would have been stuck with a lot of unusable code that we would have to rewrite completely before migrating.
We are all in agreement that you really should try to limit the amount of frameworks you add to a Windows Phone project. Usually, you can manage just as well without them. Often it is even better to write a couple of lines by yourself to get the exact functionality that you need instead of adding a framework that kind of give you that functionality. The risk that you eventually might need to work around your almost-perfect-framework (or get in trouble when converting to Windows 8…) is too big to never reinvent the wheel.