Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
I was wondering about something regarding more sophisticated programs. So when I create a Cocoa Application, it has a default MainMenu.xib and has a blank NSWindow already presented. In IB I drag over all my buttons and labels then create a custom class called AppController. Then in IB drag over an 'object' from the library and assign that to my AppController class. Whats left is to set up the IBoutlets and IBActions in the AppController.h by control dragging the links in. (I hope I worded all of that correctly)

So that is the world as I know it so far when I create Cocoa Applications.

When I open up Photoshop, I see all of these small windows pop up like the tool pallet, layers, colors and so on. Would these be different .xib files or are they just additional NSWindows, sheets and so on within the MainMenu.xib?

-Lars
 

Cromulent

macrumors 604
Oct 2, 2006
6,802
1,096
The Land of Hope and Glory
I was wondering about something regarding more sophisticated programs. So when I create a Cocoa Application, it has a default MainMenu.xib and has a blank NSWindow already presented. In IB I drag over all my buttons and labels then create a custom class called AppController. Then in IB drag over an 'object' from the library and assign that to my AppController class. Whats left is to set up the IBoutlets and IBActions in the AppController.h by control dragging the links in. (I hope I worded all of that correctly)

So that is the world as I know it so far when I create Cocoa Applications.

When I open up Photoshop, I see all of these small windows pop up like the tool pallet, layers, colors and so on. Would these be different .xib files or are they just additional NSWindows, sheets and so on within the MainMenu.xib?

-Lars

They should really be separate xib files as everything in a xib file is loaded into RAM when it is used. Thus if you have an application with lots of UI elements that may not be shown all at the same time you should separate them and load them as required rather than all in one go at application launch.

I believe this is what is recommended in the Apple documentation.
 

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
Thanks Cromulent, I went back to the book and started reading again. The book covers the basics like what I described. The Apple documentation is so vast, sometimes it is hard to even know what to look for.

I have 2 chapters left in the Obj-C for Absolute Beginners. Then I switch to "Cocoa Recipes for Mac OS X: The Vermont Recipes" to guide me through the creation of a large project.

- Lars
 

jiminaus

macrumors 65816
Dec 16, 2010
1,449
1
Sydney
Thanks Cromulent, I went back to the book and started reading again. The book covers the basics like what I described. The Apple documentation is so vast, sometimes it is hard to even know what to look for.

I have 2 chapters left in the Obj-C for Absolute Beginners. Then I switch to "Cocoa Recipes for Mac OS X: The Vermont Recipes" to guide me through the creation of a large project.

- Lars

Hi Lars,

I just wanted to weigh in with something here.

There's basically two types of Mac apps. The type of the app will determine the architecture of the app, including the arrangement of the .xib files.

Firstly there's utility apps, like Calculator.app. The architecture of these kinds of apps are typically as you describe. The main window is in MainMenu.xib and everything is hooked up the app delegate. If the utility app has secondary windows, these would be in separate .xib files which are loaded on demand.

The second, more common but more complex, app are document-centric apps, like Pages.app and Safari.app. Increasingly these kinds of apps use AppKit's document-based architecture. This necessitates separating the main window out of MainMenu.xib into it's own xib file, primarily so your app can show multiple document widows. You have many controller objects in this kind of app. The IB outlets are usually connected not to the app delegate, but to window and view controllers.

The Vermont Recipes book will evolve the major project from a utility app architecture to a document-based architecture, and will even then go on to evolving it into a core data architecture. So soon enough you'll answer your own question.

BTW If you've not already done so. Now it an excellent time to start using a version control system like Subversion or Git. That way you can tag the Vermont Recipes project at it different stages and you can fork branches to experiment on it.

Jim
 
Last edited:

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
Jim, your input is always welcome!

Thanks for the detailed information, I was wondering how all that worked and I can see it is a very different approach. Tonight I got into a neat chapter 'Storage' This book covered 2 types one is Core Data using something called SQlite and the other is for prefs using NSUserDefaults *prefs.

When I watched the Lynda.com videos there was another way they talked about which was '-(void)encodeWithCoder: (NSCoder *) coder'

So many ways to do things in Obj - C. I am looking forward to the new book Vermont Recipes.

Thanks!

-Lars
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.