Thanks for clearing it up somewhat. On Jul 23, 4:25 pm, Matt Quigley <[email protected]> wrote: > On Jul 23, 2:37 am, Indicator Veritatis <[email protected]> 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 [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
