jessecurry

https://github.com/jessecurry/keylime

After being swamped for the better part of a year I’ve finally got a little breathing room and decided to begin the monumental task of taking all of the generic iOS  code  I’ve written and pulling it into a nicely packaged, reusable library. Granted, a lot of the code was written under less than ideal conditions, with deadlines looming, and due dates trumping elegance; but I hope to remedy all of those problems over the next few months.

Developing software for iOS I find myself solving the same problems again and again, and I hate to repeat myself. keylime is an attempt to eliminate boilerplate code from my projects, allowing me to rapidly solve the same old problems and move on to the interesting stuff. One of the biggest wastes of time that I’ve dealt with in any of my iOS projects is the population UITableViews, the code is always the same, and not particularly interesting. With keylime I adopted a few conventions that let me eliminate 90% of the work I have to do to create and populate a UITableView. First, I use reasonable names for the UITableViewCells. If I am displaying a cell that represents a Person object, keylime will look for a PersonTableViewCell. There is a way to override this behavior, but I haven’t had to in a long time. Each KLTableViewCell has a method configureWithDataObject: that can be overridden to populate the cell’s subviews. When a cell is selected my view controllers receive a didSelectDataObject: message and can decide how to respond (in many cases I move all of the response conditions to a base view controller). The data that drives a UITableView can be an NSDictionary, NSArray, NSFetchedResultsController, or a class I created called KLTableData; mixing elements within these containers is no problem, keylime will pick the correct cell type at run time.

Another problem that I’ve had to solve time and time again is connecting to web services, I’ve taken a look at RestKit, but at the time it didn’t really fit my needs. In keylime I have a WebServiceConnector, just point it at a URL, and it will connect, pull data down, and parse a JSON response (I may implement XML, or a generic parsing engine, but it’s just JSON now), there’s even the ability to set a root URL so you can easily switch between testing and production. I’m leveraging the TouchJSON library for the parsing and couldn’t be happier with the results. When I first implemented the WebServiceConnector I was making one request at a time, but I recently added request queuing, I can set the maximum number of simultaneous requests and the WebServiceConnector will automatically make sure to limit the number of active connections.

The last useful chunk of keylime is the categories, every time I run into a problem that can be solved with a category I’m going to push it to keylime; right now I have some categories to help with consuming the structures returned by the JSON parser (NSNulls can be a bitch), a category to clean up NSStrings, and a category to help with common NSManagedObject fetches (allObjectsInManagedObjectContext:). If nothing else I’d love keylime to become a one-stop shop for incredibly useful categories.

I’m making an effort to compartmentalize keylime’s functionality, allowing a developer to use just the pieces they need, or the library as a whole, with just a few imports. Regardless of adoption keylime will be my personal utility library, but I’d love to get some other people using it as it matures, and contributing to it as they find new problems that need to be solved.