On Fri, Dec 9, 2011 at 8:58 AM, René Ruppert <[email protected]>wrote:
> 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? > Are you using GC.Collect (GC.MaxGenerations)? Do you do any work on separate threads? I find it quite strange that it's not very reproducible, these bugs usually are quite reproducible, at least on the simulator. Rolf > > 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
