Combining multiple UITextFields and a UITableView in a nice way for an iPhone app: part 2

My last blog post was about creating a form for an iPhone application by combining multiple UITextFields in a UITableView. I outlined the problems with this kind of screens. The first problem is the destruction of data already entered when scrolling the field off screen and secondly, app crashes when the field with focus is scrolled off screen and you touch inside another textfield. The solution I proposed was to nest the UITableView inside a UIScrollview. After receiving feedback I came up with a second solution:

  1. extend a UITableViewController instead of implementing UITableviewDataSource and UITableViewDelegate yourself
  2. disable reuse of cells by using a unique cell identifier:
  3. NSString *CellIdentifier = [NSString stringWithFormat: @"Cell%i", indexPath.row];

    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

    if (cell == nil) {

    cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];



The UITableViewController handles scrolling into view when the keyboard is shown quite nicely. Using the unique identifier will prevent a cell and it’s content to be reused. And I had to agree to some of the feedback: using a UIScrollView to nest a tableView is kind of a hack.

There is a down side to this: UITableViewControllers don’t like to be combined with other view controllers, so you have to use a NavigationController or TabBarController to offer further interaction possibilities. I tried to, but never managed nicely to have for instance a UIToolBar over the UITableView.

Try it out and let me know what you think!

Download XCode project TestTableViewWithKeyboard2 with demo using UITableView to create a form.

Combining multiple UITextFields and a UITableView in a nice way for an iPhone app

Update: also read Part 2 explaining a different way of solving this problem.

So a decent number of iPhone apps will not only show things like data, but also offer you the possibility to edit data. Many controls like UISlider, UISwitch and UITextfield are provided by Apple to create some type of edit screen, almost like a web form on a HTML page. Creating a simple form that only covers the top half of your screen is simple: you create your elements like UITextField at the top, and when you touch inside the field the onscreen keyboard will show up. You hit a Done Button or a non-UITextField control and the keyboard disappears again.

Now, when you have more data to add/edit than will fit in half a screen, things get more daunting:

  1. the keyboard should only be visible when editing a UITextField
  2. when touching a UITextField so that the keyboard becomes visible, it should not cover the field you are editing
  3. with the keyboard visible you should still be able to scroll to all elements of your editing form, and not have parts be covered indefinitely by the keyboard

Well, the most natural kind of view to use to display all controls is a UITableView. Apple uses it herself, look at the editing screen for your settings. But when you just throw in a UITableView, you run into problems:

  1. when scrolling off screen, table cells are reused and therefore also its subviews like UITextFields, which causes your newly entered data to be destroyed
  2. when having a UITextField being firstResponder (cursor in it),  you scroll it off screen and the touch inside another UITextField that then becomes firstResponder, your app will crash. This is problably because the first UITextField is destroyed before it can resignFirstResponder

So how do we do this then? Apple does use a UITableView in some way, but the above problems are show stoppers. Well the answer is: use a UITableView, but don’t let it scroll.

Continue reading