Inversion of Control (IoC)

Windows Phone presents some interesting challenges for testing apps in various deployment scenarios. For example, a common requirement for phone apps is the need to behave differently depending on whether the app has been purchased or is in trial mode. Furthermore, the launcher and chooser API does not play well with unit tests because launchers and choosers cause the app to be deactivated. Hence, there is a need for some mechanism to alter the behavior of an app, depending on its deployment scenario, and to decouple and replace various phone-specific types so that code can be more easily tested. One way to achieve these things is by using Inversion of Control (IoC).

IoC encompasses two key concepts presented in this chapter: service location and dependency injection.

Service location allows you to associate a type, often an interface, with a concrete implementation of that type, so that when another component requests the first type, it is automatically delivered an instance of the associated type. This allows your code to be decoupled from any particular concrete implementation, which increases flexibility, and allows the behavior of your app to be modified, without having to change all references to a particular concrete implementation.

Dependency Injection (DI) assists in the creation of objects by automatically supplying known types to the objects constructor during instantiation.

Employing IoC in Windows Phone apps helps overcome the challenges brought on by the rigid infrastructure and numerous sealed classes that account for many of the key types in the SDK and that hinder both unit testing and ad hoc testing.

Numerous IoC frameworks have been designed for Silverlight for the browser and the desktop CLR. Previous versions of the Windows Phone OS, prior to Windows Phone 8, were based on the Microsoft .NET Compact Framework (.NET CF), which lacks the capability to generate Microsoft Intermediate Language (MSIL) and does not include the Reflection.Emit APIs, which is a key ingredient in generating types at runtime. This limitation meant that none of the well-known IoC projects, such as the Microsoft Patterns and Practices Unity framework, existed for the phone. This has changed in Windows Phone 8, which is no longer built on .NET CF.

Included in the sample code is an IoC container and DI framework that I have created, which is based on work by Ian Randall (http://microioc.codeplex.com/). It is a lightweight container that does not have all the features of other containers, but it is sufficient for most scenarios.

I leave it to you to discover and explore other third-party IoC containers.

Like much of the code presented in this book, these classes are present in the downloadable sample code. I recommend, however, that you procure the latest code from http://calciumsdk.com, where you are sure to have the most up-to-date version.