I really don't do much else with mPeople, though I can think of two
other things it might be. As I said, mPeople does supply a
ListAdapter. Is it possible that is doing some behind the scenes
cloning? Perhaps more likely, mPeople is populated by a CursorLoader
attached to the Contacts content provider. I am not 100% clear on the
semantics of loaders (I've been working from the docs and from
examples), so maybe something I'm not accounting for is triggering the
loader to asynchronously refresh mPeople. To be safe I guess I should
throw in a class to loader.stopLoading() once mPeople has been
populated.


Jay

On Nov 6, 1:57 pm, Dianne Hackborn <[email protected]> wrote:
> Well as far as I know ArrayList won't just do this behind your back.  I
> would assume there is something else your app is doing that isn't shown
> here.  Are you sure you never change what is in mPeople that could cause a
> new instance of an object to be created?
>
>
>
>
>
>
>
>
>
> On Sat, Nov 5, 2011 at 10:16 PM, Jay <[email protected]> wrote:
> > Thank you for the reply. Is there some other mechanism by which the
> > objects in my array might be replaced with objects with the same type
> > and contents but different identities (i.e. don't compare as equal
> > using the default implementation)? Because that seems to be what is
> > happening (intermittantly).
>
> > Thanks,
> > Jay
>
> > On Nov 6, 12:00 am, Dianne Hackborn <[email protected]> wrote:
> > > None of the methods you are using will copy an object.  Generally you
> > must
> > > explicitly call clone() to do this.
>
> > > On Sat, Nov 5, 2011 at 6:25 AM, Jay <[email protected]> wrote:
> > > > I assume this is an Android question, though it may just betray my
> > > > ignorance of Java memory management.
>
> > > > I have an activity designed to randomly pick a person from a list, and
> > > > to not repeat anyone until everyone has been chosen. The core logic of
> > > > the pick method looks like this:
>
> > > >        ArrayList<Person> peopleCopy = new ArrayList<Person>(mPeople);
> > > >        peopleCopy.removeAll(mRecent);
> > > >        Person person = peopleCopy.get(mRNG.nextInt(peopleCopy.size()));
> > > >        mRecent.add(person);
> > > >        // Display chosen person in UI
>
> > > > Both mPeople and mRecent are referenced by adapters that feed into
> > > > ListViews.
>
> > > > The bug I was finding is that the same person was being chosen more
> > > > than once in a cycle, despite the code above. I had a hell of a time
> > > > tracking it down; I couldn't duplicate it on the emulator or on the
> > > > actual device when connected to the debugger. I finally managed to
> > > > "catch" the bug in progrss on the device and plug it in to the
> > > > debugger. Based on the object id fields, it appears that the problem
> > > > is that the Person objects referenced my mRecent were different from
> > > > the ones in peopleCopy, which is why the removeAll method was not
> > > > subtracting them correctly. I implemented appropriate equals() and
> > > > hashcode() methods on Person and that seems to have fixed the problem.
>
> > > > My question is where/when/why were the Persons in mRecent and/or
> > > > mPeople being replaced with clones? It wasn't happening all the time;
> > > > based on observations with the debugger, it appears that usually the
> > > > lists referenced the same objects as I expected them to. Does the
> > > > framework sometimes clone objects referenced by adapters or does Java
> > > > or am I misreading this whole situation?
>
> > > > Thanks,
> > > > Jay
>
> > > > --
> > > > 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
>
> > > --
> > > 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, and so won't reply to such e-mails.  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 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
>
> --
> 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, and so won't reply to such e-mails.  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 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

Reply via email to