iPhone: Cells order changes in UITableView Section After Call to reloadSections: Method

Question

I have a table with two sections. A segmented control in first sections changes which rows are displayed in the second section. My problem is that the order of the rows and which row are displayed in the second section shifts improperly upon each subsequent press of a button in the segmented control.

I allow a user to add a product to a shopping list 3 different ways: by name, by barcord and by taking a picture with a camera. I have 3 buttons in a UISegmentedControl so the users can select which method to use. Depending on which segement the user selects the fields in the second segment should change to show cells relevant to that method.

Section 0:
    0 row with segmented control showing name, barcode and camera buttons
Section 1:
    // button zero, name button
    0 row with textfield
    1 row with textfield 
or 
    // button 1, barcode button
    0 row with textfield
or 
    // button 2, camera button
    // shows camera view

I've put placeholders in each UITextField.

Each time a button in the segmented control is clicked, I call a pickOne: method that updates the tablevew. In that method, I construct a NSIndexSet with NSRange of (1, 1), and then I call the reloadSections: method of the UITableViewController with the NSIndexSet as a parameter.

When the view appears for the first time, everything is ok but when I click the buttons repeatedly, the order of the cells changes. Cells containing the two textFields for the button0 and the new placeHolders are written over the old ones. Worse, sometimes when I click on button 0, it shows me only the second cell of the two cells.

My detailed code can be seen here http://pastebin.com/9GwMpCS9

Answer 1

The information in this "answer" belongs in the parent question. I have moved it there -- TechZen.

Answer 2

I'm seeing a couple of problems.

The first big one is that you're adding subviews into the cells bypassing the contentView. Subviews in predefined styles are broken up into different parts depending on their roles. You have the editing control, the content view, and the accessory view. While you can add directly to the cell's view, there'll be odd behavior because the predefined cells are expecting the content to be in the content view.

I think what's causing your problem is that you're adding subviews every time a cell is decorated but you never remove them. When a cell is dequeued there's no guarantee that everything is restored to the pristine new condition as if it was alloc'ed. Things like custom accessory views that aren't removed can be left behind. I'm pretty sure that's happening. You're collecting visual trash on cells that should be clean.

Answer 3

I believe your problem is here.

// Customize the appearance of table view cells.
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    //....

        if(addMode == NAME) {
            if(indexPath.row == 0) {
                [cell addSubview:nameTextField];
            }
            else if(indexPath.row == 1) {
                [cell addSubview:categoryTextField];
            }
        }
        else if(addMode == BARCODE) {
            [cell addSubview:barcodeTextField];
        }
        else if(addMode == SCAN){

            //Scanning mode
        }
    }
    return cell;
}

This because the table always shows has having two sections, this method is always called for section 1. Regardless of the input type selected, it creates or dequeue a cell and returns it. Whenever addMode==SCAN, it randomly dequeues one of the previously used cells for the name or barcode addMode and returns that.

I suggest that you remove the SCAN logic from the table altogether or that you create a row for the camera.

I think the latter the best UI. With the first two buttons, the users is presented with a choice in the second section. You should maintain that pattern with the camera choice. Just have a cell that displays a button that evokes the camera. Yes, it adds a second step but establishes a kinetic pattern for the user: Select input type in section one then select an appropriate cell in section two. The user shouldn't have to stop and think each time whether they need to hit one of the rows in section two or not. They should just do so automatically.