You can customize the iOS Keyboard with Xamarin.

Nearly all applications require that users interact with your app via a keyboard. It could be a search bar, a text field, or something else — users typically use the keyboard in some way for input. iOS comes with different types of keyboards that can solve just about any need, but there are times when some additional feature would be great. In Google’s Gmail app for iOS, for instance, maybe you’d like to make things a bit easier by adding e-mail addresses for .net, .org, and other domain suffixes. This article will look at how to modify the existing iOS Keyboard to better fit the needs of the application.

Before I eventually get to the protocol layer underlying the new build host in Xamarin 4 (as promissed
in a previous post that introducing it,
I wanted to mention how we architected it from the get go for a key scenario that we’ll want to enable
in the future: side-by-side (SxS) versioning.

Why would I care about SxS?

Visual Studio update and release cadence has been accelerating, and we want to support users that are on
the bleedging edge. At the same time, there is a very real world of users that are still on Visual Studio
2012 or 2013 that we also need to support. At the same time, Xamarin also has a different release cadence
than Visual Studio, and it even supports the concept of Stable, Beta and Alpha channels, as well as the
occassional web preview for new features.

The way this currently works in Xamarin is you install from whichever channel (or VS-bundled version),
and you get a single Xamarin install that applies to all IDEs you have installed in the machine. This is
clearly not SxS ;). That’s not at all how Visual Studio itself works, where you can have an early CTP of
vNext (i.e. Dev15 right now) while using a very stable Visual Studio 2013 Update 5 for your daily work.

This is obviously a good place to be: you get early feedback on upcoming versions, with minimal disruption
of your daily work environment. We want to get there for Xamarin for Visual Studio (XVS from now on) too.

Step by step

The first part of such a SxS story, and you might even say the most critical one, is the build host.

The build host is tightly bound to the matching XVS version, since it’s a core part of the iOS MSBuild
infrastructure, and there must be an exact match of tasks inputs/outputs, serialization, connectivity
and the like.

So it was clear from the beginning that we needed to version the install location on the Mac for the
build host and all its agents. For versioning, we use the very awesome (if I might say so myself)
GitInfo package which versions all assemblies automatically
without patching AssemblyInfos ;). We use the semver-like version on the build host (we call it the
“broker” for reasons that will be evident when we talk about the protocol ;)) and the agents to
determine which process to talk to on the Mac side.

NOTE: our version numbers are like [platform version].[cycle counter within platform].[service release].[build],
so currently, our latest stable release as of this writing is Xamarin 4, shipped in our first “cycle 6” release,
Service 4, so it’s: 4 (platform) .0 (cycle 6) .4 (service release 4) .4 (fourth build of the bits after we
branched for the release. The upcoming cycle7 release is 4.1.0.x (4 = same major platform version, 1 = one cycle
on top of the original cycle 6 when it shipped first, 0 = first release, x = whatever build)

When XVS detects that the specific version of the broker that bundles isn’t installed on the Mac, it will
automatically deploy a new broker and all agents. So if as a user you use VMs to isolate your production vs
“cutting edge” environments, and connect with them to the same Mac, the build host will happily install
side-by-side with other build hosts.

NOTE: this does not necessarily mean that Xamarin.iOS or Xamarin.Mac on the Mac support this kind of
side-by-side right now, it’s just that from XVS’ point of view, we do. We hope to get there eventually.

Updating the Build Host

You may have noticed (or figured out if you read carefully), that there is no self-update process from the
broker/build host itself. Since the whole install/run/update is drive by XVS, there is no need for it, and
this significantly simplifies the user experience.

On the Mac, you can notice this versining scheme when looking for logs, which are located at
~/Library/Logs/Xamarin-[MAJOR.MINOR], as well as the actual broker and agents, installed under the
$HOME/Library/Caches/Xamarin/XMA (XMA stood for “Xamarin Mac Agent” originally). You can see a structure
like the following there:

Broker/
    ...
    4.0.4.4/
Agents/
    IDB/
        ...
        4.0.4.4/
    Build/
        ...
        4.0.4.4/