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.
Background
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.
Outcome
By the end of this post we should have a PCL referenced in both of our Application Projects providing a translator interface (ITranslator) along with a couple of implementations which we can then use on our ViewModels as our “contract of translation”. We won’t go into the detail of the Morse Code translation.
Prerequisites
- Visual Studio 2013 Community(or above);
- Windows 8.1;
- Windows Phone 8.1 (ideally a device but the emulator will also do the job);
- Morse Coder Part 1.
Implementation
We should have a Compiling Solution with 2 Application Projects and a Shared Code project, we are going to add a Portable Class Library (PCL) project to our solution. Do this via the “Add New Project” dialog, and selecting Class Library (Portable for Universal Apps). The Portable Class Library for Universal Apps by default targets Windows 8.1 and Windows Phone 8.1, this can be reconfigured through the Project Properties, but isn’t required here.

Our new Project will now be available to add through the reference manager, we can now add References to the MorseCoder.PCL project that we just created from our Windows and Windows Phone projects.

We now want to add some structure to the MorseCoder.PCL project, create the following Folder, Interface and Classes :

Considerations for the ITranslator interface :
- Needs to take user input as a string;
- Needs to return a translated string to the user.
With this in mind we are left with an extremely simple interface…
namespace MorseCoder.PCL.Interfaces { public interface ITranslator { string Translate(string input); } }
…with a single method, Translate, as outlined above, taking a string as input and returning a string.
We now have our Translator Contract defined through an interface, we can now flesh out our implementations, let’s look at the AlphabetToMorseTranslator we created.
Considerations for AlphabetToMorseTranslator :
- must implement ITranslator interface;
- should ideally return some Morse Code, though as previously mentioned, we won’t go into the detail of translation here.
Our essentially stubbed implementation of AlphabetToMorseTranslator looks like this :
namespace MorseCoder.PCL { public class AlphabetToMorseTranslator : ITranslator { public string Translate(string input) { return "...---..."; } } }
Note the implementation of ITranslator, enforcing that our class has a method named Translate following the contract outlined, string input as a parameter with a return type of string. For this example we’re simply returning the Morse Code for “SOS”.
We can now look at adding our interface and dummy implementation to our MainViewModel. What do we know about our current ViewModel, and what do we need to do in order for it to be able to translate and provide feedback?
- It has a string Property “Translation”, which we wired up to a textblock on our view;
- We should be able to populate an ITranslator instance with our translator of choice, we’ll go with AlphabetToMorseTranslator for now;
- If we are in design mode, we don’t want to do any translation; our Translation Property should be assigned something arbitrary in the constructor;
- At runtime, we want to do a dummy translation and assign it to our Translation Property.
With these aims in mind, our MainViewModel can look like this :
namespace MorseCoder.ViewModel { public class MainViewModel : ViewModelBase { private ITranslator _translator; private string _translation; public string Translation { get { return _translation; } set { Set(() => Translation,ref _translation, value); } } public MainViewModel() { _translator = new AlphabetToMorseTranslator(); Translation = IsInDesignMode ?"Design Translation" : _translator.Translate("Some Runtime Input"); } } }
Note the addition of a _translator field, and the assignment of a new instance of our AlphabetToMorseTranslator class (which we’ll put to better use in a later post). Translation is then carried out via our newly populated _translator field and assigned back to the Translation Property at runtime.
As at the end of the previous post we still have “Design Translation” returning in the designer…

…but at runtime we’re getting the response from our Translate method from our PCL via DataBinding updating our textblock, we end up where we set out to be, with a page looking like this…

Summary
Where are we?
- We’ve created a Portable Class Library, adding references from our Windows and Windows Phone projects;
- Created a contract by which we can do simple translation on an input string;
- Created a dummy implementation of our Translator interface;
- Added our interface and dummy implementation to our MainViewModel;
- Carried out a ‘translation’ in our constructor updating our DataBinding Property.
Where are we heading?
- We’ll make better use of our interface, changing our implementation dependent on which way the User wishes to translate;
- Start adding to our User Interface.
2 thoughts on “Morse Coder Part 2 : Portable Class Libraries with Universal Apps”