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.
