[MonoTouch] Still IntPtr Constructor issues

[René Ruppert]

In my case the weird thing is that the issues seem to show 99% on the device and there mainly on iPad 1 and not do often on iPad 2. In the simulator I was able to reproduce almost never. Only after setting up a timer with an interval of 20ms(!!) it happened sometimes in the sim and often enough on iPad 2.  So i assume it is a parallel execution and/or timing issue. Maybe you have an idea for future improvements based on this observation?

Grüße, René

Am 08.12.2011 um 22:19 schrieb Rolf Bjarne Kvinge <rolf at xamarin.com>:

> 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/20111209/68ef4a8d/attachment.html