Should I use QuickDialog?

Posted by ESCOZ on Thursday, October 18, 2012

This is an answer I originally gave for a question at the IphoneDevSDK forums, but people ask me this frequently, so I thought it would be nice to leave this answer here as well.

In my experience, making simple tableviews by implementing cellForRow:atIndexPath: is easy, and works well for simple lists. But for more complex things, like a form with 10-20 fields and different kind of cells appearing based on different conditions, things break down very quickly, and you end up having either an extremely long if/else returning lots of custom types of cells. Apple’s approach to this is to make you use static tableviews in storyboard, which are not dynamic at all and just make things a thousand times more complicate. Maybe someday storyboards will support all the kind of stuff we need, but it’s still far from that.

So the traditional solution is to either have that long if/else list that will likely have lots of bugs, or you end up abstracting things, so that you have a “model” of what you want to display, and your datasource just goes thru those items and display them automatically. Nothing amazing, just traditional OO patterns.

Well, QuickDialog, at its core, is just that: a lightweight abstraction of a table; it’s just a collection of simple objects that explain what should go into a list. Then I have a tableView/delegate that can go thru that tree of objects and display things as well as handle touches. If you just use the QElement (which translates to a row) and QSection (which translates to a section), that’s all you get. You don’t need to use anything else in the project, and if you follow the installation instructions, all the stuff you didn’t use will be automatically stripped by the linker.

But here’s the cool thing: now that you have a model of what should appear in a list, you can start to make really interesting things, like: – you can have a RootElement, which has more sections in it, so that when the tableview sees it, it knows it has to push a new controller automatically with that new table. This can go many levels deep, like the settings app. – or you could have elements to enter text/booleans/integers/etc, so you don’t have to write the same stupid logic to show and hide the prev/next buttons on top of the keyboard over and over and over – or you could store the entire tree of elements in JSON, and remove all that code from your ObjC code – or you could actually serve that JSON file from the web so that the form that appears on your app is completely driven from the web (like apps like Yelp and the AppleStore do) – or you could automatically bind values from your real domain model (from coredata or some JSON obj you loaded) to the form (with a tiny bit of configuration) – or you can automatically translate every string that appears in your JSON file without having to do anything.

Those are some of the things QuickDialog does. It won’t help with every project out there, but it works really well for a lot of them.

Performance wise, overall QuickDialog is really fast; pretty much as fast as just using a tableview directly. Creating thousands of rows and displaying them takes only a few hundred milliseconds. But nobody wants to see a link of blank items, or the same string over an over on a table; when you have a really long list, you usually want to read those values from a database somewhere. If that’s the case, having to load all the objects upfront to create the Root of your table might cause performance bottlenecks. If you’re just reading data from the web though, it’s usually really fast. So my general approach is: are you creating forms with a few dozen/hundred rows? QuickDialog. Thousands of rows? Raw UITableViewDataSource. Anything in between? Depending on the case I could go either way. Performance for ridiculously large lists is something I still want to figure out, specially when using databinding. It can be done, I just haven’t done it yet.

I’ve used it in many of my apps (Quicklytics, QuickAdsense, and a lot of business apps), and every day I get contacted by people using it for their projects, which is awesome. I hope you use it too!