præclarum

Asynchronous Talk Proposal for MonkeySpace 2013

Wed, 24 Apr 2013 11:40:00 -0700

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

Mon, 18 Mar 2013 12:36:00 -0700

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:

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.
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.
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:

We can keep using springs and struts and pretend that the world hasn’t moved on.
We can write constraints using ridiculous amounts of code.
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:

It compiles the code and statically checks types just as you would expect.
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

Wed, 13 Mar 2013 10:47:55 -0700

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:

Enter the term “cats” in the search box.

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

Tue, 12 Mar 2013 17:54:00 -0700

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:

When a touch begins, look to see if it touches any subviews
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

Tue, 05 Feb 2013 13:53:09 -0800

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…

Mobile Network Performance while Touring Seattle

Wed, 05 Dec 2012 11:15:00 -0800

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

Tue, 27 Nov 2012 09:57:00 -0800

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

Tue, 18 Sep 2012 09:06:00 -0700

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:

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).
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

Fri, 16 Mar 2012 14:16:00 -0700

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

Fri, 20 Jan 2012 15:43:00 -0800

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.

iCircuit Code Reuse Part Trois

Fri, 13 Jan 2012 13:26:04 -0800

I have recently finished porting iCircuit to Microsoft Windows Phone 7 (WP7) and wanted to see how I performed on the code reuse front.

I use MonoTouch to do iOS development, and that was the first version of the application. Some months ago, I also released a Mac version of the app using MonoMac. It was then that I gave a presentation giving some general stats on the amount of code I was able to reuse between the two versions.

Now, with a third version, it’s time to repeat the report. This is also the first version of the app not written using Mono tooling. That’s right, I used a PC. It was weird.

I wrote a little script to calculate the stats I’m about to present. Here is gist of that script so that you can decide for yourself if these stats are worthwhile. All the compiled code for each project got put into two buckets: unique code and shared code. Unique code is code used only for that project while shared code is code that was used in more than 1 project (not requiring that it be used in all projects). The majority of the shared code comes from the iCircuit cross platform library, but also includes things like shared graphics drivers and file system abstractions.

The raw output from that script is as follows:

app     t       u       s       u%      s%
Mac     29954   3901    26053   13.02 % 86.98 %
WP7     30744   5760    24984   18.74 % 81.26 %
iOS     37518   11532   25986   30.74 % 69.26 %

(t is Total lines of code, u is Unique lines of code, and s in Shared lines of code. Lines of code include comments and white space. I have a fairly consistent coding style, so this simple metric is adequate.)

And here are some pie charts to make that data easier to visualize.

Green code is shared, and Red code is unique to the app. Lines of code and percentages are shown.

The iOS version of the app has the most amount of platform specific code, 11,532 lines worth. I can give you 1,000 reasons for this, but the gist of it is that the platform has the most effort put into it and includes an iPhone version along with an iPad version.

The Mac version did much better with only 3,901 lines of unique code needing to be written. It is particularly small because it not only shared the cross-platform code, but was also able to share a lot of driver code with the iOS version: things like the audio drivers and graphics drivers were directly shared between the two platforms thanks to the awesome work of the Mono team and Apple.

I was hoping the WP7 version would be even less, but, it turns out, it still took a good amount of effort. 5,760 lines of code had to be written accounting for nearly 20% of the code base. New graphics drivers, and new audio drivers had to be written to support the Silverlight programming model along with a lot of IsolatedStorage tomfoolery. Now, when I release Windows 8, WPF, and Silverlight versions of the app, a lot of that code will also get reused, but for now it stands on its own.

Overall, I’m quite pleased with these results. I always talk about the 80/20 rule being applied to the cross-platform/platform-specific code split and so I’m very happy that the number back me up pretty well.

I can’t wait to get on to the next platform!

My Presentation in Boston

Tue, 08 Nov 2011 15:41:07 -0800

My Presentation in Boston:

This was my first professional speaking gig. So even if it went bad, please lie to me and tell me it was good.

My Great Wumpus Hunt

Sat, 18 Jun 2011 12:53:27 -0700

There is a bug in iCircuit that is tarting to feel like my white whale, my wumpus. I know all about the bug: I know why it’s happening, I know all its symptoms, and I know at least one way to squish it.

“So what’s the problem?” you might legitimately ask. The problem is that the only fix, that I know for certain, creates a very non-Apple-esque feel to my app, and that is preventing me from implementing the fix. Apple provides the wonderful UIScrollView which, among other things provides momentum scrolling and very smooth animation. If I implement my own gestures, all my problems are solved except I miss out on the benefits of UIScrollView. End result for the user? The app feels “laggy”.

I have tried 4 times to implement different strategies to fix this bug while maintaining the Apple-feel factor. I have failed 4 times.

OK, enough generalizations, thanks for sitting through that. Here is the bug:

iCircuit uses a UIScrollView that contains 3 large (usually mostly off-screen) UIViews that componsite together to show you the circuit. This (amazingly) works fine thanks to the fantastic engineers at Apple. But I consider that implementation to be a bug because of these symptoms:

Symptom 1: Everything is all blurry!

When you zoom in to the circuit, everything becomes blurry. This is due to the simple nature of UIScrollView and the fact that I don’t change the view hierarchy at all after a zoom operation. This is the default behavior of UIScrollView and drives me absolutely batty.

Apple has a way to fix this! All you have to do is switch your code to be thread safe, stop using UIGraphics, and implement CATiledLayer in the content view of the UIScrollView. Easy huh? It actually is, and works surprisingly well. When you zoom, everything gets redrawn at screen resolution.

You’ve seen this beauty before in apps like Safari. When you first zoom in, everything is blurry and then (pretty quickly) everything gets redrawn at the new native resolution. Another +1 to Apple engineers.

Great! But it doesn’t work for iCircuit. The main UI of the app is animated at about 7 FPS (it adaptively changes the frame rate to keep your battery from dying) and this ends up being too much work for the CATiledLayer. The screen becomes a mish-mash of partially updated regions and smooth animation is out the door. This is an appropriate emoticon for my mood when discovering this: :-(

Symptom 2: Way too much Memory

A lot of users of iCircuit run into one limitation before all others: I limit circuit sizes to 2048x2048 pixels. This size limitation is in place for one and only one reason, it’s because the app runs out of memory if you increase it.

Ugh. I feel like I’m 16 again implementing code in the most naive fashion just hoping it works. It’s ridiculous to tie the logical dimensions of a circuit to an OS-tracked-super-heavy-resource. If the circuit is 2048px across, I create 3 UIViews that are also 2048px across. iOS can handle this, but what if you want a circuit that’s 10 kpx wide? The OS just doesn’t have enough memory (nor CPU) to render UIViews of that size at the framerate that I want.

So if I know this is the wrong thing to do, then why do I do it? Becuase it makes UIScrollView happy.

Symptom 3: Retina Display is Sloooow

Memory is one thing, but on iOS you get all the memory you ask for until the app is shut down. It’s a good deal. CPU, on the other hand, well, there’s only one of those and it has a lot of work to do. I’m already asking it to do a lot in solving the circuit equation in the background. Asking it to draw 2048x2048px images at 7 FPS takes about 10% of the CPU on iPhone 3GS and iPad 1.

Retina display doubles pixel counts. So my 2048x2048 circuit becomes 4096x4096px. This is an increase to memory, and worse, a burden to the CPU to draw lots of anti-aliased lines. It turns out that the iPhone 4 is not capable of this. Quickly, it falls to 3 FPS (lower limit) and the whole user experience is degrated.

Alas, this is the current state of iCircuit 1.2. I surprisingly don’t get a lot of emails about this since the app is really meant for the iPad, but it breaks my programmer heart. Again, I feel like a 16 year-old punk.

Solution 1: Wherein I try to fix it 4 times and fail every time

This post is really just an opportunity for me to vent. I hate this bug. I hate that I haven’t been able to fix it. I have ideas of how to make it better, but I haven’t been able to code any of those ideas to my satisfaction.

In a nutshell, solving the problem involves keeping 1 huge UIView for the UIScrollView to deal with. Within that view, I will place a subview that draws only that part of the circuit that the user is viewing.

Sounds simple, right? A two-hour hack, right? The devil is in the details in this one, but I still have high hopes. I lied to you before: this blog post is actually a rallying call for me. I’m about to implement this solution for the fifth time. I really want it to work, wish me luck.

Solution 2: Ditch UIKit/Core Graphics/Core Animation

I love the Apple platform. After years of writing Windows apps where Microsoft said “here’s a push button and a window object, good luck with the rest”, it’s a real refresher to work with powerful APIs that are geared toward making the programmer’s life (and thusly, the end user’s experience) better.

But if it doesn’t work it doesn’t work. The Apple platform has one last escape hatch when dealing with graphics-heavy apps: fall back to OpenGL. I know from past experiences that this will solve the majority of my problems:

Drawing will be fast because OpenGL is a monster.
This will free up the UI thread which means I can deal with the touch events. I won’t be able to match 100% the smoothness of UIScrollView, but I can get close.

There are, of course, two hurdles preventing me from taking this path:

OpenGL isn’t great at anti-aliasing. 1px lines look like they’re from 1990 and my sould dies a little death. Ironically, this isn’t an issue on retina displays since the DPI is so ridiculously high. But on chunky-pixel devices, this makes the app look amateurish at best. (Actually it makes it look like all those Windows circuit editors that I’m trying so hard not to be).
Fonts. If you’ve ever programmed OpenGL, you know what I mean. Fonts suck. They’re blurry, they take effort to manage, and they’re blurry.

THE END

Enough ranting and time to start coding. Please do wish me luck as I hunt and kill this monster. And, if, like times previous, the Wumpus should eat me for dinner, remember, it was all in the name of making an app worthy of the hardware.

Kangaroo's Pizza Dough Recipe

Thu, 17 Feb 2011 16:52:53 -0800

kangaroo: here's my recipe for ~2 10" pies
[4:44pm] kangaroo: adjust volume by bakers %ages accordingly
[4:44pm] kangaroo: 340g flour
[4:44pm] kangaroo: 241g water
[4:44pm] kangaroo: 7g yeast (I like a good sponge, you can adjust)
[4:44pm] kangaroo: 7g salt
[4:45pm] kangaroo: 7g sugar
[4:45pm] kangaroo: combine warm water and yeast to bloom
[4:45pm] kangaroo: put paddle hook on your mixer to combine dry stuff
[4:45pm] kangaroo: add wet stuff and paddle until combined
[4:45pm] kangaroo: let sit for 10 minutes
[4:45pm] kangaroo: change paddle for dough hook, and start getting your dough ball
[4:46pm] kangaroo: after about 10 minutes you should have a good ball, then add "enough" olive oil, I do this by eye
[4:46pm] kangaroo: but call it ~1tbsp
[4:46pm] kangaroo: dough hook until you get the gluten development you want
[4:46pm] kangaroo: put ball into well oiled dish (overnight ideally in fridge, if you're doing same day do it in the morning and put it in a warm spot)
[4:47pm] kangaroo: ~2-4hrs before pizza time, divide with dough scraper and reform into 2 dough balls
[4:47pm] kangaroo: dust the top with oil to avoid dough skin and put on a work surface and cover with a kitchen rag
[4:47pm] kangaroo: then just stretch/toss/whatever
[4:47pm] kangaroo: when its time to eat
[4:47pm] kangaroo: I do 550F oven preheated with stone for an hour (at least) preferably 2
[4:47pm] kangaroo: and cook for 7-9 minutes per pie, directly on the stone
[4:48pm] kangaroo: if you like a tarter dough, you can bloom a sourdough starter and use that, just drop the sugar and keep the bakers %s the same
[4:49pm] fak: how much gluten do I want?
[4:49pm] kangaroo: depends on personal taste
[4:49pm] fak: how does one recognize it?
[4:49pm] kangaroo: the thinner crust you want, the more gluten you want, but you dont want to over work
[4:49pm] kangaroo: I generally knead for 15-30 in my kitchenaid
[4:50pm] kangaroo: you can pinch off a dough ball and stretch it a bit and see the breaking point
[4:50pm] kangaroo: the thinner you want, the more stretch you want
[4:50pm] kangaroo: in the 20 minute range my dough is maybe 4-5mm
[4:50pm] kangaroo: but still with good air development
[4:50pm] kangaroo: and not too difficult to work with
[4:50pm] fak: must have air development
[4:51pm] kangaroo: you can push the yeast up to 8 or 9g if you want even more air
[4:51pm] kangaroo: but dont go much higher or you'll mess with the flavor

Quantifying reflection's slowdown in sqlite-net

Sun, 14 Nov 2010 07:51:00 -0800

Yesterday I posted R64 of sqlite-net which included some performance upgrades thanks to Joe Feser.

The tweet spread and we were asked how this compares to native performance of Sqlite. I had no answer because I’ve been drinking the MonoTouch kool-aid for awhile now and don’t even think about native performance. But the questions did have me wondering.

I know there is nothing I can do about the overhead of a managed runtime like .NET over native code, but I did wonder how much overhead my use of Reflection introduces. To keep the use of sqlite-net simple (no external tool requirements, no on the fly code compilation), I rely on reflection to read and write values from properties. That design probably won’t change since I love the ease of use of the library, but I do think its time to measure the overhead.

I wrote a little test app that serializes and deserializes 30,000 objects (most of whom’s data is textual). The app performs those operations in three ways:

Using .NET’s built-in BinaryFormatter and the [Serializable] attribute on the class.
Using a custom function that uses a BinaryReader/Writer that calls the appropriate Read/Write functions and sets the properties on the objects directly.
Using BinaryReader/Writer again but using generic reflection code that is very similar to the code that sqlite-net uses to read data from the database.

Through this, I can compare the performance of the reflection code (#3) vs the non-reflection code (#2). The use of BinaryFormatter is also put in as a control.

I ran the code 3 times on my iPhone 3GS using a Release build from MonoTouch. It writes approximately 7 MB files for each method and then reads those files back. Here are the average results:

BinaryFormatter Serialize = 10.74 s
Explicit BinaryWriter = 1.30 s
Reflection BinaryWriter = 7.79 s

BinaryFormatter Deserialize = 50.38 s
Explicit BinaryReader = 2.93 s
Reflection BinaryReader = 11.21 s

Two things are immediately visible in this data: BinaryFormatter is slow, and the reflection code is much slower than the non-reflection code.

(I have made the Google Spreadsheet with all the data publicly available.)

Reflection introduced a slowdown of 3.8x for reads, and a slowdown of 5.97x for writes. I knew that the reflection code would be slower, but it’s really good to now have that slowdown quantified.

And those are not small numbers! I was hoping for 50% slowdowns, but I guess that was too much wishful thinking.

Given the static compilation limitation of MonoTouch, the only ways to improve these performance number are to: (1) Force the user to hand-write the serialization code, or (2) Create a tool that generates that code automatically and integrate it into the build process. #1 seems like a really bad idea to me, so that leaves #2.

A somewhat related side note: I have finally looked at the Entity Framework CTP4 - specifically their code-first work. They have the same goals of sqlite-net and applaud their effort. I am thinking now of writing a little database that has the intelligence and interface of EF4’s code first but that uses a .NET database. That way, you could share code between your iOS, WinPhone, Android devices and your server. A nice thought…

INotifyCollectionChanged for cleaner more reusable code

Sat, 13 Nov 2010 12:22:32 -0800

My last post briefly described the work I did to port iCircuit to Windows Phone 7. In it, I described how the UI was broken into two large chunks: the graphical circuit editor and the “chrome”.

The chrome is all the text input fields, buttons, selectable lists - it’s really quite a monstrous amount of code. But this code is not easy to port to different platforms. Yes, I communicate between the business logic and the UI through interfaces, but those interfaces have very few implementation details. When I move to a new platform, I have to rewrite all of the chrome. This is not a technology limitation as I could write a cross platform UI library like Swing, or even port WinForms to the iPhone, but those are bad ideas. Different platforms have different interaction models that must be obeyed.

That was my thinking ever since I saw Miguel de Icaza present at Lang.net 2006. And it still is. But now having worked on simultaneously porting iCircuit to 5 other platforms (Mac, Windows via Silverlight, Silverlight, WP7, Android), I am in real need of more code reuse even on the Chrome.

My first step in that direction is to embrace INotifyCollectionChanged. This interface is part of the magic sauce that makes reactive UIs easier to code. It is used heavily throughout SIlverlight to great affect.

Imagine a mail program with a list messages in one pane, and a single message in another. Imagine that the user deletes the selected message. A bunch of things have to happen:

The UI has to close the selected message and probably show the next one in the list
The app has to delete the message from its local database
It then has to transmit the delete request to the server
And then it needs to delete the message from the message list UI

This isn’t hard to code, but gets really tedious. Now imagine moving the message from one folder to another. It has to be deleted from one list and placed onto another. All I want to do in code is say:

var folder = ...;
var message = folder.GetSelectedMessage();
var otherFolder = AskUserWhere();
folder.Remove(message);
otherFolder.Add(message);

But I also have to write this code:

var uis = FindAllUIsThatShow(folder);
foreach (var ui in uis) ui.Refresh();
uis = FindAllUIsThatShow(otherFolder);
foreach (var ui in uis) ui.Refresh();

It’s stupid to write that code. First it means I have to have a way of tracking which UI elements are looking at a folder, second it means I have to perform potentially costly Refresh operations. Those refreshes are complicated by having to manage selection states, finding minimal changes in lists, requerying, and on and on.

With INotifyCollectionChanged, we have a way for the UI to react to changes in the data model. When the data changes, the UI intelligently updates. This relieves a mental burden when programming model changes, and an architectual burden when designing the UI code.

It’s not the greatest interface - I wish it was actually more capable - but I have decided to adopt it for all my apps since it’s pretty well baked into Silverlight and, by extension, .NET.

To that end, I have implemented a new UITableViewController in MonoTouch that knows how to listen to these collection change events and updates its data accordingly. It’s a very small extension to UITableViewController, but I’m already excited by its power and ease of use.

To use it, simply assign the Collection property to an IList. The DecorateCell function is called each time the table needs to update a cell with a data item from the list. If the IList also implements INotifyCollectionChanged, then a little bit of magic happens and you get a table view that reacts intelligently to model changes. Even if your IList doesn’t implement the interface, you still get a very easy way to present data using a UITableView.

Enjoy!


using System;
using MonoTouch.UIKit;
using System.Collections.ObjectModel;
using System.Collections.Specialized;
using MonoTouch.Foundation;
using System.Collections;

namespace ObservableTableView
{
	public class RowSelectedEventArgs : EventArgs {
		public object Item { get; set; }
		public NSIndexPath Path { get; set; }		
	}
	
	public delegate void RowSelectedEventHandler(object sender, RowSelectedEventArgs e);
	
	public class ObservableTableViewController : UITableViewController
	{		
		public UITableViewRowAnimation AddAnimation { get; set; }
		public UITableViewRowAnimation DeleteAnimation { get; set; }
		public UITableViewCellStyle CellStyle { get; set; }
		
		public event RowSelectedEventHandler RowSelected;
		
		Del _del;
		Data _data;
		
		IList _collection;
		INotifyCollectionChanged _not;
		
		public IList Collection {
			get {
				return _collection;
			}
			set {
				if (_not != null) {
					_not.CollectionChanged -= HandleCollectionChanged;					
				}
				_collection = value;
				_not = _collection as INotifyCollectionChanged;
				if (_not != null) {
					_not.CollectionChanged += HandleCollectionChanged;
					TableView.ReloadData();
				}
			}
		}		
		
		public ObservableTableViewController (UITableViewStyle withStyle)
			: base(withStyle)
		{
			AddAnimation = UITableViewRowAnimation.Top;
			DeleteAnimation = UITableViewRowAnimation.Fade;
			CellStyle = UITableViewCellStyle.Default;
			
			_del = new Del(this);
			_data = new Data(this);
			
			TableView.Delegate = _del;
			TableView.DataSource = _data;
		}
		
		protected virtual void DecorateCell(UITableViewCell cell, object item, NSIndexPath path) {
		}
		
		protected virtual void OnRowSelected(object item, NSIndexPath path) {
			if (RowSelected != null) {
				RowSelected(this, new RowSelectedEventArgs() {
					Item = item,
					Path = path
				});
			}
		}

		void HandleCollectionChanged (object sender, NotifyCollectionChangedEventArgs e)
		{
			TableView.BeginUpdates();
			
			if (e.Action == NotifyCollectionChangedAction.Add) {
				var paths = new NSIndexPath[e.NewItems.Count];
				for (var i = 0; i < paths.Length; i++) {
					paths[i] = NSIndexPath.FromRowSection(e.NewStartingIndex + i, 0);
				}
				TableView.InsertRows(paths, AddAnimation);
			}
			else if (e.Action == NotifyCollectionChangedAction.Remove) {
				var paths = new NSIndexPath[e.OldItems.Count];
				for (var i = 0; i < paths.Length; i++) {
					paths[i] = NSIndexPath.FromRowSection(e.OldStartingIndex + i, 0);
				}
				TableView.DeleteRows(paths, DeleteAnimation);
			}
			
			TableView.EndUpdates();
		}
		
		class Del : UITableViewDelegate {
			ObservableTableViewController _c;
			public Del(ObservableTableViewController c) {
				_c = c;
			}
			
			public override void RowSelected (UITableView tableView, NSIndexPath indexPath)
			{
				var item = _c.Collection != null ? _c.Collection[indexPath.Row] : null;
				_c.OnRowSelected(item, indexPath);
			}
		}
		
		class Data : UITableViewDataSource {
			ObservableTableViewController _c;
			NSString _ident;
			public Data(ObservableTableViewController c) {
				_c = c;
				_ident = new NSString("C");
			}
			public override int NumberOfSections (UITableView tableView)
			{
				return 1;
			}
			public override int RowsInSection (UITableView tableview, int section)
			{
				var coll = _c.Collection;
				return coll != null ? coll.Count : 0;
			}
			public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
			{
				var cell = tableView.DequeueReusableCell(_ident);
				if (cell == null) {
					cell = new UITableViewCell(_c.CellStyle, _ident);
				}
				
				try {
					var coll = _c.Collection;
					if (coll != null) {
						var obj = coll[indexPath.Row];
						_c.DecorateCell(cell, obj, indexPath);
					}
					
					return cell;
				}
				catch {
				}
				
				return cell;
			}
		}
	}
}

Interfaces + caches = Cross Platform

Mon, 08 Nov 2010 16:19:31 -0800

iCircuit is a mobile app that lets you experiment with circuits on your iOS devices. Well, soon, it will also let you do it on your WinPhone7.

It was implemented using the innovative and very rewarding MonoTouch system. MonoTouch lets you write native iOS apps in C# with full access to .NET. MonoTouch + the iPhone made programming fun again. It was the best decision I’ve made in a long time.

On the evening of Jul 21, I was frantic waiting for Apple to approve my baby, and somewhat curious as to how much effort it would take to port the app to Silverlight.

The engine ported immediately, without change, since it was written in pure .NET and only communicated with the UI through interfaces. (Well, properly said, the UI only communicated with the engine through interfaces.)

After that, I only had to port the UI which was broken into two nice big chunks: The graphical circuit editor and the “chrome” which handled file management and all that boring stuff that makes apps “apps”.

The graphical UI was again coded against interfaces only. So to port it to a new platform, I would merely (haha, “merely”) have to implement those interfaces. Because drawing on the iPhone is immediate mode (DrawCircle(); DrawLine(); …) I designed that interface along those lines. Nearly every graphic interface in existence is immediate mode: iOS, CoreGraphics, Windows GDI, GDI+, OpenGL, DirectX, whatever you call the rendering system on Android, the Canvas element in HTML, … the list goes on and on. But there are two huge exceptions: Silverlight and WPF!

Here I had a perfectly abstracted graphics driver that fit every platform in the world except Microsoft’s new platform. Yawn. So I never got around to porting the app.

But on July 21, again, I was frantic and needed to code something. So I remembered the golden rule of programming: caches fix everything. I went about writing an implementation of my immediate mode interface that translated all those Draw*() calls to the retained mode of Silverlight (line = new Line(), Add(line)). What followed was the following check ins:

changeset:   305:ea9de0ac4a9e
user:        Frank A. Krueger 
date:        Wed Jul 21 17:49:19 2010 -0700
summary:     OMFG it's actually working

changeset:   304:7c5b310e602c
user:        Frank A. Krueger 
date:        Wed Jul 21 17:27:11 2010 -0700
summary:     Fixed bug in my crazy algo, now it works!!!

changeset:   303:fe1bd8e4a3be
user:        Frank A. Krueger 
date:        Wed Jul 21 17:17:08 2010 -0700
summary:     Work toward making the silverlight circuit render. Amazed that my idea actually seems to be working.

changeset:   301:0f223a67e40d
user:        Frank A. Krueger 
date:        Wed Jul 21 15:04:02 2010 -0700
summary:     Began the Silverlight port. CircuitLib is compiling. Yeah. Now I need to reimplement the actual UI :-(

In a little less than 3 hours I had it working. God I love caches and interfaces.

Making it work on the phone was just a matter of setting up the project in Visual Studio and recreating the chrome (something I’m still working on today).

Today, Nov 8, I got to find out if my method worked - and oh boy did it! The phone is chugging along right now rendering circuits.

In conclusion: I love .NET. I love MonoTouch. My WinPhone7 is sweet. It’s a great time to be a developer!

My First MonoMac App - Spy Touch

Sun, 04 Jul 2010 12:18:00 -0700

The Mono team has recently given the world MonoMac, a framework that allows C# programmers to write native OS X (Cocoa) apps. This is wonderful news for those who simultaneously love OS X and C#.

I decided to take her for a spin by writing a little (very little) app that will assist me in my app development.

Windows developers have an app called Spy++. I grew up with this little beauty as I was learning Win32 programming. It was invaluable for learning the structure of GUIs and discovering the little tricks other programmers used to make their GUIs work the way they did. Later, we got Managed Spy for WinForms and Snoop for WPF.

We don’t have anything like these tools for MonoTouch. Well, now we do! (And by like, I mean: has 1/100th the features.)

This little app (can I say little enough?) displays the active visual tree of your app while it is running. As you navigate the visual tree, the active view gets highlighted in a little visualizer on the right hand side.

To use this tool, you just need to install a little stub client in your app. Include the file SpyTouch.cs, and put the line SpyTouch.SpyTouch.Run (); somewhere in your startup code. Here is a package containing Spy Touch, the stub, and its source code.

Now you can monitor the visual tree of the app. It refreshes automatically every 2 seconds.

The usefulness of this tool isn’t very high because it is just a proof of concept of tools to assist me in the design of GUIs for iOS apps. Now that I have this tool, I am very excited about future possibilities in constructing UI designers.

Jabroni, Jabroney, or Jaboney

Sat, 29 May 2010 18:14:00 -0700

Long story short: Jabroni is the modern form of Jaboney, American slang used to mock someone, somewhat vaguely, since at least 1931. The online etymology dictionary defines a jaboney as a “naive person, immigrant, hoodlum.”

The Long Story

Recently on No Agenda, Adam Curry was wondering about the etymology of “Jabroni”. Since I’ve heard the word all my life, I was dismayed that the internet credits it to The Rock… almost everywhere.

I started my search with the Goog of course, Goog Books to be exact. I was looking for a reference prior to 1990, that is, prior to The Rock. Some matches were found, but most of those matches seemed to be the Goog book OCR system incorrectly matching Fabroni.

And then I got lucky and ran into this internet question: Jaboney or Jabroney. The consensus on the form was to use the spelling with an “r”, but I was intrigued enough to try Goog Books again. I searched for Jaboney prior to 1990 and hit the jackpot.

The first hit that caught my eye was A-18: a novel by Thomas Taylor written in 1967. In the book, he uses the word just as we would today:

“She got the jaboney to marry her, so I didn’t have to support her too long.”

(There is a second use, but Goog cut it off.)

In addition to the reference in this novel, American Speech vol. 6 from 1931 lists the word but unfortunately there is no scan of the page available. Now I’m off to the Seattle Library to see if I can find it.

There are further references in 1934, 1949, 1953, 1969, 1987, 1989, and more.

So it’s pretty certain that those WWE wrestlers didn’t make this one up.

Obligatory First Post

Sat, 29 May 2010 09:24:19 -0700

From custom blogging software, to blogspot, to tumblr, this blog has seen a lot of engines.

I hope tumblr will be its final home.