I've been a big fan of Estimote (and beacons in general) for awhile now, but only just recently had a chance to finally play around with their nearables, dubbed Estimote Stickers. These stickers are similar to beacons, except that their primary purpose is to be attached to physical objects, and in addition to proximity also broadcast more contextual information about the object. This extra information contains a bunch of interesting details such as temperature, orientation, and motion in three dimensions.

Getting Started

With these stickers in my possession, the first step was seeing what was involved in getting set up with Estimote's SDK for interacting with the stickers. Thankfully this is as trivial as it gets. Simply head over to the Xamarin Component Store, grab the components for iOS and Android, and you're good to go!

iOS

With that installed, it's just as easy to start detecting nearables:

var manager = new NearableManager();

manager.RangedNearables += (sender, e) =>
{
	foreach (var nearable in e.Nearables ?? Enumerable.Empty<Nearable>())
	    Console.WriteLine(nearable);
};
manager.StartRangingForType(NearableType.All);

On iOS8+ you also need to specify a value for NSLocationAlwaysUsageDescription or NSLocationWhenInUseUsageDescription in your Info.plist file in order to get access to the iOS location APIs, which Estimote sits on top of.

If you're only looking for a specific nearable type you can alternatively specify that in the call to StartRangingForType(), instead of always scanning for all types. Other types available as of right now include Dog, Fridge, Door, Generic, and more. That's all you need to initiate basic scanning for nearables, and you will get access to all the discovered nearables in the RangedNearables callback.

Android

The Android SDK is also easy to get up and running with, though I do find it a bit lacking compared to the iOS one (more on that later). Here is an activity that starts scanning for nearables when it loads up:

[Activity(Label = "Nearables!", MainLauncher = true, Icon = "@mipmap/icon")]
public class MainActivity : Activity, BeaconManager.IServiceReadyCallback
{
    private BeaconManager _beaconManager;

    protected override void OnCreate(Bundle savedInstanceState)
    {
        base.OnCreate(savedInstanceState);

        _beaconManager = new BeaconManager(this);
        _beaconManager.Nearable += (sender, e) =>
        {
            foreach (var nearable in e.Nearables ?? Enumerable.Empty<Nearable>())
                Console.WriteLine(nearable);
        };

        _beaconManager.Connect(this);
    }

    public void OnServiceReady()
    {
        _beaconManager.StartNearableDiscovery();
    }
}

Easy enough. Where on iOS we were able to limit scanning by nearable type, that doesn't seem to be exposed in the Android SDK. In Fact, despite there being a NearableType enum in the SDK, that doesn't even seem to be exposed as a property on a Nearable object.

Triggers

One of the other nice things about the iOS SDK that is not currently available in the Android SDK is the ability to specify rules and triggers for when you get a callback from a nearable. While it's not the end of the world to have to compose these things by hand, this makes it trivial to define the scenarios you care about in your apps.

For example, let's say you attached the Dog sticker to your dog and wanted to detect when the dog rolled over. All you need to do is define an orientation rule for that nearable type and create a trigger based on it:

var triggerManager = new TriggerManager();
    
var dogRollsOverRule = OrientationRule.OrientationEquals(NearableOrientation.HorizontalUpsideDown, NearableType.Dog);
var dogRollsOverTrigger = new Trigger(new [] { dogRollsOverRule }, "dog rolls over");

triggerManager.ChangedState += (sender, e) => 
{
    if (!e.Trigger.State)
        return;

    if (e.Trigger.Identifier == dogRollsOverTrigger.Identifier)
        new UIAlertView(null, "dog rolled over", null, "Ok", null).Show();
};

triggerManager.StartMonitoringForTrigger(dogRollsOverTrigger);

In the ChangedState callback, e.Trigger.State indicates whether the trigger is currently active.

In addition to OrientationRule there are several other built-in rules you can use, such as DateRule, ProximityRule, TemperatureRule, and MotionRule. You can also define your own rule classes that create any scenarios you'd like.

Composing Rules

You're also not limited to a single rule for a trigger, so you can compose multiple rules together to form a more interesting scenario. Let's say that you attached a sticker to your refrigerator and want to detect when it opens late at night to cut back on late night snacking. With Estimote's trigger API this is trivial:

var fridgeDoorMovesRule = MotionRule.MotionStateEquals(true, NearableType.Fridge);
var afterMidnightRule = DateRule.HourBetween(0, 5);
var lateNightSnackingTrigger = new Trigger(new Rule[] { fridgeDoorMovesRule, afterMidnightRule }, "fridge door moves after midnight");

triggerManager.ChangedState += (sender, e) => 
{
    if (!e.Trigger.State)
        return;

    if (e.Trigger.Identifier == lateNightSnackingTrigger.Identifier)
        new UIAlertView(null, "late night snacking!", null, "Ok", null).Show();
};

triggerManager.StartMonitoringForTrigger(lateNightSnackingTrigger);

Simply compose a DateRule with a MotionRule and you're done!

Summary

Obviously this just scratches the surface of what you can do with nearables, but the exciting part to me is how easy it is to build smart, contextual experiences. Estimote is an awesome company as well, so I suspect they will close the SDK gaps between iOS in Android over time to make things easy across the board.

It's no secret that I'm a big proponent of testing, and lately I've been getting a lot of questions around how to approach getting started and what technologies to use. While I have a good amount of content coming out around this, some already announced, some to be announced soon, I thought I would also try to take some time to put together a few posts on the subject as well.

In this post I'm going to focus on setting up unit testing for Xamarin apps using the xUnit framework. If you've followed my testing content in the past, you might remember me recommending the usage of NUnitLite a few years back as the framework of choice. At the time that was the best option, but these days xUnit has a far superior cross-platform story (major props to Oren Novotny for helping drive that forward!), in addition to just being a more modern framework in general. The biggest downside, at least at the time of writing this, is that there isn't any sort of integration with Xamarin Studio, but hopefully that story will improve as well.

Creating The Test Project

To start off, create a portable class library for your tests to live in. Alternatively you could also go with a shared project if you'd prefer, but unless you need it I recommend sticking with a PCL. Using a PCL will enable you to easily run the tests in any xUnit test runner, such as Visual Studio, the command line, iOS, Android, or Windows Phone.

Once that's created, add the xUnit.net NuGet package:

As of the time of this post I recommend installing the pre-release version of xUnit, as pictured here, which brings with it improved Mono support. Similiarly, Xamarin's Alpha channel currently ships with an updated version of Mono that improves xUnit support. Both of these should hit the stable channels soon so this recommendation will be short-lived, but I wanted to point it out in the meantime.

In addition to the main xUnit package, also go ahead and install the console runner package. If you'd also like to run the tests in Visual Studio, you can add the Visual Studio runner package as well.

With those installed, let's create some tests:

using System;
using System.Threading.Tasks;
using Xunit;

namespace TestDemo
{
    public class TestsAreGood
    {
        [Fact]
        public void ThisShouldPass()
        {
            Assert.True(true);
        }

        [Fact]
        public async Task ThisShouldFail()
        {
            await Task.Run(() => { throw new Exception("boom"); });
        }
    }
}

Obviously these are pretty trivial, but as you can see xUnit has support for async tests. In fact, it has much better support for async tests than the version of NUnit that ships with Mono/Xamarin Studio, which is another awesome advantage to going with xUnit.

Runner: Console

Now that we have tests, let's start by running them from the console:

> mono packages/xunit.runner.console.2.1.0-rc2-build3176/tools/xunit.console.exe TestDemo/bin/Debug/TestDemo.dll

xUnit.net Console Runner (32-bit .NET 4.0.30319.17020)
  Discovering: TestDemo
  Discovered:  TestDemo
  Starting:    TestDemo
    TestDemo.TestsAreGood.ThisShouldFail [FAIL]
      System.Exception : boom
      Stack Trace:
        <trimmed>
  Finished:    TestDemo
=== TEST EXECUTION SUMMARY ===
   TestDemo  Total: 2, Errors: 0, Failed: 1, Skipped: 0, Time: 0.100s

As expected, we had one test pass and one fail. I suggest creating a script to allow you to easily and quickly run these tests to lower the friction to running the tests going forward. You could even set up a monitor on the DLL file and automatically re-run your tests each time you compile!

Runner: iOS

The console runner is great and all, but we're doing mobile development here, so it really only matters if our code works in that environment. Lucky for us the xUnit cross platform story is awesome, so it's nice and easy to get these tests running there as well.

Start off by creating a new single view iOS project, and then delete the generated storyboard and view controller files. Also make sure go into your Info.plist file and remove the "main interface" references to the storyboard. Next, add a project reference to the main PCL test project from before.

With that set up, add the xUnit.net for Devices NuGet package:

That NuGet package will add a new file to your solution named AppDelegate.cs.txt. Go ahead and copy the contents of that file and replace the contents of AppDelegate.cs with it. After that you can go ahead and delete the AppDelegate.cs.txt file if you like.

if you take a look in the code now in AppDelegate.cs, you'll see some references to a function named AddTestAssembly(). This is what you can use to tell xUnit which assemblies to scan for tests. By default it will include an instruction to scan the current assembly, but in our case that won't return anything since our tests are in a separate library. If you had been using a shared code project, this default scan would be sufficient.

Replace the existing AddTestAssembly() call with:

AddTestAssembly(typeof(TestsAreGood).Assembly);

Set the iOS project as the solution's startup project and run it:

Your tests are now running in iOS without having to change anything! You can run them either in the simulator or on a device to validate that your code truly works across the board.

Runner: Android

With iOS out of the way, let's also get these tests running on Android. The process here is very similar to setting up iOS. Create a new Android project, add a reference to the test library, and add the same xUnit.net for Devices NuGet package that we added to iOS.

Just like with iOS, the package will add a MainActivity.cs.txt file to your solution. Take the contents of that file and overwrite what's in MainActivity.cs. Update the AddTestAssembly() call in there with the same line as before:

AddTestAssembly(typeof(TestsAreGood).Assembly);

Set the Android runner as the startup project, fire up your favorite emulator or device, and voilà!

Summary

Setting up these runners are just a one-time thing, as they will continue to pick up new tests you add each time you run them. With just a few minutes of effort you can set up an environment where not only can you verify that your code runs properly on the full .NET or Mono frameworks, but also that they run on the device environments that really count here. In future posts I'll explore some other tips for unit testing your apps, as well as step into other areas like UI testing, Test Cloud, and more.

With the release of Android 5.0, also known as Lollipop, Google introduced its new material design style.

Material Design is a huge step forward for Android apps, bringing with it a total overhaul of theming, as well as a bunch of new UI components you can use in your apps. To make things even better, Google also released the Android Design Support Library, which allows you to take advantage of material design in versions of Android going all the way back to Android 2.1.

In this article I'll walk-through some of the new components available in this library, and show how easy they are to introduce into an app.

Read the rest of the article over at Visual Studio Magazine.

In my last post I talked about one of the roadblocks I hit when upgrading to Android's new ActionBarActivity. That was definitely a major pain, but there's one other issue I've run into so far that I wanted to call attention to as well. This one didn't cost us nearly as much time as that last one did, but it was certainly unexpected.

Our apps make use of a single activity and fragments for each separate screen within the app. After updating this activity to extend from ActionBarActivity we noticed that suddenly the hardware back button was causing the host activity to finish, even when there were multiple fragments in the backstack. Prior to this change we could rely on the hardware back button to pop fragments off the stack first, and only finish the activity if there was nothing left in the stack.

I figured this was just a documented change, but a look at Android's documentation for onBackPressed() says:

Take care of popping the fragment back stack or finishing the activity as appropriate.

This description lines up with the behavior I would have expected, but unfortunately the observed behavior is not the same.

The fix for this in the host activity is simple enough:

public override void OnBackPressed()
{
    if (FragmentManager.BackStackEntryCount > 0)
        FragmentManager.PopBackStack();
    else 
        base.OnBackPressed();
}

All in all it's certainly not the end of the world to add this small amount of code to work around the issue here. I was just surprised by the change in behavior, and wanted to call attention to it in case it helps one of you solve the issue in your apps before they make it out to the Play store.

As part of updating our apps to use the latest Android support library to bring in some of the nice material design classes in there, we also started switching over to using a Toolbar as our action bar. If you're just getting started in making the same upgrades in your app I suggest starting with this excellent post on Xamarin's blog that outlines what you need to do.

Getting things migrated was easy enough but we unexpectedly hit some snags in trying to customize the color of the back button shown in the upper left of the toolbar consistently across Android versions. After spending far longer on this than I'd care to admit and countless permutations of styles and settings, I wanted to share what we settled on in hopes of saving someone else that pain. I also want to give my colleague Sasha a hat tip here because when I say that "we" went through some pain here, I mostly mean her.

Our Solution

After some digging we ended up on this Stackoverflow post that offers a variety of potential solutions to the problem. Our initial preference was to keep things contained entirely in the style XML. This answer seemed promising, but despite working in Android 4.x, Lollipop always seemed to completely ignore anything we set. Frustrating.

Feeling defeated, we opted to try the code solution mentioned in this answer. Success! A bit hacky, but hey, it works. #yolo

Translated to Xamarin.Android it looks like this:

var upArrow = Resources.GetDrawable(Resource.Drawable.abc_ic_ab_back_mtrl_am_alpha);

upArrow.SetColorFilter(Resources.GetColor(Resource.Color.actionbartext), PorterDuff.Mode.SrcIn);

SupportActionBar.SetHomeAsUpIndicator(upArrow);

On a related note, that has to be one of the worst named resources I've ever seen.

But Wait, There's More

Unfortunately that wasn't where the pain ended for us. Our apps make use of a DrawerLayout, where on the root view of the app the home indicator in the toolbar is the standard menu icon. As you navigate away from the root view the indicator changes to the back button we just talked about. Our host activity monitors for changes to the fragment backstack and updates this indicator accordingly. Despite having set the color filter earlier, we found that it was being lost and defaulting back to black.

The culprit? Updating the DrawerIndicatorEnabled property on our ActionBarDrawerToggle, which resets this drawable to the value set by the theme. Since we're doing the tinting in code, we just needed to make sure to reset the indicator when showing it. The resulting code boils down to something like this:

FragmentManager.BackStackChanged += (sender, e) =>
{
    if (FragmentManager.BackStackEntryCount == 0)
    {
        _drawerToggle.DrawerIndicatorEnabled = true;
    }
    else
    {
        _drawerToggle.DrawerIndicatorEnabled = false;
        
        SupportActionBar.SetHomeAsUpIndicator(upArrow);
    }
};

There are undoubtedly ways to solve this more elegantly, but this approach is working well enough for us for the time being. It also passed a run through Test Cloud to try and smoke out any version/device incompatibilities. All that to change the color of a button...Android is fun sometimes.

Previously in this column, I've written about unit testing iOS apps, but what can you do when unit tests just won't cut it? If you're a Web developer you're probably already familiar with libraries like Selenium, which allow you to drive automated testing of your Web app's front-end.

Xamarin offers a library named Xamarin.UITest that enable the similar possibilities for your iOS and Android apps. In addition to being able to run those tests locally on an emulator or device, you can even push the same tests out to Xamarin's Test Cloud, allowing you to validate your tests across more than a thousand different devices.

Read the full article over on Visual Studio Magazine

Like many others right now, we're in the process of migrating our testing infrastructure from TestFlight to HockeyApp before the TestFlight shutdown next week. As we did in the past with Xamarin and HipChat, we also open sourced the FAKE helper we made for uploading builds to HockeyApp.

For example, to upload a build to HockeyApp and then send a notification to a room in HipChat you can do:

HockeyApp (fun p ->
  {p with 
    ApiToken = Environment.GetEnvironmentVariable("HockeyAppApiToken")
    File = ipaOrApkPath
  })
|> fun response ->
    HipChatNotification(fun p ->
      {p with 
          AuthToken = Environment.GetEnvironmentVariable("HipChatAuthToken")
          RoomId = Environment.GetEnvironmentVariable("HipChatNotificationRoom")
          Message = ("Successfully deployed to HockeyApp: " + response.ConfigUrl)
          Color = "green"
      }) |> ignore

As part of the transition, we created an organization for the company, and a couple teams within that organization. We then proceeded to run into a few stumbling blocks in getting things working properly, which I wanted to share to hopefully help others avoid the aggravation we went through. It's also entirely possible that we were just doing something wrong or missing something entirely - if that's the case, please do let me know!

API Tokens and Ownership

All of our uploads happen through automated CI builds, so the next thing we did was go to create an API token to use. I was a little disappointed to see that API tokens are managed at the user level, rather than the organization. It's not the end of the world, but it would be nicer if that lived under the organization so that multiple people can manage the same tokens.

The main problem we hit as a result of this is that builds uploaded using this API token would be tied to the user that created the key and not the organization. This makes sense based on the fact that the token is tied to a user and not the organization, but the documentation for uploading a build makes no mention of a way to set the owner for an app. It's possible to transfer the app to the organization on the website through a series of somewhat clunky steps, but this really wouldn't scale well for the volume of apps we process in our system.

Thankfully when I raised the question on Twitter earlier today, HockeyApp was nice enough to respond very quickly with a way to achieve what we needed. The solution is to pass in an owner_id parameter with the upload payload, which can be used to set the owner for the app using its ID. You can get the ID out of the URL when viewing the organization on the site. Here's what that looks like in cURL syntax:

-F "owner_id=3141592" \

Hopefully they add this to their documentation soon. We'll also be publishing an update to the FAKE helper soon that will include the ability to set this ID from your build scripts.

Visibility to Users

Once we got the organization ownership working the next thing we realized was that despite our assumptions, the builds weren't visible to anyone else on my team, despite the fact that I'd added them to the Owners team. There are a couple ways you can go here. First, HockeyApp does have an endpoint at /api/2/apps/APP_ID/app_teams/ID that you can use to assign a team to an app programmatically. This is fine, but what we really wanted was for people in the owners group to automatically get access to everything.

After some digging we came across this checkbox when you're adding/editing an owner for an organization:

Somehow we'd overlooked that option when initially setting things up. Personally I think this should be the default behavior, since to me an "owner" should be someone with full admin rights across the organization.

Overall things seem to work pretty well in HockeyApp but the user experience definitely leaves quite a bit to be desired, especially given that it's a paid product. Hopefully we'll see some nice updates coming to HockeyApp in the coming months now that they're part of Microsoft.

In my last couple posts on this subject I've mentioned using fragments on Android for navigation. By default MvvmCross will use activities on Android, but as I hope you've learned by now, you can use presenters to customize this sort of thing as much as you'd like. I've found it very difficult (or impossible) to properly achieve the types of fine-grained navigation control I want in my apps by using activities for all my views, which is one of several reasons I've switched to using fragments for everything.

Ultimately what this ends up looking like is somewhat similar to a Single Page Application on the web: a single container activity with a fragment stack containing the actual views of the app. You can mix and match here if you'd like too, as I'll show later in my sample presenter.

Views and View Models

First let's quickly set up the basic app essentials here, starting with the view models:

using Cirrious.MvvmCross.ViewModels;

namespace PresenterDemo.Core.ViewModels
{
    public class FirstViewModel : MvxViewModel
    {
		public IMvxCommand NavigateCommand
		{
			get { return new MvxCommand(() => ShowViewModel<SecondViewModel> ()); }
		}
    }

    public class SecondViewModel : MvxViewModel
	{
	}
}

Nothing crazy here, just a view model that can navigate to a second view model. Next we'll define the view markup, starting with FirstView.axml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:local="http://schemas.android.com/apk/res-auto"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <Button
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Navigate"
        local:MvxBind="Click NavigateCommand" />
</LinearLayout>

and SecondView.axml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:local="http://schemas.android.com/apk/res-auto"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Second view" />
</LinearLayout>

As I mentioned earlier, the app will use a single activity that hosts the fragments, so we'll also define a layout named Container.axml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:local="http://schemas.android.com/apk/res-auto"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <FrameLayout
        android:id="@+id/contentFrame"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
</LinearLayout>

Finally we need our fragments:

using Android.OS;
using Android.Views;
using Cirrious.MvvmCross.Binding.Droid.BindingContext;
using Cirrious.MvvmCross.Droid.FullFragging.Fragments;

namespace PresenterDemo.Droid
{
	public class InitialFragment : MvxFragment
	{
		public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
		{
			base.OnCreateView(inflater, container, savedInstanceState);

			return this.BindingInflate(Resource.Layout.FirstView, null);
		}
	}

	public class SecondView : MvxFragment
	{
		public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
		{
			base.OnCreateView(inflater, container, savedInstanceState);

			return this.BindingInflate(Resource.Layout.SecondView, null);
		}
	}
}

I'll get back to the activity itself a little later.

Fragment Lookup

As with most things there are an endless number of ways you can implement this sort of thing, but in this example we're going to create a class that scans the assembly for fragment views and create a mapping that can be used to match them up with view models by name. This will follow the standard convention of matching a FooViewModel view model with a view named FooView.

using System;
using System.Collections.Generic;
using System.Linq;
using Cirrious.CrossCore.IoC;
using Cirrious.MvvmCross.Droid.FullFragging.Fragments;

namespace PresenterDemo.Droid
{
	public interface IFragmentTypeLookup
	{
		bool TryGetFragmentType(Type viewModelType, out Type fragmentType);
	}

	public class FragmentTypeLookup : IFragmentTypeLookup
	{
		private readonly IDictionary<string, Type> _fragmentLookup = new Dictionary<string, Type>(); 

		public FragmentTypeLookup()
		{
			_fragmentLookup = 
				(from type in GetType().Assembly.ExceptionSafeGetTypes ()
			     where !type.IsAbstract 
					&& !type.IsInterface 
					&& typeof(MvxFragment).IsAssignableFrom(type)
					&& type.Name.EndsWith("View")
			     select type).ToDictionary(getStrippedName);
		}

		public bool TryGetFragmentType(Type viewModelType, out Type fragmentType)
		{
			var strippedName = getStrippedName(viewModelType);

			if (!_fragmentLookup.ContainsKey(strippedName))
			{
				fragmentType = null;

				return false;
			}

			fragmentType = _fragmentLookup[strippedName];

			return true;
		}

		private string getStrippedName(Type type)
		{
			return type.Name
					   .TrimEnd("View".ToCharArray())
					   .TrimEnd("ViewModel".ToCharArray());
		}
	}
}

The Presenter

With that mapping implemented, now we can actually work on the presenter itself. This implementation will keep things simple, but you could easily extend it with fancier navigation patterns like the ones shown in previous posts here. Let's start with the basic outline for the class:

using System;
using Android.App;
using Cirrious.MvvmCross.Droid.FullFragging.Fragments;
using Cirrious.MvvmCross.Droid.Views;
using Cirrious.MvvmCross.ViewModels;

namespace PresenterDemo.Droid
{
	public class DroidPresenter : MvxAndroidViewPresenter
	{
		private readonly IMvxViewModelLoader _viewModelLoader;
		private readonly IFragmentTypeLookup _fragmentTypeLookup;
		private FragmentManager _fragmentManager;

		public DroidPresenter(IMvxViewModelLoader viewModelLoader, IFragmentTypeLookup fragmentTypeLookup)
		{
			_fragmentTypeLookup = fragmentTypeLookup;
			_viewModelLoader = viewModelLoader;
		}
	}
}

The presenter takes in the fragment mapping and a view model loader as dependencies, which can be used later during navigation to inflate the proper fragments.

Now, this next part is the one thing here that feels somewhat dirty, but its scope is pretty limited. Since the container activity is what is going to be started initially, we'll make it so that activity has some knowledge of the presenter, and registers its fragment manager and an initial fragment to show with the presenter:

public void RegisterFragmentManager(FragmentManager fragmentManager, MvxFragment initialFragment)
{
	_fragmentManager = fragmentManager;

	showFragment(initialFragment, false);
}

This isn't quite as clean of a separation as you get on iOS, but it's not bad. Next we'll handle when a new view model request comes in:

public override void Show(MvxViewModelRequest request)
{
	Type fragmentType;
	if (_fragmentManager == null || !_fragmentTypeLookup.TryGetFragmentType(request.ViewModelType, out fragmentType))
	{
		base.Show(request);

		return;
	}
		
	var fragment = (MvxFragment)Activator.CreateInstance(fragmentType);
	fragment.ViewModel = _viewModelLoader.LoadViewModel(request, null);

	showFragment(fragment, true);
}

The main thing to notice here is that if no corresponding fragment is found in the map, we fall back to the base presenter's implementation. This means that if a request comes in for ThirdViewModel, it will actually go look for an activity named ThirdView, since it won't match anything in the fragment type map. This allows you to switch between activities and fragments if you wish.

Both of these last two methods call a private method to actually show the fragment:

private void showFragment(MvxFragment fragment, bool addToBackStack)
{
	var transaction = _fragmentManager.BeginTransaction();

	if (addToBackStack)
		transaction.AddToBackStack(fragment.GetType().Name);

	transaction
		.Replace(Resource.Id.contentFrame, fragment)
		.Commit();
}

For the initial fragment we don't want to add it to the backstack, because then you'd be able to hit back on the initial view and see an empty screen, rather than back out of the app as expected. This is also where you could add things like transition animations if you wanted.

Finally, we need to handle when Close requests come in:

public override void Close(IMvxViewModel viewModel)
{
	var currentFragment = _fragmentManager.FindFragmentById(Resource.Id.contentFrame) as MvxFragment;
	if (currentFragment != null && currentFragment.ViewModel == viewModel)
	{
		_fragmentManager.PopBackStackImmediate();

		return;
	}

	base.Close(viewModel);
}

Again, this implementation allows for mixing fragments and activities. If the request comes in from the current fragment it will be popped off the stack, but if not it will defer to the base implementation to close the view model.

Wiring It Up

Now all that's left is to wire up our dependencies and connect the activity to the presenter:

using Android.Content;
using Cirrious.CrossCore;
using Cirrious.MvvmCross.Droid.Platform;
using Cirrious.MvvmCross.Droid.Views;
using Cirrious.MvvmCross.ViewModels;

namespace PresenterDemo.Droid
{
    public class Setup : MvxAndroidSetup
    {
        public Setup(Context applicationContext) : base(applicationContext)
        {
        }

        protected override IMvxApplication CreateApp()
        {
            return new Core.App();
        }

		protected override IMvxAndroidViewPresenter CreateViewPresenter()
		{
			var presenter = Mvx.IocConstruct<DroidPresenter>();

			Mvx.RegisterSingleton<IMvxAndroidViewPresenter>(presenter);

			return presenter;
		}
		
		protected override void InitializeIoC()
		{
			base.InitializeIoC();

			Mvx.ConstructAndRegisterSingleton<IFragmentTypeLookup, FragmentTypeLookup>();
		}
    }
}

With that in place we can create our container activity and connect the presenter:

using Android.App;
using Android.OS;
using Cirrious.CrossCore;
using Cirrious.MvvmCross.Droid.Views;

namespace PresenterDemo.Droid.Views
{
	[Activity(Label = "Presenter Demo", 
			  MainLauncher = true,
		      Icon = "@drawable/icon")]
    public class FirstView : MvxActivity
    {
        protected override void OnCreate(Bundle bundle)
        {
            base.OnCreate(bundle);

            SetContentView(Resource.Layout.Container);

			var presenter = (DroidPresenter)Mvx.Resolve<IMvxAndroidViewPresenter>();
			var initialFragment = new InitialFragment { ViewModel = ViewModel };

			presenter.RegisterFragmentManager(FragmentManager, initialFragment);
        }
    }
}

In this example we simply pass the view model from the activity into the first fragment, but you could customize this as necessary of course.

That's all you need to set up basic fragment-based navigation in your Android apps. I highly recommend using fragments when possible, both for the flexibility around navigation and also just for the ability for reuse in different layout configurations. There are a number of different approaches to fragment presenters out there, but I wanted to share one approach I've found that has worked very well in my apps and has given me a lot of flexibility.

In my last presenter post I showed how you can use presentation hints to tell the presenter to clear the view stack prior to showing the next view. That is probably the most common custom navigation pattern I've seen used in MvvmCross apps, but I also wanted to note another similar pattern I've used as well.

When I'm mapping out the navigation paths through my apps, I try to be very conscious of the state of the back stack at any given time. Often navigation through an app is pretty linear which makes this a non-issue, but it's also easy to come across scenarios that are more problematic. Using our apps as an example, once you have a basket in progress the app will show you a persistent shortcut in the top bar that will bring you back to it from anywhere in the app. Once you do so, you end up on a screen that lets you perform some different actions, one of which is the option to return to the menu to add more items. During the initial flow through the app this would simply mean going back one screen in the stack, but if the user just jumped here from somewhere else, that view doesn't exist on the stack.

To solve this we introduced the presentation concept of navigating "back or in place". This tells the presenter to start by checking the back stack for the existence of a view of the same type we're navigating to. If found, it rewinds the stack back to that view. If not found, it pops the current view, then creates and navigates to the destination view. This allows us to map out any paths we want through the app without needing to sorry about showing the other views first.

Navigating with this mode is handled the same way shown in the last post:

var presentationBundle = new MvxBundle(new Dictionary<string, string> { { "NavigationMode", "BackOrInPlace" } });

ShowViewModel<MyViewModelType>(presentationBundle: presentationBundle);

iOS

Here's what the implementation on iOS might look like:

public override void Show(MvxViewModelRequest request)  
{
    if (request.PresentationValues != null)
    {
        if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "BackOrInPlace")
        {
        	var nextViewController = (UIViewController)_viewCreator.Value.CreateView(request);
			var existingViewController = MasterNavigationController.ViewControllers.FirstOrDefault(vc => vc.GetType() == nextViewController.GetType() && vc != CurrentTopViewController);

			if (existingViewController != null)
			{
				MasterNavigationController.PopToViewController(existingViewController, true);
			}
			else
			{
				var transition = new CATransition
				{
					Duration = 0.3,
					Type = CAAnimation.TransitionPush,
					Subtype = CAAnimation.TransitionFade
				};

				MasterNavigationController.PopViewControllerAnimated(false);
				MasterNavigationController.View.Layer.AddAnimation (transition, null);
				MasterNavigationController.PushViewController(nextViewController, false);
			}

			return;
		}
    }

    base.Show(request);
}

In cases where the target view isn't already in the stack, this will provide a little fade transition into the new view, rather than making it look like a normal navigation push. I find this to be a nice visual cue to the user on what happened, and avoid the expectation that the previous view is still there on the back stack.

Android

The implementation looks pretty similar on Android, except that again we're using fragments to give us finer control over the stack:

public override void Show(MvxViewModelRequest request)  
{
    if (vmRequest.PresentationValues != null)
    {
        if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "BackOrInPlace")
        {
        	var hasFragmentTypeInStack = 
                Enumerable.Range(0, _fragmentManager.BackStackEntryCount - 1)
                          .Reverse()
                          .Any(index => _fragmentManager.GetBackStackEntryAt(index).Name == fragmentType.Name);

            if (hasFragmentTypeInStack)
            {
                while (CurrentFragment.GetType() != fragmentType)
                    _fragmentManager.PopBackStackImmediate();

                return;
            }

            _fragmentManager.PopBackStackImmediate();
		}
    }

    // ...
}

This is just one example of what you might want to do with the back stack in your apps. I encourage you to think about the state of the stack as you build up navigation flows through your apps, in order to provide the most sensible experience possible for users.

As shown in my last post, a MvxViewModelRequest contains a dictionary named PresentationValues that can be very useful in passing around data that your presenter might find useful. Let's say you that in your view model you know that when you request to show a view model you know that you want to clear the app's back stack before showing it, such as after a login operation so that the login screen is no longer in the stack.

All overloads of ShowViewModel() in MvvmCross contain an optional IMvxBundle parameter named presentationBundle. It's easy to create a bundle from a dictionary and then pass that into the show request:

var presentationBundle = new MvxBundle(new Dictionary<string, string> { { "NavigationMode", "ClearStack" } });

ShowViewModel<MyViewModelType>(presentationBundle: presentationBundle);

When your platform's presenter gets that request, the values you passed in with the presentation bundle will be available in the PresentationValues property described earlier. With that in place, let's implement the clear operation on both iOS and Android.

iOS

For this example I'm going to assume the presenter inherits from the standard MvxTouchViewPresenter class provided in MvvmCross, which manages a UINavigationController stored in a property named MasterNavigationController. All our presenter needs to do is detect the hint we sent in the request and react accordingly:

public override void Show(MvxViewModelRequest request)
{
	if (request.PresentationValues != null)
	{
		if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "ClearStack")
			MasterNavigationController.PopToRootViewController(false);
	}

	base.Show(request);
}

I'm using magic strings here to keep things simple, but you could use constants/enums/whatever works for your application if you want to formalize things a bit more. The false sent in to PopToRootViewController() says not to animate so that it happens immediately. You can easily get yourself into trouble with UINavigationController if you have competing navigations, so definitely be careful there. I'll dig into that topic further in a future post.

Android

Now let's look at Android. I'm going to assume a presenter that's using fragments for all views and has a FragmentManager field it uses to manage them. In a future post I'll talk in more detail on how to implement this model in Android, but that's a bit off topic here. With that aside, the Android implementation ends up looking pretty similar to iOS:

public override void Show(MvxViewModelRequest request)
{
    if (vmRequest.PresentationValues != null)
    {
        if (request.PresentationValues.ContainsKey("NavigationMode") && request.PresentationValues["NavigationMode"] == "ClearStack")
            _fragmentManager.PopBackStackImmediate(null, PopBackStackFlags.Inclusive);
    }

    // ...
}

This is just one thing you can do with presentation values, so it's really up to you and what makes sense in your apps. If you have some knowledge in your view models that are of use to the presenter during a request, these values provide an easy way to pass that knowledge along with it.

As part of our effort to automate taking screenshots, we also need the ability to spin up Android emulators via the command line. This all needs to run headless, so it's necessary to be able to spin up Android emulators from the command line. A quick look at my ps output showed this to be even simpler a task than I'd anticipated.

To launch a new instance of the Android Player from the command line, all you need to do is run:

"/Applications/Xamarin Android Player.app/Contents/Helpers/Xamarin Android Player.app/Contents/MacOS/Xamarin Android Player" --name "Nexus 5 (KitKat)"

You can substitute the name there for whichever image you want to spin up. Once it finishes launching it'll be in a locked state. From the command line you can unlock it by using the adb command:

adb shell input keyevent 82

Here's a little F# script I put together to run through this sequence. If it finds any Android Player processes running, it assumes one is already running and skips that step. If you have the main Xamarin Android app running, even without having started any emulators from within it, this check will treat that as if an emulator is running. If none are found, it launches one and waits for 30 seconds before trying to unlock. Crude, but it does the job for now.

let startAndroidEmulator = fun (emulatorName:string) ->
    let xamarinPlayerPath = "/Applications/Xamarin Android Player.app/Contents/Helpers/Xamarin Android Player.app/Contents/MacOS/Xamarin Android Player"
    let exec = fun file args ->
        let info = new ProcessStartInfo()
        info.FileName <- file
        info.Arguments <- args

        let proc = new Process()
        proc.StartInfo <- info
        proc.Start() |> ignore

    if Process.GetProcessesByName("Xamarin Android").Length = 0 then
        exec xamarinPlayerPath (String.Format("--name \"{0}\"", emulatorName))

        Async.Sleep(30 * 1000) |> Async.RunSynchronously

    exec "adb" "shell input keyevent 82"

The next edition of the NYC Code Camp is coming up this weekend, and I have pushed out companion apps for iOS, Android, and Windows Phone that are all available now.

I’m pretty pressed for time right now so I’ll keep this short and sweet. You can find the apps by searching the appropriate app store, or you can use these links:

• iOS
• Android
• Windows Phone

If you’re interested, the source for all three apps is also available on GitHub. I will be giving a talk at the camp (at 9:15 AM, so get there bright and early!) on MVVM, and will be going over how I built these apps.

Enjoy!

If you haven’t checked out SignalR yet, what are you waiting for? SignalR is a .NET library that makes it really easy to build realtime applications. The server can be hosted inside a web application, or even in a simple console app. On the client side, you can access the server from the browser through JavaScript, a console application, or even from mobile apps. Naturally my first instinct was to try and get a SignalR client working that can be used from MonoTouch and Mono for Android applications.

UPDATE 4/30/2013: Please see this more recent post for more up to date information: Updates On My SignalR Fork and Xamarin Support

Building the Client

I’d be lying if I said it took a ton of effort to get things working under Xamarin’s tools. In fact, it turned out to be a great case study in the power of the Xamarin platform. Since MonoTouch and Mono for Android expose a profile very similar to that of Windows Phone, I was able to use the Windows Phone client project as a starting point. By adding in some conditional compilation symbols in many of the same places Windows Phone had them, I quickly had a set of projects that compiled for MonoTouch and Mono for Android.

The one tricky part with iOS is that features of .NET that rely on JIT compilations will not work on a device, despite the fact that they will work in the simulator. Because of this, I added a handful of workarounds to the MonoTouch build to help work around these limitations. This included some usages of ConcurrentDictionary and some Json.NET features that relied on JIT. This was not necessary for the Android build, since Android allows for JIT compilation.

Besides the JIT workarounds, that’s really all it took to get the clients working. Think about that for a second: that means I was able to reuse all of the existing SignalR client code, and leverage it on entirely new platforms! If that’s not a great example of the power of using C# across all platforms, I’m not sure what is.

You can find my fork of SignalR on GitHub.

Sample Apps

Of course, a client library is not useful without apps that use it, so I went ahead and added a simple example app for both MonoTouch and Mono for Android to verify that everything is working as expected. You can find both of these in the samples folder in the repository. To keep things simple, both of these samples make use of the SignalR.Hosting.Self.Samples sample that comes as part of SignalR. This is a console application that listens on port 8081 for incoming connections. Make sure you fire that app up before running the samples to make sure things work correctly. Depending on how your network is set up, you may also want to update the IP addresses used by the samples to point to the correct place.

iOS

To simplify the UI creation, this sample also makes use of the MonoTouch.Dialog library. All of the work happens in the AppDelegate class in the app:

using MonoTouch.Foundation;
using MonoTouch.UIKit;
using MonoTouch.Dialog;
 
namespace SignalR.Client.MonoTouch.Sample
{
	[Register ("AppDelegate")]
	public partial class AppDelegate : UIApplicationDelegate
	{
		UIWindow window;
 
		public override bool FinishedLaunching(UIApplication app, NSDictionary options)
		{
			window = new UIWindow (UIScreen.MainScreen.Bounds);
 
			var message = new EntryElement("Message", "Type your message here", "");
			var sendMessage = new StyledStringElement("Send Message")
			{
				Alignment = UITextAlignment.Center,
				BackgroundColor = UIColor.Green
			};
			var receivedMessages = new Section();
			var root = new RootElement("") 
			{
				new Section() { message, sendMessage },
				receivedMessages
			};
 
			var connection = new Connection("http://localhost:8081/echo");
 
			sendMessage.Tapped += delegate 
			{
				if (!string.IsNullOrWhiteSpace(message.Value) && connection.State == ConnectionState.Connected)
				{
					connection.Send("iOS: " + message.Value);
 
					message.Value = "";
					message.ResignFirstResponder(true);
				}
			};
 
			connection.Received += data =>
			{
				InvokeOnMainThread(() =>
					receivedMessages.Add(new StringElement(data)));
			};
				
 
			connection.Start().ContinueWith(task =>
                connection.Send("iOS: Connected"));
 
			var viewController = new DialogViewController(root);
			window.RootViewController = viewController;
 
			window.MakeKeyAndVisible ();
			
			return true;
		}
	}
}

When the app starts up it will create a connection to the server, broadcasting a message saying it has connected once the connection is open. The use of SignalR here is extremely simple. To broadcast a message to all clients, the Send() method on the connection is used. Whenever a message is broadcast, the Received event is fired, letting us know a new message has arrived. It’s possible to send more complicated messages, but in this case we just send and receive simple strings.

Android

For the layout, all the app needs is a text field, button, and list of messages received from the server:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <EditText
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:id="@+id/Message" />
    <Button
        android:id="@+id/SendMessage"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:text="Send Message" />
    <ListView
        android:minWidth="25px"
        android:minHeight="25px"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:id="@+id/Messages" />
</LinearLayout>

With that in place, the DemoActivity class takes care of the rest of the work:

using System.Collections.Generic;
using Android.App;
using Android.OS;
using Android.Widget;
 
namespace SignalR.Client.MonoDroid.Sample
{
    [Activity(Label = "SignalR.Client.MonoDroid.Sample", MainLauncher = true, Icon = "@drawable/icon")]
    public class DemoActivity : Activity
    {
        protected override void OnCreate(Bundle bundle)
        {
            base.OnCreate(bundle);
 
            SetContentView(Resource.Layout.Main);
 
            var messageListAdapter = new ArrayAdapter<string>(this, Android.Resource.Layout.SimpleListItem1, new List<string>());
            var messageList = FindViewById<ListView>(Resource.Id.Messages);
            messageList.Adapter = messageListAdapter;
 
            var connection = new Connection("http://10.0.2.2:8081/echo");
            connection.Received += data => 
                RunOnUiThread(() => messageListAdapter.Add(data));
 
            var sendMessage = FindViewById<Button>(Resource.Id.SendMessage);
            var message = FindViewById<TextView>(Resource.Id.Message);
 
            sendMessage.Click += delegate
            {
                if (!string.IsNullOrWhiteSpace(message.Text) && connection.State == ConnectionState.Connected)
                {
                    connection.Send("Android: " + message.Text);
 
                    RunOnUiThread(() => message.Text = "");
                }
            };
 
            connection.Start().ContinueWith(task => connection.Send("Android: connected"));
        }
    }
}

Outside of the Android-specific pieces, the code here is almost identical to that of the MonoTouch app, using the same Send() method and Received event on the connection.

Summary

My goal for my SignalR fork is to keep it up to date with any point releases from the main SignalR project. It tends to be a fast moving project so I won’t pretend to be able to keep up with the master branch all the time, but whenever there’s an actual new version I will try to keep my fork in line with that. As of right now, my fork is on SignalR version 0.6. SignalR has a ton of power and potential, so I hope some of you find it useful to be able to create clients in MonoTouch and Mono for Android apps!

Version 1.2 of C# To Go is now live in the Android Market. I also submitted the update to Amazon’s Android marketplace for approval, with any luck that will go through soon as well.

This is a small release of C# To Go, but does come with some cool additions. Most importantly, it includes support for Android 4.0 (Ice Cream Sandwich). I had received many reports from users that the app would crash on startup on Ice Cream Sandwich, so those issues should be cleared up now.

The one real feature addition in this release is that I added multi-line editing support. This was by far the most requested feature (and most common complaint in user reviews). If you prefer to keep the old style, the option is still available in the application’s settings.

Aside from that, this version does include some performance enhancements thanks to improvements in newer versions of Mono for Android. The most noticeable improvement there is that startup time for the application has been cut down by a lot. I also added a splash screen shown during startup to make it feel a little nicer.

I have some more improvements I’d like to make to the app as I have time, but I wanted to make sure I got this out ASAP since I didn’t want to leave Ice Cream Sandwich users hanging. I hope you all enjoy the update, and happy New Year!

Headed to the NYC Code Camp this weekend? The official mobile app for the camp is now available for Android, iOS and Windows Phone 7!

First things first, here are the links:

• iOS
• Android
• Windows Phone 7

You should also be able to find all of them by searching for “nyc code camp” in the marketplace.

I will be using these apps as a reference in my session Cross Platform Mobile Development with .NET, where I’ll talk about my approach in building them entirely in .NET, using MonoTouch and Mono for Android for iOS and Android. I won’t get into the technical aspects in this post (perhaps I will explore that in a future post), but if you’re interested the source code is all available on GitHub.

Some usage notes about the app:

• The app can pull down schedule updates throughout the day, but due to time constraints it is a manual process. A refresh button is available from the Overview screen that will check for updates and download them. The first time you launch the app the schedule will be pulled down automatically.
• Unfortunately the floor maps have changed a bit since the apps were submitted. The app does not include the map for the third floor, and incorrectly marks where the sponsor tables will be located. Aside from that they are still accurate.

Other than that, I hope you all find the apps useful, and I hope to see some of you at my session! To sweeten the deal, I’ll also have some stuffed Mono monkeys to give out to attendees as well as a discount code for the Mono products.