I am sure this is in the Apple documentation or must have been answered somewhere on this forum, since it seems so basic, but I could not find it nor a particularly elegant
OK, I figured out a simple solution after a lot of web-surfing, forum reading, and manual reading. It was, as I suspected, very simple, only one line of code added. In the viewWillDisappear
method of the EditViewContorller I simply added:
[self.view.window endEditing: YES];
Now textFieldShouldEndEditing
, textFieldEditingEnded
, and textFieldDidEndEditing
all get fired off before the viewWillAppear
of the master view does.
So now the viewWillDisappear
method looks like:
- (void) viewWillDisappear: (BOOL) animated {
[super viewWillDisappear: animated];
NSLog( @"In viewWillDisappear" );
// Force any text fields that might be being edited to end so the text is stored
[self.view.window endEditing: YES];
}
And the methods already in place to handle the 'Return' on the keyboard also handle the 'Back' button on the Navigation controller.
Thank you Aaron and Jeff for your assistance and helping me think this through.
I would think that from a UX perspective, you should display an alert to determine if the user wants to cancel the edit action they were in the middle of before exiting the current view.
By alerting the user, you can see if they hit the button by accident or if they did decide to leave the view, take the appropriate action.
// add this to the field(s) to be edited, selector will be called as the changes
// are being made... still difficult to handle a cancel, but should work
[objectToEdit addTarget:self action:@selector(updateNameField:)
forControlEvents:UIControlEventEditingChanged];
additional code here...
// the method called to update object from parent view
- (void)updateNameField:(id)sender {
<OBJECT TO UPDATE>.text = ((UITextField *)sender).text;
}
Why not just create your own Back button with that logic in its action method?