Yeah I think this would belong in Dialog. On Tue, Feb 10, 2009 at 10:34 AM, Jonathan Herriott <[email protected]>wrote:
> > 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. > > > -- 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 -~----------~----~----~----~------~----~------~--~---
