On Jul 23, 2: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.
You are referring to the code that Joseph Earl wrote above. That code snippet is NOT a proper way to use weak references; that cache should be using soft references. On the other hand, in the example blog post referred to by the OP, which uses weak references, that IS a proper way to use weak references. The main Activity already has a strong reference to the objects. The secondary thread does not need to create a strong reference; in fact, that would make the weak reference useless. > 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. You are referring to a soft reference, not a weak reference. Soft references are good for caches. Weak references are definitely recommended for the idea given in the article, where the main thread has a strong reference, and the background thread has a weak reference. That way if the main thread is killed (i.e. the app is finished), if the background thread is still running then it won't prevent the weakly referenced objects from being destroyed. I also hate to throw this bit of information into the mix, but it should be known that Android will kill your process, and hence background threads anyways, when all your main threads have been destroyed (i.e. all your activities are finished, and there aren't any services running). This means that, even if you did have a background thread running, it would be killed, implying that weak references wouldn't help because everything is going to get killed anyways. That being said, there are still circumstances where the weak references matter: just because one activity is finished, doesn't mean all of your app's activities are necessarily finished. So it would be good if you went from your main activity into another sub-activity which began a download. But then the user presses back, because they don't want to bother waiting on the download. In that case your main activity is still alive, but the background thread is working on the sub-activity that was already finished. If that background thread had weak references, then that background thread would no longer be holding on to the resources of the sub-activity with strong references, and the system could GC those resources already, before the background thread dies. -Matt -Matt -- 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
