Empty UITableViews with DZNEmptyDataSet

One item on my iOS 8 wish list from May was a new UIKit API for empty content views in UITableView. A simple UITableView data source method where you can return a UIView. UITableView would then intelligently display the provided UIView whenever there was no content in the tableView.

But WWDC passed and no such luck. Luckily, DZNEmptyDataSet to the rescue! You can find it here on Github.

It's easy to add to any project using UITableView or UICollectionView and it's being updated regularly.

So this...                                                                                  ...Becomes this!

UITableView with default no content behavior.

UITableView with default no content behavior.

UITableView with an empty content view

UITableView with an empty content view

I've tried many other open source projects and rolled a few techniques myself but none came as close as DZNEmptyDataSet.

Why use an empty content view? Primarily for communicating to the user why the screen is empty and how to add content. It's highly unintuitive, especially on first launch, to display blank rows (as seen in the first image). While a good UI design is self-explanatory and helpful, the default implementation is not.

In the example on the right (taken from Bug Trackr 1.2), I tell the user there isn't any content saved, what they can expect this view to contain, and how to add content. In this case, even though I have an add button at the top right of the screen, I include an "Add Bug" button in the empty content view. Both buttons trigger the same action. This makes it crystal clear that to get new content, you have to tap the add button.

It may seem obvious but, for users launching an app for the very first time, an empty tableView is jarring and confusing.

Apple's default implementation in UITableView is far from ideal and it's interesting that for most of Apple's own apps they implement an empty content view (private API). Until Apple makes their empty content view API public, DZNEmptyDataSet is here to fill the gap.

Coding Nits

But I’ll take the opportunity to point out some things I noticed.

Accessors shouldn’t be of the form getSomething. Drop the get.

#define SOME_CONSTANT 10 isn’t Cocoa-like. Better is static const NSUInteger PBSSomeConstant = 10; (Where PBS is replaced with your prefix.)

If you’re calling something a Handle, it should be an actual Mac memory Handle. And we shouldn’t be using Handles anymore.

All of your class names should have a prefix. All of them.
— http://inessential.com/2014/05/03/more_coding_nits

A sample of Brent Simmons' rules we Cocoa (Touch) developers should all be following. Some great stuff in there.

iPhone 6 Protruding Camera

Images posted on Weibo claim to show an iPhone 6 under testing at Foxconn, via GforGames. The validity of these images cannot be confirmed, but the shots do line up with previous rumours. The iPhone 6 depicted here has a protruding camera (similar to the current design of the iPod touch), rounded edges and a considerably thinner profile than the current iPhone 5s.
— http://9to5mac.com/2014/03/31/purported-iphone-6-pictures-show-protruding-camera-rounded-edges/

If Apple has made the (supposed) decision to use a protruding camera design for the next iPhone model, then clearly we're still missing a large part of the puzzle.

The obvious reason for Apple to use a camera module that sticks out from the main device body is to minimize overall device thickness. It's also a decision, I'm guessing, that Jony Ive would want to avoid at all costs. The iPhone camera has been flush with the body for every model including the current iPhone 5s. So why bring attention to it?

For the iPhone to become even thinner than the 5/5s, they would need thinner components like the display and battery. It appears, based off of leaks and rumours this far, that Apple has accomplished just that. But, they couldn't thin down the camera module any farther.

If thinness is the only reason for a protruding camera, I would rather stay at the iPhone 5s thickness. This phone is already pretty damn thin, I'm happy with it and I suspect the vast majority of users are.

Apple wouldn't make a design decision like this unless they had a great reason to and I highly doubt "thinness" is it.

Could we be seeing magnetic optical lens support? Apple has patents on the subject and this is the best guess I can come up with.

Aside from that, I'm baffled.