Ok, "odd" is not the right word. "surprising" maybe. Surprising to me anyway in a "gotcha" type way.
Sure, on closer examination, it makes sense. Still, I think its an easy one to miss. The problem lies with modifying (close()) the state of something (Cursor) which is already being relied on by something else (ListAdapter notifiers). On Apr 9, 9:30 pm, Mark Murphy <[email protected]> wrote: > westmeadboy wrote: > > Fixing this should solve the problem but I maintain its still odd (and > > a potential bug many devs would miss) that calling Cursor.close() > > could lead to such an exception. *ducks* > > I'm not sure why you think it's odd, that's all. > > It's been discussed many times that you have to modify Views from the UI > thread. Calling close() on a Cursor in use by an AdapterView will cause > a modification of that View, because there are no more rows to show, and > so Android wants to get rid of the rows that are there. Otherwise, if > the user tried scrolling, you'd blow up at that point. > > Hence, you have to call close() on the UI thread, or detach the Cursor > from the View before calling close(). The fact that the > Cursor/CursorAdapter are modifying the View, rather than directly from > your own code, matters not a whit. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android App Developer Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
