keep track of parent class from member imageview

Question

I have Class A with an instance variable ImageView. Currently I use setTag() to get from the ImageView back to the instance of Class A. Could that present circular loop? I also heard of mention of weak references. What is the best way to get at the parent Class A of the ImageView?

My usage scenario is I am dragging the ImageView around the screen and I need to access class A for information about the ImageView being dragged.

Answer 1

I believe that Dalvik VM doesn't have problem with detecting circular references.

Here's Q/A that discusses this: Circular References in Java

Only a very naive implementation would have a problem with circular references.

I'd use setTag to hold ref to related object. Also, using setTag/getTag on View is standard and recommended approach to achieve various optimizations on Android, even found in Android samples. Some references:

http://www.vogella.de/articles/AndroidListView/article.html#ownadapter_viewHolder

Android Custom Listview

If Android's GC would have problem to detect such dependencies, Android would not work as it works. Go ahead and use View.setTag if it suits your purpose.

Answer 2

Circular references in java aren't a problem for the GC. This isn't a problem because of a concept called "reachability".

You can think of object references as a directed graph, where the nodes are objects, and the edges are object references. There are a set of nodes in the graph called the "root nodes" - these are (roughly) the objects that are directly accessible to some thread in the vm. Things like local variables in any function call on the stack, static fields in classes, etc.

When performing a garbage collection, the VM starts with these root nodes, and marks them as "in-use". Then, for each edge that leads out of these in-use nodes, (i.e., for each object that is referenced from the in-use objects), it also marks as in-use, and so on, until there is nothing left to mark. And then, any objects that weren't marked as "in-use", it knows it can safely garbage collect.

Now, let's say for example you're in some method, and you have the following code:

a = new A();
a.b = b;

b = new B();
b.a = a

You now have a circular reference between a and b. And both of these objects are part of the root set, because they are a local variable in a method call that's on the stack.

Then, when you exit that method, both a and b will no longer be part of the root set. And as long as you didn't make a reference to them somewhere else, there is nothing else that holds a reference to either a or b.

So now, your object reference graph will have have a little disconnected part of the graph that contains a and b. They both still have references to each other, but nothing else has a reference to them. Since they're not reachable from the root set, the GC knows that they aren't being used and can garbage collect them - even though they have references to each other.

(note that this is a somewhat simplified description of garbage collection, but it is still a useful/reasonable mental model of how it works)

So the short answer is - "Yes, you have a circular reference. But this isn't a problem, because both objects will be collected once both are no longer reachawble"