Xamarin Plugins - James Montemagno https://staging.montemagno.com/tag/xamarin-plugins/ https://staging.montemagno.com/content/images/2017/08/MonogramIcon_Orange_NoBuffer.png Xamarin Plugins - James Montemagno https://staging.montemagno.com/tag/xamarin-plugins/ Hugo -- gohugo.io Tue, 13 Oct 2026 23:21:57 GMT 60 Cross-Platform In-App Purchases for Xamarin.Mac Apps! https://staging.montemagno.com/cross-platform-in-app-purchases-for-xamarin-mac-apps/ 6022c9a56c48dd0039592ea7 Tue, 09 Feb 2021 18:04:20 GMT

This week, one of my best friends Frank Krueger released his brilliant app iCircuit 3D for macOS (he also wrote an awesome blog on how it was made). While I know that catalyst support for Xamarin (and .NET MAUI) is coming soon, I still think there are great opportunities to monetize macOS apps written in C# today (see iCircuit 3D!). I released my In-App Billing Plugin a few years ago for iOS, Android, and UWP apps and it has been awesome to hear how it has helped so many developers monetize their apps. The library has expanded over the years to support subscriptions and updated to the latest Android billing libraries. I have used this library personally to monetize my apps including Island Tracker and My Cadence. If you haven't seen the API it is absolutely lovely! Check this out:

Get Product Info

Everything is basically three lines of code... Connect, Call, Disconnect:

var connected = await CrossInAppBilling.Current.ConnectAsync();
if(!connected)
    return;

var items = await CrossInAppBilling.Current.GetProductInfoAsync(ItemType.InAppPurchase, "myitem");

await CrossInAppBilling.Current.DisconnectAsync();

Purchase an Item

Rinse and repeat!

var connected = await CrossInAppBilling.Current.ConnectAsync();
if(!connected)
    return;

var purchase = await CrossInAppBilling.Current.PurchaseAsync(productId, ItemType.InAppPurchase);
if(purchase != null & purcxhase.State == PurchaseState.Purchased)
{
	//item bought
}

await CrossInAppBilling.Current.DisconnectAsync();

Now for Xamarin.Mac!

I recently had a few user of My Stream Timer as me how they can donate and support the development of the app. I never really thought about monetizing the app as I made it sort of for myself to show a countdown before my streams. However, this app has grown to nearly 20,000 downloads from all sorts of streamers including yoga instructors, teachers, coders, and gamers! So I figure I would extend support for my plugin to macOS. This weekend I sat down and 3 hours later it was done! Luckily for me the API is extremely similar to iOS with StoreKit. There are a few differences around making the actual purchase where you can't specify a string id, but instead must get the actual product from StoreKit first. Luckily this method already existed in my code and after a bit of hacking I got it working. Oh and there is no TransactionReceipt, which is weird but there are newer APIs that developers are supposed to query. Beyond that the API works as expected! Check it out!

In app purchase in My Stream Timer

My favorite part has to be testing IAPs on macOS because it is so simple. All you need to do is log out of the app store and then open your app in debug and make the purchase! It just works! I love it!

If you are making macOS apps I hope that you will checkout the plugin and try to add some monetization to your app!

]]>
Upgrading to Xamarin.Essentials from Plugins https://staging.montemagno.com/upgrading-from-plugins-to-xamarin-essentials/ 5b3ee4e62a21a600bf2b04f5 Wed, 19 Sep 2018 18:52:00 GMT

Xamarin.Essentials is a new official library from Microsoft (that I worked on) that provides developers with over 30 cross-platform APIs for their mobile apps to tap into to access native features. Yes, this may sound similar to Plugins for Xamarin, but it is an evolution that is super optimized for each plaform, provides a consistent API, and is super crazy well documented. And of course it is completely open source on GitHub!

Essentials

Why Upgrade?

A lot of developers have asked me why they should upgrade their apps, that have been using Plugins for a long time, to Xamarin.Essentials. Here is my list:

  1. This is an OFFICIAL package from the Xamarin team at Microsoft.
  2. It is super optimized and Linker Safe!
  3. All of your favorite plugins are there.
  4. Only has 1 assembly to help boost your app's startup time.
  5. Super consistent API across all features.
  6. Because it is awesome and super well tested.

Also because I upgraded one of my apps and it reduced that app's assemblies from 47 to 35 and even reduced the application size from 22.7MB to 22.2MB! Because it is crazy optimized!

With Xamarin.Essentials we started over from the beginning and we were able to craft new APIs for features, which means it wasn't just a copy and paste of plugins out there. We re-thought each and every API, optimized them with new code paths for each platform, integrated unit tests and samples, and documented the heck out of them.

This means if you are moving from Plugins to Essentials there is a tiny bit of work you need to do.

Getting Started

We have a great Getting Started Guide that outlines everything you need to know on how to install the NuGet package that you need. Be aware that since it is a single NuGet package this means on Android we DO NOT automatically add permissions, so read the docs on each API to see what you need to add.

The APIs!

I will try to cover as many of my Plugins as I can, but I am sure I will miss some of them. Here we go!

Settings Settings Icon

My settings plugin was not only my first plugin that I ever created, but it also is my most popular plugin with over 1.4 Million NuGet installs over the years. Xamarin.Essentials replaces and upgrades it with the Preferences API. The APIs are extremely similar, but fixes a lot of small things that had been lingering around in my code. It is a very smooth transition as they both use the same default locations to store preferences and even allow for a specific name to be passed in.

Preferences API Access

  • Plugin: CrossSettings.Current.
  • Essentials: Preferences.

Preferences API

  • GetValueOrDefault -> Get
  • AddOrUpdateValue -> Set

The key difference here is that Set simply is a method void call and saves the value every time.

While the new preferences API saves to the same places it doesn't support all of the value types that the Settings Plugin does like decimals. I should have never supported these as I have to store them as string, but you can convert it easily like this:

public decimal MyDecimal
{
   get
  {
       var savedDecimal = Preferences.Get("mykey",  Convert.ToString(0, CultureInfo.InvariantCulture));
       return Convert.ToDecimal(savedDecimal, CultureInfo.InvariantCulture)
   }
   set { Preferences.Set("mykey", Convert.ToString(value, CultureInfo.InvariantCulture)); }
}

In addition to the core APIs you could also open the app settings page on the device. This can now be done in the AppInfo API of Essentials:

  • CrossSettings.Current.OpenAppSettings(); -> AppInfo.OpenSettings();

Connectivity Plugin connectivity-icon

Oh connectivity plugin... I love you! My second most popular plugin out there that has helped developers detect if there is an internet connection for several years. This is also an easy one as many of the APIs are packed into Xamarin.Essentials Connectivity API. There is a little bit of setup for permissions that you should do if you want to check connection types.

Connectivity API Access

  • Plugin: CrossConnectivity.Current.
  • Essentials: Connectivity.

Connectivity API

  • IsConnected -> NetworkAccess (now returns an enum)
  • ConnectionTypes -> Profiles
  • ConnectivityChanged & ConnectivityTypeChanged -> ConnectivityChanged (all rolled into 1 nice event)

So you can replace this:

if (!CrossConnectivity.Current.IsConnected)
{
    //we are offline
}

with this:

if (Connectivity.NetworkAccess != NetworkAccess.Internet)
{
    //we are offline
}

APIs that don't exist

  • IsReachable & IsRemoteReachable: You can read my full analysis on GitHub as to why we did not include this, but long story short I should have never included these. It really makes no sense to try to ping a site to see if it is there instead of just making the web request.
  • Bandwidth: Never really was a need and super inconsistent.

App Version / Version Tracking version-tracking-icon

I simply love our App Info API that gives you all sorts of info about your application. You may have been using other plugins such as DeviceInfo or VersionTracking, but you can just use AppInfo now:

App Info API Access

  • Essentials: AppInfo.

App Info API

  • Name
  • PackageName
  • VersionString
  • BuildString

There is also a new Version Tracking API that is nearly a 1 to 1 replacement for the old plugin.

Version Tracking API Access

  • Plugin: CrossVersionTracking.Current.
  • Essentials: VersionTracking.

Version Tracking API

  • Track(); -> Track();
  • IsFirstLaunchEver -> IsFirstLaunchEver
  • IsFirstLaunchForVersion -> IsFirstLaunchForCurrentVersion
  • IsFirstLaunchForBuild -> IsFirstLaunchForCurrentBuild
  • CurrentVersion -> CurrentVersion
  • PreviousVersion -> PreviousVersion
  • FirstInstalledVersion -> FirstInstalledVersion
  • VersionHistory -> VersionHistory
  • CurrentBuild -> CurrentBuild
  • PreviousBuild -> PreviousVersion
  • FirstInstalledBuild -> FirstInstalledBuild
  • BuildHistory -> BuildHistory

There are a lot of enhancements to this API including that it just uses the built-in Preferences API instead of serialization and file IO.

Share Plugin share-plugin

The share plugin kept growing and started to add tons of APIs for no good reason including opening the browser or setting text on the clipboard. Don't worry though because Xamarin.Essentials has a Data Transfer, Clipboard, and Browser API built right in!

API Access

  • Plugin: CrossShare.Current.
  • Essentials: Browser.
  • Essentials: Clipboard.
  • Essentials: DataTransfer. (this is Share)

Browser API

  • OpenBrowser -> OpenAsync
  • BrowserOptions -> BrowserLaunchType (no current open to specify colors)

Clipboard API

  • SetClipboardText -> SetText
  • NEW API -> GetTextAsync

Data Transfer API

  • Share -> RequestAsync
  • Pass in a ShareTextRequest which specifies text or a uri.

Device Information device-info-plugin

I loved to hate my Device Info plugin becaues it had a lot of great ideas and a lot of bad ideas such as the original implementation of ID and a bunch of other random methods. This has all been fixed with Xamarin.Essentials and the Device Information API, and the addition of the Device Display API that adds the ability to get information about the device's screen metrics, which is very nifty.

API Access

  • Plugin: CrossDeviceInfo.Current.
  • Essentials: DeviceInfo.

DeviceInfo API

  • Model -> Model
  • Manufacturer -> Manufacturer
  • DeviceName -> Name
  • Version -> VersionString
  • AppVersion -> Now: AppInfo.VersionString
  • AppBuild -> Now AppInfo.BuildString
  • Platform -> Platform
  • Idiom -> Idiom
  • IsDevice -> DeviceType

Geolocator geolocator-icon

Another popular plugin of mine that was originally brought over from the old Xamarin.Mobile code base. Xamarin.Essentials has built this API from the ground up on each platform and really thought about what developers need from this API. That is why there are actually two APIs that developers can use and a standardization on what a Location and Placemark is. So hopefully any other APIs could start using these. The first API is Geolocation which is how to get the cached location or current location on the device. Also Geocoding enables getting the Placemark for a Location. As of right now there is no tracking of location changes, but that is on the roadmap.

API Access

  • Plugin: CrossGeolocator.Current.
  • Essentials: Geolocation.
  • Essentials: Geocoding.

Geolocation API

  • GetLastKnownLocationAsync -> GetLastKnownLocationAsync
  • GetPositionAsync -> GetLocationAsync

Geocoding API

  • GetAddressesForPositionAsync -> GetPlacemarksAsync
  • GetPositionsForAddressAsync -> GetLocationsAsync

Text-to-Speech text-to-speech

My plugin has gone under a lot of changes over the year and I have learned a lot that went into the new Text-to-Speech API in Xamarin.Essentials.

API Access

  • Plugin: CrossTextToSpeech.Current.
  • Essentials: TextToSpeech.

Text to Speech API

  • Speak -> SpeakAsync
  • GetInstalledLanguages -> GetLocalesAsync

Vibratevibrate-icon

Another simple tranisition to the Vibrate API and even adds some new methods. For Android be sure to setup permissions correctly in your Android Manifest.

API Access

  • Plugin: CrossVibrate.Current.
  • Essentials: Vibration.

Vibration API

  • Vibration -> Vibrate
  • NEW API -> Cancel

Battery battery-plugin

When you need to check the battery status of the device the Battery API is for you! We also have a new Power API that will help you detect if the device is in power saver mode too!

API Access

  • Plugin: CrossBattery.Current.
  • Essentials: Battery.

Battery API

  • RemainingChargePercent -> ChargeLevel (0 to 1.0)
  • Status -> State
  • PowerSource -> PowerSource
  • BatteryChanged -> BatteryChanged

Wrapping Up

If you made it this far then I am impressed and want to give you a big hug! Xamarin.Essentials is pretty fantastic and I hope that you see how easy it is to change over from Plugins, that it has the ability to shrink your app size and help with startup time by reducing your total assemblies in your app.

One thing to note is that my plugins aren't going away any time soon. Many of them will go into maintenance mode as I push developers towards Xamarin.Essentials. The key difference is that many of my plugins for better or worse support a lot of different platforms that aren't supported yet in Essentials.

There are also some plugins that I plan on supporting long term as they provide functionality not yet in Essentials such as Permissions and Store Review or features that aren't planned at all such as IniApp Billing.

]]>
Multi-Targeting: Where Did My Files Go? Fixing .NET Core 2.1 SDK Issues https://staging.montemagno.com/multi-targeting-where-did-my-files-go-fixing-net-core-2-1-sdk-issues/ 5b7ade4acce53300bfd41234 Tue, 21 Aug 2018 20:45:00 GMT I love multi-targeting for creating libraries, and it is at the core of all of my plugins and Xamarin.Essentials. If you don't know what multi-targeting is don't worry as it is pretty rare that you would need to use it if you are creating apps. Most likely you will want to use multi-targeting in creating cross-platform libraries. In the past you would have to create multiple libraries for each target framework (such as iOS or Android) that you wanted to support if there was platform specific code. With the new SDK style projects you can set the TargetFrameworks property and specify as many as you would like.

Here is Xamarin.Essentials that supports iOS, Android, UWP, and .NET Standard 1.0/2.0:

<TargetFrameworks>netstandard1.0;netstandard2.0;Xamarin.iOS10;MonoAndroid71;MonoAndroid80;MonoAndroid81;uap10.0.16299</TargetFrameworks>

What is amazing is that all of your files can live together and can be conditionally compiled so only certain files get compiled for a specific platform:

<ItemGroup>
    <Compile Include="**\*.shared.cs" />
</ItemGroup>
<ItemGroup Condition=" $(TargetFramework.StartsWith('netstandard')) ">
    <Compile Include="**\*.netstandard.cs" />
</ItemGroup>
<ItemGroup Condition=" $(TargetFramework.StartsWith('uap10.0')) ">
    <Compile Include="**\*.uwp.cs" />
</ItemGroup>
<ItemGroup Condition=" $(TargetFramework.StartsWith('MonoAndroid')) ">
    <Compile Include="**\*.android.cs" />
</ItemGroup>
<ItemGroup Condition=" $(TargetFramework.StartsWith('Xamarin.iOS')) ">
    <Compile Include="**\*.ios.cs" />
</ItemGroup>

This allows super beautiful project structures:

Capture

It also means that you can conditionally compile your code too:

#if NETSTANDARD1_0
    // do something for .net standard 1.0
#elif __ANDROID__
    // else for Android
#else
    // anything else.
#endif

This all works thanks to Oren Novotny's amazing library MSBuild SDK Extras, which is easily configured by adding a nuget to all projects and adding a single import at the bottom of your csproj:

<ItemGroup>
    <PackageReference Include="MSBuild.Sdk.Extras" Version="1.6.47" PrivateAssets="All" />
    <Compile Include="**\*.shared.cs" />
</ItemGroup>
<Import Project="$(MSBuildSDKExtrasTargets)" Condition="Exists('$(MSBuildSDKExtrasTargets)')" />

Enter .NET Core SDK 2.1

Since this is sort of "unofficial" special tooling magic, sometimes things can break and recently when I installed .NET Core SDK 2.1 all my files went missing for iOS/Android/UWP. If we toggle on "show all files" they are totally there and get compiled but now intellisense stops working:

Missing

We reported it and worked with the .NET team on how to resolve it.

Fix 1: Include Workaround

The work around from the .NET team was to add an additional include at the bottom of our csproj that basically includes any .cs files and excludes defaults.

<ItemGroup>
    <PackageReference Include="MSBuild.Sdk.Extras" Version="1.6.47" PrivateAssets="All" />
    <Compile Include="**\*.shared.cs" />
</ItemGroup>
<ItemGroup>
    <None Include="**\*.cs" Exclude="$(DefaultItemExcludes);$(DefaultExcludesInProjectFolder)" />
</ItemGroup>
<Import Project="$(MSBuildSDKExtrasTargets)" Condition="Exists('$(MSBuildSDKExtrasTargets)')" />

Fix 2: Update to 1.6.47 of Sdk Extras & Project Type

I work extremely closely with Oren and whenever something happens with Essentials I freak out :) So when we had Fix 1 in place and working the next natural thing was to roll it into the official NuGet! Last week Oren did just this!

The only thing here is that we will want to ensure we upgrade to his new project type instead of using the PackageReference and Import. He outlines it great in his documentation.

In short instead of adding any nugets or imports we will replace:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">

with

<Project Sdk="MSBuild.Sdk.Extras/1.6.47">

Of course if you are using other types of files you may need to go back to Fix 1 to add them in manually, but his system is very smart. Be sure to report any bugs over to Oren on his GitHub repo.

]]>
Continuous Integration & Delivery for Xamarin & .NET Libraries with Azure DevOps (VSTS) https://staging.montemagno.com/continuous-integration-delivery-for-net-libraries-with-vsts/ 5af5cc81dc592200bfc9400b Mon, 21 May 2018 19:20:00 GMT I build a lot of .NET libraries that include simple .NET Standard libraries to fully cross-platform plugins for Xamarin and Windows that target up to 10 different platforms. When I got started building libraries and shipping them to NuGet I went down a simple path of just building everything locally on my machine and manually uploading them to NuGet. This worked great for a single library, but as soon as I took on a second... third... forth... and so on, things got out of hand and I knew I had to put some sort of CI/CD in place. I went down many paths over the years and have now settled on using Visual Studio Team Services to fully automate the build of every library I create and a full distribution pipe line that goes to MyGet then to NuGet preview, and finally NuGet public release with a click of a button. Now I can develop and let VSTS handle everything for me so I can be productive:

If you look at this screenshot from VSTS it is everything that I wanted for so long in my development cycle. I push code, things are built, and automatically packages are pushed. In this post I am going to show you how I set this up for my projects and how you can too in just a few minutes.

.NET Standard and Multi-Target Projects

Before we start to setup our CI/CD for libraries I highly recommend you move your projects to SDK style projects. You can read my full guide on how to convert a PCL to .NET Standard or how to convert a Xamarin.iOS or Xamarin.Android project to SDK Style.

Everything that I develop now is based on a single .NET Standard 2.0 library or a Multi-Targeted project for plugins. I have previously written on how to convert your PCLs to .NET Standard and also have templates for Visual Studio 2017 to create Multi-Target projects for plugins.

SDKStyle

The reason to use these types of projects is that they include full NuGet packaging including all metadata and dependencies. This also means you can fully delete the .nuspec file that always gets out of sync. It is worth your time to update any and all projects to these types of projects to simplify your life.

If you need to learn more about multi-targeting be sure to check out Oren's amazing MSBuildSdkExtras package which is the core of my templates and all of my projects.

If you are building only an iOS or Android library do not fear as you can still just convert your existing library over to an SDK Style. Take a look at my MonoDroid.Toolkit csproj on GitHub.

Build Definition in VSTS

My builds inside of VSTS are actually really simplistic and only contain 6 steps to fully build my libraries. You can use the Hosted Visual Studio 2017 machines, however I have a small Intel NUC that runs a local VSTS agent so all my NuGets are cached which reduces my build times to seconds instead of minutes.

Empty Definition

Select New and pick your source code that you would like to build. I then like to select Empty process because we can easily fill it in.

Empty

NuGet Steps

Under Phase 1 we are going to add two NUGet steps.

First is the NuGet Tool Installer task and change the Version to 4.5.1

NuGetInstaller

Second will be the regular NuGet task which we will use the restore command on our solution that we are going to build. I like to pick the specific .sln or folder where it lives (no need to build other stuff).

NuGetRestore

Build Steps

I build my libraries twice! That is right twice! Once for a "beta" NuGet and once again for "public" NuGet. They are super quick and all it is really doing is changing the version flags. The reason I do this is for my release definition that will allow me to have a single release that goes from beta to public easily. We will be building the .csproj specifically using the MSBuild task:

MSBuild

We will add it twice so we can build the beta and public releases. Name the first Build Beta and the second Build Public. For each of them set the following:

  • Project: Select the .csproj specifically
  • Configuration: $(BuildConfiguration)

For MSBuild Arguments user the following for Beta:

/t:restore;build;pack /p:PackageVersion=$(Build.BuildNumber)-beta /p:PackageOutputPath=$(build.artifactstagingdirectory)/beta /p:AssemblyFileVersion=$(Build.BuildNumber)

For Public use:

/t:restore;build;pack /p:PackageVersion=$(Build.BuildNumber) /p:PackageOutputPath=$(build.artifactstagingdirectory)/public  /p:AssemblyFileVersion=$(Build.BuildNumber)

This will ensure that the build numbers are configured correctly and copy the artifacts to different folders.

Optionally, you may have some additional unit tests or device runners that may need to be run here.

Copy and Publish

The next thing to add is the Copy Files task to stage the NuGet packages for release.

Set these properties:

  • Source Folder: $(build.sourcesdirectory)
  • Contents: **\bin\$(BuildConfiguration)\**\*.nupkg
  • Target Folder: $(build.artifactstagingdirectory)

Finally, add the Publish Build Artifacts task and set the following:

  • Path to publish: $(build.artifactstagingdirectory)
  • Artifact name: drop
  • Artifact public location: Visual Studio Team Services/TFS

This will pull only .nupkg files that we will distribute into a folder that release can pick up.

All in all the definition should look like:

AllDone

Configure Version Number

Under the Options tab in the build definition I like to format the Build number format such as: 4.5.0$(rev:.r)

This means that the next version would be: 4.5.0.1 and then 4.5.0.2.

Now if you change this to: 5.0.0$(rev:.r) it will reset the revision so it will be 5.0.0.1.

Other things!

You will probably want to setup *Triggers so CI and PR validation are configured. This means that every time master is pushed to a package is generated.

Release Definition in VSTS

Now we have our full build complete it is time to setup our release. Our goal for me was to automatically have every build of master go to MyGet and then manually approve the next release to go to NuGet (beta) and finally another approval to go to NuGet with the public non-beta package.

Battery-CD-1

Head over to the Releases section and create a new release definition with an Empty process. Think of Environments as the stages of release. We can create three of them to define each release of the artifacts. Inside of each environment are a sequence of tasks, just like our build definition, that will be run. For my libraries it is really simple as each has just one task. However, before the NuGet beta and production environments I turn on pre-deployment approval steps.

Push to MyGet

In our first environment we will want to push to MyGet. Add the NuGet task with the following settings:

  • Command: push
  • Path to NuGet package: $(System.DefaultWorkingDirectory)/**/drop/beta/*.nupkg
  • Target Feed: External NuGet server

For this step you will want to configure the feed information from MyGet:

MyGet

Push NuGet Beta

For this step you can select Clone or if you already create the new environment simply add the NuGet task again. The settings will be the same as above:

  • Command: push
  • Path to NuGet package: $(System.DefaultWorkingDirectory)/**/drop/beta/*.nupkg
  • Target Feed: External NuGet server

However, we will now want to select or configure NuGet as our destination:

NuGet

Head back to Pipeline and for this environment we don't want it to automatically trigger, we want to approve this release. You will see a lightning bolt and a person shape on the left side of the environment to configure pre-deployment conditions. I turn on pre-deployment approvals and select myself and turn off the policies since I am a solo developer:

predeploy

There is all sorts of rad stuff you can do here on pre and post-deployment so you should totally look into that for larger projects.

Push NuGet Production

Add or clone another environment for after the Beta environment. This is going to be almost the same as the previous step but we are going to change our Path to NuGet package:

  • Command: push
  • Path to NuGet package: $(System.DefaultWorkingDirectory)/**/drop/public/*.nupkg
  • Target Feed: External NuGet server

Notice I am using public here :)

Add Artifact

Finally, click the big Add artifact button on the left side and select the build definition that you created earlier. Also tap on that little lightning bolt and turn on the Continuous deployment trigger so this flow automatically happens!

CI/CD Pro!

You did it! You are totally a Continuous integration and delivery pro!! Enjoy a seamless deployment of every push to master to MyGet and then approval steps to push to NuGet for any and all of your .NET Libraries. <3 Feel free to ask questions below.

]]>
Text To Speech Plugin for Xamarin and Windows https://staging.montemagno.com/text-to-speech-plugin-for-xamarin-and-windows/ 598df8f2c121b60019bf301c Mon, 08 Dec 2014 19:27:28 GMT You may have noticed that I am on a big Plugins for Xamarin kick currently. I have always had my Settings Plugin that I have updated over time, but then I blogged about creating plugins for Xamarin.Forms, released a Vibrate Plugin, and then discussed exactly what a Plugin for Xamarin is. I love plugins as they can abstract away features common on platforms into a simple API so you never have to write the same code twice. Today, I am please to announce and release my latest plugin, text to speech.

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.

]]>