Coming back to New York after a couple months away, I’d accumulated quite a few odds-n’-ends that needed attending to. In the meantime, I was anxious to get back to work, and so I took a brief detour and joined the ranks of indie developers who, unwilling to accept the multitudes of existing well-executed Twitter clients, decided to build my own. But mine’s a little different. I’ve dubbed it a “novelty” Twitter client, which really only stands to discourage consumption by those who assume it might actually be a traditional (read: fully capable) client. Takeaway Tweets allures not by it’s array of features as compared to existing clients, but rather by it’s lack there-of.

And so I bring you Takeaway Tweets. Half mystic, half Twitter client, it is, at the very least, unlike any Twitter client you may have used. Takeaway Tweets begins by scouring Twitter for tweets marked with the hashtags #TakeAwayTweets or #FortuneTweets. What it finds, it wraps in fortune-cookies and presents to users of the app for consumption. The premise, then, is essentially crowd-sourced fortune tweets. Mixed with a little sauce to favor user-tagged fortune tweets over the fortunes of the anonymous masses,  extended to support wrapping a user’s entire timeline in fortune cookies (well, up to eight entries), it actually progressed into something that, once-or-twice a day, can be quite fun to use. I’ve yet to find any other  Twitter client that suggests the act of consuming of a single tweet  be any more crunchily-satisfying.

Half the fun, of course, is reading and sending wisdom-filled tweets to friends, so naturally the app supports traditional Twitter functions such as compose, reply, retweet, and quote.

Given a relatively modest scope and feature set,  Takeaway Tweets moved quickly through design and production, but it did give me the chance to dabble in a few areas of the SDK that I’ve been meaning to dabble in since last year’s WWDC:  This represents my first  Automatic Reference Counting project (incidentally, also the first project I did what my first Obj-C teacher told me I never would: Found a leak in an Apple framework), it was also my first foray into Storyboards (really, really fast if you can work within the confines). This is also the first app where I developed all the art and audio components completely independently.

It’s on the app store, and it’s guaranteed to entertain you for at least 3-5 minutes while you try and figure out how to use it.

Grab a copy!

My February side-project was submitted to Apple several days ago, and I’m currently awaiting acceptance. This is a  delicious novelty Twitter client app for iPhone and iPad.

Details to follow on launch, but in the meantime, check it out for yourself at http://www.takeawaytweets.com/

I’m a big fan of UITableViews, as a class they enjoy the distinction of being completely ubiquitous and  complete workhorses, whilst still managing to look gorgeous. But they must be treated delicately, for example best practice dictates that table’s cell views be reusable, and the architecture of UITableView reflects that. Recently, I wanted to create a  table view that made heavier use of section headers by allowing the user to “tap” a section header and only then disclose its rows (also ensuring that only the rows from one section are visible at any given time). It’s quite possible I’ll have many more section header views scrolling by at any moment than I will have actual rows, and so it occurred to me that a similar enhancement approach (it’s a flyweight pattern) might benefit my header (and footer) views as they’re being presented by the table view. My solution isn’t as sophisticated as what happens with cell queueing, but it still delivers big-time in Instruments, and only takes a few moments to implement.

It’d be pretty simple to implement this functionality in a shared cache singleton class, but for my purposes , I’m going to avoid creating any additional subclasses and just add a few methods to my UITableViewController (the one Apple gave me in my project template). In this case, I’m using custom controller’s for my views (these controllers are a subclass of NSObject, not UIViewController) because I want to design my cells and wire my outlets in Interface Builder (you could easily omit the controller aspect altogether).

*Note: This sample assumes use of automatic reference counting. If you run this code in a manually managed memory project, you’ll end up with quite a few leaks.

Our adventure begins at the landing point for a handful of Apple’s Xcode templates: An empty subclass of UITableViewController. Because we’re essentially storing views that our controller will be presenting, I create an NSMutableDictionary property on the class to store our reusable view’s (controllers) in:

MasterTableController.h
…
@property (strong, nonatomic)  NSMutableDictionary *reusableControllers;

-  (void)registerController:(Controller *)controller forReuseIdentifier:(NSString *)reuseIdentifier;
-   (Controller *)reusableControllerForReuseIdentifier:(NSString *)reuseIdentifier;

Let’s hop over to implementation:

MasterTableController.m
…
@synthesize reusableControllers = __reusableControllers;

Our first method registers an existing controller for reuse:

- (void)registerController Controller *)controller forReuseIdentifier:(NSString *)reuseIdentifier
{

NSMutableDictionary *reusableDictionary  = [self resuableControllers];
if (resuableDictionary == nil)
{
reusableDictionary = [[NSMutableDictionary alloc] init];  //creates a storage dictionary if one doesn’t exist
[self setReusableControllers];
}

NSMutableArray *arrayForIdentifier = [[self reusableViews] objectForKey:reuseIdentifier];
if (arrayForIdentifier == nil)
{
arrayForIdentifier = [[NSMutableArray alloc] init]; //creates an array to store views sharing a reuse identifier if one does not exist
[reusableDictionary setObject:arrayForIdentifier forKey:reuseIdentifier];
}

[arrayForIdentifier addObject:controller];

}

The second method retrieves an available controller (along with it’s view). Because our table view controller doesn’t inform us as our section header & footer views scroll on and off the screen (we aren’t given opportunity to flag/file a controller as being available for reuse), we use a block, enumerate our controllers (don’t worry, there will never be more than the minimum quantity required to occupy the screen) and determine if any posses a view that isn’t currently on screen:

- (Controller *)reuseableControllerForIdentifier:(NSString *)reuseIdentifier
{

NSArray *arrayOfViewsForIdentifier = [[self reusableControllers]  objectForKey:reuseIdentifier];

if (arrayOfViewsForIdentifier == nil)
{
return nil;  //We don’t have any of this kind!
}

NSInteger indexOfAvailableController = [arrayOfViewsForIdentifier indexOfObjectPassingTest:^BOOL(id obj, NSUInteger idx, BOOL *stop)
{
return  [[obj view] superview] == nil;   //If my view doesn’t have a superview, it’s not on-screen.
}];

if (indexOfAvailableController != NSNotFound)
{
Controller *availableController = [arrayOfViewsForIdentifier objectAtIndex:indexOfAvailableController];
return availableController;    //Success!
}

return nil;

}

And that, my friends, is that. Because I’m feeling verbose, I’ll toss in a sample method demonstrating use. Here’s our template method providing our table it’s headerView:

-  (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section
{

static NSString *headerReuseIdentifier = @”headerView”;

Controller *headerController = [self reusableControllerForIdentifierString:headerReuseIdentifier];

if(headerController == nil) //Didn’t locate a reusable
{
headerViewController = [[Controller alloc] initWithNib:@”MyHeaderViewNib” bundle:nil];
[self registerController:headerViewController forReuseIdentifier:headerReuseIdentifier];
}

return [headerController view];

}

Lastly, don’t forget to nil out your reference to the reusableControllers property on your class when you unload. You could additionally empty the dictionary in low-memory conditions.

Apple has approved for sale my first children’s book app, a joint venture with acclaimed illustrator and children’s book author Craig Frazier, titled Stanley Mows the Lawn. Without spoiling the story, Frazier’s well-loved Stanley character appears in this title to perform the rather unpleasant chore of mowing his overgrown lawn, and, encountering the bewitching Hank the Snake in the process, is inspired to complete the task in uniquely inspired fashion.

Craig is a remarkable illustrator and it was a great pleasure to bring the inspired work of his print book to life-in-pixel on the iPad (there are two more titles from the series which will be available as soon as rights issues have been cleared).

This was my first attempt at a digital book, and technology-wise it drew from the interactive experiences of a number of existing book and children’s books apps. The functionality is primarily flip-based page turning, with peripheral features including the ability to record audio (as in, record your own narration to the book, with the option of turning the written text that accompanies the illustrations off altogether), an embedded animated short, and a touch-driven game that allows the user to mimic Stanley’s efforts in creatively maintaing a well manicured lawn.

The app utilizes the following development frameworks:
A combination of UIKit provided and custom-designed interface elements, all in beautiful orange and tangerine.
Core Animation powers all book-related animations, namely page turning.
AVFoundation provides audio recording and playback functionality, as well as presents the animated short.
OpenGL powers the visual effects in the game, alongside CoreAnimation and e-mail/print services.

The core functionality of the app is quite  simple and versatile – it accepts a folder full of PNGs, and, when accompanied by a simple XML/Plist file containing the text associated with each page, presents a flippable “book”.

Stanley Mows the Lawn is intended for an audience ages 4+, and it’s available now.