præclarum

Asynchronous Talk Proposal for MonkeySpace 2013

Here is the abstract of a talk I hope to give at MonkeySpace in July - submitted a mere one week after the deadline. Let’s hope the organizers like the idea!

Asynchronous Application Patterns in C#

Now that Mono 3.0 supports the await keyword in C# we finally have an excuse to go back and rewrite all our networking code. Wait, no, nevermind, don’t do that.

Instead, let’s explore ways to write new code that takes advantage of this new syntax. We will look at common mobile app user experiences and see how we can use await and async code to create them. And maybe, just maybe, we’ll write some networking code along the way.

After we’re all bored with the practical uses of await, let’s take a quick glance at some more advanced - exotic - ridiculus? - uses of the syntax to enable new experiences.

Easy Layout - a DSL for NSLayoutConstraint

Layout has changed in iOS 6. We no longer are supposed to calculate RectangleFs and set springs and struts (AutoresizingMask), we are to use this very advanced constraint solving system.

That’s wonderful! Springs and struts, for those unfamiliar, is a lot like Anchors in Win Forms programming. It’s a really great model while you’re using an interactive design tool for layout, but if you want to do all your UI construction in code, then it’s a bit of work and relies on a lot of assumptions.

For example, here is the code to layout a simple screen with a text box and a button:

void LayoutWithSpringsAndStruts ()
{
    var b = View.Bounds;

    button.Frame = new RectangleF (
        b.Width - HPadding - ButtonWidth,
        VPadding,
        ButtonWidth,
        44);
    button.AutoresizingMask =
        UIViewAutoresizing.FlexibleLeftMargin |
        UIViewAutoresizing.FlexibleBottomMargin;

    text.Frame = new RectangleF (
        HPadding,
        VPadding,
        b.Width - ButtonWidth - 3 * HPadding,
        text.Font.PointSize + 14);
    text.AutoresizingMask =
        UIViewAutoresizing.FlexibleWidth |
        UIViewAutoresizing.FlexibleBottomMargin;
}

This code is easy to write. You just imagine the UI in your head and write this function down as fast as possible. Why fast? Because this code is read-only. It defies modification. Imagine if there were 10 different views each with their own obnoxious RectangleF math.

There are also a lot of assumptions in the code. How tall should a button be? I don’t know so I just put in the constant 44. Likewise, how tall should the text field be? Who knows, but I found some math involving fonts that works decently well.

A better way

Apple must have gotten tired of writing this kind of code because they developed a wholy new layout system based on mathematical constraints.

In this new system you layout views relative to one another instead of using absolute coordinates, and you specify those relations using equations and inequalities:

View1.Property1 (= | <= | >=) View2.Property2 * mul + constant

That is to say, any layout property of a view can be constrained to be dependent on another property of another view. The power (and trouble) with this system derives from this generality.

Instead of positioning the text field using a RectangleF, I create a bunch of constraints:

button.Width = ButtonWidth
button.Right = View.Right - HPadding
button.Top = View.Top + VPadding

text.Left = View.Left + HPadding
text.Right = button.Left - HPadding
text.Top = button.Top

These 6 constraints lay out the UI in the same way as the springs and struts code above. But it is superior in a lot of way:

1. It makes no assumptions about sizes. When using the new layout systems, Views can control their minimum size. This means that I don’t have to guess at the two heights anymore.

2. There is no math involved. As much as I like measuring pixels and flexing my algebra skills, I am relieved to not have to do RectangleF math.

3. It’s easy enough to read this code that I would even feel confident editing it over time. That is to say, it’s not read-only code. While it’s still not easy to get a picture of the UI from these constraints, they are much easier to reason about than the prior pixel math.

But there’s an issue. I haven’t actually shown you the code you need to write to implement these constraints. Without further ado:

void LayoutWithConstraints ()
{
    // Set button width
    View.AddConstraint (NSLayoutConstraint.Create (
        button, NSLayoutAttribute.Width,
        NSLayoutRelation.Equal,
        null, NSLayoutAttribute.NoAttribute,
        0, ButtonWidth));

    // Set button top
    View.AddConstraint (NSLayoutConstraint.Create (
        button, NSLayoutAttribute.Top,
        NSLayoutRelation.Equal,
        View, NSLayoutAttribute.Top,
        1, VPadding));

    // Set button right
    View.AddConstraint (NSLayoutConstraint.Create (
        button, NSLayoutAttribute.Right,
        NSLayoutRelation.Equal,
        View, NSLayoutAttribute.Right,
        1, -HPadding));

    // Set text left
    View.AddConstraint (NSLayoutConstraint.Create (
        text, NSLayoutAttribute.Left,
        NSLayoutRelation.Equal,
        View, NSLayoutAttribute.Left,
        1, HPadding));

    // Set text right
    View.AddConstraint (NSLayoutConstraint.Create (
        text, NSLayoutAttribute.Right,
        NSLayoutRelation.Equal,
        button, NSLayoutAttribute.Left,
        1, -HPadding));

    // Set text top
    View.AddConstraint (NSLayoutConstraint.Create (
        text, NSLayoutAttribute.Top,
        NSLayoutRelation.Equal,
        button, NSLayoutAttribute.Top,
        1, 0));
}

Our 6 constraints have inflated to 30 lines of code. Frown face. You can imagine how beautiful this code is in Objective-C where you’re forced to name every argument…

Apple likes verbose APIs, but even they had to admit that this code is a bit ridiculous. So much so that they invented this THC-induced ASCII art way to establish these constraints. We will avoid this topic.

So we’re stuck in an awkward place:

1. We can keep using springs and struts and pretend that the world hasn’t moved on.
2. We can write constraints using ridiculous amounts of code.
3. We can draw ASCII art and songs about California while we’re at it.

Challenge Accepted

The world can always be improved. There is no reason to be stuck with these 3 bad options when we use a fantastically powerful language (dearest C# 5, this is a love letter) with a runtime that will keep us safe during our adventures.

We are actually going to take our queue from Apple’s THC language, but let’s develop a DSL that’s easier to understand and aligns better with the actual constraints themselves.

Here is what I came up with:

void LayoutWithEase ()
{
    View.ConstrainLayout (() => 
        button.Frame.Width == ButtonWidth &&
        button.Frame.Right == View.Frame.Right - HPadding &&
        button.Frame.Top == View.Frame.Top + VPadding &&

        text.Frame.Left == View.Frame.Left + HPadding &&
        text.Frame.Right == button.Frame.Left - HPadding &&
        text.Frame.Top == button.Frame.Top
    );
}

If you squint, this code is identical to the 6 constraint equations written earlier. I had to swap == in place of = and I had to put .Frame everywhere because this code needs to compile. But, overall, this DSL quite perfectly matches the constraint system itself.

When this code finishes, the View will have 6 new constraints added to to it. Let’s take a look at them using View.Constraints:

<NSLayoutConstraint:0xc55c9f0 H:[UIRoundedRectButton:0xc524180(88)]>
<NSLayoutConstraint:0xb4b2830 UIRoundedRectButton:0xc524180.right == UIView:0xc52c4e0.right - 22>
<NSLayoutConstraint:0xb4b0e70 V:|-(44)-[UIRoundedRectButton:0xc524180] (Names: '|':UIView:0xc52c4e0 )>
<NSLayoutConstraint:0xb4b2110 H:|-(22)-[UITextField:0xc52a710](LTR) (Names: '|':UIView:0xc52c4e0 )>
<NSLayoutConstraint:0xb4b20a0 UITextField:0xc52a710.right == UIRoundedRectButton:0xc524180.left - 22>
<NSLayoutConstraint:0xb4b2200 UITextField:0xc52a710.top == UIRoundedRectButton:0xc524180.top>

If you are one with the Visual Format Language, then you can see that our constraint equations turned into NSLayoutConstraints appropriately.

So there you go, Option #4: Easy layout. This code is shorter than springs and struts, has all the power of auto layout, and is a lot easier to read and write than both.

How it Works

In order to provide this layout DSL, I took advantage of Linq expressions:

public static void ConstrainLayout (this UIView view, Expression<Func<bool>> constraints)

When we pass code of the form () => button.Frame.Width == ButtonWidth to ConstrainLayout, the compiler does two things:

1. It compiles the code and statically checks types just as you would expect.
2. The compiler does not execute the function, nor does it pass it to ConstrainLayout; instead, it gives you the abstract syntax tree of the function represented using the Expression hierarchy.

What we do with those expressions after compilation is up to us. This is the true power of Linq. While from x in xs syntax is cool, I think this ability to do metaprogramming is 1,618 times more cool.

Since we can do anything with expressions, let’s turn them into NSLayoutConstraints! Here’s the driver:

    public static void ConstrainLayout (this UIView view, Expression<Func<bool>> constraints)
    {
        var exprs = new List<BinaryExpression> ();
        FindConstraints (((LambdaExpression)constraints).Body, exprs);

        view.AddConstraints (exprs.Select (CompileConstraint).ToArray ());
    }

This code takes expressions of the form a && b && c and turns them into a list of expressions [a, b, c]. It then compiles each of those expressions into an NSLayoutConstraint and adds those constraints to the view. Easy.

A little more work is required to actually compile:

static NSLayoutConstraint CompileConstraint (BinaryExpression expr)
{
    var rel = NSLayoutRelation.Equal;
    switch (expr.NodeType) {
    case ExpressionType.Equal:
        rel = NSLayoutRelation.Equal;
        break;
    case ExpressionType.LessThanOrEqual:
        rel = NSLayoutRelation.LessThanOrEqual;
        break;
    case ExpressionType.GreaterThanOrEqual:
        rel = NSLayoutRelation.GreaterThanOrEqual;
        break;
    default:
        throw new NotSupportedException ("Not a valid relationship for a constrain.");
    }

    var left = GetViewAndAttribute (expr.Left);
    left.Item1.TranslatesAutoresizingMaskIntoConstraints = false;

    var right = GetRight (expr.Right);
    if (right.Item1 != null) {
        right.Item1.TranslatesAutoresizingMaskIntoConstraints = false;
    }

    return NSLayoutConstraint.Create (
        left.Item1, left.Item2,
        rel,
        right.Item1, right.Item2,
        right.Item3, right.Item4);
}

This code implements all possible ways to specify constraints. Specifically, it can handle expressions of the form:

text.Frame.Width >= button.Frame.Width * 0.5f + 5;
text.Frame.Width <= View.Frame.Width;
button.Frame.Height == button.Height - 10;

And so on. In total, it takes 200loc to implement the layout DSL. You can see it on github.

These 200 lines of code will save me from writing 4 boilerplate lines of code per constraint. This is a real win. That’s 80% less code to write. #winning

Thanks as always to C# for making my life more pleasant, and the folks at Xamarin who let me use my favorite language on my favorite platform.

Await in the Land of iOS - Scripting Users

Help!

We all know our UIs are intuitive and that our icons are perfectly chosen, but why leave learning the UI to chance?

The traditional solution to this problem is to provide help files. These are great, except no one reads them (at first!). If they get frustrated with your UI, they instead press the Home button and look at Twitter.

An alternative help system, one that I think is superior, integrates with the UI of the application. Think “tooltips on steroids”.

Check out the help system in Apple’s iPhoto app:

We have attractive tooltips describing the actions of the various toolbar items.

This is nice, but what about accomplishing tasks? Tasks often take multiple steps to accomplish use different parts of the UI. We write out tasks in our help files:

To search for pictures of cats:

1. Enter the term “cats” in the search box.
2. Tap the “Search” button.

This has the failing that the user has to swap between the app and the help file.

I want a help system that walks a user through a specific task. And I want it to do it in a way that doesn’t force the user to search for “cats” (100% automated) but let’s them accomplish the task with their own input and decisions. Such a system could also be used to give introductory tutorials - the “getting to know the app” task.

Ambitious? yes.

Await

But I don’t know how to write it (frown face). Well, I don’t know how to write it without making a mess out of all my UI code that is already, well, messy. Instrumenting messy code with help file info sounds more than scary.

It be nice (understatement) if I could just take those help file directions and turn them into code.

Await has helped me see a nice way to implement it.

async Task ShowTheUserHowToSearch ()
{
    await Tutorial.EnterText (searchField, minLength: 3);
    await Tutorial.Tap (searchButton);
    await Tutorial.Congratulate ("Now you know how to search.");
}

This is an async function that uses a library I call Tutorial to execute help file instructions. I tend to call these things “scripts”.

The method first asks the user to enter some text, then to tap a button. If they take those two tough steps, then you congratulate them!

The system automatically highlights the control with some text while waiting for them to take a step to egg them on.

This is my programmer art aspiring to be Apple’s beautiful UI in iPhoto:

Tutorial

Thanks to the await keyword and async methods, it was shockingly easy to implement the Tutorial class. It comes out at a measly 40 lines of code if you ignore my ugly programmer art (100 lines otherwise).

Let’s look at directing users to tap a button:

public static class Tutorial
{
    public static async Task Tap (UIButton view)
    {
        Highlight (view, "Tap");
        await view.GetEventAsync ("TouchUpInside");
        Unhighlight (view);
    }
}

The first line highlights the button. We then wait for a TouchUpInside event to fire. Once it has, we simply remove the highlight from the button. (GetEventAsync is from the previous post.)

This code is quite straight-forward. Surprisingly straight-forward given the amount of work that it’s doing for us. It’s keeping track of state, UI elements, waiting for events. All in 3 lines of simple code.

Let’s cover the rest before I get too choked up…

public static async Task EnterText (UITextField view, int minLength = 1)
{
    Func<bool> ok = () =>
        view.Text != null && view.Text.Length >= minLength;
    if (ok ())
        return;

    Highlight (view, "Enter Text");
    view.BecomeFirstResponder ();

    for (;;) {
        await view.GetEventAsync ("AllEditingEvents");
        if (ok ()) {
            Unhighlight (view);
            return;
        }
    }
}

Entering text is just as easy but contains a bit more logic. We want to watch the UITextField every time the text changes. To accomplish this, we just keep checking the Text property whenever an editing event has occurred.

We also skip this step if there is already valid text. Whether this is a good idea or whether the library should force them to edit the text anyway is up for debate.

If you read my earlier blog post on await then you will notice this pattern emerging of infinite loops used to wait for potentially long periods of time. Please keep in mind that this isn’t polling - it just looks like polling. We are still event based and there will be 0 CPU usage due to this infinite loop. Ahh, magic. As this is only my second day of experimentation, I don’t know if this is a good pattern or not. But for now, it works well and is pretty readable.

Congratulating the user is also simple:

public static async Task Congratulate (string message)
{
    var a = new UIAlertView ("Congratulations!", message, null, "OK");
    var clicked = a.GetEventAsync<UIButtonEventArgs> ("Clicked");
    a.Show ();
    await clicked;
}

We simply display an alert with a nice message and wait for the user to dismiss it.

We can build upon Congratulate to ask the user a question:

public static async Task<int> Ask (string question, params string[] responses)
{
    var a = new UIAlertView (
        "", question, null,
        responses.First (), responses.Skip (1).ToArray ());
    var clicked = a.GetEventAsync<UIButtonEventArgs> ("Clicked");
    a.Show ();
    return (await clicked).ButtonIndex;
}

Using Ask, we can have a nice dialog with the user:

async Task ShowTheUserHowToSearchWhileBeingAnnoying ()
{
    var r = await Tutorial.Ask (
        "Do you want to search for cats?",
        "No", "Yes, cats!");
    if (r == 1)
        searchField.Text = "cats";

    for (;;) {
        await ShowTheUserHowToSearch ();

        r = await Tutorial.Ask (
            "Do you want to play again?",
            "No", "Search!");
        if (r == 0)
            break;

        searchField.Text = "";
    }
}

This script demonstrates that we can:

• Compose help tasks together easily
• Use all of C#’s control flow structures while disregarding time
• Interact with the user contextually without managing state variables

It’s a lot like scripting an application UI for testing. Except, now, we’re scripting the user and reacting to them.

And it’s all possible thanks to await. Try writing that code using event handlers. I’ll wait…

Thanks

My thanks go out to everyone who worked on async both at Microsoft and on the Mono project for building such a useful and versatile language feature.

I want to re-iterate that I don’t know how, or couldn’t implement this kind of help system without async. Managing the state of many possible interactions (imagine two of these help tasks running simultaneously) without async hurts my head. Not only does async provide a solution to the state management problem, but it does so in a way that is simple and doesn’t touch your UI code.

Await in the Land of iOS - Drag-n-drop

Today is a big day, Xamarin has released (in alpha) support for the await keyword in C#.

To celebrate, I thought I would write a few articles describing the ways I plan (and now am) taking advantage of that support.

Async code without await is code written inside out

Asynchronous programming has taken over our lives. We allowed it to because it benefits software ranging from high performance servers all the way down to responsive UIs on phones. That is to say, it’s good for machines and users.

But async programming comes at a cost for us programmers. It often asks us to mangle our beautiful procedural code into state machines or continuation passing style. We can’t just say “Do A, then B, then C”:

DoA ();
DoB ();
DoC ();

Instead, we have to write the code using callbacks:

DoA (errA =>
    if (errA != null) HandleError (errA)
    else DoB (errB =>
        if (errB != null) HandleError (errB)
        else DoC ()));

That code is pretty horrendous compared to the procedural code. It’s too long. It turns our error handling from exception-based to return code-based. The error handling also hides the control flow. It is, quite simply, a mess.

The C# await keyword allows us to write asynchronous procedural code in our preferred style so long we don’t mind a few keywords:

await DoA ();
await DoB ();
await DoC ();

What a breath of fresh air!

What else is inside out?

Await has paid for itself by greatly simplifying our async code. But it made me wonder, what other bits of code am I writing inside out? In other words, what other APIs do I often interact with that are async - that happen in user time, not CPU time?

Event handlers for touch events sprung immediately to mind.

I wondered about an old friend of mine, the drag-n-drop procedure. Dragging objects on the screen is simple:

1. When a touch begins, look to see if it touches any subviews
2. If it does, then move that view whenever the touch moves until the touch ends

Below is code that I have written 1,268 times (I checked) to implement that procedure in iOS:

class DragInfo
{
    public UITouch Touch;
    public UIView View;
}

readonly Dictionary<UITouch, DragInfo> drags =
    new Dictionary<UITouch, DragInfo> ();

public override void TouchesBegan (NSSet touches, UIEvent evt)
{
    foreach (var touch in touches.ToArray<UITouch> ()) {
        var loc = touch.LocationInView (this);
        var view = Subviews.FirstOrDefault (x => x.Frame.Contains (loc));

        if (view != null)
            drags[touch] = new DragInfo {
                Touch = touch,
                View = view,
            };
    }
}

public override void TouchesMoved (NSSet touches, UIEvent evt)
{
    foreach (var touch in touches.ToArray<UITouch> ()) {
        DragInfo drag;
        if (!drags.TryGetValue (touch, out drag))
            continue;

        var loc = touch.LocationInView (this);
        var ploc = touch.PreviousLocationInView (this);

        var fr = drag.View.Frame;
        fr.X += (loc.X - ploc.X);
        fr.Y += (loc.Y - ploc.Y);
        drag.View.Frame = fr;
    }
}

public override void TouchesEnded (NSSet touches, UIEvent evt)
{
    foreach (var touch in touches.ToArray<UITouch> ()) {
        DragInfo drag;
        if (drags.TryGetValue (touch, out drag))
            drags.Remove (touch);
    }
}

It implements multi-touch dragging of views by using some fields to store state between touch events.

How well does this code align with my dragging procedure above? I wrote the code as well as I ever have (i.e. my style hasn’t changed since programming Windows 3.1). But it still has very little resemblance.

The events become the main focus of the code instead of the procedure. I had to introduce a data structure and some mutable, essentially global, data that 3 different functions work with in a coordinated way. Since async methods can be called any time, I just have to hope that I worked out all the possible interleaves in my head (I probably didn’t).

Can we do better? I rewrote that code using await to find out.

// Step 1: Watch for dragging starts
async void WatchForDrags ()
{
    for (;;) {
        var began = await this.GetEventAsync<TouchEventArgs> ("TouchBegan");

        foreach (var t in began.Touches) {
            var loc = t.LocationInView (this);
            var view = Subviews.FirstOrDefault (x => x.Frame.Contains (loc));

            if (view != null)
                DragView (t, view);
        }
    }
}

// Step 2: Carry-through with the drag until it's over
async void DragView (UITouch touch, UIView view)
{
    for (;;) {
        var moved = this.GetEventAsync<TouchEventArgs> ("TouchMoved");
        var ended = this.GetEventAsync<TouchEventArgs> ("TouchEnded");

        var ev = await Task.WhenAny (ended, moved);

        if (!ev.Result.Touches.Contains (touch))
            continue;

        if (ev == ended)
            return;

        var loc = touch.LocationInView (this);
        var ploc = touch.PreviousLocationInView (this);

        var fr = view.Frame;
        fr.X += (loc.X - ploc.X);
        fr.Y += (loc.Y - ploc.Y);
        view.Frame = fr;
    }
}

Using a little trick function, I was able to turn normal .NET events into tasks. The idea is simply to subscribe to the event long enough for it to fire once and only once. That one little trick allowed me to increase the readability of the code.

What was 3 functions, 1 data structure, and 1 chunk of memory has been turned into two procedures that align very well to the English procedure above.

I love that this code doesn’t leak its state out into the class containing it. DragInfo is a failure of encapsulation - the data required by the events Began, Moved, Ended was available to all other methods in the class. Now, there is no leaked state. Instead, the state is held in a clojure created when DragView is called by WatchForDrag.

I love that the new code is procedural - lines higher up on the screen happen earlier in time. I love that it processes events in the order that it cares about - no other order.

This is straight procedural code that executes asynchronously in response to user interactions. The machine is happy because I’m not spawning threads, the user is happy because the UI is responsive, and I am happy because I can write code the way I think, not the way I’m required to just to satisfy those other two conditions.

I hope you found this a little interesting. I have a lot more ideas on how to take advantage of await so I hope you’ll stay tuned.

A little trick function

The GetEventAsync is the magic that allows me to await events. Here is a rough implementation of it.

public static Task<T> GetEventAsync<T> (this object eventSource, string eventName)
    where T : EventArgs
{
    var tcs = new TaskCompletionSource<T>();

    var type = eventSource.GetType ();
    var ev = type.GetEvent (eventName);

    EventHandler handler;

    handler = delegate (object sender, EventArgs e) {
        ev.RemoveEventHandler (eventSource, handler);
        tcs.SetResult ((T)e);
    };  

    ev.AddEventHandler (eventSource, handler);
    return tcs.Task;
}

iCircuit Code Reuse, Part Cinq

I have toiled away with the new Windows 8 OS, the new Visual Studio 2012, and the new Office 13/365 to present you, dear reader, with this fine set of charts:

(This post is the 5th in a series where I describe the code reuse of iCircuit while porting it from platform to platform. Check out the previous posts.)

Yesterday I completed the Metro, I mean Windows Store Modern App, version of iCircuit and achieved 85% code reuse from my other platforms! You should check it out, it’s amazing to see Windows 8 actually do something useful! ;-)

iCircuit for Windows 8

To build this version, I used the work from the Windows Phone 7 port to get the basic app working in a XAML/C# solution. From there I “just” had to build up a modern desktop/tablet UI for the app. The initial port took about 1 day. Then I spent about 2 months refining the UI to feel good.

Thanks to the amazing .NET/Mono platform I was able to reuse 39,000 lines of code and had to write 6,700 lines of platform dependent code. These figures represent a code reuse of 85%. This is on-par with all my other ports, and so I deem it a success.

That said, I’m a little disappointed that I had to write 6,700 lines. I was hoping for code reuse more inline with the OS X port of the app where I only had to write 4,000 loc. I blame WinRT’s immaturity. You would be shocked to see some of the crazy bits of code I had to put in because the Win8 platform, while very rich, is also very generic and doesn’t help you at all to build standard apps (document based, tools, etc.) That is to say, Cocoa is a very mature platform designed to make apps feature-rich and consistent while also making the developer’s life easy. WinRT on the other hand gives you rectangles and a blog post that says “good luck”.

Post Mortem

• Microsoft did a great job of porting XAML graphics over to this new brave DirectX world. All my Silverlight code worked out of the gate and had decent performance.
• The XAML implementation is slow as a snail slithering up a mountain during a rainstorm when it comes to changing the scale of render transforms. I can pan around with high FPS but the moment you zoom in or out, the app feels like we’re back in the 80s. Now, this is probably not Microsoft’s fault since the perf profiler says that I spend all that stalled time in video card drivers (Intel 3000 on my dev machine), but Microsoft should lay some tough love on these hardware peeps.
• WinRT introduces yet another way to track multi-touch. Now we have to wire up 5 Pointer events instead of a single Touch event from Silverlight. Check out my implementation in CrossGraphics to see the horror unfold. CocoaTouch nailed multi-touch on their first go. This is Microsoft’s 3rd attempt. Let’s hope they’re happy this time.
• Just when I thought I had completed the port, I realized that the app isn’t functional on non-touch devices - there was a whole list of actions you just couldn’t do. So I had to write keyboard and mouse code to make that all happen. Coming from iOS, this felt crazy indeed. Why am I putting keyboard shortcuts into a tablet app? Because WinRT apps have to be just at home on the desktop as they need to be on tablets.
• The WinRT XAML implementation isn’t able to render the visual tree to bitmaps (WriteableBitmap does not have the Render method). Let me just add my voice to the 1,000,000s of other devs as we cry “Why Microsoft, why???” To export PNGs, I had to resort to deep dark black magic of DirectX and Direct2D. Simple question to all the devs on the XAML team: if I can write code to render a visual tree using DirectX that gets dumped into a WIC bitmap, why the hell can’t you?
• Testing the Share Charm is a real pita. One little mistake and you will have to reboot Windows (yes, I said reboot Windows) to make sharing work again.
• The Visual Studio performance analysis tools are wonderful. They give nicely detailed reports in a UI that makes… well, some sense. It’s still lightyears behind Instruments, but it’s functional and enabled me to fix some hot spots in the code.
• The file system security model is ludicrous and stupid and dumb and confusing and stupid and annoying and a pain to use. I had to disable one of my favorite features of iCircuit (subcircuits) because I couldn’t find a way to open a StorageFile using just a path. “Access Denied” all over the place.
• The media system is a piece of crap compared to what we had in Silverlight and WP7. I, again, had to disable major chunks of the app (microphone, speakers, and buzzer elements) because WInRT doesn’t expose the media system to C#. There are “capture” devices but they incur a 500ms delay because you can’t control buffer sizes. And playback, well, let’s just say it has many problems too. I greatly miss Microsoft.Xna.Framework.Audio. (Oh, and while we’re at it, fuck you MS for cancelling XNA, your only good API. I feel like I can swear now that we’re way down in the list.)
• The graphics system of WinRT is very fragile. I want to do real-time 2D vector drawing. Direct2D is perfect for this. But WinRT puts all sorts of limitations on onscreen rendering, most notably: you can only have 1 DirectX swap chain (view) per window. That means I can’t use Direct2D for rendering the scope which means the scope is slower than it needs to be. Dear Microsoft, go spend a few minutes and see how beautifully CocoaTouch and OpenGL work together on iOS. You might get inspired.
• The App Store review process was crazy fast. It took 5.5 hours for the app to be placed on the store. While I’m ecstatic that the review process was so fast, it does leave me wondering. I spent days struggle over the UX guidelines debating the right way to exposes this feature or that. In the end, it looks like it doesn’t even matter. I wonder if they even looked at the app? It’s big and complex. It contains a hand-written C compiler for God’s sake. It has 5 UI views that are individually larger than most apps on the store. Ah well, it will be up to the users to tell me if the effort was worth it.
• This WinRT version lacks a natively optimized solver. iCircuit for iOS uses Apple’s Accelerate framework to do the heavy lifting in its solver to get wonderful performance that only gets better as the CPUs get wider and Apple’s engineers optimize the library. Windows has none of this. I ran into many problems trying to get this C# app to use a WinRT C++ component but eventually gave up. It’s too bad Microsoft doesn’t care enough about high-performance computing to integrate useful numerical libraries.
• I need a better way to write cross-platform documentation.

Thanks for tuning in one more time! I hope you found this at least a tiny bit educational!

So which platform is next? I’m thinking of porting it to Windows 7, but will wait to see how sales do first. :-) In the mean time, MonoTouch and I need to spend some quality time together…

• iCircuit for Windows 8
• iCircuit on iOS/OS X/Android/WP7

Mobile Network Performance while Touring Seattle

I recently journeyed around Seattle to get a sense of the impact motion has on the network performance of mobile applications.

The image above is a graph of how long it took to download the homepage of Google News (588 KB) while I was traveling by bus and train throughout the city. Blue bars are successful downloads and red bars (and time entries with no bars at all) represent errors. The height of the bar shows how long it took to find out if it was successful download or an error.

I wrote the test app using MonoTouch and ran it on an iPhone 5 with Verizon LTE.

Observations

When you’re standing still, performance is pretty consistent and error free

Whenever I gave the phone time enough to pair with a cell tower, the performance was pretty consistent with 2.5 second response times with 588 KB of data (240 KB/s). I never received errors (go TCP!).

You will get spikes errors when moving

While most downloads took 2.5s, I received many 5s spikes. This is 100% increase in time. There was a even a time (look in the last 1/3rd of the chart) where 5s became the average and I received 10s spikes.

The spikes happened quite spuriously so I can only guess that they occured in cell tower transition zones.

While TCP is an insanely resiliant protocol, it would still fail from time to time. In a 2 hour interval, I recorded 2 errors that weren’t tunnel-related. This means that there was a 1% error rate while moving. My only guess is that these happened whenever I was switching towers and the request happened just then.

3G sucks compared to LTE

Do you see those blue spikes near the center just after a little gap (the Mount Baker tunnel)? The one that peaks at more than 50s? That’s 3G my friends: slower downloads by an order of magnitude and a huge variance increase. I can only wonder what this graph would be like if I was stuck on 3G the whole time…

Timeout and ReadWriteTimeout control these spikes

For the test, I used a WebRequest.Timeout of 20 s and a ReadWriteTimeout of 20s.

You can see the affect of Timeout with all the errors that cap at 20s. Mono gave a “System.Net.WebException: The request timed out” at that mark. This is great because it’s very predictable.

So, how do bars go above 20s? That’s the effect of ReadWriteTimeout. This is the timeout that affects each Read and Write call to the response object. I was using a 16 KB buffer for my reads so this means that I did about 37 read operations. Since each of these had a timeout of 20s I could have ended up waiting up to 740s (12 minutes)! Thankfully that never happened.

About 50% of the time, ReadWriteTimeout was able to finish the download. On the other 50%, I ended up receiving “System.Net.WebException: The operation has timed out.” exceptions. I’m not sure if I see much value in setting it up - I would prefer that errors come sooner rather than later.

The system default of 300s (5 minutes) seems beyond ridiculous to me. Don’t use that value.

TL;DR ReadWriteTimeout is an important value that you should think about.

Thank God for ConnectFailures

While travelling through a tunnel, the request would fail immediately with “System.Net.WebException: Error: ConnectFailure (No route to host)”.

These errors are represented by the white gaps in the chart. In the face of those 38 s errors, this is wonderful.

All errors were represented by WebExceptions

I’ve always wondered if a try-catch block of:

try {
    // Do some System.Net.WebRequest stuff
} catch (System.Net.WebException) {
    // OMG. OMG. OMG.
}

one that caught only WebException - was sufficient to catch all network related errors when using WebRequest. It turns out that yes, yes it is. One less thing to think about…

Here are all the errors MonoTouch emitted during this test (in Type.Name + Exception.Message format):

• System.Net.WebException: Error: ConnectFailure (No route to host)
• System.Net.WebException: The request timed out
• System.Net.WebException: The operation has timed out.

Code Setup

• Request Class: System.Net.HttpWebRequest
• URL: http://new.google.com
• Timeout: 20 s
• ReadWriteTimeout: 20 s
• HTTP Keep-Alive: No
• ReadBuffer: 16 KB
• Request Interval: 30 s

The actual code for the netowork request can be found in the HandleTimer method in the gist for the test app.

The app disabled the idle timer of the phone so that it could run continuously in the foreground. Every 30 seconds, it would download the full 588 KB of Google News. In all, I figure I burnt through 8% of my monthly data allowance.

Test Procedure

• Device: iPhone 5 (white)
• Carrier: Verizon (LTE, usually)

I started the test by getting a slice of pizza at Pagliacci’s in the University District of Seattle. I figured this would be a good way to establish a baseline for staying still, and I was very hungry. I then took a bus to Westlake, downtown, wherein we entered the transit tunnels and I transferred to the light rail. I took the light rail through the tunnel and back into the open air as far as Columbia City. This journey consumed the first hour of the test. There, I switched trains to head back into the city. The trip back was essentially the same and even included another stop for pizza in the name of consistency (at Sbarro this time).

Programmatic Panning and Zooming with a UIScrollView

Let’s say you have a zoomable and scrollable UIScrollView all setup in your app. Great! Good job. But how do you programmatically zoom in on something particular? (For example, you may want to pan and zoom into an object that was double tapped.)

UIScrollView exposes the SetZoomScale and ScrollRectToVisible methods, each of which can be animated. These are the methods that you will use but getting them to work together is a bit tricky. There was a lot of trial and error when I tried to get them to work together so I thought I would share my solution with you.

Step 1. Determine a rect that bounds the content you want to zoom into.

var contentFrame = new RectangleF (x, y, width, height);
var scrollFrame = contentView.ConvertRectToView (contentFrame, scrollView);

First, we determine a bounding box for the content that we want to zoom into. Let’s call it contentFrame.

We will also convert that bounding box to the coordinate system of the scroll view for use later.

Step 2. Determine the new zoom scale.

var desiredZoomScale = 2;
var zooming = Math.Abs (scrollView.ZoomScale - desiredZoomScale) > 0.05f;

Now, determine the new desired zoom scale. This will depend on your app logic and perhaps on the contentFrame from Step 1. It’s very app-specific, so I’ll leave it at that for now.

We will also record whether the zoom needs to happen by comparing the desired zoom scale and the current zoom scale. We’re going to need to know this to work our magic in Step 3.

Step 3. Animate the pan and zoom.

if (zooming) {
    scrollView.SetZoomScale (desiredZoomScale, true);
}
scrollView.ScrollRectToVisible (scrollFrame, !zooming);

The trick here is to perform the zoom operation before the pan operation and to toggle the automatic animation system depending on whether we’re zooming or not.

If we are zooming: Then tell SetZoomScale to animate and ScrollRectToVisible not to animate.

If we are only panning: Then don’t call SetZoomScale but do tell ScrollRectToVisible to animate.

If you follow this simple procedure you will end up with nice smooth animations. If you don’t, well, the results can be a bit jarring. Enjoy!

iCircuit Code Reuse, the Fourth Edition

Hell has indeed frozen over and I have released the Android version of iCircuit! iCircuit is now on 4 platforms!

I wrote the app using Xamarin’s Mono for Android so that I could reuse large amounts of code that I have painstakingly written and debugged on other platforms.

That means it’s time to run that code reuse script and find out how I did as a developer. How much of the Android code base had to be written anew and how much was I able to reuse from the other platforms?

Here is a visualization of the code reuse. The percentage in green is the amount of code reused while the code in red is code I had to write for each platform.

We can see that Android was only (“only”, haha) an 81% code reuse - I had to write nearly 7,000 lines of code to port iCircuit to it. This is great, but I was aiming for closer to the 90% mark as the Mac was able to achieve.

I can chalk this difference up to two new additions to the code base:

1. Two new UI controls have been added that are unique to Android. The first is a “mini-scope” that is shown persistently on the screen. The other is a new dial that makes it much easier to input numbers on a multi-touch screen. The dial will eventually make it into the other platforms (iCircuit 1.5).
2. Two new graphics drivers. The first uses Skia (Android.Graphics) to render scenes, and the other uses OpenGL. The Skia driver is used to render thumbnails, draw the scope, and other UI elements, while the OpenGL driver renders the main editor (very quickly).

Code reuse aside, I’m very excited to have this released (it’s taken me awhile), and hope all the Android engineers out there give the app a try!

(This is a followup to the post iCircuit Code Reuse Part Trois. More details on my methodology can be found there.)

Speakers I can’t wait to see at Lang.NEXT 2012

The speaker list for Lang.NEXT 2012 has been released, and I found myself trying to decide which speakers to go see. There are a lot of fine choices so I thought I had better get organized!

Here are the speakers I want to see because of a “personal” connections:

• Andrei Alexandescu was my C++ hero for years as I dove deeper and deeper into the language and metaprogramming.
• Martin Odersky created Scala and I loved Scala for a time.
• Herb Sutter because I’ve read all his books and in doing so fooled myself into thinking C++ was a valid language. :-) Honestly, I really don’t care what other ridiculous features have been bolted onto C this year, but it would be fun to see him present.

And then there are those I want to see because of their notoriety:

• Gilad Bracha because he just seems ridiculously smart and continues to invent new and interesting languages.
• Erik Meijer because he is energetic and usually has something interesting to say.
• Mads Torgersen for his C#ness. But really, do I need more C# knowledge. ;-)

Then there are the speakers I want to see because they sound fascinating:

• Andrew Black says he understands OOP and mobile. I want to see if his ideas of OOP jive with my own.
• Walter Bright seems to be a big compiler geek. Compilers are boring, but compiler geeks are not.
• Kim Bruce he said OOP and Java in the same sentence, but I’ll forgive him for that since he sounds like a sincere smart one.
• William Cook worked on AppleScript and more OOP.
• Jeroen Frijters because kangaroo vouched for him and IKVM is cool.
• Andy Gordon because his bio mentions machine learning and F#. Check, and check.
• Robert Griesemer made Go and worked on the V8 engine. There must be some good stuff to learn from him.

A Two-year-old Bug Found by Microsoft

I submitted the Windows Phone 7 version of iCircuit to Microsoft a few days ago and was shocked (shocked!) that it failed certification by their testers.

I was in denial, how could this be? The engine is two years old, and, while it has issues, is very stable on a variety of platforms. Add to this the fact that I couldn’t reproduce the bug right away, I was stymied.

But after some patience and Diet Coke, I discovered that not only did they discover a bug in the engine, but one that’s been there since its initial release. That means it has been hidden from thousands of users and many many rounds of testing. I have to hand it to Microsoft for finding it.

I would like to discuss the nature of the bug in some detail here since I have never run into something of its kind before.

As with all numerical apps, the bug lied in floating point precision problems.

The Scope in iCircuit automatically determines a range for the value axis of the plot. If the signal ranges from -5 to 5 V, then the plot shows that range. To do the actual plotting it calculates a pixel ratio:

PPV = Height of the Plot / (Max Value - Min Value)

But what happens if you have a DC signal that ranges from, say, 5 V to 5 V? You would get a divide by 0 in the calculation of PPV. Being an electronics simulator where DC signals occur all the time, iCircuit had to have code to handle this case. And so, pseudo min and max values were introduced:

DV = Max Value - Min Value

if (DV == 0) { DV = 1e-6; }

Pseudo Min Value = Min Value - DV

Pseudo Max Value = Max Value + DV

PPV is then calculated as above but using these pseudo variables instead of the real values. DV is set to a value that makes the plot look decent but is any arbitrary value greater than 0. You can think of DV as creating a little gap around the constant values.

This is the code that’s been in iCircuit since v1.0 and has worked quite well. Until Microsoft got their hands on my app.

Their tester decided to hook up an LED directly to a DC source. All electricians know that this is a bad idea - you’ll burn out the LED since diodes have very little internal resistance. You always put some resistance in series with the LED. But he didn’t.

LEDs do have some internal resistance that iCircuit was simulating to produce a current of over 1.9e19. That’s a huge current! Impossibly huge, but theoretically correct.

When the tester went to observe that current on the scope, it was determined to be a DC value (DV == 0) and the pseudo values were calculated. Kinda.

It turns out that 1.9e19 +/- 1e-6 == 1.9e19 thanks to floating-point imprecision.

Oh my. That means that the pseudo values were still the same and we hit the divide by 0 bug. When I tried to plot a NaN value (some more math is done on PPV), an unhandled exception was triggered. Oh my indeed.

That is the crash that the Microsoft tester found. Good job, man.

Now the solution. Instead of using a fixed minimum DV value of 1e-6, I calculate it as

Min DV = |Max Value| * 1e-6

and DV becomes

DV = max(Min DV, Max Value - Min Value)

This makes sure that DV will be substantial enough to ensure Pseudo Min Value and Pseudo Max Value are different and the divide by 0 is avoided.

Well, almost, there’s still a bug there, but I’ll let you discover it.