views:

83

answers:

4

I am working on the iTuneU Stanford iPhone course HelloPoly drawing assignment, and I am getting a call to my object's init routine when I don't expect one. The callback seem to indicate that the call is coming from _loadMainNibFile (after other calls). What I am trying to understand is why is my object being init-ed implicitly. The source files can be found here: -- http://www.cavedrawings.com/hp2_files.zip

Can anyone tell me why the init routine would be called implicitly when loading the NIB file?

+1  A: 

Most implementations of initWithCoder: ultimately call another initialization function. It's normal to stack initialization methods when you have a series of them that progressively add information to the initialization process.

_loadMainNibFile calls the initWithCoder: of the file owner of the nib which in turn calls another initialization method which leads up to the final init.

TechZen
Yes, it is being called from initWithCoder. The nib file should only have an IBOutlet for the object, not the definition itself...
Arana
I don't think you understand the nib loading process. Nibs freeze dry objects for persistence. When you load an object from nib, it creates a new, cloned instance of the freeze dried object by calling the initialization methods of the objects class. The designated initializer of any class defined in a nib is called when the nib loads.
TechZen
Clearly! So if I get what you are saying... any object I reference in that nib gets init'ed when the nib loads...Then how could I possible include an Outlet in the view without initializing the object until I want it to be? Is there any reference in the Apple docs about how all of this works?
Arana
See the Nib Resource Programming Guide: http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html
TechZen
Thanks for all of the help. I have figured out that my 'problem' lies in my design. It 'blurred' the MVC model. I am going back to a cleaner implementation using key / value observing. This site is a great resource for the programming community. Thanks! Is there something I can do to support it?
Arana
+1  A: 

When a nib is loaded all objects within it get instantiated to do any prep work they need to do.

If you want a nib's object loaded and init'd later, put the object in a separate nib and explicitly load that nib when you need it.

ExitToShell
I'm not quite sure I get it... The object is defined in the drawRect method for the view. I'm not sure I get why that method would get called when the nib gets loaded. I thought that was only for objects created in Interface Builder. How would I create a separate nib for a subview, if that's what I should do?
Arana
A: 

@TechZen: you wrote “most implementations of initWithCoder: ultimately call another initialization function. It’s normal to stack initialzation methods …”

Maybe you didn’t miss it, but for safety: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html#//apple_ref/doc/uid/TP30001163-CH22-SW14

The third point is the big one in this context: “In the implementation of a custom initializer, you must ultimately invoke a designated initializer.” — Notify the imperative mood!

Greetings

Objective Interested Person
That's what I said.
TechZen
A: 

@TechZen: “That's what I said”? You wrote most inits do. This sounds a bit like “if you prefer something else, just do it your way”. No good idea, as your application will do so too. It will start to init and it will never stop it. Not in every case. Maybe just once for a long time as the problem might sit in a rearely used initiator. Then the user will have fun, watching a game of init-pong: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html#//apple_ref/doc/uid/TP30001163-CH22-106471

Greetings

Objective Interested Person