Question

As I understand it, we need to hold references to our Cocoa objects when dealing with them in MonoTouch. The reason for this is that the ObjC runtime might still hold references to the objects, and if we have no “MonoTouch references” on them, they could be garbage collected, which results in a EXC_BAD_ACCESS as soon as the ObjC runtime tries to access them.

Say, we have two UIViewController subclasses, VC1 and VC2. If the user clicks on a button on VC1, the UI navigates to VC2, and the user can navigate back and forth. If I create a new instance of VC2 every time the user navigates to it, then the references to the old instances get lost, so they’re garbage collected and the app crashes the next time a didReceiveMemoryWarning is propagated to the UIViewControllers.

How can I release the old references, so I don’t have to use the same instance of VC2 every time? Dispose seemed to not be enough.

Answer 1

As I understand it, we need to hold references to our Cocoa objects when dealing with them in MonoTouch.

Not quite. MonoTouch managed instances will keep a reference to native instances. As long as the managed instance exists the native instance will be alive (since they are reference counted and MonoTouch won’t release it’s reference).

IOW your need to hold references to the MonoTouch managed instances as long as their native part are required.

The reason for this is that the ObjC runtime might still hold references to the objects … they could be garbage collected,

Native (Objective C) instances are reference counted, not garbage collected. Native instances won’t be released until their reference count reach 0 (which won’t happen while an associated managed instance exists);

Also native instances can hold references to other native instances. Not every native instances have a corresponding managed instance.

which results in a EXC_BAD_ACCESS as soon as the ObjC runtime tries to access them.

That won’t happen, at least not this way. OTOH it’s hard to tell you what’s happening in your case (without seeing the code and/or the crashes).

I suspect you’re disposing (manually or not) your managed instances before they have completed their jobs. Here’s a simplified of what could happen:

• you create a managed MT.X instance (e.g. an UIView);
• this creates and reference a native X (native reference count == 1);
• you override an event (or add a delegate…) `ViewWillUnload’ on MT.X (which also exists natively);
• you assign the MT.X instance to another (managed) instance, e.g. an UIViewController;
• the native UIViewController will add a reference to the native X (native reference count == 2);
• application executes happilly…
• you stop having a reference to the MT.X instance (e.g. set the variable to null or a different instance);
• since there’s no reference to MT.X anymore the Garbage Collector will dispose the managed instance, calling Dispose which will reduce the reference to native X (native reference count == 1). But the native instance won’t be freed since it’s still referenced (not 0) by the view controller;
• the UIViewController does something that triggers, natively, X.ViewWillUnload (e.g. it tries to load a new UIView);
• since X still exists natively (ref count == 1) it will call it’s ViewWillUnload which will try to go back to the managed instance… that was disposed.

The solution to this problem is to ensure ensure you’re not disposing managed instance until their native part have completed their jobs.