[mono-android] drag-drop listener

[Wally McClure]

Wow, that was a firehose of awesomeness.  Thanks Jon and Chris!

BTW, I would have posted the link, but was unsure how "public" it was.  

Wally

From: chrisntr at gmail.com
Date: Wed, 4 Jan 2012 22:57:01 -0500
To: monodroid at lists.ximian.com
Subject: Re: [mono-android] drag-drop listener

For the benefit of everyone else, I had recently ported the Drag and Drop sample into Mono for Android (just hadn't had time to put it up online anywhere), you can download the example here: http://dl.dropbox.com/u/90453/DragAndDrop-AndroidExample.zip



Whilst Jon makes some good point, there is a "Drag" event for the OnDragListener so you don't have to implement it yourself :) Much easier!
I hope this helps,


ChrisNTR

On Wed, Jan 4, 2012 at 9:49 PM, Jonathan Pryor <jonp at xamarin.com> wrote:


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.



_______________________________________________

Monodroid mailing list

Monodroid at lists.ximian.com



UNSUBSCRIBE INFORMATION:

http://lists.ximian.com/mailman/listinfo/monodroid



-- 
ChrisNTR
Microsoft ASPInsider
http://weblogs.asp.net/chrishardy
http://twitter.com/chrisntr





_______________________________________________
Monodroid mailing list
Monodroid at lists.ximian.com

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodroid/attachments/20120105/29325f46/attachment-0001.html