If the garbage collector deletes an object I have a "hard" reference
to, it's broken. Doesn't matter if it runs in a different thread or a
different country. Once I have executed ref() and stored the result
somewhere in my VM (in stack or in another object) that object cannot
be deleted until I overwrite the value.
On Jul 25, 7:19 pm, Indicator Veritatis <mej1...@yahoo.com> wrote:
> As the author of the IBM Developerworks article I referenced mentions,
> that is not good enough. The Garbage Collector runs on a different
> thread, you have no control over when it will be called. It is quite
> possible that just after you test for null, the GC is called, and it
> is no longer valid. Not likely, but possible.
>
> If instead you create a strong reference and use that, discarding it
> when done, then you have shut the door on a really nasty transient
> bug.
>
> Or perhaps the version of 'ref()' you found did this for you? What
> package did you find it it?
>
> On Jul 23, 5:21 am, DanH <danhi...@ieee.org> wrote:
>
> > Yes, you must "guard" any use of the WeakReference by taking the ref()
> > of it, testing that for null, and then proceeding to use the result of
> > the ref() if not null. The size of the "guarded" sections is up to
> > the programmer -- if too large then the object will never get deleted,
> > if too small then the code gets chopped up.
>
> > On Jul 23, 1:37 am, Indicator Veritatis <mej1...@yahoo.com> wrote:
>
> > > You left out something very important: the code hidden under "//
> > > reload the image" must not assume that it is not itself interrupted by
> > > yet another call to the garbage collector. That is, instead of simply
> > > continuing to use the soft/weak reference, it should make a strong
> > > reference to the same object, allowing this latter reference to either
> > > go out of scope or be set to null when it is done.
>
> > > But if we are making this strong reference, what was the point of
> > > using the weak/soft reference in the first place? Ah, that is the
> > > tricky thing about using them. Depending on when you can make and
> > > release the strong reference, they might not buy you much; they might
> > > not buy you anything at all. That is why they are not recommended for
> > > much outside of caches and normalized mappings.
>
> > > On Jul 22, 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
![http://mysite.com/images/1.jpg"](http://mysite.com/images/1.jpg"){kind=link}