My question is based on the fact that, one might have multiple smaller projects and then wants to integrate them into one bigger one, for coding efficiency.
I saw multiple project's where the App Delegate wasn't used at all, I think the Adium project was one of them. I also was a couple of times able to recreate it in the past, now I cannot remember how.
I figure a basic NSObject inherited class would fit, plus its instantiation and connections.
The question is, is it possible to work without App Delegate (or have a workaround)?
You need an app delegate, if you want to implement some of the methods declared in the NSApplicationDelegate protocol to respond to certain app life-cycle events. If you don't need to implement any of those, you don't need an app delegate. Some delegate methods also have notification alternatives.
OK, from your comment...
I mean having no additional code in AppDelegate
Then yes.
It is not only possible, it is recommended. Exactly for the reason that you have said.
The app delegate is there as a communication layer between the app and the OS. i.e. "the app has started", "the app is about to close", "the app just received a notification", etc...
All of these is what the app delegate is for.
The logic of your app should not go anywhere near you app delegate. Like you said, you may have different apps or different targets in your app that use different app delegates.
If you have code in there then you would have to duplicate it to each copy.
There are many other reasons too.
Here is a quick link... http://www.hollance.com/2012/02/dont-abuse-the-app-delegate/
There are many others about not using the app delegate.
Related
This is just a theoretical question. It was born from a real problem in my app, but I re-designed the problem out of the application. But the question remains:
If in my app delegate I write my singleton object to disk upon applicationWillTerminate: but also use NSNotificationCenter to call updateSingletonData upon UIApplicationWillTerminateNotification in some view controller, which will happen first? Will my data be written to the singleton, then the singleton be written to disk, then the app terminates? Or will the reverse happen, with the singleton being serialized and then the singleton updated (worse), or will the app just terminate after a certain amount of time if the serialization takes too long (much worse!)?
I guess this shows my lack of understanding of the guts of Springboard... thanks to anyone who can shed some light here.
A couple of things to note here:
Only Apple know the order these will happen in, as they wrote the code that does it.
You shouldn't care about the order these will happen in. If you do care, then you've designed your code badly.
In reality, you could go and check what order the happen in - for your particular device, for your particular iOS version, etc.
But really, you shouldn't care what order they happen in. From the sounds of it, you should be either firing off to the view controller to write the data before saving in applicationWillTerminate:, or letting the view controller handle saving after it's written its data.
This question is old and the response by #mattjgalloway is correct in terms of code quality but, for the sake of the knowledge, I just saw in the docs that the notification is posted after the UIApplicationDelegate method is called (emphasis mine):
After calling this method, the app also posts a UIApplicationWillTerminate notification to give interested objects a chance to respond to the transition.
https://developer.apple.com/reference/uikit/uiapplicationdelegate/1623111-applicationwillterminate
I'm new to Mac programming and I'm working on a document-based application.
My NSDocument subclass creates a NSWindowController subclass. This window controller creates two NSViewController subclasses as well.
Sometimes, a change in one of the views of a NSViewController needs to notify the NSDocument and/or the main model class. Also, a change in the model needs to be notified to every/some view(s).
My question is: what is the best approach so that there is no (or minimum) coupling? I know there are several choices, but I'm not sure which one suits best for my application as I'm newbie not to programming but to Cocoa and especially NSDocument:
KVO. Looks nice and easy to implement, but I don't like the idea of not explicitly notifying the observer(s) about a change (AFAIK, self.someProperty = newValue does automagically notify observers), and don't like the fact that you have to register to property names which could change in time.
Notifications. I know what they are and I've used them for iOS. But I've read somewhere that they are not guaranteed to be sent immediately to observers. Is it true? If not, do you see them as a good approach for a document-based app?
Delegates. Yes, under normal conditions (or what I've usually seen), a class has one delegate. But creating an array of delegates works as well (just tested it). The problem I see here is that every time I need to notify the delegates I have to loop through them, make sure they respond to a method, and call that method.
Are there any other alternatives I'm missing?
KVO by a controller class is the most common way to do coupling between a model and its view(s). In fact, Cocoa Bindings, which are intended to mostly eliminate code in the controller layer, are based on KVO. It is true that KVO/KVC relies on property names, and that if those change, you'll have to change the bindings or KVO setup connecting your view. However, it's not usually feasible to make your views completely unaware of the underlying model specifics, so I don't see this as a problem.
My recommendation would be to use Cocoa Binding where you can, as they eliminate a lot of glue code. In places where they can't be used, your controllers (the middle layer in MVC) should use KVO to observe model changes and update the appropriate views. Changes in the views can be passed back to the model via property accessors and/or KVC by the controllers.
Yes, under normal conditions (or what I've usually seen), a class has
one delegate. But creating an array of delegates works as well (just
tested it).
Delegates are often used to modify the behavior of the delegating object. An application delegate is a good example: NSApplication by itself isn't very interesting; it relies on its delegate to define the interesting behavior of the application. Having multiple delegates all trying to modify the behavior of a single object could be a problem if the various delegates conflict with each other. What do you do if the delegates disagree?
There are some cases in Cocoa where a class uses more than one delegate, but each one has a separate role. For example, NSTableView has both a delegate and a data source, but both are really delegates of a sort.
The problem I see here is that every time I need to notify the
delegates I have to loop through them, make sure they respond to a
method, and call that method.
That's not hard to solve. For example, you could create an NSInvocation to encapsulate the call, and then send the invocation to each "delegate." However, if you do that you'll have nearly reinvented the notification system. If you need the one-to-many communication that you'd get with your multiple delegates proposal, you'll probably be better off using notifications or KVO.
I am new to mac os X development ,I downloaded an open source mac application ,but i couldn't able to understand the flow of execution of cocoa program.so any one can explain the program flow of a general cocoa program briefly.
Thanks in advance
Start in main. It's not likely to contain anything interesting, but worth checking just in case. Most probably, it will contain only a call to NSApplicationMain, which will create the NSApplication object and send it a run message. That's what gets the application running, and this method will run for the rest of the rest of the process.
Then look in the MainMenu nib. Loading this is one of the first things the application will do. Any windows here that are set as “Visible on Launch” will come up immediately; more importantly, the application delegate will probably be here. Check the application's or File's Owner's (the application is both of them in this nib, so you need to check both) delegate outlet, and if one of them is connected, follow the connection. See what class that object is an instance of.
Once you've found the application delegate class, open it up in Xcode. Look through the list of application delegate methods and find which ones are implemented, and read the ones that are. The application:…FinishLaunching: twins will be particularly important at the start of the process.
From there, it's all just reading code, seeing what it does, and going where it takes you.
Peter's answers are good - I'd also say to check for implementations of 'awakeFromNib', especially for object loaded from MainMenu.nib. You often find interesting things stashed away in that method, rightly or wrongly.
I'm still working on my problem that an NSView in NSMenuItem is not receiving any notification when the user chooses it by pressing the return key.
For this i want to log all methods which are called on an Objective-C object.
Can i do this in some way without using a debugger?
Not easily, no, and probably not the most effective way to debug this anyway. If it isn't receiving a notification, it is likely that no method is being called.
You could build a proxy class that forwards all methods and then plug that in, logging as it forwards. See the documentation for NSProxy for more information.
But, again, not the best way to debug this.
Do you have a separate question regarding the views, menus, and notifications? (I didn't obviously find one).
Ok, I'm totally new to obj-c + cocoa, so this is probably obvious, but here goes:
I've been moving from command line apps to cocoa apps in learning how to work with objective-c in Xcode. One thing I don't really understand is the role of the AppDelegate and how it connects to main.m
It seems like you could put your entire program in the appdelegate and it would run fine, and you don't even need main.m, but not the other way around, if you're making a cocoa app you have to at least have the appdelegate.
I've done a lot of php web development and command-line tools, so I guess what I'm looking for is the file that the program will execute first and is intended to "control" the rest of them.
Can anyone help me understand what's going on in a Cocoa program, how AppDelegate and main.m are (or are not) related, and what the flow of the program is supposed to be?
main.m contains the main() function, which is the entry point for the program, it's run first. Then it calls UIApplicationMain(), which does the OS-specific application setup stuff, and loads the main Interface Builder .xib file which contains your app delegate instance.
That is, without main.m your app delegate wouldn't even get loaded.
A key feature of many object-oriented systems (such as Cocoa) is "inversion of control", which basically means that the framework is running everything, and any code you write is under its control.
So, unlike PHP, you don't write the code that executes at startup. What you do is define methods for the app delegate, controllers, views, and other objects, and let the framework invoke those methods as it needs to do so. You will never see the overall "flow of control" throughout the program; you will only see it as control flows into your pieces of the program.
This can be confusing at first, as you try to figure out how to trick the framework into calling your code at the times and in the order you expect, but in the long run it actually makes things easier, as you can trust the framework to take care of a lot of things for you.
In a Cocoa app, a lot of the logic of the app will actually be in view controllers, rather than in the app delegate. The app delegate generally handles startup and shutdown responsibilities, but other objects do most of the work between startup and shutdown. So don't try to squeeze everything into the app delegate.