I have a small Swift-based Cocoa app that I'm writing. It's a single window app, something like Spotlight/QuickSilver/Alfred. It's set as NSApplicationActivationPolicyAccessory (docs) (though I've tried the same thing using LSUIElement, which is equivalent). It's activated via a global hot key.
Everything works well, except that when it's active I can't hide the application using NSRunningApplication.currentApplication().hide().
The docs for the hide method say "The property of this value will be NO if the application has already quit, or if of a type that is unable to be hidden." (emphasis mine), and I'm getting a NO back (though I'm actually using Swift, so I'm getting false).
I can understand why a NSApplicationActivationPolicyProhibited app wouldn't be able to be hidden, since it's never active, but it's confusing to me that this would be the case with NSApplicationActivationPolicyAccessory too.
I tried myWindow.orderOut(self);, but that just hides the window without hiding my application and returning focus to the previous app.
I do store a reference to the previously active application, so if need be I can manually activate that app again, but I'm hoping there is a cleaner method of doing this.
Use NSApplication.sharedApplication().hide(nil). One would normally address the application object (instance of NSApplication) rather than an instance of NSRunningApplication to operate on the current app.
The manual solution is to store a reference to the previously active NSRunningApplication instance (called previouslyActiveApplication below), and then activate it when you want to deactivate your NSApplicationActivationPolicyAccessory application, like so:
previouslyActiveApplication!.activateWithOptions(NSApplicationActivationOptions.ActivateIgnoringOtherApps);
Related
I'm looking to differenciate a dock clic from a click on the app icon in the finder.
Can I know what called applicationShouldHandleReopen or is there another way to do it ?
applicationShouldHandleReopen:hasVisibleWindows: is sent to the application's delegate. Delegate messages are normally sent by the delegating object, which in this case would be the application object.
The application object sends that message to its delegate in order to handle the reopen-application Apple Event. So, to find the sender, install your own Apple Event handler for that event and get the sender from the event. (The sample code is in Pascal and uses Apple Event Manager, but you can translate it to Objective-C and NSAppleEventDescriptor.)
That said, what you're doing is very dubious from a UI perspective. Reopening is meant to do the same thing no matter which application is reopening you—and it is not limited to the Finder or the Dock. In the common case, it is literally the user trying to launch the app while it is already open.
It may make more sense to only do your “reopen” behavior when no windows are open. Cocoa's built-in document-based-apps support does this automatically; if you don't respond to applicationShouldHandleReopen:: or you return YES, the application tries to open a new document. You can perform the same check (it even tells you whether you have any windows open) and perform your desired behavior under the same condition.
I love the new "Resume" feature in Lion. After a restart window size and position is exactly how you left it. But during development this is a bit annoying.
If I resize a window in the Interface Builder and restart my application it doesn't have the new size but the old size.
In the past you had to set the AUTOSAVE property to get this kind of behavior but with Resume it all happens automatically. Can I disable resume for my application somehow?
Yes. As documented in the Lion AppKit release notes, you can set the ApplePersistenceIgnoreState user default for your application. (The docs imply that the value isn't significant; it just needs to be set to something.)
An easy way to do this for debug runs only, while preserving the state restoration feature when you use your app normally, is to set it in Xcode. In your scheme's Run action, set a command-line argument for -ApplePersistenceIgnoreState, and, immediately after it, another one with the value (e.g., YES). This makes use of AppKit's feature of reading user defaults from the command-line.
I am currently working on a web browser project from Apple's Mac Dev site.
I have completed the project, but have a bit of a problem. I have created the project as a Document-Based Cocoa Application, and now whenever I enter text in any text field on the web, the red traffic light button shows a black dot in the middle that signifies an unsaved document. When I try to close the window or entirely quit the application, a warning pops up like that in TextEdit or Pages where it alerts me to unsaved changes. It's not too much of a problem, but I would like if someone could please tell me how to remove that feature of a Cocoa Document-Based Application.
Why a document based application if your application isn't document based? Document based applications inherently include the concept of open and save; it is a fundamental part of what they are.
In any case, you could "work around" this by configuring NSDocument appropriately; override the proper methods and otherwise muck with the change count & dirty state of the document. But it'll be just that, a workaround. The documentation for NSDocument has all the information you need.
A cleaner overall solution would be to refactor your app to not use NSDocument. Creating multiple windows is quite straightforward in Cocoa (an action method tied to a menu item where the action method loads a nib file; if I remember correctly, you could even use NSWindowController still).
An easier solution would simply be to override the isDocumentEdited method to always return NO.
- (BOOL)isDocumentEdited {
return NO;
}
I am familiar with iOS programming, but I don't know where to put my logic when I start a Cocoa project for OS X. Are there any good online resources for transitioning to OS X from iOS?
EDIT:
Thanks for the help so far. My main question is where my code goes in the default template.
My main question is where my code goes in the default template.
Assuming a single-window app, I make a separate custom controller to own that window, and I have the application object's delegate own that controller.
So:
The application object's delegate
Owns the custom controller.
Creates it in applicationWillFinishLaunching: (note: not Did; I change this).
Releases it (and nils out the instance variable) in applicationWillTerminate:.
Does not own the primary window (I remove that ivar and all references to it).
Responds to applicationShouldTerminateAfterLastWindowClosed: with YES, so that the user can quit the application either by specifically quitting or by closing the primary window.
May also respond to application:openFile: or application:openFiles:, typically by passing the file(s) along to the controller to import or something.
The MainMenu nib
Owns the application's delegate.
Does not contain the primary window (I remove the blank one).
The primary-window controller
Owns the primary window.
Owns the model displayed in the window.
Creates initial/empty model in init.
Loads the primary-window nib with itself as owner in init.
Closes and releases window (first) and releases model (second) and subordinate controllers (third) in dealloc.
The primary-window nib
Named similarly to the controller; e.g., “SnippetListController” for the controller and “SnippetList” for the nib.
Contains the primary window.
Primary window has “visible on launch” (really on nib load) turned on and “release when closed” turned off.
The advantage of all of this is that the lifetime of every object but the application's delegate is clear and explicit, as is the area of responsibility. My application's delegate is little more than that; the only thing it does that isn't specifically an app-delegate job is owning the primary-window controller. Likewise, the primary-window controller does nothing but own the primary window and whatever model I have to show in that window. And at quit time, everything but the application's delegate gets deallocked.
For document-based apps, I stick pretty close to the template. I delete any template methods I don't need to customize, and I may switch one or both of the I/O methods to one of the other versions (e.g., from readFromData:ofType:error: to readFromURL:ofType:error:), and maybe delete the write method if I'm writing a viewer only; that's about it.
Dive in.
Seriously just jump in with both feet. Find something that you want to make and just make it.
From what you've said you've already got a fair bit of experience with Objective-C and Cocoa and most things carry straight across.
What method should be called to deactivate an app right after it's launch in applicationDidFinishLaunching: delegate method has been called? Or maybe there is a better place to do that? The documentation for deactivate method for NSApplication says that I shouldn't call this method directly since AppKit knows better how to deactivate stuff.
Maybe using -[NSApplication hide:] would work, or perhaps activate another app using -[NSRunningApplication activateWithOptions:] (10.6 only, tho). However, I don't foresee many problems with using deactivate:.
It's not clear what you're trying to achieve.
You can use -hide: to deactivate your app. I also wouldn't hesitate using -deactivate if it actually does what you need. It's just that normal applications do not explicitly deactivate themselves; I think that's what the documentation is saying.
However, if you set LSUIElement in Info.plist your application should not become active when launched; it also won't have a menu bar or dock icon.