Concern

Recently I’ve been working on an iPad-native interface for WOD. I did it the straightforward-ish way: make it a split view, with the source lists and navigation on the left (or in a popover in portrait mode) and put the detail view on the right. It was, overall, pretty simple to do, but I ran into some issues that I thought I’d write about.

The first issue was odd: occasionally, the navigation views on the left would get wonky; the color scheme is such that it’s white text on a dark background (the built-in, dark textured background), but occasionally these views would switch to a white background, and some of the views wouldn’t get populated with data anymore. This happened when memory pressure started hitting, and views needed to be unloaded.

I spent a long time trying to figure this out; I thought the problem might have been with UINavigationController, which people say is really only meant for full-screen views, or as the “root” view controller of a split view.

So, I spent some time reimplementing UINavigationController from scratch, and produced this: https://github.com/csm/CustomNavigationController. This is also nice, because it supports custom animation directions.

This wasn’t the problem, though; the problem was that I was subclassing UITableViewController in each of the content views, but wasn’t setting the view property to a table view: instead, it was a container view that held the table view. Well, it seems that if a UITableViewController gets unloaded, it doesn’t seem to re-load this correctly from the nib: instead, it was creating a brand-new UITableView that had the default settings and occasionally, didn’t have the delegate or dataSource properties set properly. So the solution was actually simple: just subclass UIViewController and implement the appropriate protocols. UITableViewController seems really optimized for just handling a single table view, so it’s better to just ignore UITableViewController if you’re doing anything fancy.

But anyway. I made something neat out of the process.

Note, this is a start of this implementation, and I don’t consider it complete. In particular, I’d like it to take advantage of concurrency and Grand Central Dispatch in the future, and expand it to different kinds of sequences.

But anyway, I decided to give implementations of map, reduce, and filter for iOS development a try. Here we go.

First, let’s define some function block types:

typedef id (^MapBlock)(id);
typedef id (^ReduceBlock)(id, id);
typedef BOOL (^FilterBlock)(id);

This defines block types that (1) apply a function to an object, returning the result; (2) takes an accumulation as the first argument, the next object in the sequence as the second, and returns the next accumulation; and (3) is a simple predicate, which takes an object and returns a truth value based on that argument.

Now, let’s define a category for NSArray:

@interface NSArray (mapReduceFilter)
- (NSArray *) arrayByMappingWithBlock: (MapBlock) block;
- (id) valueByReducingWithBlock: (ReduceBlock) block;
- (NSArray *) arrayByFilteringWithBlock: (FilterBlock) block;
@end

And then, a straightforward implementation:

@implementation NSArray(mapReduceFilter)

- (NSArray *) arrayByMappingWithBlock:(MapBlock)block
{
    NSMutableArray *ret = [NSMutableArray arrayWithCapacity: [self count]];
    for (id value in self)
    {
        [ret addObject: block(value)];
    }
    return [NSArray arrayWithArray: ret];
}

- (id) valueByReducingWithBlock:(ReduceBlock)block
{
    id ret = nil;
    for (id value in self)
        ret = block(ret, value);
    return ret;
}

- (NSArray *) arrayByFilteringWithBlock: (FilterBlock) block
{
    NSMutableArray *ret = [NSMutableArray arrayWithCapacity: [self count]];
    for (id value in self)
        if (block(value))
            [ret addObject: value];
    return [NSArray arrayWithArray: ret];
}

@end