When using hierarchical table views (e.g. with a Navigation Controller) to enter or edit information, the proper sequence of UI events can be surprisingly subtle. Consider what happens when you edit a phone number in the Contacts app:
- You click on the number (in the “Edit” mode of the “Info” view)
- The row highlights blue
- The “Edit Phone” view scrolls in from the right
- You change the number, and press “Save”
- The “Edit” mode of the “Info” view scrolls in from the left
- The row highlight fades out
Note that when the “Edit” mode of the “Info” view scrolls in from the left, the edited number field shows the new value, before the highlight fades out. This is a tricky effect to achieve.
What Doesn’t Work
Simply popping the child view off the Navigation Controller’s stack won’t work; the parent’s row highlight will fade properly, but the row will still display the old value.
The natural impulse might be to update the parent view with a reload call in (void)viewDidAppear:(BOOL)animated:. Unfortunately, this will clear the row highlight immediately, so you won’t get a pleasing fade effect on the highlight if you perform the reload before the deselectRowAtIndexPath:animated: call.
On the other hand, if you perform the reload after the deselectRowAtIndexPath:animated: call, you’ll get a nasty “pop” as the cell’s value changes suddenly, after the table has scrolled into view, and the fade has completed.
What Does Work
In order to get the proper effect, you have to locate the selected row and change its contents before scrolling the parent view back onscreen. I like to do this with a target-action callback pointed at the parent’s view controller; it’s a little wordy, but it seems to work ok.
