[MonoTouch] Still IntPtr Constructor issues

[Rolf Bjarne Kvinge]

On Thu, Dec 8, 2011 at 1:52 AM, Rene Ruppert <rene.ruppert at googlemail.com>wrote:

> But isn't that then,like Miguel said, an issue of Monotouch? Shouldn't it
> keep a reference?
> I have not seen a single MT example so far tat keeps explicit references
> to table view cells. Are they all wrong?
>

It's actually quite a tricky subject, we've tried a lot of possible
solutions and we've come to the conclusion that it's virtually impossible
to make it perfect (which is that managed code should not need to hold
objects alive manually and at the same time no objects should be leaked).
We have improved some scenarios (included in the current v5.1.1 beta, but
it has to be enabled manually), and we're working on documentation
explaining exactly what has been improved.

Returning to your particular problem: in theory it should work if you
subclass UITableViewCell (which you do) - in which case the object is kept
alive while native code has a ref. Unfortunately objc might not keep a ref
in all cases (for instance look at assign setter semantics here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW2),
which I suspect is what's happening to you. It is however hard to find the
exact cause without a sample we can run ourselves.

Keeping an explicit ref to table view cells is a pretty easy workaround
(and it doesn't suffer from the undefined behavior adding the IntPtr ctor
would have). The problem is of course to know when to remove the explicit
ref - but in my experience you don't end up with that many table view cell
instances if you reuse them (and just release the explicit ref when the
corresponding view is unloaded).

I hope this helps,
Rolf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monotouch/attachments/20111208/6b4392d6/attachment.html