I was an iOS programmer and recently switched over to making Cocoa apps for Mac. When creating a project in Xcode, it seems there are two options:
(1) Using the MainMenu.xib default, insert buttons and link to AppDelegate. I have tried creating an NSView class and linking to that with no success.
(2) Creating an NSViewController class and linking the view from MainMenu.xib and any buttons to that.
Which of these methods is better when creating larger applications, with multiple views and windows?
Edit: What would be the best way to start out if not connecting anything to AppDelegate? Create an NSWindowController class with an xib and connect its view to a NSViewController class?
I guess overall I am confused as to which class I start with and what elements (window, views, buttons) to connect to what class file.
You can create a window object in your MainMenu xib and create a reference to it in your AppDelegate class. You will be able access items in it. But this is good only for a little learning.
You should start with an NSWindowController. For a first try, don't make any view controllers yet. Use the xib file and build your first window in the subclass of NSWindowController.
In AppDelegate, create an instance of the new class and open it.
Once you have mastered that, you can define view controllers for parts (or all) of you window's view.
If you need sample code, let me know, but it's a good exercise to work it out.
Related
This is a beginners question about Cocoa and Objective-C.
I have created an encapsulated reuseable GUI component with an Cocoa NSViewController class and a XIB resource file. Now i would like to use this component in other XIB files but can't figure out how to do that.
I want something like the custom views that you can just use as a placeholder to position and size after assigning the class name.
While i can create the controller class as an object in the xib i don't know how to connect the view. Currently i'm just using an additional custom view where i add my component at loading time with some code. But i'm sure there must be a better way without explicit coding.
I am playing around with the default XCode template for a cocoa application. By default it has a MainMenu.xib with a window and a menu -- awesome.
I intend to build up my views/subviews in code, so I then create a RootView : NSView and a RootViewController : NSViewController, and bind them up in IB so that my base view in that window is my RootView, controlled by my RootViewController.
Enter my question -- How do I do the same to have a RootWindowController bound to the NSWindow? I had assumed File Owner was the trick, but it's set to NSApplication, which I think is correct. The main goal of NSWindowController in my case is to manage the toolbar based on NSNotifications fired from other services -- is this even the correct design here? I don't think I can do this from my RootViewController since I don't have a window reference, but is that where I should do it instead?
Many times, the application delegate is used as the main/central controller for a non-document-based application. This is a good place. This can be an NSWindowController instance if you like. You can just do away with the existing window in your nib.
Helpful information from the NSWindowController API reference:
You should create a subclass of NSWindowController when you want to augment the default behavior, such as to give the window a custom title or to perform some setup tasks before the window is loaded. In your class’s initialization method, be sure to invoke on super either one of the initWithWindowNibName:... initializers or the initWithWindow: initializer. Which one depends on whether the window object originates in a nib file or is programmatically created.
But if it were me, I wouldn't bother going the NSWindowController route; I'd just add this logic to my app controller (and set it as the app delegate) since this is app-level stuff. No need to add a layer of complexity unless you've got a LOT of main-UI-updating complexity you want to compartmentalize.
I'm using XCode 4, and note that when setting up a new Cocoa Application project, you get an AppDelegate.m and .h file, as well as a .nib (.xib). Using alt-command-return, you get the 3-column editor layout, from which you can control-drag from controls to the AppDelegate.h file to create Outlets or Actions.
My question is, is it recommended to utilise these AppDelegate files to manage your interface controls ie. updating labels, acting on button presses etc. OR is it better to create an AppController class, add an object to the .xib and subclass it to AppController, modifying AppController to mange the controls? If this is the case, what are appropriate uses of AppDelegate?
I would like to say, it is just a matter of development style. What I do is use another class and change the AppDelegate to that class/view and use. Also I do not draw outlets and button on the default window. I make a view and add those as subviews to the mainWindow.
Alright, I will try and make this short and sweet. I recently created my first iOS app, and in my app I decided to go the storyboard route by selecting the checkbox when creating the project. On a side note, I recently just started developing in Xcode, keep that in mind. So I started by designing the GUI elements of my app, and before I knew it, I had 8 scenes in my storyboard file and one view controller. Needless to say the view controller has been populated with code from different scenes thus making it difficult to understand what does what in the view controller. In the spirit OO design principles, I thought it would be a good idea to create a separate view controller for each scene. So I created some class files for the project. When I try to associate the newly created class file with the scene my computer just sounds a beep / donk sound. I am trying to associate the newly created class file to a scene by selecting the scene in the storyboard / Interface Builder view, then displaying the Utilities pane on the right, then selecting the Identity Inspector at the top of the Utilities pane, then setting the Custom Class to my newly created class file, but when I type the name of the class and press enter I just hear a beep.
If any one has any insight or knows of a tutorial explaining this process please post. Part of the reason I am trying to do this is for code readability, better code management, and a better code structure for the application. I came across this stack thread explaining some of what I am talking about.
Also here's a picture of what my project looks like if that helps shed any light.
You need to consider the parent class of your controllers, UIViewController for example.
To do so, you must check the .h file and your xib/nib file.
I. In your .h file, you will be seing:
#interface ViewControllerWelcome : NSObject
Change 'NSObject' to 'UIViewController' - this will mean that ViewControllerWelcome has a parent class UIViewController.
II. In your nib/xib file:
1. Click on the controller that you are going to set from the storyboard.
2. Go to interface builder and click the "Identity Inspector" (third item from the left) from the Utilities panel.
3. You need to specifically set each controller's name (eg. ViewControllerWelcome)
Do these to all controllers from your storyboard.
Here's something you can read about ViewControllers and Storyboards.
I have basic *.xib file, which have NSView.
How can I use another nib files for this Custom View? What is NSViewController and how should I use it?
Generally, you create a new nib, selecting "View" as the nib template. Then you select the File's Owner and set its class to NSViewController (or your own subclass of it, in which case you may have to add the nib to your Xcode project first) in the last tab of the Inspector. Then you connect the view controller's "view" outlet to the view.
You should read Apple's docs on NSViewController, it's actually a very simple class. However, before you start drawing and coding I would suggest you should carefully structure your app in MVC terms. If you make a mistake in the design phase, you will have to redo a lot of your work later. Using view controllers is not always justified, it depends on the complexity of the app.
NSViewController as its name suggests is a Controller class, means it connects the View to the Model, in a perfect MVC environment.
Each ViewController is bound to one View, you can build that view in code or using the Interface Builder.
For more help, I would suggest to watch Stanford University iPhone programming course, it's available on Stanford iTunes (iTunes link), iPhone SDK share the same underground with the OSX SDK so it's exactly the same for ViewControllers.