Actually, I would disagree with this characterization. In many cases, it's completely infeasible to maintain the information you'd need. For example, if you provide an API that accepts objects, and you maintain some internal information about them -- you have no opportunity to track the client's use of the API. You COULD warp the API to require the client track this information for you -- but they'd get it wrong, and the result would be a less-efficient and more unreliable package.
It's also inefficient to track that. Especially in cases with circular references, where simple reference counting cannot work. In many cases, what you end up having to do is to implement your own GC of these objects. Using WeakReference means you don't have to do that; the GC itself informs you. So it's not just an easier way to avoid poor programming. It's far more valuable and essential than that implies. Let's say I have a persistence package, that maintains a huge mass of information for immediate real-time access about a player. It streams in from a database, and stays around in memory. Now, let's say I have a client of that, that's one node in a grid. Players come and go from grid to grid, join the game, leave the game, even permanently. And not just players -- objects come, go, are changed. you have a rich mix of lightweight objects, and heavy-weight back-end data in support of them. A WeakReference is really the only sane way to manage this. The back- end can associate its data with the Player and Object's using a WeakReference. When a Player disappears from memory, perhaps moving on to another realm, the back end can then persist any changes and free the storage. (It can even arrange to be notified of this, or it can do it as a background sweep when not busy). I cast that as an MMO game to grab your interest, but it could also be something much more mundane, like a shopper's web session, and loaded product description objects. If no shoppers are browsing a product, it can be GC'd. In this case, you might use a map with a WeakReference for the key, and a SoftReference for the data. The WeakReference allows you to drop the mapping when the shopper goes away; the SoftReference allows you to reclaim the storage if you're running low on memory. Without the WeakReference, you'd continue to hold onto the shopper or player AND the mapping, just by remembering the association in a table. On Jul 22, 3:36 pm, DanH <[email protected]> wrote: > " So you'd only want to use WeakReference when you think your activity > might run out of memory?" > > Not exactly. If you use poor programming techniques just about any > long-running operation can run out of memory. WeakReference is an aid > to keep you from having to use much more complex techniques (like > reference chains) while still having "good" programming practices. > > On Jul 22, 1:36 pm, GodsMoon <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > 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 <[email protected]> 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 [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 > > > > -- > > > Romain Guy > > > Android framework engineer > > > [email protected] > > > > 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 [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
![http://mysite.com/images/1.jpg"](http://mysite.com/images/1.jpg"){kind=link}