EditText items in a scrolling list lose their changes when scrolled off the screen

Question

I have a long scrolling list of EditText items created by a SimpleCursorAdapter and prepopulated with values from an SQLite database.

I make this by:

cursor = db.rawQuery("SELECT _id, criterion, localweight, globalweight FROM " + dbTableName + " ORDER BY criterion", null);

startManagingCursor(cursor);

mAdapter = new SimpleCursorAdapter(this, R.layout.weight_edit_items, cursor, new String[]{"criterion","localweight","globalweight"}, new int[]{R.id.criterion_edit, R.id.localweight_edit, R.id.globalweight_edit});    

this.setListAdapter(mAdapter);

The scrolling list is several emulator screens long. The items display OK - scrolling through them shows that each has the correct value from the database.

I can make an edit change to any of the EditTexts and the new text is accepted and displayed in the box.

But...if I then scroll the list far enough to take the edited item off the screen, when I scroll back to look at it again its value has returned to what it was before I made the changes, ie. my edits have been lost.

In trying to sort this out, I've done a getText to look at what's in the EditText after I've done my edits (and before a scroll) and getText returns the original text, even though the EditText is displaying my new text. It seems that the EditText has only accepted my edits superficially and they haven't been bound to the EditText, meaning they get dropped when scrolled off the screen.

Can anyone please tell me what's going on here and what I need to do to force the EditText to retain its edits?

Thanks

Ian

Answer 1

But...if I then scroll the list far enough to take the edited item off the screen, when I scroll back to look at it again its value has returned to what it was before I made the changes, ie. my edits have been lost.

Of course.

List rows get recycled. Your Cursor may have 1,000 records, but there are not going to be 1,000 EditText widgets created if you scroll through the list. Rather, there will be 10 or so, depending on how many rows are simultaneously visible. Rows get recycled, and the binding operation will replace the old EditText value with a new value from the Cursor for whatever row just scrolled onto the screen, replacing whatever was there before (previous value from the database or a user-edited value).

And, since a regular Cursor is immutable, you have no way of persisting any edits in a way that will transparently be put back into the list.

I suspect it is possible to create a ListView with rows that are EditTexts, probably by creating a custom Adapter class and handling all the row recycling yourself. However, it is going to be a fair amount of work, and the built-in classes will only give you a bit of support for this pattern.