I am fortunate to both attend and speak at Music City Code this week.

I spoke Friday June 2nd on how my journey becoming a Xamarin mobile developer got me excited about microcontrollers.

The slides are available here.

All Xamarin code samples are available on GitHub. The arduino code samples are available from Adafruit.com.

Other Resources

Xamarin

• Xamarin
• Xamarin IoT Mini Hack

Adafruit

• Adafruit
• Adafruit IO

Arduino

• Arduino

Microsoft Azure IoT

• Build 2017

Local Meetups

• Nashville Mobile .NET Developers
• NashMicro

I'm a big fan of the Redth's Addins extension for Xamarin Studio and Visual Studio. Specifically, I love the Obliterate menu option it adds to the IDE context menu. Creator, Jonathan Dick, makes some cool stuff. Check out his GitHub sometime.

However, the Obliterate command has had a bug in Visual Studio for Mac for a little while. Basically, you try to run the command and the IDE would hang or read "Obliterating Output Paths" forever.

If you already use his extension, you many have noticed that an update was available when you launched Visual Studio today.

But after clicking Restart and Install Update, an error popped up.

No worries!

Simply head over to the Visual Studio > Extensions menu.

Find the Redth's Addins extension, and update it from here.

Everything should work fine. When you're done, Obliterate works like a champ again!

Contributions

Some of these screenshots are from my co-worker Ryan. Thanks for posting them.

If you use SQLite-net (aka sqlite-net-pcl on NuGet) and have seen disk I/O or connection exceptions in your applications, you may be overlooking some features of the library or mixing concerns.

We were.

This is Part 1 of a short series on SQLite-net Async connection gotchas that we have come across and are learning from.

• Part 1 - Keep It Clean
• Part 2 - Mixing Connection Types

SQLite-net Async

We have mobile applications that use SQLite for data persistence, and we use SQLite-net as our ORM. SQLite-net has a beautiful and simple API that supports synchronous and asynchronous data access. Because async / await makes writing responsive applications so much easier, we use async anywhere we can --- including our data access code.

Creating Async Connections

When using SQLiteAsyncConnection, if you don't already have a connection, when you request one, SQLite-net opens a new connection to the requested path, then adds that open connection to a connection pool that it manages. That open connection has a handle to the specific file on disk.

This snippet shows how to request a connection:

var conn = new SQLiteAsyncConnection("file1.db");
await conn.CreateTableAsync<AppData>();

This code works whether the file exists or not, and whether a previous connection has been requested or not. Just ask and SQLite-net hands a connection back --- either an existing connection from the pool or after opening a new one.

What You Might Not Realize

The SQLiteAsyncConnection API makes grabbing a connection simple. It just works.

However, if you delete, move, or similarly alter your database file at a FileSystem level after a connection has been established, the open connection's handle to the file on disk can be broken. The connection stays alive in the connection pool, but any attempt to use that connection might produce an error.

Common Errors

• SQLiteException: IOError
• SQLiteException: ReadOnly
• disk I/O error

Keep It Clean

To guard against these kinds of errors, SQLite-net provides an escape hatch.

If you need to alter your database files or clean up open connections, simply call the static SQLite.SQLiteAsyncConnection.ResetPool();. This will Dispose all of the connections sitting in the pool. The next time your app requests a connection, a new one will be created like nothing ever happened.

Acknowledgements

I want to thank my entire team for their accommodation and help in making these discoveries. I especially want to thank Ryan, Moose, and Macie.

Hopefully our learnings help someone else.

Xamarin Test Recorder is a really neat way to automate your mobile UI tests.

The tool lets you connect your mobile application to a device or simulator and record interactions with your app. The recorded interactions can then be fine-tuned and output as C# test cases. Those test cases can be saved for reuse in your own UI test automation projects or uploaded directly to Xamarin Test Cloud.

There are some general articles on recording tests using the test recorder, but I didn't see any with specific instructions for setting things up for iPhone on a mac. This is my attempt at closing that gap. Hope this helps you too!

Getting Started

Here's a basic getting started and requirements article from Xamarin.

Required: Pay close attention to the device provisioning instructions. In order to test your app on an iOS device, your app must have a development provisioning profile configured for the specific device in your Apple Developer portal.

For this post, I'm going to target a very specific version of the Xamarin Test Recorder. Because this tool is still in Preview, I want to make sure that I'm explicit.

Version

To download the test recorder, visit the getting started link, then click the Weekly Build link along the right side panel.

After downloading the installer and installing the app, you may be prompted to download the latest Weekly Build.

Important Note: Continue only if you're being asked to install version 0.13.0 or greater. Device support for iPhone doesn't appear to exist in earlier builds.

You can confirm the version you have installed by checking the About Test Recorder menu.

This is the version I'm running for this post.

Xamarin Test Recorder
Version 0.13.0 (1.0)
Xamarin

If your version doesn't match what I have, you can check for updates.

Preferences

There are some preferences that can be set.

Account: Insert your Xamarin Test Cloud API Key

General: See image below

Advanced: Android SDK and Mono Locations

Record an iPhone Test

See the Xamarin developer documentation on Recording a Test for detailed steps with screenshots.

Having Trouble?

I'm going to embed a little in case you see this too (ICYSTT) section to this post. I was plagued with problems when I tried to get started; almost to the point that I assumed there was a bug that I wouldn't be able to work around.

Steps

1. I chose my attached iPhone device

2. I selected my Debug|iPhone compiled .ipa

3. Then, after a few seconds of the test recorder attempting to connect, I would see this popup error:

   failed to install app /var/folders/7k/msfhh81j6hv3xdr09h1122hh004444/t/tmp574fcd7.tmp/payload/iostest.app: applicationname='/var/folders/7k/msfhh81j6hv3xdr09h1122hh0000gn/t/xdb/deviceagent.ios.dependencies/93c12f7393c12d1493c1d41793c14444/bin/iosdevicemanager', commandline='install -d 3d0e3d0e3d0e3d0e3d0e3d0e3d0e3d0e3d0e3d0e -a /var/folders/7k/msfhh81j6hv3xdr09h1122hh004444/t/tmp574fcd7.tmp/payload/iostest.app', currentdirectory='', native error= cannot find the specified file

This forum post helped me.

A colleague had a similar problem when attemping to run UITests against an iOS simulator. The "fix" mentioned in the forum helped her, and ended up helping me too. Basically, delete the {tempdir}/xdb/ directory ( /var/folders/7k/msfhh81j6hv3xdr09h1122hh0000gn/t/xdb/) then try again.

Xamarin also has a link for some Known Issues.

Hope this helps you guys! Leave comments below. I'd like to hear about the things you're testing.

Thanks for showing interest in my topic at Music City Code 2016! Below are links for my talk.

Native mobile apps beyond Hello World

Xamarin lets you build native Android, iOS, and Windows apps on a shared C# codebase. You already know how to get started, but now you want to make the most of Xamarin app development. What is the best way to share code? Can you access device-specific APIs from shared code? In this session, we'll dig deeper than "Hello World". First, I'll discuss popular code sharing strategies. Then we'll write shared code that accesses device-specific APIs like Connectivity and Notifications. Come with your "how do I Xamarin?" questions, and we'll cover as many as we can.

Slides and Code

• Slide deck
• Code examples

Resource Links

• Components
  • Xamarin Component Store
• Plugins
  • Connectivity
  • Local Notifications
  • More community plugins...
• NuGet
  • Xamarin-related NuGet packages
• How To
  • Creating Reusable Plugins for Xamarin
• Bait and Switch (Advanced PCL)
  • The Bait and Switch PCL Trick - Paul Betts
  • How to Make Portable Class Libraries Work for You - Daniel Plaisted

ICYSTT: In Case You See This Too

Humor me. I'm trying this acronym as a way of signaling the content of posts where I struggle through a problem and come out the other side with some findings.

Thanks to my teammate Ryan O. for piling onto this problem to help.

The Problem

Recently, some of the command-line build scripts for an iOS project starting failing. Specifically, the build steps around archiving the project. Of course, the problem only showed up after updating some of the tools on the machine.

Here's what was updated:

• OS X -> 10.11 (El Capitan)
• Xcode -> 7.3.1
• Xamarin Release Cycle 7
  • Xamarin Studio 6, etc.

In this particular build pipeline, FAKE is the build system of choice. The bundled XamarinHelper adds an easy iOSArchive task that generates a command something like this:

mdtool -v archive "-c:Release|iPhone" -p:YourApp.iOS your_solution.sln

Ordinarily, this command builds the project, then generates an .xcarchive.

Enter problem #1:

mdtool archive doesn't work

Oh no! Is mdtool deprecated?

Well, not really as Xamarin's Mikayla points out. However, more and more we're being pointed toward xbuild or msbuild since mdtool is just an interface into those other systems.

So, while mdtool may not be officially deprecated, the archive command broke as of Xamarin Studio 6 as commented on here and hinted at over here. Previously, the archive command would first build the iOS project, then archive. No longer the case as of this write-up. Maybe Xamarin will patch things up in a future release?

Squirrel Alert!

Before I get to the fix, I want to warn you about a squirrel we chased. Once realizing that the mdtool archive command had changed -- and therefore the FAKE iOSArchive task -- we tried running the FAKE iOSBuild task immediately before the iOSArchive task to make sure a build happens.

The build happened and an archive was created, but the build still failed. There are additional steps in my build pipeline that export the archive as an .ipa. This one-two punch of iOSBuild and iOSArchive ultimately generated a bad archive. Turns out, if your achive is bad, you won't be able to export and may see errors such as:

xcodebuild: WARNING: -exportArchive without -exportOptionsPlist is deprecated
...
** EXPORT FAILED **

We chased that squirrel before realizing that the generated archive was simply bad. Although, duly noted, the export step needs to change.

You can anecdotally recognize a bad archive by viewing the Xcode Archive Organizer, selecting an archive from the list, and verifying that the Export, Validate, and Submit buttons are grayed out.

The fix for problem #1:

This post was the most helpful.

Down the page a bit, a Xamarin employee suggests using an xbuild command explicitly:

xbuild /p:Configuration=Release /p:Platform=iPhone /p:ArchiveOnBuild=true /t:"Build" MyProject.csproj

He goes on to explain how the ArchiveOnBuild property works. Not entirely familiar with xbuild, I whittled the suggestion down to a simpler:

xbuild /p:Configuration=Release /p:ArchiveOnBuild=true /t:"Build" MyProject.csproj

The Platform property wasn't described, so because I didn't want to include something I wasn't sure of, I removed that bit.

Enter problem #2:

The project builds, but no archive is generated

Well, running that command certainly built the app, but no .xcarchive was generated, and my app didn't show up in the Xcode Archive Organizer.

The fix for problem #2:

You guessed it -- Platform was necessary. Putting that property back fixed the script:

xbuild /p:Configuration=Release /p:Platform=iPhone /p:ArchiveOnBuild=true /t:"Build" MyProject.csproj

The Platform property is the platform target (e.g.- iPhone, iPhoneSimulator, x86, etc.)

Executing this command built the project, and generated an archive, but the archive wasn't listed under my iOS Apps in Xcode Archive Organizer.

Enter problem #3:

Archive shows up in Xcode Archive Organizer under Other Items instead of under iOS Apps.

If you read the entire post from the problem #1 fix, you already know what's going on. If you jump down to this comment you'll see that the CFBundleVersion must be present and populated in the archive's Info.plist.

The fix for problem #3:

This isn't necessarily a big problem if your application's Info.plist is correct. Your app will still export correctly and be able to be submitted to the App Store. However, this comment provides a suggestion that works perfectly.

/usr/libexec/PlistBuddy -c "Add :ApplicationProperties:CFBundleVersion string "your build number here"" path/to/archive.xcarchive/Info.plist

Adding that command to your build pipeline will ensure that the archive files correctly under the iOS Apps section of the Xcode Archive Organizer.

That's it! Build scripts work again. The community did a great job helping with the various fixes, but I wanted to compile everything into a single how-to. Maybe it will save someone else some time.

I'd love your feedback. Let me know if this helped you or if you ran into different kinds of problems.

It's overdue, but I just published version 2.7 of the Android AltBeacon Library.

You can find it on:

• GitHub
• NuGet
• Xamarin Component Store (update coming soon)

What's new

There have been several major version releases from AltBeacon since the Xamarin library has been updated, so here's a quick rundown of new shiny bits you can expect to find:

Features changes:

• Optionally allow tracking multiple beacons with the same identifiers, distinguishing with the mac address.
• Support for Gatt-based beacons and interleaved frames
• Filter out invalid RSSI values of 127 for distance calculations
• Identifier class now supports conversion to/from the UUID class.
• Optionally allow using an ArmaRssiFilter for faster distance calculation convergence.
• Support detection of Eddystone-UID, Eddystone-TLM and Eddystone-URL
• Support transmission of Eddystone-UID and other GATT-based formats
• Add more options for parsing identifiers of specific lengths
• When scanning in Background on Android 5+, do a full scan without filters during the main scan period (default for 10 seconds once every 5 minutes) in case scan filters are unavailable
• Common open-source BeaconParser layouts are defined as constants on BeaconParser
• Bluetooth address is now a field on Region, offering the option of monitoring and ranging for all beacon transmissions from a known device's MAC Address
• Target SDK bumped to 23 for Android 6.0
• Adds hardware accelerated detection of Eddystone frames in the background on Android 5+
• Provides ability to forward BLE scan callbacks for non-beacon advertisements

Bug Fixes:

• Workaround for 500 alarm limit on Samsung devices.
• Fix NPE in scanning for beacons on Lollipop in the emulator
• Restart scanning after app is killed due to memory pressure
• Protect against crashes when falling behind on scans
• Protect against null pointer exceptions in race conditions
• Protect against crash when stopping advertising with bluetooth turned off
• Stop BLE scanning after stopping ranging of the last region
• Fix for NPE on Galaxy Note 4
• Keep from getting stuck in background mode after stopping and restarting service
• Protect against Null Pointer Exceptions when dynamically adding and removing monitored/ranged regions
• Protect against an underlying Android BLE bug that sometimes causes Null Pointer Exceptions when starting stopping scanning.
• Ignore corrupted beacon BLE packets instead of throwing an exception about them
• Use a private ThreadPoolExecutor for beacon scanning to avoid thread starving apps using AsyncTask
• Allow missing data fields, setting data values to zero if data fields missing in packet
• If a custom AltBeacon parser is supplied, don't crash with NPE if it is not found
• Android 5.x devices could not detect AltBeacons on with unusual manufacturer codes in versions 2.3 and 2.3.1 due to Android 5.x BLE scan filters being inadvertently enabled in the foreground.
• Improve handling of PDUs with unexpected lengths.
• Add ability to optionally shorteten Beacon identifiers if their max length can be longer than the PDU.
• Fix improper termination of URLs on URI Beacons causing an extra byte to show up on the end.
• Identifer.parse("0") is now handled properly. A bug in the previous release did not handle it properly leading to ranging/monitoring failures on regions with such an identifier.
• Switch BeaconParsers list to be a CopyOnWriteArrayList to avoid UnsupportedOperationException changing list after starting scanning.
• Fix crash when region has more identifiers than beacon
• Fix bugs with compressing Eddystone-URL to bytes and back
• Allow Regions to match beacons with fewer identifiers if the extra region identifiers are null. This allows matching Eddystone-UID and Eddystone-URL beacon with the default Region with three null identifiers. This started failing in version 2.6.
• Declare the ACCESS_COARSE_LOCATION permission in the manifest since it is required for Android 6.0. This is helpful to keep beacon detection working on Android 6.0 for apps that don't explicitly declare this in their own manifest.
• Fix rescheduling of alarms in the distant future so they don't inadvertently go off right away

If you notice an issue...

Please help the community by logging any issues you find.

1. make sure that the issue hasn't already been logged against the original library
2. if the original library works correctly, log an issue against the Xamarin binding

Can't wait to hear about the cool apps you build!

I often see people on the Xamarin.Forms forums asking for a carousel-style control. We have the CarouselPage built in, but you can't resize the viewport or easily indicate which page you are viewing. I believe the official documentation even mentions that this control is mainly intended for Windows Mobile.

Thankfully, the power of Xamarin.Forms allows us to build our own.

Thanks to my friends at Firefly Logic and to Michael Watson for inspiring techniques that helped me create this custom control recipe.

The control is similar in functionality to the Xamarin.Forms CarouselPage - except the "pages" can be any type of content.

I have examples that show the CarouselView used as:

• A full-page control with no page indicators (like CarouselPage)
• A gallery-style control with dots as page indicators
• A full-page control with tabs as page indicators

Let's take a look at the different components.

Control

Probably the most important piece is the custom Xamarin.Forms control. There's a lot to look at, but I'll try to talk about the important bits.

The control itself inherits from ScrollView. We set the orientation to Horizontal and set the Content to a horizontal StackLayout. This should immediately tell you that the content will display horizontally allowing you to scroll to the parts not on screen.

We manage "pages" of data by creating a bindable IList property as our ItemsSource. Anytime we update the ItemsSource, we add our page items as children of the StackLayout.

We're close!

We should be able to load pages of data and scroll through the pages. What's lacking is that snap into place that we expect when swiping through pages of content. For that, we'll add a Renderer for each of our platforms.

Renderers: Snap Into Place

Our Xamarin.Forms control derives from the ScrollView which means that the native views at work are the Android.Widget.HorizontalScrollView and UIKit.UIScrollView. Each of these controls provide native methods for programatically scrolling to a given position.

The secret sauce in having our custom control pages snap into place is by doing a little math, then telling our native ScrollView controls to scroll to a position based on that math.

There are some other things at work, but I'll skip to the interesting parts:

Android

iOS

Pretty neat, right? We'll finish by pulling this together with page indicators.

Page Indicators

This is the interesting part, and the part missing from some other controls. The page indicators are just a horizontal StackLayout grouping of child elements -- one child element per page. My example shows a few different options:

• None: No page indicators. This behaves like the CarouselPage control.
• Dots: The page indicators appear as tiny dots. It is common to see this style of page indicators on gallery-style carousel layouts.
• Tabs: The page indicators appear as a tab bar with icons (and for iOS, text).

The dots are simply Buttons. As the ItemsSource changes, so does the number of dots.

The tabs are a bit more involved. As the ItemsSource changes, we clear all of the existing tabs, and make sure to draw new ones. Each tab is itself a StackLayout. If on iOS, you will get the icon and tab text. If on Android, you will only see the icon. These are typical patterns, but the code is customizable and can be configured in whichever way makes most sense for your application. Also, my example has hardcoded icon and text values, but these are easily configurable.

Putting It Together On Screen

This example has some conditional logic to handle the different page indicator styles, but generally I'm laying out the screen using a RelativeLayout.

You can make this as simple or complex as you need. If you look at the layout for Dots, I overlay the dots page indicator onto the carousel view content. This is a common pattern with gallery-style carousels.

This post is already TL;DR, and a lot of the details were left out. Hopefully, if nothing else, this recipe introduced some new and interesting ways to approach laying out your content.

To see the entire project with multiple examples, visit the GitHub repo.

James Montemagno recently blogged about More Material Design for Your Android Apps. In the post, James discussed two controls that he has built around Material Design components. One of the components is the Floating Action Button (FAB).

Let's see how we can pull this control into use with Xamarin.Forms.

Pull in the Component

Start with a new Xamarin.Forms application. In your Droid project, pull in the Floating Action Button control. You can use the Xamarin Component Store or Nuget Package Manager.

Build a Custom Control

For the FAB's properties to be bindable in Xamarin.Forms, we need a custom control with bindable properties.

We will then map each property to a corresponding property on the native FAB control.

Attach a Renderer

If we want to use a native control in Xamarin.Forms, we need a renderer. For simplicity, lets use a ViewRenderer. This renderer will map our custom FloatingActionButtonView to an Android.Widget.FrameLayout.

Pull it all Together

OK! We've built the custom control, and mapped it to a renderer. The last step is laying out the control in our view.

You can pull the completed sample application from GitHub.

Recently, Xamarin released major updates to its iOS and Forms platforms in order to support 32/64-bit architectures from a Unified API.

These updates came across as Stable Channel updates in Xamarin Studio (or Visual Studio) which included version 8.6 of the Xamarin.iOS platform.

Suddenly, our existing Xamarin.Forms iOS app started crashing at runtime with an error similar to the one below:

Unable to cast object of type 'Xamarin.Forms.Platform.iOS.ActivityIndicatorRenderer' (Objective-C type: 'Xamarin_Forms_Platform_iOS_ActivityIndicatorRenderer') to type 'Xamarin.Forms.Platform.iOS.ViewRenderer`2'.
Additional information:
Selector: layoutSubviews
Method: Xamarin.Forms.Platform.iOS.ViewRenderer`2:LayoutSubviews ()

Why?

Turns out, a configuration that we set months ago to remedy an issue with some 3rd party libraries was both no longer necessary and was causing a conflict with the new Xamarin.iOS release.

Read more about Type Registrar on Xamarin.iOS

The important bit for us was to remove
<MtouchExtraArgs>--registrar:legacy</MtouchExtraArgs>
from the iOS project file. This can be done by manually editing the .csproj file or in the IDE by editing the
iOS Build Options > Advanced > Additional mtouch arguments.

If you've been looking for a way to develop your Xamarin Android apps in a Parallels Desktop Windows VM, but run the app in an Android emulator on your Mac, this post is an attempt to distill the information from across multiple sites to get you started.

Many thanks to James Montemagno for pointing me to Paul Batum's post on the Xamarin forum.

My Configuration

• Intel MBP running OS X Mavericks
• Parallels Desktop running a Windows 8 VM

Set up your Mac

1. Download & Install the Android SDK

Nothing can get done until the Android SDK is installed, so let's start there.

Install the Android SDK

You should end up with an SDK directory somewhere on your Mac with subdirectories like: extras, platform tools, tools, etc.

Yeah? -- Okay. Next.

2. Install the Intel HAXM

Intel HAXM - What?

Intel Hardware Accelerated Execution Manager. In short, it speeds up Android app emulation on Intel host machines. This step is necessary if you plan on creating custom AVDs that leverage the much faster Intel x86 images.

Install the Intel OS X HAXM Zip

Do you use OS X Mavericks + Parallels Desktop 9 ?

Install the OS X 10.9 HAXM Hotfix

If you don't do this, when you launch an Intel x86 emulator image, your entire computer will freeze up forcing you to perform a hard reboot. No one wants that.

3. Configure your Mac for SSH sharing

In OS X Go To:
System Preferences > Sharing > Enable Remote Login

Leave the other options set to their defaults.

4. Start the Android emulator

Several AVDs came pre-configured when you installed the Android SDK. For the sake of this tutorial, we'll use one of those devices which use ARM images. To view the configured devices, start the AVD Manager:

• Open a command line

• Navigate to the tools directory of your Android SDK: yourandroidsdkdirectory/tools

• Enter the following command:

  ./android avd

• The AVD Manager will open

Start an Android device:

• select a device with a green check
• press Start...
• the Launch Options dialog will appear. Press Launch

Earlier, we installed HAXM which allows the use of the Intel x86 images which run much faster than their ARM counterparts. If you'd like to try those out: open the SDK Manager, download the x86 images, then configure devices in the AVD Manager to use the x86 images instead of the ARM images.

• Open a command line

• Navigate to the tools directory of your Android SDK: yourandroidsdkdirectory/tools

• Enter the following command:

  ./android

• download the x86 images

• edit a device in the AVD Manager to use an x86 image instead of an ARM image

5. Kill the ADB Server

• Open a command line

• Navigate to the platform-tools directory of your Android SDK: yourandroidsdkdirectory/platform-tools

• Enter the following command:

  ./adb kill-server

Okay! -- Your Mac is ready.

Set up you Windows VM

1. Start your Windows VM in Parallels Desktop

2. Download and install PuTTY SSH Client

Install the PuTTY SSH Client

3. Create a new connection to your Mac

Let's connect to the Mac.

• Start PuTTY SSH Client
• Select Session from the Category panel on the left
• In the Host Name (or IP Address) field, enter the IP Address of you Mac (found at: System Preferences > Sharing)
• Leave the Port set to its default (should be 22)
• Make sure SSH is selected under Protocol

4. Configure port forwarding

Select Connection > SSH > Tunnels from the Category panel on the left side of the PuTTY SSH Client. From here add two forwarding configurations.

First

• Source Port: 5555
• Destination: localhost:5555

Second

• Source Port: 5554

• Destination: localhost:5554

• Click on Open

You will be presented with a command line console. When prompted, enter your Mac admin username and password to open a connection from your Windows VM to OS X.

5. Kill then Start the ADB Server

• Open a command line

• Navigate to the platform-tools directory of your Android SDK: yourandroidsdkdirectory/platform-tools

• Enter the following command:

  adb.exe kill-server

• Then enter the following command:

  adb.exe start-server

• Confirm that your Mac emulator device has been picked up by entering the following command:

  adb.exe devices

• You should see a device listed something like: emulator-5554

6. Open a Xamarin Android project

Now for the big test!

Launch your Xamarin IDE of choice and open a Xamarin Android project. Once the project initializes, you should see your already running Mac emulator listed in the device dropdown.

And that's it! -- You can debug all day long from Parallels over to your Mac.

The Bonus Round - Genymotion Emulator

The AVD emulator that comes with the Android SDK is fine, but it could be better. Enter Genymotion.

The Genymotion emulator is noticably faster, but it requires some baggage: VirtualBox - which doesn't play well with Parallels Desktop 9 out of the box.

[Detailed tutorial coming soon]