When you say there isn't enough information, I'm assuming you mean that the views don't know when they are being released from memory. In that case, the two options would be to have views death-aware or to have the Dialog manage its lifecycle. I'm sure the choice really boil down to performance/memory usage, and in that case, the Dialog managing its lifecycle is probably the best option. If you agree, I'll file a new bug on the Dialog.
On Feb 10, 10:16 am, Dianne Hackborn <[email protected]> wrote: > Dialog is a good point, but the lifecycle would need to be managed by the > dialog, not by ListView. At the ListView level there just isn't enough > information to manage it correctly -- that is, the management that would be > added for Dialog would be fairly different that what we currently have for > Activity. > > On Tue, Feb 10, 2009 at 10:13 AM, Jonathan Herriott <[email protected]>wrote: > > > > > > > > > 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. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
