the class name of the table. each table view cell must have a unique class name if the cell layout is different. however, use the same name for rows that have the same structural layout (even if the content is different) to provide maximum rendering performance.

Fair enough. But after playing with “real” iPhone developement for a couple of days, it makes more sense. The className is the row’s “reusableIdentifier” in Cocoa’s terms. It is used for enabling reuse of row objects, so that when rows move off the screen their instances can be reused.

Thus it makes sense, that as rows are reused, we must make sure that all rows with the same class name have the same structure. I didn’t realize that earlier, so I had written code like this:

function mapListingToTableViewRow(listing) {
    var row = Ti.UI.createTableViewRow({ height: 53, className: "listing", hasChild: true });

    if (listing.pictures.length > 0) {
        var pic = listing.pictures[0];
        var imageView = Ti.UI.createImageView({ image: pic.url, width: pic.width, height: pic.height, left: 0 });
        row.add(imageView);
    }
    var label = Ti.UI.createLabel({ text: listing.title, left: 80 });
    row.add(label);

    return row;
}

This function builds up a row with the className “listing”, always adding a label, but only adding an imageView if there is an image on the listing. Sounds ok, right? What if Cocoa tries to reuse a row that only has a label, for a row that needs both image and a label? The app breaks down. It turned out that the error was in the method updateChildren in the Objective-C class TiUITableViewRowProxy. In particular, it was the first line in this for-loop that failed:

for (size_t x=0;x<[subviews count];x++)
{
    TiViewProxy *proxy = [self.children objectAtIndex:x];
    TiUIView *uiview = [subviews objectAtIndex:x];
    [self reproxyChildren:proxy view:uiview parent:self touchDelegate:contentView];
}

The cause was simple: the subviews were two, but the proxy array only contained one object.

Going back to the JavaScript code, this was easy to fix – adding an empty image view did the trick:

function mapListingToTableViewRow(listing) {
    var row = Ti.UI.createTableViewRow({ height: 53, className: "listing", hasChild: true });

    if (listing.pictures.length > 0) {
        var pic = listing.pictures[0];
        var imageView = Ti.UI.createImageView({ image: pic.url, width: pic.width, height: pic.height, left: 0 });
        row.add(imageView);
    } else {
        row.add(Ti.UI.createImageView({});
    }
    var label = Ti.UI.createLabel({ text: listing.title, left: 80 });
    row.add(label);

    return row;
}

This problem was driving me crazy a couple of days ago – I almost dropped using Titanium because of that. But after getting an insight into how things work underneath, and by running the Titanium app in debug mode through Xcode, I quickly was able to track down the error. So if you're running into strange breakdowns - fire up Xcode, set it to stop on Objective-C exceptions, and step through the breaking code. Hope you'll have the same luck as I did!

As this is something LaTeX doesn’t provide out of the box, my first idea was to do some post processing with the PostScript tools that you have on a Unix system. But introducing an extra tool wasn’t feasible at all: Running LaTeX from a webapp is fragile enough. Fortunately, LaTeX is just a module for TeX, and TeX is nothing but a programming language. So there most definitely is a way for doing this in plain TeX. Unfortunately, programming in TeX is everything but straight forward. Luckily I can’t resist language challenges…

And I did it! Here is my LaTeX macro that makes the number of pages in the document a multiple of some number:

The loop construct is the tricky part. It’s of the form

\loop
  ...
  \ifsomething...
  ...
\repeat

The if-statement in the middle controls whether we continue the loop or break out. Today, most people are probably more used to seeing the above logic written like this:

while (something) { .... }

A thing to note is that TeX-loops allow for statements to be run both before and after the if-statement is evaluated. Code before the statement is run in each iteration, similar to traditional do {} while (...) loops, but the code after is only run if the if-statement returns true:

\loop
  % Code to run in each iteration (do-while style)
  \ifsomething   %
  % Code to run if the if-statement above returned true (while-style)
\repeat

Finally, note that the if-statement must not have a closing \fi, as most if-statements in TeX have.

Tip: Finding material on programming in TeX is hard, but the TeXbook provides some help. Deep down in chapter 20 there are some examples of looping and conditionals, which proved to be enough for me.

Update: kongo09 came up with a more robust solution to this, which also works when resetting the page counter. See below. Thanks kongo09!

Ukulele chord progressions

The progressions currently lack some basic variations, most notably some seventh chords. So that’s up next!

Ukulele and guitar versions coming!

Here it is: Mandolin chord database.

The implementation is pure JavaScript, using the canvas element for displaying the chords.

Recently I’ve been working with developers new to jQuery, and it has come clear to me that my code – as simple and smooth I find it – is often hard to understand. I’ve gotten the same looks I would get presenting a Perl-golf program. Ah well, maybe not quite. But you get my point.

I have set to make my code more readable, without making it ugly. Below are a few best-practices I’ve made for myself.

Break down long chains

Here is a typical bit of code I might write:

$('table')
    .find('.activate').click(function () { activate(this.id) }).end()
    .find('.deactivate').click(function () { deactivate(this.id) }).end()
    .find('a').show();

Long chains of code tend to use jQuery commands like end and andSelf to modify the wrapped set. Those methods are good to have when you know them, but their semantics can’t be easily deducted from their names. A long chain performing many tasks can also be harder to walk through than smaller independent bits. So it is wise to break chains down:

var table = $('table');
$(table).find('.activate').click(function () { activate(this.id) });
$(table).find('.deactivate').click(function () { deactivate(this.id) });
$(table).find('a').show();

This version – without doubt – lacks the beauty of the chain above, but is more readable, especially to someone unfamiliar.

Bind events using explicitly using bind

Having the same method to bind and fire an event is bound to confuse – hell, I get confused again and again:

$('select')
    .change(function () { ... })
    .change();

Explicitly calling the bind command to bind to the change event is much easier to grasp:

$('select')
    .bind('change', function () { ... })
    .change();

This holds for all events who have shortcuts for binding, e.g blur, click and mousedown.

Clarify what this means

The this keyword is probably one of the most infamous elements in the JavaScript language. And even when you’ve gotten fluent in using it, you never can be quite sure it’s used the same way in the same contexts.

This is a typical code snippet:

$('a')
    .addClass('logged')
    .bind('click', function() {
        logUrl(this.href);
    });

What does this point to? This example is that simple, and the href attribute that specific, that it’s maybe not hard to guess. But in more complex situations it’s hard to find out.

Copying this to a clearly named variable does a great deal in clarifying what’s going on:

$('a')
    .addClass('logged')
    .bind('click', function() {
        var clickedLink = this;
        logUrl(clickedLink.href);
    });