September 21, 2014 9:12 GMT

Dave Winer: The lost art of software testing

Absolutely worth a read:

I remember when I first encountered a software tester. I had just signed up with a publisher, and they employed testers, and one was assigned to my product. His first report was a total shocker. He found so many problems with my product. I thought some of them were really petty, some indicated he didn't understand the product, and in a very few cases he found real bugs.

And having a great tester on a team pretty much guarantees you won't ship garbage. (It can happen.)

My current contract/job is the second project I've had what I would describe as "real" testers. In the past, we had some people who "did testing", but we didn't work that closely with them. Some were in other cities, some were doing more high level testing, and some where just a bit disconnected in general.

As an aside, that's why I don't think outsourced testing works, regardless of if they are in another country, another state, or just another floor of the building. Sure, you can get someone to run thru a script every night, but you can also get a bot to run thru your app every night, too, and bots are cheaper in the long run (eg use Xamarin Test Cloud)

But what a difference it makes having testers who are literally on your team. They are a second set of eyes, a representative of the user and the product owner, and most importantly, NOT close to the code.

The last thing I want to do is throw things over the wall at them, because getting a load of bug reports from a person you interact with all day is horrible - it feels like I'm wasting their time - which I am.

I can highly recommend getting testers on your team, especailly for customer-facing things like apps or websites. There is only so much you can do with automated testing (which is also important) - a human using your product will always pick up different things to a computer making sure the flow works.

Worst case, if you can't get testers, follow this one simple rule:

Never, ever, test your own software.

And always try to keep the testers happy. You're all on the same team after all, and chocolate is cheap.

September 20, 2014 1:44 GMT

Renaming your Xamarin.Mac App

Apple has a number of guidelines and rules for developers looking to publish their Apps to Apple’s app ecosystem. One of these rules relates to the name of your app. To give you a quick overview of how some developers can have issues with theses rules, I’ve gone ahead and listed a few of them below:

  • Apps with names, descriptions, screenshots, or previews that are not relevant to the content and functionality of the App will be rejected.
  • App names in iTunes Connect and as displayed on a device should be similar, so as to not cause confusion
  • Apps that misspell Apple product names in their App name (i.e., GPS for Iphone, iTunz) will be rejected.

If your App has any of the following issues then Apple will reject your binary and ask you to change the app name. In this tutorial, I will show you the properties you need to change your app name.

Menubar & About dialog

To update the name in the Finder menu bar and the About dialog, you will need to update the Bundle Name which can be found in your projects Info.plist (you will need to select the ‘Source’ tab).

Screen Shot 2014-09-21 at 12.45.05


To update the name displayed in the Dock (on hovering over the app icon), you will need to change the “Assembly name.” To do this, you will need to navigate to the project options (right click the project and select “Options”). You will find the Assembly name property under the “Output” tab.

Screen Shot 2014-09-21 at 12.45.17

Installer Package

If you’re producing an installer package for your App, you will need to edit the project name in order for the generated package to have your new name. To do this, simply right click on the project and select “Rename”.

Screen Shot 2014-09-21 at 12.45.22


The post Renaming your Xamarin.Mac App appeared first on Mike James.

September 19, 2014 9:09 GMT

Add Some Punch to Your Apps with iOS 8

iOS 8 iconWith over 4,000 APIs, and 12 major new or upgraded frameworks and features, iOS 8 is one of Apple’s biggest OS releases yet. Now, Xamarin is here to get you started with the new goodies and 64 bit support with the iOS and Mac Unified API.

To get building apps that take advantage of the new iOS 8 frameworks and features today:

  1. Download and install the latest Xcode.
  2. Update Xamarin.
  3. Check out the Introduction to iOS 8 Guide.

While you’re downloading Xcode and installing the updates, watch the Get Ready for iOS 8 webinar for a curated overview of the new features, hosted by Xamarin Developer Evangelist Mike Bluestein.

If you want to see the new features in action for yourself, you can also download and play with our new iOS 8 Samples.

iOS 8 has a ton of new frameworks and features, so when you’re ready to continue your journey and dive deep, check out the Xamarin guides, which will help you utilize the new features and add some sparkle to your apps.

Provide Rich OS Integration with App Extensions

App Extensions iconApp Extensions allow for apps to deliver unprecedented functionality through deep OS integration. With Extensions, applications can now offer features like the Today Widgets that live on the notification screen, custom keyboards, and sharing extensions, to name just a few. To learn how to create your own, check out the Intro to App Extensions guide.

Access Secrets Biometrically with Touch ID

Touch Id iconThe new TouchID APIs allow app developers to integrate with Apple’s biometric touch sensor to authenticate users and restrict access to data and functionality within your apps. Additionally, with TouchID, access to the keychain and secure storage is available biometrically. For more information, check out the Introduction to TouchID guide.

Build Custom Photo Galleries and Create the Next Instagram with Photo Kit

Photo Kit iconPhoto Kit is a new framework that makes working with the image library a snap. With Photo Kit, you can more easily fetch photos, create custom galleries, and even apply filters and modify them en masse. For an example of using the Photo Kit framework in Xamarin, see Mike Bluestein’s Build Great Photo Experiences in iOS 8 with Photo Kit blog post.

Use Manual Camera Controls to Create Highly Stylized Photos

Camera API iconThe AVFoundation Framework got a big upgrade in iOS with the addition of the all new manual camera controls. With them, you can get low-level access to the camera hardware, enabling the iPhone’s camera to be controlled more like traditional cameras. Jump in and read the Intro to Manual Camera Controls guide for more information.

Take your iCloud Integration to the Next Level with Cloud Kit

Cloud Kit iconCloud Kit expands on the existing iCloud APIs to enable much more sophisticated integration with iCloud, and is targeted at developers who want to take advantage of iCloud to handle cloud-based data persistence and retrieval. It offers a much simpler integration story than previously, while offering a much more feature-rich experience. For more information, check out the Intro to Cloud Kit guide.

Share Documents with other apps with the Document Picker

Document Picker iconThe Document Picker allows applications to reach beyond the app sandbox to share and access documents with other applications. With the Document Picker, you can now create complex document workflows between more than one application. For more information on working with it, check out the Intro to the Document Picker guide.

Work with Calendars and Events in Event Kit

With iOS 8, Apple expanded on the Event Kit framework to allow easier access to, and manipulation of calendars and events. For more info, check out the Intro to Event Kit guide.

Simplify UI Creation Across All iOS Devices with Unified Storyboards

Unified Storyboards iconWith the introduction of the iPhone 6 and iPhone 6+, creating user interfaces that work well across all iOS devices got much more complicated. Fortunately, Apple introduce Unified Storyboards to simplify the process by allowing you to create single screens that scale for different devices. For more information, see the Intro to Unified Storyboards guide.

Integrate 3D Graphics into your App with Scene Kit

Scene Kit iconSceneKit is a 3D scene graph API that makes integrating 3D content into your application and causal 3D games a breeze. For an example of using the Scene Kit framework in Xamarin, see Mike Bluestein’s Lights, Camera, Action – 3D in iOS 8 with Scene Kit blog post.

Create 2D Games Quickly with Sprite Kit

Sprite Kit iconSprite Kit, the 2D game framework from Apple, has some interesting new features in iOS 8 and OS X Yosemite, including integration with Scene Kit, lighting, and physics enhancements. For an example of using the SpriteKit framework in Xamarin, see Mike Bluestein’s New Sprite Kit Physics Features in iOS 8 blog post.

Browse the Entire List of New APIs and Features

These are some, but not all, of the new features in iOS 8. For a comprehensive list, check out the API change log and release notes.

September 19, 2014 4:45 GMT

Xamarin Evolve 2014 Speaker Spotlight: Rachel Reese

This is the sixth post in our Xamarin Evolve 2014 “Speaker Spotlight” series, helping you get to know a little bit more about some of the amazing speakers who will be contributing at this year’s conference.

Photo of Rachel ReeseToday’s spotlight features Rachel Reese, a long-time software engineer and math geek who recently relocated to Nashville, TN to work with the fabulous folks at Firefly Logic, as well as to be a part of the Nashville functional programming scene. She currently helps run the Nashville Xamarin user group, @NashXam, and is an ASPInsider and an F# MVP. You can hear Rachel’s talk, “1) Write Cross-Platform Apps with F# & Xamarin. 2) ??? 3) Profit!: Mobile App Development in F#” in the Xamarin Platform track at Xamarin Evolve.

How long have you been doing mobile development?

Actually, not very long (around eight months). I’d been hearing about Xamarin and F# development for about two years, but it took my move to Nashville for me to get really involved in mobile development. In just under a year, I’ve jumped all in — what’s there to not love about using my F# and C# skills to build iOS and Android apps? This is awesome!

Why did you get into software development?

Oh, good question. I was a math/physics major in college. The summer after my freshman year, I started a research job with a high-energy physics lab. One of the grad students sat me down on my first day, handed me a book on C, and told me that I wouldn’t really be useful until I understood most of it. I spent the summer going through the book meticulously. I took a couple programming courses in school, as well, so when I graduated (after much, much hemming and hawing about whether or not to go to grad school) I opted for a job with a friend of mine that only required I know a bit about HTML. It was all downhill from there!

What is your favorite line of code that you have ever written?


What will attendees get out of your Xamarin Evolve talk?

A basic understanding of how and why using F# is a fabulous alternative to C# for mobile developers.

How much do you love curly braces and why?

Curly braces!?

*puts on shades*

Where I am, I don’t need no stinkin’ curly braces.

What are you doing when you’re not doing mobile development with Xamarin?

I’m confused. Life outside mobile development with Xamarin!? That… exists?

Traveling (both near and far)! Fun fact: my two dogs have been to more countries than I suspect most Americans have (5: France, Germany, Spain, Canada, US).

Also, cooking. I have an awful/amazing habit of buying spices, infused balsamics, and kitchen trinkets. Sometimes I concoct awesome things, sometimes not so much, but it’s all fun.

If you missed the earlier posts in this series, click through to read about Jesse Liberty, Jon Skeet, Jonathan Peppers, Laurent Bugnion, and Paul Betts.

September 19, 2014 1:05 GMT

Dropbox Joins Xamarin Evolve 2014

Dropbox LogoWe are very excited to welcome Dropbox as a Silver Sponsor for Xamarin Evolve 2014. Dropbox  joins an exciting list of industry leaders at Xamarin Evolve this year, including Google, Microsoft, IBM, Twilio, Amazon, and more.

Photo of Steve Marx Steve Marx, Developer Advocate at Dropbox, will present, “Cross-Platform Syncing with Dropbox,” in the Mobile Ecosystem track. In this demo-heavy talk, Steve will walk attendees through the challenges of cross-platform syncing and the tools that Dropbox provides for mobile developers.

Don’t miss your ticket to mobile expertise – register now for Xamarin Evolve 2014.

September 19, 2014 4:00 GMT

New and Improved Xamarin Studio Launcher

Awhile back I made a quick little AppleScript based app called Xamarin Studio Launcher to help launch multiple instances of Xamarin Studio (it had a pretty little icon that you could keep in your dock to open new instances - which I recently updated to the newer Xamarin look).

Xamarin Studio Launcher

While it was cute, and relatively functional, as a recovering ex-Windows user, I found myself still constantly opening .sln files from finder, which would cause them to open in an existing instance of Xamarin Studio, closing whatever current solution happened to be open in that instance.

Now I know about the ability to open multiple solutions in the same Xamarin Studio instance, and generally I’m pretty good about forcing myself into learning the nuances of the platform I’m working on, however, having multiple instances of Visual Studio open was something I grew so accustomed to that I just couldn’t shake the habit of being on a Mac!

Not sure why it took me so long to make this, but here it is, finally!

Xamarin Studio Launcher v3

This new launcher app works first and foremost exactly like the previous Xamarin Studio Launcher I released. You can put it in your dock, and when you open it, it will launch a new, blank instance of Xamarin Studio.

The new feature is that it can now handle opening .sln files. If you choose to open a .sln file with this app, it will open that .sln file in a new instance of Xamarin Studio.

This means you can set Finder to open all .sln files with Xamarin Studio Launcher so any time you double click or otherwise open a .sln file from Finder, it will open in its own instance of Xamarin Studio!

How to set this as the default app for .sln files

Xamarin Studio Launcher

  1. Find a .sln file in Finder
  2. Right click the .sln file and Get Info (or highlight the file and cmd + i
  3. Under the Open With section, click the drop-down list and click Choose
  4. Navigate to and select Xamarin Studio Launcher
  5. Click Change All


Here’s the .zip file containing Xamarin Studio

Download Xamarin Studio Launcher v3

September 18, 2014 4:42 GMT

Top Mobile Security Experts Come to Xamarin Evolve 2014

The global mobile economy is growing at an incredible rate, and with that explosive growth come risks and responsibilities for app developers. We’re excited to bring together top mobile security experts at Xamarin Evolve 2014 for a special Panel on Mobile Security Best Practices.

AirWatch, MaaS360, Arxan, Good Technology, and Mobile Iron logosJoin moderator Steve Hall, Director of Mobile Enterprise Mobility at Xamarin, along with panelists Erich Stuntebeck, Director of Research at AirWatch by VMware, Anar Taori, Senior Director of Product Management at MaaS360 by Fiberlink, an IBM company, Vince Arneja, Vice President, Product Management at Arxan Technologies, John Britton, Director of the Office of the CTO at Good Technology, and Sean Ginevan, Director of Corporate Strategy at MobileIron, to discuss how to best secure sensitive data in your apps, on devices, and over the wire.

Don’t miss this opportunity to learn from industry experts – register now for your ticket to mobile expertise at Xamarin Evolve 2014.

September 18, 2014 4:33 GMT

Meme Generator Powered by MMS

If you haven't heard yet, Twilio annouced MMS support today on all US and Canada phone numbers. I'm so stoked about this new feature and I knew exactly what I wanted to build with it.

Introducing the MMS Meme Generator

It is my belief that a mechanism for sending pictures cannot survive in the market if it does not generate memes. The internet demands the ability to express itself with images containing words. So, I am excited to bring you the first Twilio powered MMS meme generator.

How it works

All you need to do is send a properly formatted text message to (443)746-3637 -- that's (443)74-MEMES -- and you'll get back an MMS with your meme. Here are the supported memes in v1:

  • One does not simply ______
  • What if I told you ______
  • Brace yourselves ______
  • ______ but that's none of my business
  • ______ all the ______
  • ______ ain't nobody got time for that
  • ______ we're dealing with a badass over here
  • ______ aaaaand it's gone  (note: any number of a's will work on this one!)


Have fun with this!

Hope you have some fun with this. Share your funniest memes with me on Twitter @brentschooley! Future additions will allow you to send these memes to your friends by sending their phone number in the text. Also, stay tuned to the Twilio blog where in a few weeks I'll show you how this was built.

If you want to get started with Twilio MMS, my team has put together a great Getting Started post that covers Node, Python, C#, PHP, Java and Ruby. Show me what you build!

September 18, 2014 2:02 GMT

Google Joins Xamarin Evolve 2014

Google LogoWe’re thrilled to announce that Google is joining Xamarin Evolve 2014 as a Gold sponsor. Google is the latest addition to the growing list of fantastic sponsors and speakers, including Microsoft, IBM, Github, Salesforce, and more, attending the cross-platform mobile development event of the year from October 6-10 in Atlanta, Georgia.

peter friese roundGoogle Developer Advocate Peter Friese will provide a rundown of the core services available via Google Play Services in his talk, “Google Play Services Rock.” Attendees will get an overview of the new APIs that come as a part of the latest version of Google Play Services, and dive into some of the lesser known features that enable developers to build apps that truly rock.

Register now to join Xamarin and Google for the mobile development event of the year.

September 17, 2014 5:56 GMT

Webinar Recording: Android L and So Much More

The Android L Developer Preview introduced a plethora of new APIs for developers to take advantage of, including Material Design, notifications, and new animations, to name a few. Xamarin developers can access these APIs right now with our preliminary support in Xamarin.Android.

In this webinar, Xamarin Developer Evangelist James Montemagno walks viewers through the top new and updated APIs in the release. In addition to everything new in the Android L Developer Preview, he also covers new features in Google Play Services, Support Libraries, Android Wear, and Android TV SDKs.

Access the slides for this webinar here.

Additional Resources

If you’d like further information on getting started with Android L and Xamarin, follow the steps outlined in this blog post.

Xamarin Evolve 2014 attendees, be sure to check out our Android track for even more information. If you are not already attending the conference, you can register here.

September 17, 2014 4:00 GMT

Smarter Xamarin Android Support v4 / v13 Packages

If you’ve ever built an Android app, you’ve probably used the Android Support libraries. Google created these as a way to enable developers to use new features on older Android versions. The most common Support library is arguably Support-v4, however as older Android devices retire and newer versions of Android increase in market share, Support-v13 is becoming more commonplace.

Warning: This is going to be a bit geeky of a post. If you don’t want to know the details, skip down to the TL;DR section for the need-to-know bits :)

Support-v4 can be used all the way back to Android API Level 4 (Donut - 1.6), but Support-v13 is only compatible back to API Level 13 (Honeycomb - 3.2).

The challenge with these two support libraries is that they are mutually exclusive. That is, you can’t have Support-v4 and Support-v13 referenced in the same app.

There’s a good reason for this though: Support-v13 actually contains all the code and classes that you’d find in Support-v4, it just adds a bit more on top of them. So, the answer is, just use Support-v13 if you need to instead, right? If only it were that simple.

Trouble in Paradise

Since Support-v4 is so prevalent in apps and provides so much to developers, a lot of third party libraries themselves reference it. Facebook, and even Google Play Services both depend on Support-v4, for example.

Usually 3rd party libraries choose to depend on Support-v4 and not Support-v13 so that they can be used in apps with older API levels.

In the Xamarin world, these libraries (or bindings) are compiled to expect a reference to Xamarin.Support.v4.dll, and if you try and add Xamarin.Support.v13 to your project, things blow up (since Support-v13 already contains Support-v4). This has proven to be painful for developers wanting to use the new Support-v13 features, but also any 3rd party libraries which reference Support-v4.

TypeForwardedTo the rescue!

Luckily, fellow Components Team member Matthew thought up a crafty solution to this issue. There’s a somewhat little known Assembly level attribute called TypeForwardedTo. This nifty attribute allows you to forward an expected type declaration in a given assembly to an actual implementation of it which exists in another assembly.

So, what we’ve done is created a Xamarin.Android.Support.v4.dll assembly which contains nothing but [assembly: TypeForwardedTo (..)] declarations to forward all of the expected Support-v4 types to Xamarin.Android.Support.v13.dll instead.

This means if you’re using a library which requires a reference to Xamarin.Android.Support.v4.dll (Let’s say Google Play Services for instance), you can swap in this ‘type-forwarded’ assembly, and then add a reference to Xamarin.Android.Support.v13.dll as well. Since v13 contains all the implementation which v4 has just forwarded to it (and then some), you can use the new v13 fanciness in your app, while still satisfying the v4 reference that 3rd party libraries are depending on!

Sprinkle in some magic NuGet dust…

This wouldn’t be nearly as fun if you had to worry about which Xamarin.Android.Support.v4.dll you needed to pick (the actual implementation, or the type-forwarded one). Luckily, in addition to the TypeForwardedTo magic, we’re adding some NuGet pixie dust to the mix!

If you’re interested in the mechanics, this is essentially the new .nuspec file we’re using (You can skip ahead to the TL;DR section below otherwise):

<?xml version="1.0"?>
<package >
    <title>Xamarin Support Library v4</title>

  <!-- Ommitted boring parts -->

      <!-- Depend on v13 support nuget if targeting equal or higher than Android 3.2 -->
      <group targetFramework="MonoAndroid32">
        <dependency id="Xamarin.Android.Support.v13" version="" />
    <!-- Use Support v4 lib for anything up to Android 3.2 -->
    <file src="V4\Xamarin.Android.Support.v4.dll" target="lib\MonoAndroid10" />

    <!-- Use Support v4 typeforwarded (to v13 types) lib for anything equal or higher than Android 3.2 -->
    <file src="V4TypeForwarded\Xamarin.Android.Support.v4.dll" target="lib\MonoAndroid32" />

TL;DR - The need to know bits

We’ve made some minor, but important changes to the Xamarin.Android.Support.v4 NuGet package:

  1. If your app is targeting Android API Level 13 or higher (Honeycomb 3.2), you will automatically get the Xamarin.Android.Support.v13 NuGet package as a dependency.

  2. If your app is targeting Android API Level 13 or higher, you will also get the Type-Forwarded assembly version of Xamarin.Android.Support.v4.dll installed by the NuGet package. This will work in conjunction with and forward all of its types to the Xamarin.Android.Support.v13.dll assembly that gets installed by the v13 NuGet dependency.

  3. If your app is targeting anything below API Level 13 (eg: Froyo, Gingerbread), you will get the good old Xamarin.Android.Support.v4.dll assembly that you’ve come to know and love!

To be clear, yes, we have decided that if you are targeting API Level 13 or higher, and choose to use the Android Support library v4, you will actually be using v13 instead. We decided the very small size increase was well worth the much improved compatibility between your apps and 3rd party libraries.

You can use these new packages today! We will be rolling out updates to our Components to achieve the same results in the near future!


September 16, 2014 6:12 GMT

Scanning for iBeacons in iOS 8

With iOS 7 you could easily range and scan for beacons in your application with just a few lines of code. CLLocationManger took care of all of the heavy lifting for you and things were just enabled for you automatically. With iOS 7.1 your users got prompted that you were going to do some scanning and it required Bluetooth. This was alright since the system took care of it for you automatically.

Enter iOS 8

While iOS 8 hasn’t added too many new feature for iBeacons that I can tell thus far, they did change the API for developer to enable iBeacon support in there application.

When you create a new instance of CLLocationmanager it is extremely important that you call the following:

manager = new CLLocationManager();
1.) manager.RequestWhenInUseAuthorization (); //This is used if you are doing anything in the foreground.
2.) manager.RequestAlwaysAuthorization ();// This is used if you want to scan in the background

Of course these are iOS 8 only methods so makes sure to do a version check with: UIDevice.CurrentDevice.CheckSystemVersion (8, 0);

But wait there is more!

This isn’t enough though to prompt your user for access to iBeacons. You will need to now modify your Info.plist! You will need to add a new string entry called NSLocationWhenInUseUsageDescription or NSLocationAlwaysUsageDescription. Then you can specify the message you want to prompt your user with when attempting to scan for iBeacons.

Now we can return to happy iBeacon Scanning!
September 16, 2014 3:09 GMT

Xamarin Evolve 2014 Speaker Spotlight: Paul Betts

This is the fifth post in our Xamarin Evolve 2014 “Speaker Spotlight” series, helping you get to know a little bit more about some of the amazing speakers who will be contributing at this year’s conference.

Photo of Paul BettsPaul Betts is a C# Hacker at GitHub, and the author of several open source .NET projects, including Refit, Splat! and Akavache. Paul graduated from The Ohio State University, and likes to spend his spare time hacking on open source software, playing guitar and bass, and in general is within ε of really awesome. Don’t miss Paul’s talk at Xamarin Evolve, “Writing Mobile Apps the Github Way,” in the Mobile Best Practices track.

How long have you been doing mobile development?

My interest in mobile development started when iPhone first released their non-web SDK, but I really got started in mobile development when I added Xamarin support to ReactiveUI, which was about two years ago.

What are your favorite mobile apps and why?

My favorite app these days is Dropbox’s Mailbox. The usability designers who created that app are absolutely brilliant; while I don’t find it to be a particularly visually beautiful application (so much white everywhere!), using it is an absolute joy. If you’re building any kind of content-management/TODO app, study this thing like a graduate student.

What is your favorite platform to develop for and why?



What devices are you carrying around with you right now?

The devices I carry around with me are usually:

  • An HTC One (M7) – It’s getting a little long in the tooth, but getting the Developer Edition meant that it was super hackable and easy to flash with the latest software, given a bit of adb and fastboot work. It’s a great device except for the camera.
  • LG G Watch – I couldn’t wait until the Moto 360 came out – I’m excited to see if I can come up with a cool watch app!
  • nVidia Shield – It’s an Android phone with a super-powered graphics chip and an HDMI out, bolted to a game controller. I use it to play old SNES games and write software for it.

What are your favorite open source libraries, and why?

My favorite libraries? The Xamarin ones I write, of course! I’ve got a lot of them:

The common theme around most of these libraries is that they let you write cross-platform code in a Portable Library, and the library handles the platform details. For example, ModernHttpClient brings the best platform-specific networking libraries to your app, but wraps them in a familiar HttpClient interface that works everywhere.

Separate from that, I love all of the great work that Jake Wharton does; he’s a great Android developer and a lot of my library ideas come from him.

What is your favorite line of code that you have ever written?

My favorite line of code I’ve ever written is here.

To explain it though, I need to back up. The goal of this class is to provide a mapped operation queue – i.e. you schedule a Task with a specific Key – Tasks with different keys run in parallel, and Tasks with the same key run sequentially.

The entire behavior of this class, this complex notion that would take pages and pages of buggy, unverifiable threading/locking code, is reduced to a single (relatively) beautiful statement in C# with Rx. What’s even cooler, is that the notion of scheduling priority (i.e. important operations should go to the head of the line), was added simply by changing a data structure, from using a normal Queue in a SemaphoreSubject, to using a PriorityQueue.

If you missed the earlier posts in this series, click through to read about Jesse Liberty, Jon Skeet, Jonathan Peppers, and Laurent Bugnion.

September 16, 2014 4:00 GMT

Unifying Google Play Services

Once upon a time, you may have noticed there were a lot of choices when it came to adding Google Play Services to your Xamarin.Android apps.

Google Play Services Chaos

This was always a bit confusing. Which version should you use for your app? Should you use the version for the highest API level you’re targeting, or the lowest one? The answer wasn’t always clear.

I won’t go into great detail as to why we did this in the past, because the good news is, there have been improvements in more recent versions of Xamarin.Android which have allowed us to unify many of these packages into one!

Starting today, we have simplified Google Play Services bindings into the two following packages (both for NuGet and Component Store):

  • Google Play Services (Froyo)
  • Google Play Services

This mirrors exactly what Google releases to developers: a .jar file frozen in time for Froyo compatibility, and the new, frequently updated .jar file for Gingerbread and above.

Which one do I use?

As a general rule, you should almost always use Google Play Services, unless you have a special need to target Froyo, however given that Froyo is now only 0.7% of devices, you are most likely safe to drop support for it.

There is one caveat: If you are targeting Gingerbread, there will be some classes in Google Play Services that you aren’t able to use while running on Gingerbread (eg: MapFragment). You should take care to avoid using these if you are running on an API Level they aren’t compatible with (Google has documented this). Luckily Google also provides Support* versions of these classes (eg: SupportMapFragment).

Updated & Disabled/Delisted Components/NuGets

Finally, if you have referenced the Google Play Services (ICS) Component or NuGet, you should update it (it will now appear as simply Google Play Services). This also means we have disabled and delisted the following Components and NuGet packages:

  • Google Play Services (Gingerbread)
  • Google Play Services (JellyBean)
  • Google Play Services (KitKat)

If you were using any of those packages, now is a good time to update them to use the new packages!

September 16, 2014 3:53 GMT

Apple Pay: It's not one thing

TL;DR: Apple announced a payment thing called Apple Pay.

I've seen a few knowledgeable people talking about it recently, and apparantly either getting it wrong, or missing some of the point (or only covering half of it)

The bit I think they are missing (in the case of John) or possibly ignored (in the case of Matt Vickers from Xero, who's article is a really good read) is that it's two distinct products rolled into one. They are related, but not really the same.

The first is an NFC-based, tap and pay system. NFC-based payments are not that common in the US yet, but they are in the UK, EU, NZ and AU, and possibly in other places too (I've not been to many of them recently). Most countries with Chip and Pin cards (which is almost everywhere but the US) are moving to the Visa Paywave / Mastercard PayPass NFC system.

In the UK and AU, "stickers" which stick on the back of your phone, are quite popular - it's basically a small NFC chip with your credit card info on it. Think about the small loyalty cards you stick on your keyring, but stuck to your phone. Works like a tap-and-pay credit card otherwise. Very handy, and aside from the obvious internal smarts, very easy and cheap to roll out. The banks can even do some smart things like put a unique card number on, and work out which one of your accounts to charge on the back end - makes it easy for you to pick which real account to use from their mobile app.

For the hardware side of Apple Pay to work, Apple needs to "just" add it to their phone, which they have done with the iPhone 6 and 6+. Your card details (or some form of them) are stored securely on the phone, and when you tap it (and use TouchID to authorise it), it pays, the same way as your credit / debit card would if you used it at a store (and which I've done 3 times today, so far). Android can also do this, with the Nexus 5, Galaxy S5 and a few others.

Infrastructure-wise, Apple needs to do a fair bit - they didn't expose the interface between the user-level of the phone (where we can write apps) and the secure element - only Apple can write to it (on Android, anyone with permission can write to it), so they have to be the go-between between your bank and the secure element. This is why it's US-only - they have only got deals with the US banks. That will change.

On Android, anyone with permission can write to it, so a bank could write their own mobile wallet app, authenticate you how they see fit, and write the appropriate thing to the secure element. Anyone else could, too, but the block of data that's written is encrypted by the bank, the same way that it's encrypted on your credit card, so you can't write anything useful into the secure element.

BTW, taking a photo of your credit card is only a quick way to get the data in - you could type it - it still has to go back to your bank and be "swapped" for the secure block that is written to the secure element.

The second part is, confusingly, also called Apple Pay. This part is also about paying for things in the real world, where In-App Purchase isn't allowed, but it's not about tapping to pay: it's about standing in the queue at Starbucks, putting your order into the SB's app on your phone, paying using your iTunes Store-connected credit card, and having that integrate into the store's POS system (and get presented with a decidely average coffee).

Think of the (US only) Apple easy-pay thing, where you buy a physical apple product on your phone, walk into the store, pick it up (off the shelf) and walk out. Sounds like a security nightmare, but they have made it work.

In New Zealand there is a crowd called "YQ" who do this already. I can get off the ferry, select my local cafe, put an order in for a coffee and pick it up when I walk in the door. The payment is done between YQ and the coffee shop (I loaded my card into YQ) - this is just Apple making it really easy for developers to do this: YQ had to go to a local payment provider to sort out the payment, and I'd assume, is paying more than Apple is per transaction.

Expect to see Amazon do an app which pays with this method. It's all about physical goods.

This is all Apple. They charge the card, their apps - that we write - present the UI, and it can use any credit card or other payment method that Apple supports. I suspect it's not taking 30% either, like a normal IAP.

It could hit the same source credit card, but thats up to how you have it configured. This should work on any iPhone - tho they may make it require TouchID to keep the credit card companies happy and get a better rate, but thats up to Apple.

It does not, however, allow you to pay a random merchant you just walked into - thats the "other" Apple Pay.

Thats really it - the two sides of Apple Pay. Similar, and not mutually exclusive, but not that same.

September 15, 2014 5:57 GMT

Web Series: Better Know a Xamarin

You may have met a Xamarin or two at Evolve, developer group, or at one of our other awesome events. However, there are many Xamarins working hard behind the scenes and out in the field around the world to bring you this amazing development platform. Better Know a Xamarin is a new web series that you can find on our YouTube Channel, where we sit down with our fellow Xamarins to see what they do here at Xamarin and what their passions are.


To kick things off, we have four episodes for your enjoyment. So sit back and get ready to Better Know a Xamarin.

Morgan Forsythe - Marketing Operations Manager

Jon Goldberger – Customer Support Engineer

Aaron Bockover - Mac Team Lead

Alex Soto - Software Engineer (Components)

The web series will continue to roll out new videos each week, so be sure to follow our Twitter account or subscribe to our YouTube channel for updates. If you’re interested in joining our growing global team, check out our available positions here.

Want to better know a Xamarin in person? Meet us in Atlanta, Georgia for Xamarin Evolve, October 6th-10th. Register for your ticket to mobile expertise here.

September 12, 2014 4:15 GMT

Webinar Recording: Get Ready for iOS 8

On September 17th, iOS 8 will launch with over 4,000 new APIs, making it one of the largest iOS releases ever. Xamarin developers can start building for iOS 8 now, with support currently in the alpha channel for App Extensions, TouchID Authentication, PhotoKit, HealthKit, HomeKit, Apple Pay, and more.

In this webinar, Xamarin Developer Evangelist Mike Bluestein provides an overview of the top new and updated APIs, and how to incorporate all of the great new features into your app.

Download the slides for the Get Ready for iOS 8 Webinar here.

Additional Resources

To ensure you get the most out of the exciting changes in iOS 8 using Xamarin and C#, we’ve created an extensive set of resources to help you get started that are outlined in this blog post.

If you’re already registered for Xamarin University, we’ll be debuting a new class on September 17, 2014, that will help you update your apps for iOS 8. If you’re not already registered for Xamarin University, you can learn more about our unlimited, live mobile app development training here.

Lastly, if you are coming to Xamarin Evolve 2014, we will be covering iOS extensively, including iOS 8. If you are not already attending the conference, you can register here.

September 11, 2014 4:51 GMT

Xamarin Evolve 2014 Speaker Spotlight: Laurent Bugnion

This is the fourth post in our Xamarin Evolve 2014 “Speaker Spotlight” series, helping you get to know a little bit more about some of the amazing speakers who will be contributing at this year’s conference.

Photo of Laurent BugnionToday we’re getting to know Laurent Bugnion, the Senior Director of IdentityMine in Zurich, Switzerland. This year will mark his 8th year as a Microsoft Client Development MVP and his second year as a Microsoft Regional Director. He is also the author of the well-known open-source framework MVVMLight for Windows Phone, Windows 8, WPF, and Silverlight. In his free time, Laurent writes for MSDN Magazine and various other publications, as well as on GalaSoft, his blog. Be sure to see Laurent at Xamarin Evolve giving the talk, “Building Cross-Platform Applications with Xamarin, Xamarin.Forms and MVVM Light.”

Why did you get into software development?

I was an electric engineer and started doing low level coding for embedded controllers twenty years ago.


How long have you been doing mobile development?

I started doing programming about 20 years ago and worked on all kind of systems, from embedded controllers to full blown PCs. I am still coding for multiple systems and mobile is, of course, an important part of it. I did some code for the Palm line of devices, but it was more of a hobby. I really started coding professionally for mobile devices when Microsoft released the first Windows Phones.

What is your favorite platform to develop for and why?

After working on many different platforms, I would say that my favorite remains the various XAML/C#. I am able to create UI in XAML that I cannot easily create with other platforms, and XAML/C# is available for many devices, from TVs (XBOX) and phones to computers and tablets. Also the tooling (especially Blend) is just fantastic, especially when you work closely with designers (which I do). Of course, on Android and iOS without XAML, working with C# is nice, too, but I do find the UI on these platforms quite complicated to build for compared to the simple beauty of XAML.

What devices are you carrying around with you right now?

I carry the Nokia Lumia 1020, which is my most trusted companion, all the time. I love this device, especially the amazing pictures it takes, and the large screen.

I also usually carry my Kindle Paperwhite. I love to read and the reading comfort is just fantastic on this device, though I also read on my Lumia when I don’t have my Kindle with me.

I recently fell in love with a Dell Venue Pro 8, on which I installed Windows Pro 8.1. It’s an awesome little device where I can run any Windows application, including legacy ones, and has great battery life.

Finally most of my work is done on my Surface, and I cannot wait to get my new Surface Pro 3 at the end of August!!

What are your favorite mobile apps and why?

I love geolocation, and it still feels somehow magical when an app knows where I am. This can be a huge help, especially when traveling. Also, anything related to photography.

What will attendees get out of your talk?

Users of MVVM Light on Microsoft platforms love it because it isn’t overly complicated and “does the job”. Now, with the possibility to use MVVM Light on Xamarin, too, I want to build a knowledge base for new users. Some of them have never heard of MVVM, some of them know of it but have heard contradictory statements. There is a need for information, and this will help people to switch platforms more easily, as well.

If you missed the earlier posts in this series, click through to read about Jesse LibertyJon Skeet, and Jonathan Peppers.

September 08, 2014 1:00 GMT

Episode 16: iBeacons

iBeacons are an emerging technology with a lot of exciting applications. In this episode we talked to Doug Thompson to dive into what they are, how they’re used, and where beacons are heading in the future.

Hosts: Greg Shackles, Jon Dick

Guests: Doug Thompson


Thanks to our Sponsors! – Exceptional Error Tracking is the fastest and easiest way to track your application’s errors and get the level of detail you need to fix crashes quickly. Notifications are delivered right to your inbox and presented on a beautiful dashboard.

September 07, 2014 9:00 GMT

NuGet Support in Xamarin Studio 5.3


  • NuGet package restore is now part of Xamarin Studio and no longer uses NuGet.exe
  • Add Packages dialog – Package sources could not be reached shown for failing package sources
  • Packages restored for the selected project instead of the solution
  • Show packages added to solution in Add Packages dialog
  • Show packages up to date message in status bar if there are no package updates available
  • Show status bar warning message when no updates found and package sources are unavailable
  • Restore missing packages before updating a package
  • Do not check for updated packages if the project has no packages
  • Fix version shown as download count in Add Packages dialog when searching for package versions
  • Fix empty source being selected in Add Packages dialog when package source disabled and All Sources selected
  • Fix packages.config marked as deleted by Git when updating packages

More information on all the new features and changes in Xamarin Studio 5.3 can be found in the release notes. Now let us take a more detailed look at the new NuGet changes.

NuGet package restore no longer uses NuGet.exe

The NuGet package restore is now a part of Xamarin Studio and no longer uses NuGet.exe. This allows the package restore to integrate with the Xamarin Studio credential provider and provides more control over the package restore process. So if a package source needs authentication, or uses a proxy, then Xamarin Studio will now show a dialog asking for credentials if the credentials are not stored. Previously the package restore would fail with an error message logged in the Package Console.

Add Packages dialog – Package sources could not be reached

Previously when All Sources was selected and if any package source could not be reached then an error message would be displayed and no packages would be shown in the list. Now packages will be displayed with a warning even if one package source could not be reached.

Add Packages dialog - package sources could not be reached warning

Packages restored for the selected project instead of the solution

Xamarin Studio will now restore packages for the selected project instead of the entire solution. When you right click the Packages folder in the Solution window and select Restore only the packages for that project will be restored.

Packages folder - Restore menu

This is now possible since Xamarin Studio is now responsible for restoring packages instead of using NuGet.exe which would only restore for the entire solution.

To restore packages for the entire solution you can still use the Restore Packages menu which is available from the Project menu or by right clicking the solution in the Solution window.

Show packages added to solution in Add Packages dialog

Opening the Add Packages dialog will now show the packages added to all projects in the current solution.

The order of the items displayed in the Add Packages dialog is recent packages first, then solution packages, and then the packages from the active package source.

Show packages up to date message in status bar if there are no package updates available

When you try to update a package and there are no package updates available then the status bar now displays a message indicating that the package is already up to date.

Package up to date status bar message

Similarly if you update multiple packages and there are no updates available then the status bar will now show a packages are up to date message.

Packages are up to date status bar message

Previously the status bar would show a message that the package was updated successfully even if nothing was updated.

Show status bar warning message when no updates found and package sources are unavailable

When one or more of the package sources is unavailable or invalid then Xamarin Studio will now report a warning in the status bar after checking for updates.

No updated found but warnings reported status bar message

Restoring missing packages before updating packages

Previously when NuGet packages were unrestored and an attempt was made to update a NuGet package, which had updates available from the package source, the update would fail with a message indicating that the package was installed successfully but the project did not reference the package.

To prevent the update from failing Xamarin Studio will now check that the packages are restored for the project before trying to update and restore any missing packages. In the status bar a Restoring packages before update message will be displayed when a restore must be completed first.

Restoring packages before update status bar message

Bug Fixes

Do not check for updated packages if the project has no packages

Xamarin Studio was checking for package updates in all projects even if they had no packages.config file when the solution was opened. This would result in the Packages are up to date message being displayed in the status bar even when no projects were using any NuGet packages.

Now if the project has no packages.config file then Xamarin Studio will not check for updates.

Fix version shown as download count in Add Packages dialog when searching for package versions

When running a package version search, such as Xamarin.Forms version:*, the right hand side of the dialog was showing the version number instead of the download count.

Now the dialog shows the download count. Ideally it would show the download count of that particular version but this is not currently available from the Package object returned by NuGet. It is returned in the results back from the package source but it is not available on the Package object.

Also the download counts are different for the same package if you compare the normal search result with a package version search result. The package version search shows a larger download count number. This may be related to the stats problem NuGet had recently. Currently Xamarin Studio is showing the download count it receives. The standard search download counts match those shown in Visual Studio’s Manage Packages dialog. For the package version search the download count value matches that shown on the website for an individual package (e.g.

Fix empty source being selected in Add Packages dialog when package source disabled and All Sources selected

An empty package source selected in the Add Packages dialog could occur when All Sources was selected in the Add Packages dialog and one of the enabled package sources was unchecked in Preferences. On opening the Add Packages dialog again an empty package source would be displayed as the selected package source.

Now the Add Packages dialog will have the remaining enabled package source selected.

Fix packages.config marked as deleted by Git when updating packages

On updating packages in a project, and the project is using Git for version control, then the update was causing Git to show the packages.config file as deleted. This would occur if all the NuGet packages were uninstalled as part of the update which caused NuGet to see that there were no NuGet packages referenced and delete the packages.config file.

Now the packages.config file is shown as modified instead of deleted.

September 03, 2014 2:35 GMT

Build Your Own Continuous Integration Pole

If you live in Boston and happen to walk around the Commons when evening falls, you may have noticed a strange glow coming from the top of one the building along the park:

A Mysterious Glow on Boston

This eerie light comes from our designer pole, an experiment I did to provide cheap feedback over our build status in our continuous integration system:

Le Pole

The setup is based around 3 main components: a Raspberry Pi, a 5V relay module board and a basic 12V RGB LED strip. You can buy all those parts directly from Amazon for about $112 total (of which $77 was for a premium Raspberry Pi package but it’s up to you).


No matter the RGB LED strip “brand” you end up buying (it all seems to be from the same generic supplier), the wiring is pretty simple and consist of a common ground and a wire for each color channel (red, green, blue) so 4 wires in total.

Thus in the simplest form we can very easily turn on and off those channels using a bunch of relays. Each build status (success, test failure and build failure) will be mapped to a specific color (green, blue, red respectively).

A relay is the basic building block to control a power circuit (the 12V DC from the LED strip power adapter) from a control circuit (the 3.3V DC of the Raspberry Pi). There are a bunch of different designs available (magnetic, solid state, …) depending on the amount of power you are controlling. For this type of setup pretty much anything should work (it’s just LEDs after all).

A relay module

Those relays are then mounted on a board like the one in the picture to conveniently expose a control interface that you can plug to your Raspberry Pi GPIO ports. That’s the final product you can buy (unless you want to do your own PCB).

Below is a close-up of the wiring between all the different pieces, the GPIO ports are exported to the breadboard and then connected onto the relay module control circuit.

Close-up wiring

I also made a more schematic version so that you can see which GPIO ports are used:

Wiring schema

The common of the LED strip (the white cable) is connected directly to the power source (we don’t care about controlling it). All the other color wires go in and out of their own relay.

If you are short on connectors, you may have noticed a little trick I use which is to go scavenge your old computers for IDE connectors (what you used to plug your old harddrive, floppy disk readers and the likes). They fit perfectly well and have the same type of wire that standard Dupont cables.

Below is the part of the code that controls the relay module to turn on and off the LEDs:

using System;
using System.Threading;
using RaspberryPiDotNet;

namespace WrenchBerry
	public static class Ledder
		public enum Color {

		static GPIOPins[] pinMapping = new GPIOPins[] {

		public static void FlashLed (Color color, int times = 3)
			var pin = pinMapping [(int)color];
			for (int i = 0; i < times; i++) {
				GPIO.Write (pin, true);
				Thread.Sleep (500);
				GPIO.Write (pin, false);
				Thread.Sleep (500);

		public static void TurnOn (Color color)
			var pin = pinMapping [(int)color];
			GPIO.Write (pin, false);

		public static void TurnAllColorOff ()
			foreach (var pin in pinMapping)
				GPIO.Write (pin, true);

The code use the RaspberryPi.Net library to directly access the chip memory controlling the GPIO pins.

The main program is then a super-simplistic infinite loop over the CI results:

using System;
using System.IO;
using System.Linq;

namespace WrenchBerry
	class MainClass
		const Ledder.Color NoColor = (Ledder.Color)(-1);
		static Ledder.Color currentColor = NoColor;

		public static void Main (string[] args)
			var lane = args [0];

			while (true) {
				try {
					var builds = CISystem.GetStateListFromLane (lane);
					if (builds == null || builds.Length == 0 || !builds.Any (IsFinishedState)) {
					    Console.WriteLine ("Lane or fetching is fucked up");
					var firstBuilt = builds.First (IsFinishedState);
					Console.WriteLine (DateTime.Now.ToString ("u") + " - " + firstBuilt);

					Ledder.Color color = GetColorForState (firstBuilt);

					if (color != NoColor && currentColor != color) {
					    Ledder.TurnAllColorOff ();
					    Ledder.FlashLed (color);
					    Ledder.TurnOn (color);
					currentColor = color;
				} catch (Exception e) {
					Console.WriteLine (e);

				System.Threading.Thread.Sleep ((int)TimeSpan.FromMinutes (2).TotalMilliseconds);

		static Ledder.Color GetColorForState (DBState state)
			Ledder.Color color = NoColor;
			switch (state) {
			case DBState.Failed:
				color = Ledder.Color.Red;
			case DBState.Issues:
				color = Ledder.Color.Orange;
			case DBState.Success:
				color = Ledder.Color.Green;
			return color;

		static bool IsFinishedState (DBState state)
			return state == DBState.Failed || state == DBState.Issues || state == DBState.Success;

All that’s left to do is to make yourself a nice little storage area and, why not, spice up the system a little bit. For instance in our setup (pictured below) I also hooked up a small speaker.

Final Setup

As an example our current playlist consist of: the Imperial March (build failure), Mass Effect Reaper sound (test failure) and, last but not least, our friend He-Man (build success).

Happy (hardware) hacking!

August 28, 2014 2:02 GMT

Xamarin.Forms Programming in F#

Things are kind of busy what with Evolve being only 40 days away and iOS 8 coming down the pipe, but I thought I’d share the easy hack that allows you to program Xamarin.Forms with F#.

(Of course, Xamarin loves F# and official support and templates and documentation and all that sort of stuff is forthcoming. This is just something you can do for the moment to begin exploring Xamarin.Forms with F#.)

tl;dr: Use the beta PCL 78 F# Core and link to the facade assemblies for monotouch

OK, so assuming that was a bit too brief…

In Xamarin.Studio create a “New solution…” of type F#/iOS/iPhone/Empty Project…

Open the “References” folder and delete the existing reference to Fsharp.core.dll.

Right-click the solution and select “Add Packages…”

Screenshot 2014-08-27 15.42.39


In the NuGet dialog, select “Show pre-release packages” and type FSharp.Core into the search box. This should allow you to add the “FSharp.Core Mono delay signed” package.

Screenshot 2014-08-27 15.25.05Also, add the Xamarin.Forms package:

Screenshot 2014-08-27 15.46.26

And now the tricky part!  You have to add references to the System.ObjectModel.dll and System.Runtime.dlls from the monotouch facade assemblies by hand.

Right-click on the References folder, Select “Edit…”, and select “.NET Assembly”. Add references to System.ObjectModel.dll and System.Runtime.dll from, in my case:


Your path may be a little different.

Write a Xamarin.Forms app in 36 lines of code :

namespace FSXF1

open System
open MonoTouch.UIKit
open MonoTouch.Foundation
open Xamarin.Forms

type App = class
 static member GetMainPage =
   let lbl = new Label()
   lbl.Text <- "Hello, F# Xam.Forms!"
   lbl.VerticalOptions <- LayoutOptions.CenterAndExpand
   lbl.HorizontalOptions <- LayoutOptions.CenterAndExpand

   let cp = new ContentPage()
   cp.Content <- lbl

type AppDelegate() =
 inherit UIApplicationDelegate()

 member val Window = null with get, set

// This method is invoked when the application is ready to run.
 override this.FinishedLaunching(app, options) =
   this.Window <- new UIWindow(UIScreen.MainScreen.Bounds)
   this.Window.RootViewController <- App.GetMainPage.CreateViewController()

module Main =
   let main args =
     UIApplication.Main(args, null, "AppDelegate")

And you’re good to go!

Screenshot 2014-08-25 10.16.14


P.S. If it helps:

August 24, 2014 9:29 GMT

Enhanced Xamarin.Android Designer with Tools Attributes

The announcement of Android L Developer Preview support for Xamarin.Android developers brings tons of goodies to start playing around with, but did you know that there has been several updates to the Android designer as well? If you look through the release notes of Xamarin Studio 5.3 you will several enhancements such as the new Android L & Wear themes and devices, but also support for Action Bar menu icons and navigation style via the menu and actionBarNavMode XML attributes. More information on those attributes can be found at So, let’s take a look at these new features in the Alpha Channel.


To take advantage of any of the features you will need to add this attribute to your root node in your layout:


So your layout might look something like this:

Now we can take advantage of the tools and other attributes and add them onto our root node.


Normally your menu’s live completely separate away from your layouts, however the tools attributes allow you to get a preview right in the designer. First we will want to add the tools attribute:


Notice that we don’t use any @menu or anything like this. It is just referencing the name in the Resource/Menu folder. This will give us a nice preview:

Navigation Style

Additionally, you might be using tabs or a spinner as part of your navigation in your ActionBar and you can now visualize this with another attribute


The actionBarNavMode can be set to tabs, list, or standard. I actually use a list navigation in My StepCounter, so this is great to be able to visualize:

That is just the beginning as Jérémie Laval has hinted at some more awesome updates coming soon:

Issues with Menu?

If you are having issues with the tools:menu property you might need to remove the Unicode BOM from your xml file. This is just a side effect currently of how the xml files are generated. Once you delete the 3 invisible bytes you will be able to browse things just fine. It is relatively easy and quick to do this. First make sure the file is CLOSED inside of Xamarin Studio. Then you will want to say open in HEX Editor:

Now simply delete the first 3 bytes on the right hand side that:
Alright you are all set now :)
August 23, 2014 4:21 GMT

Clean ViewModels with Xamarin.Forms

I like to keep my view models focused on just the code needed for a particular view, and to keep as much plumbing and infrastructure code out of the view model as possible. I've already covered how to use Fody to implement INotifyPropertyChanged and use auto properties in our view models. Now I want to cover how to connect the ViewModel to the View automatically.

The most straight forward way to access our view model would be to simply instantiate it in the constructor of our view.

using Xamarin.Forms;

namespace CleanViewModels
    public partial class UserPage : ContentPage
        UserViewModel _viewModel;
        public UserPage ()
            InitializeComponent ();
            _viewModel = new UserViewModel ();
            BindingContext = _viewModel;

This technique requires us to add this bit of code to every view that uses a view model though. I'd prefer to have that handled automatically for each view.

View Model

Let's begin by creating a marker interface for our view model. At its simplest, this interface is just used to constrain the generic type later.

namespace CleanViewModels  
    public interface IViewModel {}

Each of our view models will need to implement our marker interface.

using PropertyChanged;
using System.Windows.Input;
using Xamarin.Forms;

namespace CleanViewModels
    public class UserViewModel : IViewModel
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public ICommand LoadUser {
            get {
                return new Command (async () => {
                    this.FirstName = "John";
                    this.LastName = "Doe";

View Page

Now that we have the ViewModel defined, we can wire it up to the View. We'll create a new class, named ViewPage.cs. This will be our base class for each view. We will derive ViewPage from ContentPage and pass in the type of our view model. In the constructor, we will create a new instance of the requested ViewModel and set the view's BindingContext to the current ViewModel. We also provide a read only property to be able to access the view model in the page, if needed.

using Xamarin.Forms;

namespace CleanViewModels
    public class ViewPage<T> : ContentPage where T:IViewModel, new()
        readonly T _viewModel; 

        public T ViewModel
            get {
                return _viewModel;

        public ViewPage ()
            _viewModel = new T ();
            BindingContext = _viewModel;


When using XAML in Xamarin.Forms, I was not able to set the root to use ViewPage<T> directly. Instead, we will create a wrapper class that defines the parameter for us, so that we can use the wrapper class in XAML.

namespace CleanViewModels
    public class UserPageBase :  ViewPage<UserViewModel> {}

    public partial class UserPage : UserPageBase
        public UserPage ()
            InitializeComponent ();

Once the code behind is defined, we can add our xml namespace local: and create our view in XAML as UserPageBase

<?xml version="1.0" encoding="UTF-8"?>  

            WinPhone="5,0,5,5" />

        <Entry Text="{ Binding FirstName, Mode=TwoWay }" />
        <Entry Text="{ Binding LastName, Mode=TwoWay }" />

          Text="Load User"
          Command="{Binding LoadUser}"></Button>

By using a base view page, along with Fody, we are able to keep our view models clean and focused only on the properties and commands that are needed for the view, thereby increasing the readability of the code.

Check out the sample project on my Github repo.