I think the difference in the code I've written in the past was I was
referring to a window progress bar and not an independent view in the
onPostExecute.
That's why I was getting a Null Pointer when the activity was killed.

I'm starting to get a grasp on this stuff. Clearly I don't know how
the GC works.

Thanks for the links guys. I'll keep reading.

David Shellabarger
www.nightshadelabs.com

On Jul 22, 5:26 pm, GodsMoon <godsm...@gmail.com> wrote:
> Perhaps the difference was because I was declaring my view in the
> onCreate method instead of in the onPostExecute method of the
> AsyncTask?
>
> If I declare the view in my activity, maybe it gets GCed when my
> activity is killed, but in the blog post example he tries to declare
> it in the AsyncTask even though the activity is long gone.
>
> Am I on the right track here?
>
> David Shellabargerwww.nightshadelabs.com
>
> On Jul 22, 4:09 pm, Joseph Earl <joseph.w.e...@gmail.com> wrote:
>
>
>
> > I am confused somewhat about the issue myself now. Hopefully someone
> > else it will clear it up once and for all.
>
> > On Jul 22, 9:01 pm, GodsMoon <godsm...@gmail.com> wrote:
>
> > > I have done something like that and got a null pointer reference.
> > > I was starting a AsyncTask and if you backed out of the activity
> > > before the AsyncTask was finished I would get a null pointer when I
> > > tried to refer to the activities elements (force close).
> > > So I just check to see if the views are null first. I thought that if
> > > it returned null then it must have been GCed.
> > > But that's not the case?
>
> > > David Shellabargerwww.nightshadelabs.com
>
> > > On Jul 22, 3:49 pm, Joseph Earl <joseph.w.e...@gmail.com> wrote:
>
> > > > When your UI activity is killed as far as I am aware the GC will
> > > > collect your Views. The problem is (I think) if the GC closes your UI
> > > > thread while the downloader is still running - in this case your
> > > > downloader thread maintains a reference to the ImageView so the GC
> > > > cannot collect it - hence memory leak - the downloader thread cannot
> > > > actually do anything to the ImageView since the UI thread no longer
> > > > exists.
> > > > Thus the downloader thread should only store a weak reference to the
> > > > ImageView so that if the UI thread is killed the GC may reclaim the
> > > > memory associated with the ImageView.
>
> > > > On Jul 22, 8:34 pm, GodsMoon <godsm...@gmail.com> wrote:
>
> > > > > The blog post is confusing.
> > > > > "Note that this ImageView is stored as a WeakReference, so that a
> > > > > download in progress does not prevent a killed activity's ImageView
> > > > > from being garbage collected."
> > > > > I didn't know that would cause a memory leak. I thought the garbage
> > > > > collector would clean up ImageView if its activity gets killed.
> > > > > Am I wrong?
>
> > > > > David Shellabargerwww.nightshadelabs.com
>
> > > > > On Jul 22, 3:06 pm, Joseph Earl <joseph.w.e...@gmail.com> wrote:
>
> > > > > > No. I'm unsure as to what to use a WeakReference for exactly - as
> > > > > > Romain Guy said above it is too weak for this purpose, but I think
> > > > > > (hopefully Romain will correct me if I'm wrong) that a SoftReference
> > > > > > could be suitable for this purpose.
>
> > > > > > A ListView already does efficient management of your Views by
> > > > > > recycling. This means that you must ensure the correct details are 
> > > > > > set
> > > > > > in the view each time getView is called, even if you do not inflate 
> > > > > > a
> > > > > > view or call findViewById that time. Recycling does not mean that 
> > > > > > the
> > > > > > ListView caches all your items or their content.
>
> > > > > > Suppose you had a list of 10 items, all of the same type but only 5
> > > > > > will fit on the screen at a time. The ListView only really needs 5
> > > > > > views to show the rows since the other 5 won't be visible.
> > > > > > Thus at the top of the list the ListView might use 'View 1' for the
> > > > > > first item, but scroll down to the bottom and 'View 1' would now
> > > > > > contain item 6. As far as I understand it this is recycling.
>
> > > > > > Recycling does not take care of the amount time of it takes to get
> > > > > > content and set it to the view - thus if it takes a long time to 
> > > > > > get a
> > > > > > piece of information and display it in a list item (such as
> > > > > > downloading an image from the web), you will want to cache the 
> > > > > > result
> > > > > > in a way that does not adversely affect memory usage (as much as
> > > > > > possible). In this case you will also want to use a Thread or Async
> > > > > > task to download/get the info off the UI thread.
>
> > > > > > On Jul 22, 7:36 pm, GodsMoon <godsm...@gmail.com> wrote:
>
> > > > > > > So you'd only want to use WeakReference when you think your 
> > > > > > > activity
> > > > > > > might run out of memory?
> > > > > > > But a list view already does efficient memory management for you
> > > > > > > right?
>
> > > > > > > You'd saying if I were create a large array or something like that
> > > > > > > then it would be good to use WeakReference. right?
>
> > > > > > > Thanks for the help guys,
> > > > > > > David Shellabargerwww.nightshadelabs.com
>
> > > > > > > On Jul 22, 2:26 pm, Romain Guy <romain...@android.com> wrote:
>
> > > > > > > > You definitely do NOT want to use a WeakReference to cache 
> > > > > > > > object. If
> > > > > > > > you do so, as soon as your data is put in the cache and not used
> > > > > > > > outside of the cache, it gets garbage collected.
>
> > > > > > > > On Thu, Jul 22, 2010 at 11:07 AM, Joseph Earl 
> > > > > > > > <joseph.w.e...@gmail.com> wrote:
> > > > > > > > > Suppose you had a long list of images. As the user scrolled 
> > > > > > > > > down you
> > > > > > > > > load the images from the net, and then display them.
> > > > > > > > > To avoid having to reload the images again if the user 
> > > > > > > > > scrolls back
> > > > > > > > > up, you put the images in a cache (probably something like a
> > > > > > > > > Map<String, Drawable>)
>
> > > > > > > > > However because it is a long list you don't want to run into 
> > > > > > > > > an out of
> > > > > > > > > memory situation if the user scrolls very far down and lots 
> > > > > > > > > of images
> > > > > > > > > are put in the cache.
> > > > > > > > > So instead of storing the Drawables directly in the map, you 
> > > > > > > > > create a
> > > > > > > > > Map<String, WeakReference<Type>> (although I would use 
> > > > > > > > > SoftReference
> > > > > > > > > for the purpose described here).
> > > > > > > > > This means that if Android is going to encounter an out of 
> > > > > > > > > memory
> > > > > > > > > situation it will clear all of the Soft/Weak references (and 
> > > > > > > > > thus
> > > > > > > > > hopefully avoid running out of memory). You will have to load 
> > > > > > > > > the
> > > > > > > > > images again since your cache has been cleared, but this is 
> > > > > > > > > far better
> > > > > > > > > than your application running out of memory and crashing.
>
> > > > > > > > > So you do something like:
>
> > > > > > > > > // caching an image
> > > > > > > > > Map<String, SoftReference> cache = new HashMap<String,
> > > > > > > > > SoftReference<Drawable>>();
> > > > > > > > > cache.put("http://mysite.com/images/1.jpg";, new
> > > > > > > > > SoftReference<Drawable>.put(myDrawable));
>
> > > > > > > > > // retrieve an image
> > > > > > > > > if (cache.containsKey(url)) {
> > > > > > > > >   // looks like we have this image cached
> > > > > > > > >   Drawable drawable = cache.get(url).get();
> > > > > > > > >   if (drawable == null) {
> > > > > > > > >       // the softreference has been cleared by the GC, reload 
> > > > > > > > > the
> > > > > > > > > image
> > > > > > > > >   } else {
> > > > > > > > >       // softreference is still valid, got our image
> > > > > > > > >   }
> > > > > > > > > }
>
> > > > > > > > > Essentially a weak reference is a weaker reference than a soft
> > > > > > > > > reference - the GC should free weak references to regain 
> > > > > > > > > memory before
> > > > > > > > > soft references.
>
> > > > > > > > > I think that's (mostly) correct, hope it helps.
>
> > > > > > > > > On Jul 22, 6:48 pm, GodsMoon <godsm...@gmail.com> wrote:
> > > > > > > > >> Google just posted a new blog post 
> > > > > > > > >> onhttp://android-developers.blogspot.com/2010/07/multithreading-for-per....
> > > > > > > > >> I understand the AsyncTask and I'm even using one in a list 
> > > > > > > > >> with
> > > > > > > > >> images already.
>
> > > > > > > > >> But I don't understand what a WeakReference is. I gather is 
> > > > > > > > >> is a
> > > > > > > > >> garbage collector directive, but I thought I didn't need to 
> > > > > > > > >> manage
> > > > > > > > >> garbage collection on Android.
>
> > > > > > > > >>http://developer.android.com/reference/java/lang/ref/WeakReference.html
> > > > > > > > >> isn't as helpful as I was hoping it would be.
>
> > > > > > > > > --
> > > > > > > > > You received this message because you are subscribed to the 
> > > > > > > > > Google
> > > > > > > > > Groups "Android Developers" group.
> > > > > > > > > To post to this group, send email to 
> > > > > > > > > android-developers@googlegroups.com
> > > > > > > > > To unsubscribe from this group, send email to
> > > > > > > > > android-developers+unsubscr...@googlegroups.com
> > > > > > > > > For more options, visit this group at
> > > > > > > > >http://groups.google.com/group/android-developers?hl=en
>
> > > > > > > > --
> > > > > > > > Romain Guy
> > > > > > > > Android framework engineer
> > > > > > > > romain...@android.com
>
> > > > > > > > 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 Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to