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 <[email protected]>: > Hi René, > > On Thu, Dec 8, 2011 at 5:40 PM, René Ruppert <[email protected]> > 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 <[email protected]>: > >> On Thu, Dec 8, 2011 at 1:52 AM, Rene Ruppert <[email protected]> >> 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 >> >> >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
