Re: [android-developers] Re: What is a WeakReference?
Java also gives you enough rope to hang yourself. Just have to try a
little harder to find it.
Here is an example from production code ummm u some 12 years
ago (written by someone else).
class Item {
String myKey;
Hashtable myHashtable;
.
Item (Hashtable table, String key) {
myKey = key;
myHashtable = table;
myHashtable.put(myKey, this);
}
protected void finalize() throws Throwable {
myHashtable.remove(myKey);
}
}
Instant circular reference, no garbage collection. This brought an
enterprise-level server system down to its knees over a few hours :)
-- Kostya
27.07.2010 12:11, AlanLawrence пишет:
However, presumably (only occasionally) screwing it up includes
creating circular data structures...???
--Alan
On Jul 26, 10:10 pm, DanHdanhi...@ieee.org wrote:
Qt implements object assignment. One such object is a pointer
(similar pointers are implemented in other C++ dialects) that
increments a reference count in the addressed object when constructed,
decrements on destruction. You can assign the pointer and it's
copied, with appropriate incrementing. If you use the right flavor
pointer (there are several) the object will be be deleted when the
reference count goes to zero. Other flavors (linked in a reference
chain) act like weak references and go null when the object is
deleted.
All rather automatic (and atomic), with lots of (ahem, shall we say)
less than stellar programmers using the stuff and only occasionally
screwing it up.
On Jul 26, 3:49 pm, Bob Kernsr...@acm.org wrote:
Um, no. For Qt to do what you claim, it would have to traverse all the
application data -- including data owned by non-Qt code -- to discover
what application objects are still in use. In other words, it would
have to implement a GC.
Unless your definition of almost exactly the same stuff is a lot
looser than what I would think.
Would you care to give an example of which Qt API you mean? And
perhaps what binding, if that's relevant?
On Jul 26, 4:13 am, DanHdanhi...@ieee.org wrote:
That's odd, because Qt can do almost exactly the same stuff, without
weak references or implicit garbage collection, using reference chains
that the average user never has to think about.
--
Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
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
Re: [android-developers] Re: What is a WeakReference?
Java also gives you enough rope to hang yourself. Just have to try a
little harder to find it.
Here is an example from production code ummm u some 12 years
ago (written by someone else).
class Item {
String myKey;
Hashtable myHashtable;
.
Item (Hashtable table, String key) {
myKey = key;
myHashtable = table;
myHashtable.put(myKey, this);
}
protected void finalize() throws Throwable {
myHashtable.remove(myKey);
}
}
Instant circular reference, no garbage collection. This brought an
enterprise-level server system down to its knees over a few hours :)
-- Kostya
27.07.2010 12:11, AlanLawrence пишет:
However, presumably (only occasionally) screwing it up includes
creating circular data structures...???
--Alan
On Jul 26, 10:10 pm, DanHdanhi...@ieee.org wrote:
Qt implements object assignment. One such object is a pointer
(similar pointers are implemented in other C++ dialects) that
increments a reference count in the addressed object when constructed,
decrements on destruction. You can assign the pointer and it's
copied, with appropriate incrementing. If you use the right flavor
pointer (there are several) the object will be be deleted when the
reference count goes to zero. Other flavors (linked in a reference
chain) act like weak references and go null when the object is
deleted.
All rather automatic (and atomic), with lots of (ahem, shall we say)
less than stellar programmers using the stuff and only occasionally
screwing it up.
On Jul 26, 3:49 pm, Bob Kernsr...@acm.org wrote:
Um, no. For Qt to do what you claim, it would have to traverse all the
application data -- including data owned by non-Qt code -- to discover
what application objects are still in use. In other words, it would
have to implement a GC.
Unless your definition of almost exactly the same stuff is a lot
looser than what I would think.
Would you care to give an example of which Qt API you mean? And
perhaps what binding, if that's relevant?
On Jul 26, 4:13 am, DanHdanhi...@ieee.org wrote:
That's odd, because Qt can do almost exactly the same stuff, without
weak references or implicit garbage collection, using reference chains
that the average user never has to think about.
--
Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
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
Re: [android-developers] Re: What is a WeakReference?
GC can reclaim WeakReference even memory is still plenty, but SoftReferences will only be cleared when the system is just about to starve out of memory.. On Sat, Jul 24, 2010 at 2:25 PM, Joseph Earl joseph.w.e...@gmail.com wrote: I did say '(although I would use SoftReference for the purpose described here).' But it wasn't clear enough I agree (and because I admittedly wasn't sure enough about the differences) On Jul 23, 4:25 pm, Matt Quigley matthew.quig...@gmail.com wrote: 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 -- 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
Re: [android-developers] Re: What is a WeakReference?
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
MapString, 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
MapString, WeakReferenceType (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
MapString, SoftReference cache = new HashMapString,
SoftReferenceDrawable();
cache.put(http://mysite.com/images/1.jpg;, new
SoftReferenceDrawable.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
Re: [android-developers] Re: What is a WeakReference?
I remember seeing somewhere that Dalvik didn't initially support Soft /
Weak references, and this was implemented at some point.
Can someone clarify: starting with what version of Dalvik / Android
these are available?
-- Kostya
22.07.2010 23:34, GodsMoon пишет:
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 Shellabarger
www.nightshadelabs.com
On Jul 22, 3:06 pm, Joseph Earljoseph.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, GodsMoongodsm...@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 Guyromain...@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 Earljoseph.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
MapString, 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
MapString, WeakReferenceType (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
MapString, SoftReference cache = new HashMapString,
SoftReferenceDrawable();
cache.put(http://mysite.com/images/1.jpg;, new
SoftReferenceDrawable.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, GodsMoongodsm...@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.
