iOS - UITableViewController vs. a TableView widget

In iOS, lists are actually called tables. However, to keep the terminology (somewhat) consistent, I'll continue to refer to them as lists.

Lists are managed by a widget named TableView. In fact, they're used so extensively, that Apple developed a special view controller to manage the list: UITableViewController.

For this example, I've decided against using a UITableViewController class, because it assumes that the entire view will be a TableView widget. So, when additional custom navigation controls are added - such as a toolbar - the behavior becomes a bit unpredictable. In the following screen shot, I expected the button bar to appear at the bottom of the screen. However, since there are only two items in the list, the button bar "floated" up to the bottom of the list.

Another reason I decided against using a UITableViewController concerns application navigation. The table view controller encourages a consistent navigation pattern. In this case, the recommended approach is to use a UINavigationController class to push and pop views on and off the view stack. When this occurs, iOS automatically handles the navigation controls on the screen.

In my experience, navigation isn't always hierarchical. A user may be viewing the details of a fishing spot, but then want to manage information about a recent outing. In situations like this, I feel that the UINavigationController behavior can get in the way of a positive user experience.

Clearly, there are times when the default behavior of a navigation controller is warranted. And in those situations, there are plenty of examples on the web of how to use this approach. But for Futile Fishing, I plan to use my own custom navigation approach. (This also lines up much better with Android navigation.)