There’s a famous quote in the world of Software Development:
“We can solve any problem by introducing an extra level of indirection.”
In my experience, this is almost certainly correct, this post will see us adding in an additional layer of Abstraction to allow us to simplify our Controller(s) and manage our Dependencies in a more straightforward manner.
Last post saw us implement our Translation PCL into our Web API using Dependency Injection. The problem is that our ITranslator Interface only handles a single Translator Implementation, such that when we inject from our Container we can’t currently translate more than one direction. We’ll look into the why’s shortly, but by the end of the post we will have created :
User controls offer a way to abstract common areas of your User Interface in a reusable package, allowing you to simplify your views and push some of the complexity of your UI into more manageable pieces. This tutorial will focus on Data Binding to Properties on a User Control from a ViewModel.
By the end of this post we should have a basic User Control bound against some Commands living in the MainViewModel to manipulate the content of the Input, in our case, we’ll offer a way to input Morse Code (dots/dashes) outside of needing to use a Keyboard in preparation for extending the App to translate both ways from the User Interface. Continue reading “Morse Coder Part 7 : Data Binding User Controls”
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!)
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.