UISplitViewController is a really neat class that can do both the neat “on ipad, show the main/detail paradigm”, and showing the regular “navigation controller with main, then go to detail if you tap somewhere”.
On iPad, to get both the main and the detail to show up, set the
preferredDisplayMode property to
You should also make sure you’re displaying a navigation controller in your detail, so you can include the UISplitView
On iOS, a UITableView is a subclass of a UIScrollView. While I understand why this is the case (99% of the time, you want a scrolling tableview), I’ve been starting to think that the OSX/cocoa approach of having them be separate classes is actually a better approach. But, I can see that this might have made the implementation of UITableView much easier to just always assume it’s in a ScrollView.
It used to be that you had to use a
UITableViewController and it’s
refreshControl property to get a pull to refresh behavior. This is no longer the case. As of iOS 10, you can set
refreshControl property to get a refresh control on any scrollview (and any subclass). Of course, on earlier versions of the OS, you can also add the refreshcontrol as a subview of the scrollview, and it’ll still work. This is just less magical in how you do it.
The old (pre iOS 7) way of dismissing the keyboard when you scroll is to use UIScrollViewDelegate methods to be notified when the scrollview scrolled, and then call
-resignFirstResponder from the scrollview.
At first glance, the crash log will read like you tried to access an object that had already been deallocated. However, the giveaway is that
0x8000000000000000 address. This suspicious address tells you that you have a concurrent write bug. Somewhere, you have a race condition with multiple threads writing to the exact same address at the same time.