weak-references

Is it a good practice to implement event handling through WeakReference if that event is the only thing holding the reference and that we would need the object to be garbage collected? As an argument to this: Folks say that if you subscribe to something it’s your responsibility to unsubscribe and you should do it. It is good to get in the habit of unsubscribing from events when you can, but sometimes there isn't an obvious "cleanup" method where it can be done. We recently posted a blog article on this subject; it includes methods that make it easy to subscribe to an event with a WeakReference

Can someone explain when and when not to use a 'weak' assignment to a delegate pointer in Swift, and why? My understanding is that if you use a protocol that is not defined as a class you cannot, nor want to, assign your delegate pointer to weak. protocol MyStructProtocol{ //whatever } struct MyStruct { var delegate: MyStructProtocol? } However, when your protocol is defined as a class type protocol then you DO want to set your delegate to a weak pointer? protocol MyClassProtocol:Class{ //whatever } class MyClass { weak var delegate: MyClassProtocol? } Am I correct? In Apple's swift guide

When I'm declaring variables as weak in Swift, I sometimes get the error message from Xcode: 'weak' may only be applied to class and class-bound protocol types I was just wondering why keyword weak can only applied to class and class-bound protocol types? What is the reason behind it? weak is a qualifier for reference types (as opposed to value types, such as struct s and built-in value types). Reference types let you have multiple references to the same object. The object gets deallocated when the last strong reference stops referencing it (weak references do not count). Value types, on the

In Apress Pro Android 4 the author has said that: [...] context of currently running activity will no longer be valid when the device is rotated. [...] One approach is to use a weak reference to the activity instead of a hard reference [...] But the author just suggest this, and does not tell how it is done. Who has done this before please give me an example. Somewhere in your AsyncTask you'll want to pass in your activity. Then you'll save that reference in a weak reference. Then you can dereference and use it again in onPostExecute . Class member: WeakReference<Activity> weakActivity;

I know there is a WeakHashMap in java.util , but since it uses WeakReference s for everything, which is only referenced by this Map , referenced objects will get lost on the next GC cycle. So it's nearly useless if you want to cache random data, which is very likely to be requested again without being Hard-linked the rest of the time. The best solution would be a map, which uses SoftReference s instead, but I didn't find one in the Java RT Package. VonC Edit (Aug. 2012): It turns out that currently the best solution are probably Guava 13.0's Cache classes, explained on Guava's Wiki - that's

I really love WeakReference's. But I wish there was a way to tell the CLR how much (say, on a scale of 1 to 5) how weak you consider the reference to be. That would be brilliant. Java has SoftReference, WeakReference and I believe also a third type called a "phantom reference". That's 3 levels right there which the GC has a different behaviour algorithm for when deciding if that object gets the chop. I am thinking of subclassing .NET's WeakReference (luckily and slightly bizzarely it isn't sealed) to make a pseudo-SoftReference that is based on a expiration timer or something. Adam Gawne-Cain

I'm trying to nut out the details for a true WeakKeyedDictionary<,> for C#... but I'm running into difficulties. I realise this is a non-trivial task, but the seeming inability to declare a WeakKeyedKeyValuePair<,> (where the GC only follows the value reference if the key is reachable) makes it seemingly impossible. There are two main problems I see: Every implementation I've so far seen does not trim values after keys have been collected. Think about that - one of the main reasons for using such a Dictionary is to prevent those values being kept around (not just the keys!) as they're