b1ueskyz wrote:
Nobody warned me yesterday was a holiday!
I would've mentioned it, Phil, but I wasn't sure folks down in Paso Robles knew about the 4th. Guess you're not as far off of 101 as I remember. I didn't have the opportunity to miss the celebration. My kids scored enough ordnance to keep Watsonville safe for democracy until next summer. I don't know why you couldn't have seen the Grand Finale from your place.
Anyway I'm back working on your text fields again. I fixed the items on my todo list, but now I've run into a problem that might be organic.. not sure there's an easy workaround. It seems that when a text field gains the focus (becomes first responder), the table view somehow knows this and automatically scrolls the containing cell into the middle of the visible area. This happens despite sending any scroll-to messages and so far I have no idea whether this behavior can be turned off.
In other words, suppose cell 5 is in the middle, with cell 4 visible above and cell 6 visible below. When you hit the return key, this code runs:
- (BOOL)textFieldShouldReturn:(UITextField *)textField {
// get the current first responder
NSLog(@"textFieldShouldReturn: textField.tag=%d", textField.tag);
// identify the next cell and scroll it into view
int nSection = (textField.tag - kTextFieldTag + 1) % kTableViewSections;
NSLog(@" nSection=%d", nSection);
NSIndexPath *indexPath = [NSIndexPath indexPathForRow:0 inSection:nSection];
[self.theTableView scrollToRowAtIndexPath:indexPath
atScrollPosition:UITableViewScrollPositionNone animated:YES];
// find the textField for the cell and make it first responder
UITableViewCell *cell = [self.theTableView cellForRowAtIndexPath:indexPath];
if (cell == nil) {
NSLog(@" ** cell not ready");
// set first responder in willDisplayCell
nextSection = nSection;
}
else {
UIView *textField = [cell viewWithTag:kTextFieldTag + nSection];
[textField becomeFirstResponder];
}
return YES;
}
UITableViewScrollPositionNone should scroll the table only if the next cell isn't visible. So if you edit the text field in cell 5, then hit return, the table view shouldn't scroll if cell 6 is already visible. That's what I think the user would like. I.e. I think it's distracting if a form scrolls when it doesn't need to. But as soon as 6 gets the focus it's scrolled into the middle of the visible table regardless of where it was to begin with.
If there's no good way to prevent this extra scrolling, I might prefer to put the text fields onto an ordinary UIScrollView instead of UITableView. Hopefully the scroll view isn't as smart as the table view and won't care where the focus is.
Re: your todo's -
1. I wasn't planning on letting the focus wrap around from 8 to 0. Wondering if it's really necessary.
No, it's not necessary. Many similar interfaces wrap around, so I thought you might want that. Remember there's no other way to return to a field from the keyboard. But it's certainly not necessary.
Btw, the above code indicates how I solved the wrap around problem. If the return from cellForRowAtIndexPath is nil, we assume the cell we want isn't visible yet. In that case we save it's section no. in an ivar and wait to set the focus until that cell comes up in willDisplayCell.
2. I'm wondering if, since it's a small hardcoded environment, the reuse of cells is more trouble than its worth? There will always be exactly 9 sections with exactly 1 cell each. Seems it could be much more straight forward to create 9 cells. Choose which cell to use based on indexPath.section. And get a free ride on determining the contents of that cell.
I don't think we have a choice about reusing cells. UITableView always queues cells for reuse as soon as they're no longer visible. That's how it can show thousands of cells without running out of memory. It only needs to keep as many cells as are visible at any one time. So your cells would only stay put if all 9 were always visible.
But the memory management isn't nearly as complicated in an ordinary scroll view. So if you chose that option, the 9 text fields would always be in the same place relative to the content view.
Could also help your #3 concern.
#3 went away when I realized cellForRowAtIndexPath is the only place that loop is needed. When I came back to the code with a (relatively) clear mind, I saw that we know exactly what tag we're looking for at every other point, since it will always correspond to the index path (duh!).
I think the option of using UIScrollView becomes attractive if you're not using a grouped table view. If you want the look of a grouped table view--the rounded borders like Contacts->New Contact->Add New Address--then it might be worth the effort to solve the problem discussed above. But if you were planning on a plain table view for a more linear look, you might want to consider an ordinary scroll view.
- Ray
