This is in reference to issue # 1944. http://code.google.com/p/android/issues/detail?id=1944
I know I am being nitpicky, but a similar issue happens when I do: AlertDialog.Builder builder = new AlertDialog.Builder(context); builder.setCursor(someCursor, onClickListener); builder.show(); If I do that and close the dialog, the cursor leaks as well. Since the lifecycle of a Dialog is not the same lifecycle as an Activity, using a managed query doesn't make sense, so I have to close the cursor in both the onClickListener and an OnKeyListener even if I didn't plan on implementing an OnKeyListener (to manage the back button). See my point? If the dialog's Adapter doesn't get rid of the resources it no longer needs, I would consider that leaking memory in the sense that the cursor is hanging around even when it is no longer needed. And if the user opens the dialog more than once, then multiple cursors are left open unless explicitly closed by the developer. This all, of course, assumes that a Cursor object's lifecycle is only that of an adapter's lifecycle, which by how I've seen Cursors treated, I would assert this to be true. Are there instances where a cursor is left open and used in multiple adapters? Even so, the Adapter should be notified when its lifecycle is over, and when the Adapter is instantiated, I should be able to specify whether it needs to cleanup on close or not. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" 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-framework?hl=en -~----------~----~----~----~------~----~------~--~---
