I’m sure you’re probably all aware that Windows 10 is out, (if not in the news then the nagging to upgrade), I recently took the plunge and upgraded my PC and tablet and have to say I’m rather impressed. Along with the Operating System I also upgraded my development environment to Visual Studio 2015 Community to start taking a look at Windows 10 Apps, (and maybe start dabbling in Xamarin now that it’s so accessible). In light of this, now seems as good a time as any to start looking at implementing our Morse Coder App as a Windows 10 Universal App.
Windows 10 Universal Apps differ from Windows 8.1 and Windows Phone 8.1 apps in that they require only a single Project for the UI, where the 8.1 apps would have had Windows, Windows Phone, and a Shared Project; Windows 10 requires only a single project. By the end of this post we should have a functioning Windows 10 app, with all the current functionality from the existing Desktop Version, running on both the Phone Emulator and the Desktop (and everything in between).
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”
It feels good getting a new app on the store as it’s been quite a while since I got round to finishing something new, the process has changed a bit since last time so it took a little while to get my head around it!
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.
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.