CocoaUI & factory class design pattern in ObjC
CocoaUI & factory class design pattern in ObjC
- Subject: CocoaUI & factory class design pattern in ObjC
- From: Brian Willoughby <email@hidden>
- Date: Thu, 11 Aug 2005 03:18:37 -0700
I just read a comment in the AudioUnit sample code which is alarming.
Further research in the CocoaAUHost sample code shows that CoreAudio does not honor established Cocoa design patterns with respect to loading nibs.
In a nutshell: The CocoaAUHost sample code frees the instance that was used as the File's Owner when loading the nib, yet somehow expects the contents of the nib to remain valid. This is completely at odds with efficient Cocoa programming, and I think it needs to be changed ASAP.
First of all, let me quote the comment from line 81 of SampleEffectCocoaUI.m:
// zero out pointer. This is a view factory. Once a view's been created
// and handed off, the factory keeps no record of it.
The above comment is very misleading, because it implies that one should use a factory class as a nib File's Owner class. The code that appears in the SampleEffect example would be a proper implementation of a class factory, but it is a really awful practice to use a class factory instance as File's Owner. This should not be shown in sample code from Apple. The real question is how wide this misuse of Cocoa has spread.
The kAudioUnitProperty_CocoaUI property returns an AudioUnitCocoaViewInfo structure containing a CFURLRef for the bundle and a CFStringRef for the class name(s). This is a proper design, but the devil is in the details of how it is handled from there.
In my 15-year experience as an AppKit programmer, I would say that the proper behavior would be for an AudioUnit host to create the File's Owner instance and let it live for the duration of the CocoaUI view hierarchy. The whole point of the File's Owner is to serve as the one focal point for reference counting, and to represent not only the view hierarchy, but also the non-UI objects which are sometimes needed in conjunction with the UI objects.
The File's Owner is the only instance described in a nib which must exist before the nib is loaded. All other instances are creating during the process of loading the nib, and connected into either the View hierarchy or the outlets of the File's Owner. While it is certainly possible to reuse one instance as a File's Owner multiple times, clearing the outlets each time they are set by loading each new nib, that is a really poor way to use Cocoa. In fact, the proper design pattern is often missed by beginner AppKit programmers until they understand.
One very handy, but optional, design pattern is to implement the class for the File's Owner such that it loads its own nib in its -init method(s). This is not always possible, since the location of the nib may not be known, but this approach makes use of the objects in a nib very simple to outsiders, and that's the whole point of object-oriented programming. Since AudioUnitCocoaViewInfo provides the URL for the bundle as well as the priciple class name, this would be entirely possible, certainly if the sample code showed how it is done.
The CocoaUI for AudioUnits seems very similar, but the nib loading is postponed. Instead of occurring during -init, it occurs when
uiViewForAudioUnit:withSize: is called. It appears that an unwieldy hack has been engineered to make it possible to reduce the object count by one (by releasing the File's Owner) and changing the established design pattern such that the responsibility is shifted from the File's Owner to the "uiView" object. This makes CocoaUI nibs differ from all other Cocoa nibs for no good reason. Sure, it saves one object, but the memory footprint is probably only 32-bits smaller as a result. I will admit that a CocoaAUHost is probably easier to implement if it only needs to track the uiView and not also the File's Owner, and this is a rather convoluted hack to make that possible, but I think it is really confusing for Cocoa to be abused this way.
NOTE: It is entirely possible to engineer a nib such that closing a window ends up releasing the File's Owner. It should be equally possible to engineer a normal nib, whose File's Owner sticks around, such that freeing the uiView does the right thing. It might require an extra method call...
So, to get to an actual question: Can I get any sort of feedback on what is going on with the CocoaUI sample code? Is there a very good reason why the established Cocoa design patterns were thrown out in favor of this hacked alteration?
Sorry if this is confusing or poorly written. I can clarify any details if asked.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden