Animating the stroke color of a CAShapeLayer with Xamarin

I wanted to indicate the most recent move in an AI-on-AI game of TicTacToe, so I wanted to have the most recent move be highlighted. The Xs and Os are CAShapeLayer objects.

Here’s the code to do it, featuring a very ugly hack to cast an IntPtr to an NSObject Including the use of SetTo and SetFrom to use a type that is not an NSObject in CABasicAnimation (thanks Sebastien!):

var layer = mark == 'X' ? ShapeLayer.XLayer (endFrame) : ShapeLayer.OLayer (endFrame);
layer.Position = origin;
this.Layer.AddSublayer (layer);

var animation = CABasicAnimation.FromKeyPath ("strokeColor");
animation.Duration = 0.5;

layer.AddAnimation (animation, "animateStrokeColor");

TideMonkey: Development Diary 0

I am publicly committing to developing “TideMonkey,” a tide-prediction application that will run on (at least) iOS and watchOS.

TideMonkey will be based on Xtide, an excellent piece of software developed by David Flater. At the moment, my hope is that it will be a very loose port, or what Flater refers to as a “non-port” that reuses the harmonics files of Xtide but is otherwise only loosely based on the source code. On the other hand, I know virtually nothing about the domain, so it is likely that I will have to hew pretty closely to Xtide’s algorithms, at least initially. Ideally I would like to be able to plugin different algorithms and compare their results with the canonical Xtide. Neural nets are a particular interest of mine and one would think that a harmonic series would be the type of thing that one could successfully train (if this ever happens, it won’t be for months and months and months).

I am battling the urge to dive right into coding. Instead, I know that I will be happy by investing in:

  • automation, and
  • testing, and
  • continuous integration

All of which argues for me to begin my journey by getting Xtide, which is written in C++, up and running in a CI server. For no particular reason (but it’s free for personal use) I’ve chosen to use TeamCity for my CI server.


There are several Xtide ports on Github to iOS or Android. The first one I tried was last updated in 2013 and doesn’t run on iOS 9 (it looks like a simple permissions issue, but it doesn’t run “straight from the cloud” and I don’t know if I want to deal with a port rather than just go with the original “straight from the horse’s mouth” Xtide source.

At the moment, I think I’ll work all inside the single “TideMonkey” Github repo. I’ll have to check license restrictions on that, and I don’t know how it will work out once the project structure starts to become more complicated, with testing and mobile development as part of it.


Creating TideMonkey Github report

MIT License

TideMonkey repo

GameplayKit path-finding in iOS 9 with Xamarin.iOS

Easy-peasy, lemon-squeazy:

var a = GKGraphNode2D.FromPoint (new Vector2 (0, 5));
var b = GKGraphNode2D.FromPoint (new Vector2 (3, 0));
var c = GKGraphNode2D.FromPoint (new Vector2 (2, 6));
var d = GKGraphNode2D.FromPoint (new Vector2 (4, 6));
var e = GKGraphNode2D.FromPoint (new Vector2 (6, 5));
var f = GKGraphNode2D.FromPoint (new Vector2 (6, 0));

a.AddConnections (new [] { b, c }, false);
b.AddConnections (new [] { e, f }, false);
c.AddConnections (new [] { d }, false);
d.AddConnections (new [] { e, f }, false);

var graph = GKGraph.FromNodes(new [] { a, b, c, d, e, f });

var a2e = graph.FindPath (a, e); // [ a, c, d, e ]
var a2f = graph.FindPath (a, f); // [ a, b, f ]


FizzBuzz with iOS 9 GameplayKit Expert System in C# with Xam.iOS

OK, so this is silly, but:

			var clearRule = GKRule.FromPredicate ((rules) => reset, rules => {
				output = "";
				reset = false;
			clearRule.Salience = 1;

			var fizzRule = GKRule.FromPredicate (mod (3), rules => {
				output += "fizz";
			fizzRule.Salience = 2;
			var buzzRule = GKRule.FromPredicate (mod (5), rules => { 
				output += "buzz";
			 buzzRule.Salience = 2;

			var outputRule = GKRule.FromPredicate (rules => true, rules => {
				System.Console.WriteLine(output == "" ? input.ToString() : output);
				reset = true;
			outputRule.Salience = 3;

			var rs = new GKRuleSystem ();
			rs.AddRules (new [] {

			for (input = 1; input < 16; input++) {
				rs.Evaluate ();
				rs.Reset ();


2015-08-04 13:08:47.164 GameplayKit0[46277:18357203] 1
2015-08-04 13:08:47.164 GameplayKit0[46277:18357203] 2
2015-08-04 13:08:50.338 GameplayKit0[46277:18357203] fizz
2015-08-04 13:08:50.338 GameplayKit0[46277:18357203] 4
2015-08-04 13:08:51.089 GameplayKit0[46277:18357203] buzz
2015-08-04 13:08:51.934 GameplayKit0[46277:18357203] fizz
2015-08-04 13:08:51.934 GameplayKit0[46277:18357203] 7
2015-08-04 13:08:51.935 GameplayKit0[46277:18357203] 8
2015-08-04 13:08:52.589 GameplayKit0[46277:18357203] fizz
2015-08-04 13:08:53.256 GameplayKit0[46277:18357203] buzz
2015-08-04 13:08:53.256 GameplayKit0[46277:18357203] 11
2015-08-04 13:08:53.872 GameplayKit0[46277:18357203] fizz
2015-08-04 13:08:53.873 GameplayKit0[46277:18357203] 13
2015-08-04 13:08:53.873 GameplayKit0[46277:18357203] 14
2015-08-04 13:08:55.005 GameplayKit0[46277:18357203] buzzfizz

The important thing I learned is that you have to call GKRuleSystem.Reset() if you want evaluated GKRules to be re-evaluated.

Why You Should Watch WWDC Session Streams

From an editorial perspective, one thing that is clear about WWDC is that the main audience for the sessions is not the developers in attendance, but the much more diverse, more diffuse, and more transient on-line audience that will view the videos over the next months and even years.

WWDC Session Videos are great as overviews, poor as references

What I’ve come to realize is that WWDC sessions are great as overviews, but poor for depth. They are very much worth watching when you’re new to a framework, they’re somewhat worth watching if you haven’t programmed in the framework lately (you might see some class you hadn’t appreciated), but they are not the place to discover a way out of some corner-case or programming limitation.

Microsoft explicitly labels the depth of their conference talks as being 100-, 200-, or 300-level, and 300-level content at WWDC was vanishingly rare. (As I write this, I can only speak to the talks I physically attended, but several talks definitely promised more depth than they delivered.)

I wonder if this is an artifact of The Dog That Didn’t Bark aka Apple TV. It must have been pulled very late. Both Xcode and Apple’s Developer Site, which had to be updated to support the new OS betas, are littered with Apple TV references. Perhaps it was the case that some of these weaker talks were late substitutions. (Although you wouldn’t guess it from the universally well-practiced speakers.)

The real keynote was the Platform State of the Union

Monday’s keynote was covered by news vans and live blogs and all that crap. There was, perhaps, 5 minutes of developer content in this 2.5-hour stemwinder. From the audience, anyway, the music stuff was awkward to the point of embarrassment.

Skip it and watch Platform State of the Union instead. This was the true developer’s keynote and contains an excellent overview of El Capitan, iOS 9, and watchOS. (By the way, the witty kids pronounce “watchOS” so that it rhymes with “nachos.”)

The Shocking Secret You Can Use to Determine Which Videos to Stream

Is that a proper 21st century headline?

Anyway, here’s the key: many sessions followed a standard naming practice:

— “Introduction to…” talks are 100-level (if that) “tables of content.” They hardly have any code on screen, but contain references to other videos that provide the 200- or 300-level content. If you’ve ever programmed in the namespace before, you can skip these talks.

— “What’s New In…” talks are 100-level “Release Notes.” There may be some code, but what you’re really looking for here are the new classes and general new capabilities. This is the video with which you should start if you have programmed in the framework before, even if you’re pretty comfortable. Again, all of these talks are good at referencing other, more substantive, talks. This is my main recommended tactic for finding deep content on frameworks with which you are familiar: it’s much more effective than guessing from session titles and descriptions.

— Beware talks that have the words “tips”, “tricks,” or “practices.” These were the talks that disappointed me. Such words traditionally mean 300-level content. If you’re an attendee and you’re budgeting precious in-conference time to “tricks” and “practices,” that’s a strong indicator that you’re familiar with the framework and are encountering its limitations and corner cases. But at WWDC, these sessions appear to be more focused on the newcomer or relatively inexperienced framework user.

How to: Handoff to a Xamarin iPhone app from Apple Watch

# How to: Handoff to a Xamarin iPhone app from Apple Watch

There are two ways to activate the parent (aka container) app from an Apple Watch app. You can either directly activate the container app using WKInterfaceController.OpenParentApplication or you can use Handoff.

Using Handoff is a little more complex, so I thought I’d write a quick little how-to. There are a few different Handoff scenarios, but perhaps the most common for the  Watch is: “On my watch I want to begin a task that I complete later on my iPhone.” So, for instance, some task that requires either more data-entry than is appropriate for the watch or some capabilities not available on the watch.

I want to keep the focus on the APIs, so instead of a real-world sample, I’m going to create a minimal example: a button on the Watch activates handoff and a status label on the phone app is updated when the user activity is continued on the phone.

As always, we have a single Solution with 3 projects: the parent App, the Watch extension, and the Watch App.

Napkin 10 05-06-15, 4.21.12 PM

Every handoff activity has a unique identifier. By convention, this is a domain-reversed string such as: com.xamarin.HandOffDemo.verb.

To trigger the Handoff behavior, the watch extension calls the WKInterfaceController.UpdateUserActivity method, with its first argument set equal to this identifier:

partial void ActivateHandoffClicked (WatchKit.WKInterfaceButton sender)
    var userInfo = NSDictionary.FromObjectAndKey(new NSString(“value”), new NSString(“key”));
    this.UpdateUserActivity(“com.xamarin.HandOffDemo.verb”, userInfo, null);

The third argument is a NSUrl object that can be used for Handoff tasks that should be handled by Safari. But in our case, we’re handing the userInfo dictionary containing the very complex data associated with our handoff.

Your parent app registers its interest in this type of handoff within its info.plist. In the parent app info.plist, add a new array called NSUserActivityTypes and add to it a string with value com.xamarin.HandOffDemo.verb

Napkin 11 05-06-15, 4.29.20 PM

It’s possible that an app could be interested in certain handoffs, but not always be in a position to actually handle them. That logic can be placed in an override of the UIApplicationDelegate.WillContinueUserActivity method:

public override bool WillContinueUserActivity (UIApplication application, string userActivityType)
    //Yeah, we can handle it
    return true;

Assuming that we return true from that method, the next step is to override the UIApplicationDelegate.ContinueUserActivity method:

An architectural issue that needs to be addressed is that this Handoff re-entry point is in the UIApplicationDelegate object, which of course does not have an associated user interface. There are several ways to handle this, but as a fan of reactive programming, I think the proper design is to create either an IObservable sequence or a more traditional C# event, which is what I do here:

public event EventHandler HandoffOccurred = delegate {};

public override bool ContinueUserActivity (UIApplication application, NSUserActivity userActivity, UIApplicationRestorationHandler completionHandler)
    HandoffOccurred?.Invoke (this, userActivity.UserInfo);

    return true;

The third parameter, completionHandler used if you have references to custom UIResponder objects that should handle the user activity. In the case, you put those references in a NSArray and pass them to completionHandler, which will cause each of their ContinueUserActivity methods to be called. (Update: Apple would probably prefer this technique to my event, but I am not sure if it’s necessary, and it requires the UIApplicationDelegate to maintain a reference to the subscribing UIResponder, so you either have an ugly dependency or you have to implement some kind of Observer / Subscriber pattern. So I still would suggest an event or IObservable as the better solution.)

In the parent app’s main UIViewController class, I have:

public override void ViewDidLoad ()
    base.ViewDidLoad ();

    //Configure user experience for Handoff
    var myAppDel = (AppDelegate) UIApplication.SharedApplication.Delegate;
    myAppDel.HandoffOccurred += HandoffOccurred;

public void HandoffOccurred(object sender, NSDictionary userInfo)
    InvokeOnMainThread( () =&gt; statusLabel.Text = userInfo[“key”].ToString() );

And that’s all there is to it. Obviously, a real use-case would involve building a more complex NSDictionary holding the context of the watch interaction and a similarly complex handler in the parent app.

Now, when the Handoff is activated from the Apple Watch, my iPhone lock screen shows the icon of the parent app in the lower-left corner. If I drag that up, the parent app opens, the re-entry process begins, with UIApplicationDelegate.WillContinueUserActivity and UIApplicationDelegate.ContinueUserActivity.

Programming WatchKit with F#

Disclaimer: This is just a hack. I’m not in any position to make announcements about stuff, but Xamarin loves F# and I’m sure that better solutions than this are forthcoming. But this was fun to get running, so…

Xamarin just released it’s Preview of Watch Kit support and naturally, I had to see if it was possible to use F# to program the forthcoming Apple Watch. Yes, it is.

As always with Watch Kit Apps, the Xamarin solution consists of three projects:

  1. A Parent app that is a normal iOS app;
  2. An Extension that runs on a connected iPhone and executes the program logic; and
  3. A Watch App that runs on the Watch and is essentially a remote display for the Extension App

You can read much more about this at Xamarin’s Watch Kit Documentation site.

To create an F# Watch solution, first create an F#-based Parent App. Then, add the Extension project to that app, an F#-based Custom Keyboard Extension. Finally, add a Watch App from the C#/iOS/Unified/Apple Watch solution template.

The Watch App consists only of a storyboard and resources. It doesn’t actually have any C# (or F#) code in it.

Follow these instructions to [set project references and identifiers].

Switching the Extension from Custom Keyboard to Watch Kit

You will have to manually edit the info.plist of the Watch Extension:

  • In NSExtension, switch the NSExtensionPointIdentifier to; and
  • Under NSExtensionAttributes, add a WKAppBundleIdentifier key to the identifier of your Watch App (e.g., com.xamarin.FWatch1.watchkitapp)

Screenshot 2015-01-21 15.02.07

Now you can get rid of the template F# code and replace it with something like this:

namespace WatchX

open System
open UIKit
open Foundation
open WatchKit

type InterfaceController(ip : IntPtr) =
    inherit WKInterfaceController(ip)

override this.Awake (context) =
    System.Console.WriteLine("Hello F#")
    this.myLabel.SetText("F# |> I ♡")

Again, this is covered in much more detail in Xamarin’s docs, but every scene in the Watch App’s storyboard is backed by a subtype of WKInterfaceController. Since it’s loaded from a Storyboard, it uses the constructor that takes an IntPtr. The Awake method is called when the controller is instantiated.

The Hacky Part

Xamarin has not yet released designer support for Watch Kit, so for now, you need to edit your Watch App’s Storyboard in XCode Interface Builder.

That’s not the hacky part.

Once you’ve designed your UI, you have to hand-edit the Storyboard XML, adding connections elements that define your outlets (properties) and actions (event-handlers). You have to set the destination attribute to refer to the id of the associated control:

Screenshot 2015-01-21 15.37.52

But really, that’s the only ugly part! ;-)

Back in your Extension app, you now have to use attributes to link up your F# code with elements within the Storyboard. The RegisterAttribute on your WKInterfaceController links to the customClass attribute of the controller element, and the name of your OutletAttribute properties must correspond to the property attribute of the outlet elements. Finally, the selector attribute of your action elements must have a corresponding ActionAttribute :

    namespace WatchX

    open System
    open UIKit
    open Foundation
    open WatchKit

    [<register ("InterfaceController")>]
    type InterfaceController(ip : IntPtr) = 
        inherit WKInterfaceController(ip)

        let mutable label : WKInterfaceLabel = null
        let mutable button : WKInterfaceButton = null

        let mutable clickCount = 0
        member this.myLabel with get() = label
        member this.myLabel with set(v) = label < - v

        member this.myButton with get() = button
        member this.myButton with set(v) = button < - v

        member this.OnButtonPush () =
            clickCount < - clickCount + 1
            sprintf "Pressed %d times" clickCount 
            |> this.myLabel.SetText 

        override this.Awake (context) = 
            System.Console.WriteLine("Hello F#")
            this.myLabel.SetText("F# |> I ♡")

And that’s really all there is to putting F# on your wrist!

Github project

Experiment in Auto-Generated UML as a Documentation Tool

I wrote a program to automatically generate class diagrams, filtered by coupling. Here is the result for CoreBluetooth in iOS:


Screenshot 2014-12-20 08.33.14


You can see there are clusters around CBPeer, CBPeripheral, and CBCentral and that CBCharacteristic is another class with lots of references.

Obviously, huge class diagrams are more noise than signal, but if I further filtered this down to specific topics…?

I dunno’.


P.S. Yeah, yeah, they should be open diamonds, not filled diamonds.


Good Bye, Dr. Dobb’s

Today comes the shitty news that Dr. Dobb’s (…Journal of Computer Calisthenics and Orthodontia) is shutting down.

I would not have had the career I have had without DDJ: first as an inspiration, then as a competitor, and then as the last torch of technically rigorous, personally-voiced but professionally edited high-quality programming articles.

DDJ was the last of the great programming magazines and was, probably, the greatest. Only Byte could, perhaps, have an equal claim to the crown. All the rest of ours, an entire industry, envied their columnists, technical editors, and authors. Even the standouts (Microcornucopia, Programmer’s Journal, C/C++ Programmer’s Journal, Unix Review, PC Techniques, WinTech Journal, and, … hell, it’s my feed… Computer Language, Software Development, and Game Developer) could only occasionally match their quality.

Perhaps what I admired most about Dobb’s was that it never wavered from being a programming magazine. In the early 90s, I decreed that Computer Language would never again refer to our profession as “programming,” it would only be referred to as “software development.” We published articles about management, about architecture and design, we boasted (boasted) of how little source code we published (because we talked about “the real issues”). And while I think there was a valid point to be made, the truth is that programming — the infinitely challenging alchemy of turning sparks traveling through blocks of sand into computation and information  — is what drew me to the profession, why I will code when I retire, and why I would have a computer under the floorboards if programming were illegal. Dr. Dobb’s understood, and celebrated, that mysterious joy. Perhaps that is why it out-lasted all the rest.

Now, it seems like, if our industry has a face, it’s the face of an arrogant Silicon Valley douchebag who knows everything about monetization, socialization, and micro-localization and nothing about algorithms, memory models, and programming languages. Dr. Dobb’s wasn’t a magazine for venture capitalists or “Digital Prophet”s or “Brand-Story Architect“s. It was a magazine for hard-core coders, people who could appreciate the trade-offs in the design of a macro preprocessor, get an “ah-hah!” moment from reading an assembly language listing for a chip they didn’t know, or  grasp the theme of an implementation discussed over a year of columns.

It will be missed.