Like many iOS productivity apps, several screens in The Hit List feature an editing mode. While in that editing mode, among other changes, the toolbar items get swapped out for a different set of commands.
The swap is mostly straightforward to make (more on that in a minute). When switching mode, we simply change the view controller’s toolbarItems property to match.
But where do those items for the editing mode come from? We could create them programatically — as existing versions of The Hit List have been doing — but where’s the fun in that? I want to use Interface Builder if I can!
In the previous entry, I discussed how we load up shared toolbar items from the navigation controller, rather than define them directly for each view controller. Happily, this leaves us the toolbar free to define in the Storyboard Editor for other purposes, such as this:
If you’re not so lucky as to have this free “slot” in your storyboard, a couple of alternatives:
- Cram into the toolbar items for both modes; at runtime remove those that aren’t applicable to the current mode
- Set up the toolbar items in the list of auxiliary objects associated with the view controller; sadly you lose out on being able to preview those items directly, but you can at least tweak their properties in Interface Builder
For either, I dare say IBOutletCollection would come in handy for referencing the items.
There is a slight spanner in the works. As a convenience, we want to support the ability to swipe on a table cell and delete a task directly from there.
An interesting quirk of how the frameworks implement this is by switching the whole view controller over to be “editing” while the “Delete" button is visible. I think the main reason for doing this is so the standard “Edit" button switches to read “Done”, giving more novice users an easy avenue to cancel the edit.
Great for the Edit button, but bad for our toolbar. We don’t want the toolbar switching over unless the user is explicitly in editing mode.
As far as I can find, there is no direct way to query the view controller or table view when a swipe-to-delete is in progress. Instead, we have to track that ourselves:
Update: I thought of an alternative way to do this, albeit a bit of a nasty one.