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.
Related
I have been making iOS apps for a while now and I decided that I wanted to start working on making some of them for the Mac too.
The question I have is this: is there any need for an NSWindow, now that developing for the Mac is so similar to iOS??
So I made a simple cocoa application using Xcode and its comes with a storyboard called "Main", just like on iOS.
In that storyboard file, there is a NSWindow which then links to a NSViewController.
Can I get rid of that NSWindow? As I tried setting the NSViewController as the "Initial Controller" and the app still works fine. So whats the point of the NSWindow?
Also, what class links to the NSWindow? I was trying to blur that background of the NSWindow, but I have no way of linking code to the NSWindow.
Sorry for my stupid questions, but I am completely new to development for OS X.
Thanks for your time, Dan.
Those are many questions in one question:
Can I get rid of NSwindow? No, you need a window to show you views.
What is the point of the NSWindow? NSWindow is needed as the window in which the views are displayed and your events are going up the responder chain.
What class is linked to NSWindow? Obviously the NSWindow class, but that is not what you want to know. I think you want to know the delegate that controls NSWindow. This is NSWindowController, although for the MainMenu.xib it is NSAppDelegate.
Hope this gives you the answers you need. An example for working with views in a window is given in this question.
Please, see for further details the windows programming guide, which states:
The NSWindow class defines objects that manage and coordinate the
windows an application displays on the screen. A single NSWindow
object corresponds to at most one onscreen window. The two principal
functions of an NSWindow object are to provide an area in which NSView
objects can be placed and to accept and distribute, to the appropriate
views, events the user instigates through actions with the mouse and
keyboard.
For the question: Can I get rid of NSwindow? I have further comments. In most cases, You need a NSWindow to show view on screen; but in special case you don't, for example, a popup view when you click a NSStatusItem.
So my answer is whenever you need to respond window event such as min/max, you need NSWindow as the view container.
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.
I'm attempting to convert my view based application to a tab bar application. I'm having trouble connecting a new UITabBarController to the App Delegate. It doesn't give me the option. I must be missing some sort of connection along the way.
I added a Tab Bar Controller to my "MainViewController.xib". From most of the things I've read, I should be connecting to the "MainWindow.xib," only problem is that I've got both iPhone and iPad formats setup from the View-Based Application so I'm looking for a way to connect it universally (so I don't have to recreate it for both the iPhone and iPad formats separately).
I created an outlet in my MillersAppAppDelegate.h file (and synthesized it all correctly) but the outlet that I created for the Tab Bar Controller does not appear as an option when I attempt to connect it in the Interface Builder (I'm assuming this is because I haven't correctly connecting the Tab Bar Controller to the delegate in the first place).
I'd like to just stop here and learn this first step so it doesn't get too confusing yet:
1) How do I connect my new Tab Bar Controller to the App Delegate in a View-Based App?
2) How do I then subsequently connect my Tab Bar Controller (that was created and synthesized in the App Delegate) to the UITabBarController?
I've looked at other people's questions regarding this type of thing and most of the reactions are "It's easier to just start a new tab bar app and transfer the content over." I still want to be able to learn how to do this though, it'll help me learn the language of X Code and Objective C better by pushing through it and make me well versed and better in the end (as it will for the others with similar questions). Thanks for putting up with my beginner questions, I'm still learning!
I am about to tackle my first Mac OSX project after developing for iOS.
In my iOS applications, it is clear to me the whole NavigationViewController->MyViewController->MyViews paradigm.
A bit more background on the iOS app so it would be easier to understand me:
The application is some sort of graphic viewer. Once you login you have a list of drawings, and if you select one, it opens it up.
Now in the iOS app I have a custom UIViewController that have some menu UI and a UIScrollView that holds a UIView in which I draw the drawing.
The custom UIViewController is responsible for acting as the "application" where the UIView inside is merely a graphic context.
Now - back to Mac:
I was thinking that my main window would show the drawings and once one is selected,
I would add another window with an NSView that is the graphic context of the drawing,
and the window will be acting as the UIViewController in the iOS app.
Does that make sense?
You can have NSViewController or NSWindowController on the Mac, to put your controller logic in. If you're going for separate windows, subclassing NSWindowController would make sense.
Usually I've used NSNavigationController to switch between different view controllers smoothly. Now, on the iPad, I need a way to switch between view controllers, but am at a loss, since it seems that I cannot start a UINavigationController iPad app from Xcode. The only substitute I've found is SplitViewController -- I don't wish to display my app in this manner. In short, all I need is:
NEED: A way to smoothly transition (Switch) between UIViewControllers (the views therof?) from my application delegate.
The templates are just starting points to make initial configuration easier. You can just as easily start with the View- or Window-based Application template and then reconfigure it however you like.
Though keep in mind that Apple has not made iPad an option on the Navigation-based Application template for a reason (transitioning the entire window in an iPad is discouraged in the user interface guidelines).