I'm trying to understand what the "App Controller" is in a document based application. Apple doesn't mention it here. In the book I'm reading (Cocoa Programming for Mac OS X fourth edition), the author creates an app controller for handling a NSWindowController subclass that acts as a prefernce window. The app controller is a direct subclass of NSObject, so it appears that this isn't some standard Cocoa class.
Is this what app controller does? Handling shared windows in a document based application? Does it do something else?
[The AppController] is responsible for setting up all of the initial view controllers, the window and serving as the handler for OS<->Application messages.
This is taken from an answer to a similar question here.
Related
Why is it that when a WKInterfaceButton is connected to both a push segue and an action, the action isn't called?
When you perform a segue, the old InterfaceController goes off screen, of course. WatchOS seems to destroy the bridge between your extension and the App (the storyboard/interface). The same thing happens in the other direction. The extension can't modify UIs that aren't on screen. An example is UI properties. Try setting the color of a label after the interface controller goes off screen. It won't work.
From the docs:
Important
An interface controller can make changes to its interface only during initialization and when the interface is active. Once the didDeactivate() method is called, any attempts to change the value of related interface objects are ignored until the interface controller’s willActivate() method is called again.
Presumably you're an iOS dev. It might be good to read through https://developer.apple.com/reference/watchkit/wkinterfacecontroller
Since I started learning watchOS, a lot of my assumptions/experience did not translate well over to the watch.
I am trying to use Parse.com SDK in my Mac OSX app written in swift. I have followed the Quickstart Guide and used a bridging header but when I launch the app I am shown this message and the object is not created on launch.
Failed to set (contentViewController) user defined inspected property on (NSWindow): You have to call setApplicationId:clientKey: on Parse to configure Parse.
Any Ideas?
Thanks
I just ran into the same issue, for some reason the viewDidLoad() on the view controllers are executing before the app delegate's applicationDidFinishLaunching: method.
Although Parse recommends having their methods setup in the app delegate, setting up the app id/client key on your initial view's viewDidLoad will let you use parse normally.
I am quite new to Cocoa and to iPhone programming.
I am using the Xcode Utility Application template to implement a simple app that has:
a view with a text field to collect a username
a view with a connect button to start a connection to a remote site using the
username to get some data via HTTP. The data will be presented as a text string on the screen.
I think this represents my VIEW in the MVC pattern.
I created a simple class to store the username and to do all connection work that represents my MODEL and instantiated it inside the AppDelegate.
Here a really simplified sketch:
It is not really clear to me how can I get data nested deep into subviews (username) or how can I trigger actions in nested parent views (connect button).
My question is:
What is the best/cleanest way to implement this architecture?
How do I implement the CONTROLLER?
Thanks in advance for any help,
Paull
Updating my answer based on comment:
It's in most cases ok to have state in your controller. Like an array or an instance of whatever modelobject you are writing an application for.
I would keep the model object clean of any networking code and put that in the Controller instead though. In this case the ViewController where that connection action is triggered.
Original answer:
It is not really clear to me how can I
get data nested deep into
subviews(username) or how can I
trigger actions in nested parent
views(connect button).
With the utility application template you already have a couple of ViewControllers.
To get references to your UI inside your controllers you need to declare IBOutlets and connect them inside Interface Builder. To respond to actions you need to declare and implement IBActions in your ViewControllers and hook them up in Interface Builder as well. Which you do in Connections pane (2nd from left) in the inspector.
I have a simple document-based Cocoa app that acts as a viewer for .wav files, to do a bit of frequency analysis. I'd like to be able to export the data gleaned from opened files to CSVs for further analysis in other programs.
The document-based application framework in Cocoa lets you override
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
to implement the default Save/Save As... workflow, but I don't want to write the files that I open.
The obvious thing to do is implement an export workflow in my document, to present a file save sheet, build some NSData, and write it to a file path, but there is not an obvious way to connect an outlet in the MainMenu nib to an action on a document controller.
So, then, what is the accepted way to implement such functionality in a document-based Cocoa app?
You can create a new action in MainMenu.nib's "First Responder" object, called "export:", and connect to it. Then, implement an export: method in your document subclass. This will call your method.
The reason this works is that messages sent to the magic first responder object go through the entire responder chain, looking for some object that handles them. One of the items in that responder chain is the document, and so when the currently selected control, view, superview, window, etc, all do not handle the message, the document gets a chance. (The document controller is also on that chain, so you could use it, too.)
Take a look in Apple's responder chain docs - figure 1.10 covers this particular path.
I want to load some data from mysql into my cocoa application view before the application starts.
I am sure that this should happen in the controller so that it can send the required data to the view.
I am looking for a method or common technique that is used for this sort of thing.
Many Thanks
Sounds like you're looking for the awakeFromNib function.
http://www.cocoadev.com/index.pl?AwakeFromNib
Cocoa gives you many places to perform tasks before and after objects are loaded from a nib, but it's important to read the documentation carefully to make sure things are happening in the order you expect. Usually I use the following strategy when I'm working on a Cocoa application:
Where appropriate I implement the
+(void)initialize method, which is called before any instances of a class are created. I'll probably set the app's default preferences here, for example.
In my application controller (app delegate), I implement the applicationDidFinishLaunching: delegate method to load my data file. If this works okay, I then create the window controller(s) and display any windows I want to show at launch.
In the window/view controllers, I override windowDidLoad: or loadView to perform tasks involving objects loaded from a nib. If I need to create any instance variables that don't involve the nib, I also override the init method and do that there.
If I need to do anything in my view objects after they're loaded from a nib, I'll override awakeFromNib.
You can use the - applicationDidFinishLaunching: or - applicationWillFinishLaunching: delegate messages, by implementing one of them in your application delegate/controller, and do whatever initialization you want there.