• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage]


  • Subject: Re: Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage]
  • From: Ricky Sharp <email@hidden>
  • Date: Sat, 3 Dec 2005 18:26:11 -0600


On Dec 3, 2005, at 9:05 AM, Ricky Sharp wrote:

OK, I found a winning solution.

Problem:

Application has a single window whose content view will be swapped out over time. The content view is replaced by the content views of panels such that you have one panel per nib. As views are swapped in and out, all bindings must be reestablished and all top- level objects must be managed correctly to not leak.

Solution:

(1) MainMenu.nib - Contains app delegate (app controller) and the main window (Main Window is an outlet named say 'widow_outlet'
(2) AppController (owner of MainMenu.nib) which has an ivar to maintain the current window controller
(3) ScreenController (base class for all our individual "screens".
(4) Subclasses of ScreenController; one for each screen (nib) we have. These will be the owners of the nib.
(5) WindowController (custom subclass of NSWindowController)

(6) One nib for each "screen". Contents are as follows:

- File's owner is an instance of ScreenController subclass
- Panel whose content view is the UI of the screen (this is an outlet in ScreenController base class)
- Any model object instances as needed
- Any NSObjectController instances as needed

One important item to point out is that you cannot have any of the object controllers in the nib manage the nib owner (i.e. manage the screen controller subclass). If doing that, releasing the window controller will no longer release the screen controller (or other top- level objects).

The proper solution is not to bind anything to the screen controller subclass. Instead, move the bound ivars from the controller subclass into a model class. Put an instance of the model class in the nib and have the object controller manage that. Then, have the model instance be an outlet of the screen controller.

In summary, the screen controller (owner of the nib) can contain the following:

- IBOutlets
- IBActions
- ivars that are never bound

___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >Re: instantiateNibWithOwner:topLevelObjects: usage (From: Ricky Sharp <email@hidden>)
 >Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage] (From: Ricky Sharp <email@hidden>)

  • Prev by Date: Re: NSString's compare:options: and NSNumericSearch. Huh?
  • Next by Date: Re: NSString's compare:options: and NSNumericSearch. Huh?
  • Previous by thread: Re: Releasing all nib objects [Was: instantiateNibWithOwner:topLevelObjects: usage]
  • Next by thread: Reducer Tutorial leak?
  • Index(es):
    • Date
    • Thread