I asked a question about quitting an App when windows close, and the answer was to use delegates :
There is a optional method for the application's delegate which will do this
automatically. All you have to due is add this to the implementation. You don't need to create an outlet or anything.
- (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)theApplication
return YES;
}
It definitely works, but you may have put the code in the wrong place. Make sure it's in your application's delegate.
I'm not sure how can I put the applicationShouldTerminateAfterLastWindowClosed in the application's delegate?
Your xcode project should have created an application delegate class when the project was created. The only thing you need to do to implement this in your delegate is to add the method into the delegate .m file (you don't need to worry about the .h file since the method is already declared as part of the application delegate protocol).
So you have the class called RubichevAppDelegate. Put the method into the .m file.
PS. You forgot the opening brace in your code.
Related
I'm very comfortable with writing iOS apps, but OS X unexpectedly seems somewhat alien.
Here's the question upfront (read on for context):
When my application launches using the .xib set in the Main Interface field under the deployment info of my apps target, why does the AppDelegate get instantiated after the ViewControllers?
Context (no pun intended):
The reason I ask is because I'm using Core Data (spare me any heckling for this decision), and typically you keep a pointer to the MOC (Managed Object Context) in AppDelegate. One of my controllers is trying to get this MOC instance variable but the AppDelegate instance isn't around yet and therefore my app doesn't present data just after launch.
The AppDelegate and the two ViewControllers are in the .xib. The VCs are hooked to views inside a split view. They're trying to use the MOC in viewDidLoad to make queries. They are accessing the AppDelegate like this:
let delegate = NSApplication.sharedApplication().delegate as AppDelegate
let moc = delegate.managedObjectContext
This will crash as the .delegate property of the sharedApplication() returns nil.
I tried making an NSWindowController from the .xib in applicationDidFinishLaunching and removing the .xib from the Main Interface field, but then applicationDidFinishLaunching doesn't get called at all.
I've ensured that all the connections in IB for from the Application and the Files Owner (NSApplcation) delegate IBOutlets to the AppDelegate have been made.
UPDATE - 31/03/15
Stephen Darlington's answer below offers a good solution for my/this case. And as I understand it's actually better to setup the MOC in the way he's suggested.
If a correct answer arrives that explains why the AppDelegate is being instantiated at some later time in the launch process, I'll mark it correct instead of Stephen's. Thanks Stephen!
The "easy" solution would be to have managedObjectContext create a MOC if one doesn't exist (i.e., change it from a property to a method). That way which ever code gets there first the stack will be available.
(I'll spare the lectures about both creating the Core Data stack in the app delegate and accessing the app delegate like that!)
Here's another option without having to subclass NSApplication:
Don't put your view controllers in the .xib that you set as the Main Interface, just have the Main Menu (menu bar), AppDelegate and Font Manager in there.
Then make your view controllers in other .xibs.
Then in the applicationDidFinishLaunching method init your view controllers from their .xib files.
I also faced this issue with setting up Parse. To get around it, I simply subclassed NSApplication and set it as the Principle class in the Info.plist. In your NSApplication subclass, override the init methods and initialise Parse or anything else you need to, there.
Given that iOS SDK 6.1 is used in Xcode 4.6.3 , does it make a difference to declare the method signature of IBAction in a header file or not?
Without putting the method declaration in the header file, the app is still able to compile and run without problems. However, the method cannot be seen in a storyboard.
Are there any hidden issues of not declaring the method in the header file? Is there a memory consumption difference?
The entire point of an IBAction method is to be a public connection point in Interface Builder (using Storyboards or not).
The word IBAction itself is #defined as void. Its only purpose (and the same is true of IBOutlet) is to allow Xcode to scan your code and find these points where your controller needs to be wired up views via IB. You don't need the IBAction part of the declaration if you're programmatically connecting a control to that method.
There's no performance difference, but semantically, putting an IBAction in your implementation file doesn't really make sense. Having an IBAction means the controller is communicating to an outside object via that method, and that's exactly what header/public #interface declarations are for.
Only declare it in the .h file if you want to connect it in your storyboard/interfaz builder or you want to make it public for other classes to call it.
If you just want to make it private and only use it inside your class, there's no need of declaring it in the header file.
There's no memory or performance difference.
Even if you plan to hook it up to the interface builder, it still doesn't have be in the header file. I personally just place them straight into the implementation file.
I read a post to use macro to reference AppDelegate. I wonder what I should use to replace (MyOwnAppDelegate*)
#define AppDelegate ((MyOwnAppDelegate*)[[UIApplication sharedApplication] delegate])
If you're referencing the UIApplicationDelegate so often that you need a special macro for it, then you're referencing it too often. The application delegate is the delegate of the main UIApplication object. It is not a general place to store "stuff." See the following discussions:
What describes the Application Delegate best? How does it fit into the whole concept?
Is it ok to place most logic and models in the appDelegate?
If it's a more recently started project, your delegate is probably called AppDelegate. To find out, you have to find the class in your project that implements NSApplicationDelegate or UIApplicationDelegate (depending on your target platform).
I am using the WebViewDidFinishLoad delegate Method of WebView, but it is not getting called. Whenever I run the application and load request in a WebView.
Please tell me, how to call the method and which delegate I need to connect with the file owner.
Any help will be appreciated.
Thanks in advance.
You said in a comment on another answer:
- (void)webViewDidFinishLoad:(WebView *)webView{ NSLog(#"hello");}
This method is not getting called.
That's because there is no such method.
WebView and UIWebView are not the same thing. The former is in the WebKit framework on the Mac; the latter is in the UIKit framework on iOS. WebView is not available on iOS and UIWebView is not available on the Mac.
UIWebView is a very stripped-down version of WebView. In particular, UIWebView has only one delegate protocol, of which webViewDidFinishLoad: is one of its methods, whereas WebView has no fewer than six delegate protocols.
webViewDidFinishLoad: only exists in the UIWebViewDelegate protocol, in the UIKit framework for iOS apps. Implementing it in a Mac application will achieve nothing, because nothing will call it.
Please tell me how to call the method …
That will do you no good, because the whole point of implementing it is to find out when a load has finished. For you to call it yourself, you would need to know when to call it—i.e., when a load has finished. To know that, you would need to be told that a load has finished by WebKit. This is, as they say in logic, begging the question.
The correct solution is to set the correct delegate to an object that conforms to the correct delegate protocol and implements the correct method. The correct delegate is the WebView's frame load delegate. Accordingly, the correct protocol is the WebViewFrameLoadDelegate protocol. The correct method within that protocol that your frame load delegate must implement is the webView:didFinishLoadForFrame: method.
Cocoa Touch programmers with the same problem (webViewDidFinishLoad: not getting called) should make sure that their UIWebView's delegate is set to the correct object. If you're setting it in code, make sure you're talking to the correct web view—i.e., that your outlet to the web view is connected (if it's in a nib or storyboard), that you're loading the nib or storyboard (if it's in one), and that you're not clobbering the value of the outlet with a different web view (one from the nib, then one created in code, or vice versa).
Try to add (And replace the myUIWebView with your UIWebView outlet name):
[myUIWebView setDelegate:self];
And in the header file, add <UIWebViewDelegate>, so you can use this methods:
-(void)webViewDidStartLoad:(UIWebView *)webView {
}
-(void)webViewDidFinishLoad:(UIWebView *)webView{
}
First Bound ResourceDelegate of webview with file Owner
(void)webView:(WebView *)sender resource:(id)identifier didFinishLoadingFromDataSource:(WebDataSource *)dataSource
This will work for me perfectly.
I'm developing an iPad app.
Now I ran into the following problem. I created a "Custom Class" for a UIScrollView. So in my nib file I have added a default UIScrollView and set the Custom Class to MultiSelectView (which is the custom class I created). Screenshot here.
So in my MultiSelectView I have added some methods that I want to use. This works!
The issue is that I'm wondering how I can initialize certain objects that I need in these methods. It seems like - (id)initWithFrame:(CGRect)frame {} is not called, and neither is - (void) viewDidLoad {}.
Thus, is there a way to initialize a custom (GUI) class?
When you unarchive a view from a .xib file, it is not sent -initWithFrame:, as you've noticed. Instead, it's sent -initWithCoder:.
So, if you've got any UIView subclass in a .xib file that needs custom initialization, you'll need to override -initWithCoder: as well as (or instead of) -initWithFrame:.
Looks like you need initWithCoder, it is called when object is loaded from NIB
Or, better, awakeFromNib. The difference is that awakeFromNib is called when all outlets are connected.