[mono-android] drag-drop listener

[ChrisNTR]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodroid/attachments/20120104/3c55697b/attachment.html