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.
Related
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.
I would like to be able to set a terminal variable; basically what I want to do is assign my own exit code through my app. My research finds that NSTask maybe the way to do this, but I can't say for sure how to go on about this since I know for one, I do not know if I can have a setLaunchPath:.
Here is an example of what I would type in the terminal:
bash-3.2$ $(exit 15); echo ${?};
15
Sorry if the question doesn't sound very technical. Please ask if you need clarifications. Thx in advance.
This isn't a good fit with a Cocoa application. Or are you considering a Foundation command-line tool?
First, it's not typical to invoke a Cocoa application from a command-line shell. If you do, it's most common to do so using the /usr/bin/open command, which is not normally synchronous and so doesn't convey the app's exit status to the shell.
Second, the process which exits does not directly set the shell variable. It exits with a status code and that's stored in the kernel. The shell then obtains that status code from the kernel and sets its own variable. It is not generally possible for one process to set an environment variable (or any other state) in another process (other than one it spawns itself) without that other process's cooperation.
Third, a Cocoa application typically quits using -[NSApplication terminate:]. That doesn't provide a way to tell the framework what value to use as the exit status code. NSApplicationMain(), which is what's typically called by the app's main() function, is documented to never return and to call exit(). The documentation suggests that it may specify some meaningful status code – "If you want to determine why the application exited, you should look at the result code from the exit function instead." – but not what that might be nor any way to influence it.
You might call exit() yourself from the -applicationWillTerminate: method of your application delegate. That way, you get to specify the status code. I'm not sure, though, if that might break any final cleanup that Cocoa might do. For example, if you have promised some data to the pasteboard, Cocoa requests that you provide it before your application terminates. I'm not sure if that occurs before or after -applicationWillTerminate: (probably before). That delegate call is in response to the application object posting the NSApplicationWillTerminateNotification notification and there may be other observers of that notification. The order in which observers get notified is not specified, so the app delegate is not necessarily the last thing that would get it.
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
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.
I'd like to use gdb or Xcode's debugger to watch every message sent to an object in an Objective-C 2.0 program. I don't care about arguments and such, as I just need to see every message it receives (retain, release, autorelease, etc). I also don't want to profile my entire program.
Is there a means, in Xcode, to select an instance (possibly by address) and say "show me every message sent to this object"? Since the plumbing is fairly standard, I imagine there would have to be a probe hook or something. Anyone ever done this?
(Aside from subclassing the object in question, of course; looking for a more general solution.)
This is for iPhone development with Xcode 3.2 on Snow Leopard.
You can set the NSObjCMessageLoggingEnabled environment variable to YES and then grep/filter through the resulting log for the object you're interested in.
Here's a relevant blog post as well, though I'm not sure how much of the information there is still true in the runtime today. (It might all be. I really don't know.)