I've done a fair amount of iOS development in the past couple of years, so I'm pretty familiar with iOS architecture and app design (everything's a ViewController that you either push, pop, or stick into tab bars). I've recently started exploring proper Mac app development and feel a little lost. I'd like to really just have a sanity check and maybe some advice as to what the proper way to build an app like this is:
I'd like to build a library-style, single window app, that will spawn additional windows during its operation, but not as full-blown documents. The main window will be laid out much like OS X Lion's Mail.app, with a three-wide split view containing:
A source list, or high-level topic selection
A list view of items pertaining to the topic selected in the first pane
A detail view, which shows the details of the object selected in the middle pane
Like I said, really similar to Mail.app as far as looks go.
My question is really how to glue all this together from inside XCode. Here's where my confusion lies so far:
The default project generated a NIB with a main menu and window. I like to encapsulate functionality, so should I make a window controller for this window and somehow hook it up in Interface Builder, or does window-specific functionality belong somewhere else?
If possible, I'd like each of my three panes to be separate view controllers. I created three NSViewController subclasses (XCode automatically generated NIBs), and added (to the main menu/window NIB) view controller objects with each class specified, hooking up each one's view property to one of the three Custom View generic NSView objects I dropped into the NSSplitView. When I tried to set each view controller's NIB, only the main menu/window NIB appeared in the drop-down, and typing the desired one by hand seemed to have no effect (the view's contents didn't actually appear when running the app). This makes me think I'm doing something wrong.
I'm a little fuzzy on what types of views I should use for each of the first two panes. I'll obviously build a custom one for the final pane, but it seems like the first two should be present in the Cocoa framework already.
Anyway, if I'm doing completely the wrong thing, don't bother addressing my questions; just tell me what I should be doing instead. I think I just need a proper Mac developer to point me in the right direction.
With regard to your first question, you don't need to use the main window that Apple supplies in MainMenu.xib. If you want, you are free to delete that window from the nib and then instantiate an NSWindowController in your applicationDidFinishLaunching: delegate method which then loads and controls the main window.
You are definitely confused about NSViewController, which is not really all that surprising, since you might assume that it works like UIViewController.
In fact, NSViewController is completely different to UIViewController and does not have the same level of Interface Builder support. You can't place a view controller in a window in IB, for example, whereas this is standard practice on iOS. NSViewController is a relatively new class on the Mac and generally you use it to load views programmatically and manage the view content.
The class that most closely maps to UIViewController on the Mac is NSWindowController. This has been around a lot longer than NSViewController and in fact many Mac apps don't use NSViewController at all.
Generally, each window in your app should have a window controller managing it. You can use subclasses of NSWindowController to handle a lot of the functionality for each window.
If you want to use NSViewController, then you should use your window controller to manage those view controller objects. This is generally done programmatically due to the aforesaid lack of Interface Builder support. Each NSViewController instance loads its view from a specific nib file. You generally don't add view controllers in Interface Builder.
For your source list you would generally use an NSOutlineView if you have multiple sections or an NSTableView. These two objects are used whenever you need a list of items. NSOutlineView is hierarchical, whereas NSTableView is flat.
I hope this helps.
Related
I am building an OS X app in Xcode using storyboards. I have found that working with menu items is difficult and non-intuitive. The menu items are in a different scene (the application) than the view controller, and can not be connected to the view controller by the usual control-drag methods to create an outlet/action. I need to access menu items from the main view controller. I have figured out how to connect actions via first responder chain. However, I also would like to enable/disable menu items from the view controller, and I see no way to create an outlet to be able to do this.
I am new to OS X programming. I feel like I am missing something very basic here. I have watched several WWDC videos related to storyboards, and have not seen a good example showing the proper way to work with menus. Any help would be most appreciated.
There are several ways to work with menus. The traditional Cocoa way is to add an action method to First Responder proxy in IB.
Then flesh out the same action method in the NSResponder subclass that you want. Declare it in the header too.
This will then receive the action message via the Responder Chain.
Read up on the Responder Chain.
I often make use of views in interface builder that live outside of the viewcontroller hierarchy (see screen grab below for simple example).
Before upgrading to Xcode5 I could get this view to appear on the storyboard by writing an IBAction outlet and dragging a connection from the code to the view in the storyboard.
If you paused over the button for a moment it would flash and then open up as a view on the storyboard that is then a lot easier to work with.
Since upgrading this function no longer seems available. Has anyone found out how to get these views to appear on the storyboard?
Edit:
Using the temporary viewcontroller as described in this answer seems one approach, although fiddly since you need to move the UIView stack between viewcontrollers each time you want to edit the layout. Using a separate XIB is starting to seem like the sanest approach.
https://stackoverflow.com/a/13713385/1060154
Finally, we get this back in Xcode 7.
Hallelu!
I have a question, I do some iphone application and now I want to do a little mac application.
From a clean application I add a button on MainMenu xib, than I add a NSViewController to MainMenu (from IB) with one Action.
I create a new NSViewController (FirstViewController) with a nib file and a button.
Now I want only to create a function to push FirstController from MainMenu and a simple function to push MainMenu from FirstController.
something like this
ViewController = [[ViewController alloc] initWithNibName:#"ViewController" bundle:[NSBundle mainBundle]];
[self.navigationController pushViewController: ViewController animated:YES];
How can I do it???
I think you're trying to bring an iOS-style interface to MacOS X, and that won't work in many cases. The MacOS X user interface is very different from that of iOS.
iOS apps are limited to a single (and often small) window, and users generally do one thing at a time. The navigation interface standardizes the way that users drill down through different parts of a task so that the journey is predictable. The interface is very modal in the sense that the user is constantly navigating between different parts of the app, and user actions are often linked to the part of the app that's active.
The desktop, on the other hand, has plenty of screen space and allows multiple windows. Desktop apps should be modeless -- a user doesn't navigate through the app, but sees the whole thing laid out before him or her. As much as possible, the user should be able to perform any action at any time.
For these reasons, there is no navigation controller in Cocoa similar to Cocoa Touch's UINavigationController. If you can tell us more about the tasks that your two view controllers manage, perhaps someone here will help you think of ways to translate that better to the expected desktop experience.
Here apple discusses the migrating iOS to OS X strategies. Your scenario is also discussed here:
For example, AppKit uses the NSBrowser class to manage the display of
hierarchical information; in contrast, an iOS app would use navigation
controllers.
And NSBrowser can be seen in use here with the output as shown in the attached image.
I'm making an NSDocument-based application in which I have an inspector window. This inspector window is part of Pwnshop.nib which is my main nib. I have another nib called 'Document.nib,' which is the document window. I want to be able to change the inspector based on which document window is the active one, sorta like Interface Builder's inspector. The problem is that I want to access an object in another nib. Note that there are multiple document windows, but only one inspector window.
Could anyone help me?
This is essentially the same question as found here. The answer is the same, too. You need to read the documentation and learn about Communicating with Objects and plan your architecture so that you get get to some universally-reachable controller (eg [[NSApp delegate] myInspectorController]) from your NSDocument instances.
I can recommend both this and this article (both from Cocoa with Love) for a fundamental lesson in how to structure a Cocoa project. They will answer all of your questions and get you started on a path to building applications the right way.
I think one of my design problems is that I keep creating navigation objects when I should only have one UINavigationController and a delegate. Is that correct?
I not as concerned from a style-preference, but the answer I am looking for is more about the a technical perspective and managing the navigation among several view controllers. Any pointers are very much appreciated and recognized.
I continue to think that I have the SDK under control and then I struggle again.
OK ... I am re-reading Apple's Dev Doc and the answer is 'usually only one, but quite often more than one.'
"iPhone Dev Center: View Controller Programming Guide for iPhone OS: Introduction"
"It makes the most sense to include navigation controllers in your application’s main nib file. You do this when the navigation controller itself provides the main view for your application’s window or in situations where the navigation controller provides the root view for a tab bar interface. Although you could also load standalone or modally presented navigation controllers from your main nib file (or any other nib file), doing so is not optimal. In those scenarios, it is usually easier to create the navigation controller programmatically at the point of use."