In Universal Apps the ApplicationData.LocalSettings Property in the Windows.Storage namespace can be used to persist Application Settings. It stores your data into an ApplicationDataContainer, which ultimately provides a wrapper around a Dictionary<string, object> and manages the persistence around the application lifecycle for you.
It can be helpful to be able to reference your Application Settings without needing to cast them from the object stored in the dictionary to the relevant type before consumption every time. We’ll look at wrapping an interface around our Application Settings, giving us the object types, along with the ability to be able to use application settings in our UI at design time.
TL;DR: open the whole solution in blend*.
*for my scenario.
On using the Open In Blend menu option from right clicking a view in Visual Studio…
…I was experiencing the following System.NullReferenceException when opening the view in the Designer…
…on further investigation “The Resource “Locator” Could not be resolved.”
When you right click Open in Blend, it will open the project that your view resides in, along with the View itself in the design window. What it won’t do however, is bring with it any resources it requires from other projects at design time. In this case, my App.xaml file located within the .Shared project, and NOT the platform specific project being loaded was defining my static resources and as such it could not be resolved due to not currently being loaded in Expression Blend. As mentioned in a previous post, the shared folder for all intents and purposes is part of the platform specific projects at compile time.
My resolution was simple, open the entire Solution in Blend allowing it to be resolved!
Seems obvious now but I was stumped for a little while there! Hopefully this will come in handy to someone.
How do we know that our Morse Code Translation Logic is working correctly? This is where Unit Tests prove to be a valuable tool to have in our toolkit. There are a number of Test Frameworks available, NUnit, XUnit, etc. Given that we’re using PCLs targeting Universal Apps, our choices are limited slightly at this stage, so for simplicity and speed of getting up and running we can use the Libraries and Test projects bundled with Visual Studio. There’s masses of documentation and blog posts around Unit Testing and Test Driven Development (TDD) so I won’t go into the why’s here, but if you’re new to the concept I would recommend you read The Three Rules of TDD by Robert C Martin (Uncle Bob).
(If we were following strict TDD, these tests would have been written before we created the translators, but we’ll look past that for now!)
To date, we have a functional, but basic set of Windows Phone and Windows Store applications which can translate Alphabetical Input to Morse Code. One of the key tenets of MVVM Light is the ability to inject design time services or functionality to provide a better design experience. We need somewhere to store our Application Settings, along with a means of setting and retrieving them, we won’t cover the implementation of this, but we will cover the creation of our interface and the implementation of a design time settings class.
By the end of this post we will have, at design time, the ability to manipulate a settings class to be used with the designer in Visual Studio, or through Expression Blend. This will be done via an application settings interface detailing what data we need to store and of course what type it needs to be. As we are targeting multiple platforms, the interface, in a future post will be implemented to provide the storage of our settings per operating system.
One of the main benefits of using Dependency Injection to achieve this is that the implementation of our ViewModel is not concerned with where it retrieves information from and doesn’t need to make decisions depending on which context it is being ran in, this moves us closer to alignment with the Single Responsibility Principle.
Data Binding can be used to dynamically bind information from a set of objects (View Model) to controls on a page (View). Following from the previous post, Morse Coder Part 2, we will be adding some flesh to the User Interface to take input from the user, process, in our case ‘translate’, and return output back to the user via our ViewModel.
By the end of this post we should have a basic, but functional User Interface, taking a sentence from the user via a TextBox, and returning a Morse translation via a TextBlock. We’ll also start to consider Background Colour bindings. As before, this will cover both Windows 8.1. and Windows Phone.
Portable Class Libraries allow the reuse of code cross-platform, following from the previous post, Morse Coder Part 1, we will be implementing a very basic Portable Class Library (PCL), again targeting Windows 8.1 and Windows Phone 8.1.
Portable Class Libraries provide a means of sharing code between Projects targeting different types at the Solution/Project level, they differ from Shared Code Projects in that Shared Projects share resources at compile time and compile as ‘part of’ their host project. You choose your Targets as part of the configuration of the Project, the result being a subset of libraries and namespaces being made available based on intersection of what’s available in the chosen Targets. We will be looking at Windows 8.1 and Windows Phone 8.1, this could be extended at a later date to include a number of other platforms, such as Silverlight, Xamarin, etc.
This is the first in a series of blog posts detailing the process of creating a new Universal App targeting Windows 8.1 and Windows Phone 8.1, from creation of the solution to publication to the store. The goal of the application is to translate between Morse Code and the standard Alphabet and vice-versa.
MVVM Light is an excellent MVVM toolkit by Laurent Bugnion that I’ve used on a number of apps currently published on the Windows Phone Marketplace.
Universal Apps (can, and do by default) use a shared code project in order to share code between platform specific Projects at compile time.