I'm stuck on this step of developing an XCode application: https://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/07_WhereNext.html
What I'm confused about is the role of the AppDelegate class that's created by default when creating a project initially in XCode 4. If I implement a custom controller, let's use the example link above and call it TrackController. Do I make that controller the app delegate? It seems any tutorial I read isn't very clear on this.
So, in AppDelegate, do I create a new instance of the controller class here? And if so, do I then hook up the outlet here? Or do I change the File's Owner to be the controller class? If that's the case, then how's that done in XCode 4?
Not a very well defined question I know, but I'm sure someone knows what I'm talking about.
EDIT
The following screenshot shows what I mean. The blue box is now "Track Controller". I've shown the AppDelegate class in this case though to make it clear. What do I use, AppDelegate.m, or TrackController.m? How should it be done?
EDIT 2
Going back to this, I've uploaded the code to GitHub here as I still haven't figured out how to hook everything up.
To re-explain, I need to figure out how AppDelegate and TrackController all relate and communicate with one another. The concepts are generally new to me and I've read the Apple documentation but they haven't really helped me. I've even had in-depth discussions with experts and I still fail to see how it should work.
My model is Track, then I have TrackController and of course AppDelegate. AppDelegate is instantiating TrackController and I was hoping that it'd be able to open up its window.
What am I doing wrong? Hopefully an expert can help me!
What it's describing is that the application delegate should focus on handling the delegate calls sent to the app.
You actually create a new class to act as the primary controller of the app, and then you add code to call it when the app is finished loading. From there on out, that app is (supposedly) your primary control point (except, of course, when it 'hands off' to another class).
I'm more familiar with how the process works on iOS than Macs, which have to worry about windows, but for an iOS app you'd add code to call your starting view controller from inside ApplicationDidFinishLaunching:WithOptions:. From there, the view controller takes off, and the easiest way to view the entire process is that you start at the view controller (that's how most tutorials handle it, in fact, letting XCode handle the fact that the app delegate creates that view controller).
Related
I have studying how to use IKImageView in my app. I downloaded the following demo from Apple site.
https://developer.apple.com/library/mac/samplecode/IKImageViewDemo/Introduction/Intro.html#//apple_ref/doc/uid/DTS10004049
One thing I do not understand is: This project has only implemented a Controller class.
#interface Controller : NSObject
{
...
I do not understand how does it work at all. If I create a new project in XCode, it will usually generate an AppDelegate class which implements NSApplicationDelegate interface.
I do not know if I understand the mechanism correctly.
Does the following steps describe how it works?
1) In info.plist it specifies the main bundle is MainMenu.xib.
2) the Window is binded to the Controller like so
3) When the application starts, it loads the Windows from the MainMenu.xib and the Controller class takes over the windows interaction from there.
It's really old sample code. It predates Xcode project templates generating an app delegate for you.
Back then, early Xcode and ProjectBuilder (the old name for it)
Left it up to you to do that.
Lots of older sample code has this sort of thing. As long as things get kickstarted by nib loading, magic happens, objects are instantiated and connected
If you have a simple controller that inherits from NSObject and it has a proxy in you main nib file, it will get created. If you also connect its proxy as delegate to some view or control in the nib, all of that happens.
You don't technically need an object that is the delegate of you NSApplication object. But in reality it is a good best practice and any non trivial app will have that and a lot more.
There's a lot of magic that happens when the C function NSApplicationMain() is called at the launch of your app.
The old and in many ways out if date book Cocoa in a Nutshell covers this well.
Yeah you pretty much describe how it works and what it's doing.
It's relying on the fact that NSApplicationDelegate is an informal protocol and it doesn't declare that Controller conforms to it and is using the NIB to kick-start the app.
When you first create an Application in XCode, at it's lowest level it creates the AppDelegate.h/.m and a MainWindow.xib
Once you start modifying the Xib to best suit your design needs - is it best practice to move away from the AppDelegate as the initial Controller or is it always better to create a new WindowController to use with the MainWindow.xib ??
Fritzables
The AppDelegate class cannot be used as a view controller, if that's what you're asking. Your AppDelegate class should be creating an instance of your main View Controller, which loads your main .xib file. Unless you're referring to defining the main Xib in your target configurations, but that's pretty old school.
Are you constrained by the version of iOS you need to support? Because you could avoid using .xib files altogether by using storyboards if you can use iOS 5.0 and up.
Well good question. To me app delegate always has been a initial step to define a project that I create. There are many use for delegates but that is another subject. If you look at the apple doc's related to this subject (over view section) in the following link, there is a great explanation of what is the function of the app delegate there. To answer the question you ask, it is always a good practice to leave the app delegate and create a new controller and execute whatever function you want in there. Here is the link to apple do's and I hope it clears up everything for you my friend. Happy coding.
http://developer.apple.com/library/ios/ipad/#documentation/uikit/reference/UIApplicationDelegate_Protocol/Reference/Reference.html
Sorry for the stupid post, but I am new to Objective-C programming and Cocoa and have a couple of questions which I can't find the answers to, I'm hoping someone can enlighten me.
Firstly, in XCode, when using the Interface builder, when I want to create a new object I drag the object to my 'assets'. However I can't specify methods or anything without manually creating a new class file. Is there any point using the interface builder's 'object'?
The first app I built to test things with, I put most of the code in the AppDelegate class files. Research has shown me that the AppDelegate's purpose is simply handling application events like launching and closing. Was I wrong in putting the methods in this class? Does it make any difference?
Finally, if I have several class files created, each handling their own functionality with an interface built and linked to the classes, then what do I do with the 'main' file? It seems to me that the 'main' file and 'appdelegate' class files will be for the most case left as-is?
I hope that makes sense. Again i'm sorry for the silly-sounding questions but I can't find any answers.
Thanks in advance everyone!
Firstly, in XCode, when using the Interface builder, when I want to create a new object I drag the object to my 'assets'. However I can't specify methods or anything without manually creating a new class file.
Sure you can. Just set the class of the object using the inspector.
Note that you can only connect nib objects to an outlet or action. You can't specify any random methods, nor should you—the whole point of the IBOutlet, IBOutletCollection, and IBAction keywords is to declare in code that these properties/methods are used by a nib.
Is there any point using the interface builder's 'object'?
Yes, but pretty rarely. Usually you create objects in code and connect outlets to them.
The application's delegate is one object you may want to create in the MainMenu or MainWindow nib, if you build your application that way (the iOS templates have changed away from it for some reason).
The first app I built to test things with, I put most of the code in the AppDelegate class files. Research has shown me that the AppDelegate's purpose is simply handling application events like launching and closing. Was I wrong in putting the methods in this class?
Probably. The application's delegate generally should only handle business relating to the NS/UIApplicationDelegate protocol.
On the flip side, it's OK to make your root view controller the application's delegate, if it makes sense to do so (and the NS/UIApplicationDelegate implementation code is not too voluminous). The question you have to answer—and only you can answer it for your application—is whether you are making your root view controller the application's delegate or the application's delegate the root view controller. If in doubt, keep them separate.
Does it make any difference?
Long-term, yes. It's very easy, especially in the class of the application's delegate, to create a Big Ball of Mud class—one without well-defined and clearly-delineated responsibilities. Take dynamite to such a class as soon as possible.
Finally, if I have several class files created, each handling their own functionality with an interface built and linked to the classes, then what do I do with the 'main' file? It seems to me that the 'main' file and 'appdelegate' class files will be for the most case left as-is?
Yes. They're boiler-plate.
If you haven't written any code in the application's delegate (or have removed everything you had put there into new and better-delineated classes), such that all that's left are empty method bodies or none at all, you can safely remove the application's delegate. You can always create it again later if you change your mind.
Note that if you delete your application delegate class, you should also change the main.m file—or the MainMenu/MainWindow nib, if you have one—to not refer to it. Your application won't build if your UIApplicationMain call (or any other code) refers to a class that doesn't exist, and it will crash if your MainMenu/MainWindow nib (or any other nib) refers to a class that doesn't exist.
There is no shame in your application having a delegate if you need it to, but if you don't, removing it and the class you were using for it eliminates future temptation to stuff code there or use it to store third-order globals.
The point of using objects in interface builder is to connect methods of the object to UI elements.
It partly depends on what your methods are doing, but for the most part the app delegate class is going to be left alone. It isn't an actual requirement (your program will work either way) but it is common practice because it generally creates more maintainable code. The app delegate should just handle the application events ( using other classes to do any complex logic or heavy lifting ).
The 'main' file will most likely not change. I can't think of any reason to do so, but I wouldn't rule it out for some advanced cases.
To be honest I only used the Object thing in IB once, when I wanted a separate object to have some UI bindings.
About the app delegate and main file, yes, you'll leave them as-is most of the time. But if you try to do something besides test apps you'll need to handle open events to, for example, connect to a server, ask the user for a review, increment some launch counter, etc... Those are just examples!
The main file I advise you to left it alone and use the object oriented tools provided. You should have a view controller hierarchy, isolate your views from the data, and use the view controller to comunicate between view and model. Read about MVC if you want more info on how your application should be organized.
I'm fairly new to Objective-C and cocoa programming, so I don't really understand the concept of App Delegates.
When we create a cocoa application, do we store our code (Methods, actions, outlets) in the App Delegate files or do we create a new file that will act as a controller and code from there. Right now, I put all of my code in those two files, but from what I read, your goal is to try to make your App Delegate files as slim as possible.
My question is: What's the usage of the app delegate files?
Talking about applicationDidFinishLaunching::
It's just your application entry point. Normally you only create the window and your first ViewController, or your Tabbar - your main starting interface class - here.
All the other delegate methods of the NSApplicationDelegate have other functions of course. Most of them are the point, where you react on the state of the app. Opened / Closed / Backgrounded / Reopened etc.
But you should probably have a look at the programming tutorials in the iPhone documentation. There is a lot of information on how to structure your objc projects. E.g. look here: Start Developing iOS Apps Today
Or if your looking for OSX Apps, look here:
1) Your First Mac App
2) Mac App Programming Guide
There is also a bunch of Sample code.
The App Delegate is a handler location to handle events that occur on the application. Things like open and close. It also hangs around the whole time the application is executing and you can grab the singleton instance at any point by doing [[NSApplication sharedApplication] delegate].
This comes in handy for handing objects between controllers and serving as a router for events. You can also store some data on the delegate if you need to modify/have access to it in different parts of the code.
This all works well for simple applications, but as things become more complex, you need to have some division of responsibilities. The AppDelegate should really only be responsible for actions that occur on the application itself, not on another view or a controller. Putting all/most of your code in the AppDeligate is certainly bad practice and will lead to horrible code as things get more complex and need to be maintained.
My iPad app was working fine until I opened up IB and started editing the interface. Now, my application:didFinishLaunchingWithOptions isn't getting called. I understand it's an optional function and it gets skipped if it doesn't exist, but in my case it does. What are some reasons that application:didFinishLaunchingWithOptions method could get skipped?
I should note that I'm building with the iPhone OS 3.2 SDK.
Thanks in advance for your help!
UPDATE: I fixed it, please see my answer below
Are you sure that class has been set as the application delegate of the app?
(source: xanga.com)
And also make sure the "File's Owner"'s delegate has been linked to "App Delegate".
(source: xanga.com)
Well it turns out, for an unknown reason, I had a "view" view object as a child of my RootViewController in IB that didn't serve any purpose except to hold my a TableView view object and a DatePicker view object. I thought it was harmless, but when I removed it in IB and programmatically added the TableView object and and DatePicker object, suddenly this problem went away. If anyone has any ideas why this is, I'd would love to understand it.
Thanks, everyone!