[MonoTouch] Still IntPtr Constructor issues

[Rolf Bjarne Kvinge]

Hi René,

On Thu, Dec 8, 2011 at 5:40 PM, René Ruppert <rene.ruppert at googlemail.com>wrote:

> Thanks for this detailed answer. Is there a list of cases that show when I
> will have to keep explicit refs? You should know best where things can go
> wrong.
>

Unfortunately it's not possible to have an exhaustive list of cases, since
the iOS API is quite big. As a general rule you need to keep explicit
references to framework objects (instances of framework types you haven't
subclassed, for instance UITableViewCell). In some cases MonoTouch will add
that explicit reference for you (it depends on the API, sometimes we can't
add explicit references because of how the API is bound, in some cases
because we don't know when we'd have to clear that explicit reference). In
any case issues tend to show themselves pretty quickly in the simulator
(since we've made the GC very aggressive there exactly to catch issues like
these), and you'll usually be able to tell at least the type of the object
that's been freed (that's the exception about the IntPtr ctor).

Please announce once you have that document ready that explains the
> changes. Miguel said you are working on a concept that will fix all of
> these problems. Is this the same topic?
>

Yes, it is.


> As for releasing the references: if the view that is using the cells is
> managed by a controller, is my assumption correct that I do not need to
> release them explicitly if I hold them in the view itself? I mean, if the
> view is unloaded it should get GC'd together with the cells.
>

If you have a (managed) list of cells in a view, and that view is freed by
the GC, then the list (and its items) will be freed too (note that the fact
that a view is unloaded doesn't necessarily mean that the view can be
collected from the GC's point of view (even though that's generally true),
you might have a reference to the view somewhere else - what you can do
though is to clear the list of cells in the ViewDidUnload method).

Best regards,
Rolf


>
> Grüße, René
>
> Am 08.12.2011 um 16:56 schrieb Rolf Bjarne Kvinge <rolf at xamarin.com>:
>
> 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/0bfbb526/attachment-0001.html