On Jul 11, 2012, at 7:02 AM, andyjohnson0 wrote:
> In a recent MfA project I needed to link UI elements (derived from View) to
> their corresponding data model object (derived from System.Object). The most
> natural way to do this was to use the View.Tag property. Since this is a
> java.lang.Object reference, I had to write a generic class that derives from
> java.lang.Object and wraps a System.Object reference.
>
> This seems like it should be unnecessary for two reasons: it complicates the
> code where the Tag property is set and got, and it adds two extra object
> instances (a java object and a c# proxy).
There is no way to avoid the "extra object instance" problem: in order for the
View instance to refer to a C# instance, the C# instance must (1) itself
inherit Java.Lang.Object, or (2) be wrapped in an object that inherits
Java.Lang.Object.
Could we do this automatic wrapping automatically? Yes. In fact, I believe we
did so in one of the early previews, but changed it for "stylistic" reasons:
since any such wrapper object would need to hold a gref, we felt that gref
creation should be explicit, so that it can be reasoned about (somewhat)
easier. This is also why we don't "fold" all Java.Lang.Object instances into
System.Object instances.
At least that was the historical reasoning, which was never entirely credible
anyway (e.g. JavaList<object> is entirely valid, and will implicitly wrap
non-Java.Lang.Object subclasses).
Which brings us to today: making gref creation "explicit" (via `new`) isn't
credible (too many grefs can be created behind the scenes anyway), so the
proper solution is better tooling (e.g. something to parse `adb shell setprop
debug.mono.log gref` output), profilers, etc., and allowing System.Object to be
used ~everywhere Java.Lang.Object is used today. Given that we're now intending
to provide API stability between minor releases, this won't happen before 5.0,
if even then:
https://bugzilla.xamarin.com/show_bug.cgi?id=6085
> Am I missing something, or is this best/acceptable practice? If it is the
> standard solution, does Mono for Android provide a predefined class for this?
> I have been unable to find one.
Yes, creating wrapper objects is currently the only practice, and we don't
provide a predefined class for this purpose. Feel free to create your own.
- Jon
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
