[mono-android] drag-drop listener

[Jonathan Pryor]

On Jan 4, 2012, at 9:06 PM, Wally McClure wrote:
> Thanks.  Christntr got me set on this.

For the benefit of everyone else... ;-)

> The problem is that nothing in myDragListener seems to fire.  I think the problem is when I instantiate the class, I am handing in the incorrect handle.

>         protected class myDragEventListener : View.IOnDragListener

Unless you're me [0], always, _always_, ALWAYS inherit from Java.Lang.Object when implementing an Android interface.

Here's why: the IJavaObject.Handle property is the JNI handle of the Java-side object to pass as a parameter. This thus requires that you have a Java-side object to provide (and is why any IJavaObject.Handle implementation which throws an exception or returns IntPtr.Zero is broken). Subclassing Java.Lang.Object handles creating the Java-side instance automatically.

Furthermore, the associated Java object needs to be "correct." If you're implementing an interface (as `myDragEventListener` does), and passing an instance of that type to a Java method (your previous `iv.SetOnDragListener()` call), then IJavaObject.Handle will be used to obtain the Java instance to use, and _that_ instance will be passed to the Java-side setOnDragListener() method.

That Java-side instance had better implement the Java View.OnDragListener interface. If it doesn't...anything could happen. (ClassCastExceptions, aborts, corruption...)

In your case, you're doing:

	IntPtr IJavaObject.Handle {
		get {return _c.Handle;}
	}

where `_c` is a Context instance. Unless `_c` is your Activity _and_ your Activity is also implementing View.IOnDragListener, you'll be providing a Java object which does _not_ implement the Java VIew.OnDragListener interface.

This is, suffice it to say, Bad™.

If you instead subclass Java.Lang.Object (as you should!), an Android Callable Wrapper (ACW) will be generated, which will implement the Java-side interfaces which are present in your subclass. The ACW will be created in the Java.Lang.Object constructor, thus ensuring that the Handle property is mapped to an appropriately typed Java instance.

Finally, there's the GC problem. Java.Lang.Object has support for cross-VM object references. If you implement IJavaObject yourself, your class won't, and you'll need to (somehow) ensure that your Java object is eventually freed. Worse, you'll need to figure out some way to keep the managed instance from being GC'd as long as the Java object is alive. Don't go there, just subclass Java.Lang.Object.

 - Jon

[0] ...and I would avoid implementing IJavaObject manually unless there was absolutely no other alternative. Please, just don't.