I have seen Nick Landry’s session on implementing Text to Speech with Cortana and how you can add this small feature to your applications to add some really unique functionality. The issue of course is that each platform handles Text to Speech completely different. I have create a very simple yet flexible API allowing you to add Text to Speech functionality to: Xamarin.iOS, Xamarin.Android, Windows Phone, and Windows Store.

GetInstalledLanguages

This was bonus perk really to add, which was the ability to gather all of the installed languages that are compatible with the Text To Speech engine on the platform. This allows you to manually set or allow your user to pick what language they want to speak back with. On Android this even takes advantage of the new Lollipop APIs!

Speak

My speak API allows you to simply pass in some text to speak back with all defaults, or really go to down and completely customize how the TTS engine plays back the sound. Here is what it looks like:

As you can see you have complete control over pitch, speak rate, locale, and even if you want to queue up the TTS engine or stop it completely. I am really proud to say that on Windows Phone/Store I use the complete Ssml engine to handle the advanced functionality, which is pretty slick.

Get It Today

The full source code is available today on GitHub along with full API documentation. Of course you can grab the NuGet as well and install it from Xamarin Studio or Visual Studio in a Xamarin or Xamarin.Forms project.

Settings Everywhere

Back in March, I updated my settings plugin to be completely generic from any framework. This means anyone can use it no matter if you are developing with traditional Xamarin, Xamarin.Forms, or MVVMCross. Today, I am pleased to announce a brand new update, 1.4.0.0, that brings a flurry of enhancements and fixes.

Enhancements

Over the last several months I have added support for Windows 8.1 and Windows Phone 8.1 RT development and in this latest version I bring full support for Xamarin.iOS Unified projects.

Simplified API

I have received a lot of feedback over the year on how the API worked. The biggest issue was that I enforced that you first attempt to “Update” the setting and then call “Save” to actually store the value. This is nice if you wanted to do batch saving of settings, however it was very annoying and created extra code. I have listened and created an even easier API:

There you have it, simply get and set from the settings and the library will handle the rest for you.

Data Types

I have also expanded the datatypes that you can store:

• Boolean
• Int32
• Int64
• String
• Single(float)
• Guid
• Double
• Decimal
• DateTime

Bullet Proof

In addition to all of these enhancements I wanted to make sure that going forward anyone would be able to pull down the library, make changes, and do a full regression test. I have built out a full NUnit test library to ensure the highest quality for the library.

Get it today

As always you can get the entire source code on the GitHub project where you can contribute to the project. Additionally, you can get the NuGet today.

On my GitHub I have started to build out a lot of applications, sometimes using MvvmCross and sometimes not. One of my most starred repos is my MvvmCross plugin for saving settings on Android, iOS, WP, and Win 8. My idea originally was simple: Use the native settings management system across all platforms. This means SharedPreferences, NSUserDefaults, IsolatedStorageSettings, and ApplicationDataContainer. I didn’t want to do anything too crazy to re-invent the wheel, so this means you can only store data values that the platform allows such as:

• Boolean
• Int64
• String
• Single
• DateTime

Doing anything more then this to me means you should use some sort of blob storage such as Akavache. Since my library is very simple this means you can still use a PreferenceActivity on Android to get a nice native settings screen (this was my main motivation really). So it is great that I have MvvmCross support, but what about standard Xamarin projects?

Today, I am pleased to introduce a brand new GitHub repo called “Xam.PCL.Plugins”. This is a repo that is open source and will house all of my PCL NuGet Plugins for cross platform development. To start things off I am introducin my very first plugin, which as you might have guessed is cross platform settings! It is already available on NuGet for your app consumption :)

All you need to do is install the NuGet into both your PCL and client projects and you will be on your way! If you are interested in creating more plugins with me or converting MvvmCross plugins over simply fork my repo and send a pull request. You can use my settings project as an example of how to structure your project to work properly with PCLs. Additionally, PCLStorage is a great repo to also look at for starting development for a more advanced PCL.

One feature in particular was a bit tricky which was that when the app starts up it calls out to a web service to pull down an update notification. I use HttpClient to easily call out with GetStringAsync and then parse the JSON with Json.NET. While this feature seems trivial, you have to remember that a PCL uses just a subset of the .NET Framework and unfortunately when you select Windows Phone System.Net.Http is no longer available. So here is how I went about adding in this functionality.

Create my PCL

From File -> New Project you will want to create a new Portable Class Library. Once you name it you can specify what platforms you want to support in this popup:

Inside of Xamarin Studio it is very similar except that this popup doesn’t exist. You will have to select the Projects options and select the platforms you want to select after the project has been created, which is easy enough:

NuGet to the rescue!

One amazing thing about PCLs is the vast libraries that are available on NuGet. To get started you first need to get the latest NuGet manager for either Visual Studio or Xamarin Studio to consume these NuGets in your app. Once you have this we can simply right click on our References in the PCL and select Manager Nuget Packages. Once the window opens up simply search for Http Client to find the System.NetHttp Nuget:

Awesome! Now we have HttpClient in our PCL and we can use it to make web request…. right?

Not so fast! Troubles in PCL Land

One thing to know about Portable class libraries is that they aren’t like other libraries out there and can bent and twisted to do crazy things. I wont get into the details of how PCLs exactly work as you can read Stephen Cleary’s post on them. I will say is that the NuGet package we just installed has a portable implementation of the HttpClient for platforms that don’t have them built in, such as Windows Phone. We can compile against this “contract” and implementation, but at build and deploy time the platform specific version will be used. This is important because both Xamarin.Android and Xamarin.iOS already have an implementation of System.Net.Http, so to make sure they get used we will want to add the references to those projects from our Add References popup.

On Windows Phone though it is a bit trickier as we need proper async/await support and a few platform specific HttpClient implementations. This is easy to remedy though as all we need to do is add the same NuGet to our Windows Phone projects! Check! Done!

Close to the finish line!

Now ideally at this point we should just be “done” and when I was building out my demo project I thought I was until I ran my app on an iOS device. As you may know that iOS apps are all ahead of time compiled (AOT), which means that if any of your code needs to JIT it simply will not work. For some reason at compile time the facades don’t kick in properly and it tries to use the NuGet version of System.Net.Http which has some specific functionality for older platforms. We simply do not need this, so let’s show MSBuild who the boss is and redirect it to use our DLL that we have already. All you need to do is create a new app.config file in your Android and iOS project. We will then tell the app.config to forcefully use our DLL that we included with this config:

Now we are back on track and everything works properly!

Super charge HttpClient!

Now we could just stop there, but what fun would that be? HttpClient is great, but we can actually improve upon it with using platform specific networking libraries. This is where Paul Betts’ ModernHttpClient Component comes in. He describes it as:

*This library brings the latest platform-specific networking libraries to Xamarin applications via a custom HttpClient handler. Write your app using System.Net.Http, but drop this library in and it will go drastically faster. This is made possible by two native libraries:

On iOS, AFNetworking 1.3.3

On Android, via OkHttp 1.2.1*

So this is fantastic because we don’t actually have to change any of our HttpClient code except for when we create a new one where we can pass in a HttpMessageHandler. So let’s get this puppy installed and super charged!

First off is to install the ModernHttpClient Component in both Android and iOS projects. You can do this by right clicking the components folder and selecting Get More Components. Once the component store comes up simply search for ModernHttpClient and add it to your project:

Alright, now it is time for some platform specific code as we will need a way to get the AFNetworkHandler or OKHttpNetworkHandler in our PCL. To do this we will need a little bit of platform abstraction, so I will create an interface that I will implement on both Android and iOS. The interface is simple as it has one simple getter for a HttpMessageHandler and then simply create the specific handler on each platform:

I have my own IoC container that I use to register these classes in each application’s start up code. Then whenever I need to actually create a new HttpClient I use this simple method to get the correct HttpMessageHandler to pass in to HttpClient’s constructor:

There you have it! HttpClient everywhere and super charged on both Android and iOS with ModernHttpClient. If you happen to be using MvvmCross check out my good friend Tomasz’s GitHub for a nice plugin for ModernHttpClient.

*Note: System.Net.Http relies on Microsoft BLC Build Components NuGet and this is recommended to add to all of your projects that reference the PCL.

It is important to remember that there is nothing special you need to do to get PCL support. If you copied over dlls or added xml files you should remove all of this and just use the Stable branches of Xamarin to get official support.

What is a PCL and what are profiles?

A PCL is a portable class library which is a project template inside of VS and XS which allows you to select platform targets that the project will be compatible with. This is amazing because you have one project that works everywhere. PCLs have actually been around since VS 2010, but they have always been locked into Windows specific platforms, but that all changed last November when Microsoft and Xamarin announced a major partnership which included PCL support for Xamarin.Android and Xamarin.iOS apps. PCLs use these things called “profiles”, which are actually supposed to be hidden from developers, but you will see them everywhere. Profile numbers are a peek into what platforms the PCL supports and how NuGet handles PCL support when installing. There are several parts to a profile such as net45, wp8, and now monotouch and monoandroid. PCLs work a bit interestingly which is that the DLss that are in the .NET subset are actually more like stub methods or interfaces that you are developing against. The DLL that gets used is the DLL that is included in the base project. This still puzzles me a bit and I am not a Microsoft PCL compiler expert like Daniel Plaisted, so you can ask him tons of questions on Twitter.

Tips & Tricks

1. Remember that PCLs are platform independent. Not all APIs will be available to you.

2. Don’t try to put platform specific code in a PCL, that is now what they are for. Abstract all platform specific code with interface that you implement on each platform

3. PCL’s are great for large or small libraries, try to break your project up into small re-usable components. For instance I have a Settings PCL that is cross platform compatible that I reuse on every project. Growing a large PCL is fine, but try to think about how you can reuse code on more projects

4. Choose only the targets you want to support. The more you select the smaller the subset of .NET you will get. If you select Windows Phone which doesn’t have HTTPClient you will not get access to it.

5. Use NuGet to fill in the gaps. If you need to use a specific PCL profile be sure to search NuGet to see if there is something to fill in the missing functionality such as HTTPClient or PCL Storage.

6. Recommendation is to leave out Silverlight and Windows Phone if you are not currently developing for these platforms as they will limite your APIs.

7. This means use Profile 7 or Profile 78 for your projects based on your needs.

Setup

Here is a short guide on how to create your first PCL:

Visual Studio

Inside of Visual Studio it is easy to create a PCL by simply selecting File->New Project -> C# -> Portable Class Library.

When you select this you will see a dialog pop up asking you what platforms you wish to support.

That’s it you are good to go. As you can see they hide the “Profile” from you, but if you expand your References folder and select the .NET Subset DLL you will see in the path a specific profile that you are using.

Xamarin Studio

Similar to Visual Studio you will create a new PCL by selecting File->New Project -> C# -> Portable Library:

Now instead of popping up the target dialog like Visual Studio does you need to actually edit the project properties to specify the correct PCL Profile:

PCL/NuGet Issues

All PCLs and NuGets are not created equal and you will need to do some testing that is for sure. One issue that a lot of people might run into is with Json.NET that has an official Xamarin Component and also an official NuGet as well. While the NuGet does have official support for Xamarin.iOS and Xamarin.Android and issue does comes up if you are using profiles that include .NET 4.5, which is that Json.NET will install a newer version that is including System.Runtime.Dynamic, which is not supported in Xamarin.iOS. This means that that NuGet in general just will not work. There are a few work around for this and I recommend simply installing the Json.NET component in both the Android and iOS project and then manually referencing this DLL (iOS or Android it doesn’t matter) in your PCL. The only thing you will really miss is the DeserializeAsync, which you can create your self easily by wrapping it in a Task. This may change in the future as I have been working with James to get this fixed, but this can be the case with any NuGet out there so be careful.

I hope this helps you get up and running with PCLs. I love PCLs because they are awesome so always feel free to reach out to me on Twitter with questions.