I'm trying to intercept when iTunes starts up on Mac OS X, so I can relaunch my application to work around few bugs in the iTunes Framework.
What I did is to temporarly disable the sandboxing of my application and listen to all NSDistributedNotificationCenter notifications in order to examine them and pick the ones I want.
What I found is that upon start iTunes apparently sends this event:
object: com.apple.iTunes.help name: HelpBookRegistrationDidChange userInfo: (null)
which seems rather unique but also doesn't give an exact clue it is related to a startup event only at 100%.
Does anyone know if this is safe way to intercept such event?
If so, once my app is sandboxed again I need to ask temporary permission to listen to this kind of event, how can I do that in code?
Do you believe scripting bridge can help in this case?
You don't need to disable sandboxing for this, just observe NSWorkspaceDidLaunchApplicationNotification in the notification center provided by NSWorkspace, not the distributed one.
You'll get an instance of NSRunningApplication in the user info of the notification, which you can use to determine whether the launched app was iTunes (use the bundleIdentifier property).
Related
when in 10.11, a new feature is brought: user can shake mouse to find cursor(cursor become larger).
my mac app want to get notify when user does this.
is there a way or any clue?
Apple engineers have reviewed my request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations. Application's can not be notified when the user activates the cursor location assistance feature.
In my main app bundle I have supporting XPC service included. App is sandboxed and everything works quite fine, except that when I call [[NSUserDefaults standardUserDefault] setObject:forKey:] method and than - synchronize method from the XPC service app, preferences are not written and data cannot be retrieved next time I need it.
I didn't find anything related to this problem in Apple's documentation, except that the sandboxed app cannot access preferences of other apps. That's all right, I don't need it. XPC service has its own container in ~/Library/Containers, where it should be able to store its own data, I'd suppose. But obviously it's not the case for some reason.
I probably missed something, but cannot find what. Is there anything special which needs to be done (adding some entitlement or so) in order to make this work?
Thanks for any tips.
I believe you'll need to use Group Containers to share the preferences and I have achieved something similar (a non-UI LSUIElement app sharing preferences with its conventional Preferences app countpart) using RMSharedPreferences.
I'm having some architectural doubts about a project (Mac OS X app) I'm working on. It basically consists of two elements: a daemon that runs in the background gathering some data and a viewer used to represent the gathered data.
The daemon should be visible in the status bar (no dock icon) and includes a small menu accessible via the status bar. It saves data in a core data store. One of the menu items is a link which opens the viewer. When this viewer is opened, a normal GUI application should start including a dock icon and menubar. The viewer is also opened when opening the application itself (by double-clicking on the icon).
After some experimenting, I figured out the best way to achieve this functionality is by creating two applications, the main application representing the viewer and a helper utility representing the daemon. One of the reasons I did it this way is that it isn't possible to switch between LSUIElement values instantly to force the daemon/viewer state.
Now I have some questions about this architecture:
Both the daemon and viewer application uses the same core data store to save and retrieve data. When having a multi-threaded application I know multiple NSManagedObjectContext objects are needed to correctly synchronize data. What about having multiple applications using the same core data store simultaneously? Is this even possible without having the risk of conflicts, locks, etc.? How do I guarantee consistency?
The daemon should always start when the viewer starts. I achieved this by simply looping through all open processes and checking if the bundle identifier of the daemon is listed. If not, the daemon is started using NSWorkspace's launchApplication. This works fine. Now when the user quits the daemon, the viewer should also stop. What is the best way for the viewer to be notified of the daemon stopping? I can periodically check active processes and quit the viewer if the daemon is gone but that sounds a bit odd. I would rather choose some kind of notification that I'll send when the viewer is about to close. But since this notification should be sent and captured between apps I don't know which simple notification service is available. Any thoughts?
The application is sandboxed as it will be distributed on the Mac App Store. Starting apps with NSWorkspace's launchApplication causes the target app to run in the same sandboxed environment as the source which I think is not a problem at all because running both applications in the same sandbox feels better and probably is. But imagine this scenario: the daemon is started automatically at login (using SMLoginItemSetEnabled) and the user double-clicks Viewer.app. As the daemon is already running (again, this is checked by looping through active processes) it won't be started. Now we have the daemon and the viewer running in different sandboxes right? Will this cause any problems regarding preferences, core data store, etc.?
I would like to use NSUserDefaults for basic configuration, can I somehow interchange this data between the daemon and the viewer? Again, both applications will have different bundle identifiers.
Thanks in advance for your help, appreciated!
There isn't one right answer to this problem, but here's how I'd approach it:
Both the daemon and viewer application uses the same core data store to save and retrieve data.
Because sharing a Core Data store between processes isn't supported (as far as I know), I'd have the daemon expose an XPC Service. Instead of opening the Core Data store itself, the viewer would use an NSXPCConnection to access the data via the daemon.
Assuming the viewer never runs without the daemon, it can use SMLoginItemSetEnabled, like you mentioned in the question, to register a mach service for the daemon, and then connect to that service.
There's sample code that goes over the details of setting that up here on Apple's website (summary: the daemon needs to be at App.app/Contents/Library/LoginItems/daemon.bundle.id.app), and you might also want to read this blog post that discusses some extra requirements imposed by sandboxing (summary: make extra sure that your Team ID is in the daemon's bundle identifier).
The daemon should always start when the viewer starts.
All set: once you register the daemon with SMLoginItemSetEnabled, launchd will start it (if necessary) when the viewer connects to its XPC Service.
Now when the user quits the daemon, the viewer should also stop.
The viewer can use the NSXPCConnection to find out when the daemon quits. The daemon can also use SMLoginItemSetEnabled to un-register itself before it quits, so that it doesn't get relaunched.
I would like to use NSUserDefaults for basic configuration, can I somehow interchange this data between the daemon and the viewer? Again, both applications will have different bundle identifiers.
Use a suite for this:
// To read or write:
NSUserDefaults* suiteDefaults = [[NSUserDefaults alloc] initWithSuiteName:#"com.example.app.shared"];
[suiteDefaults setObject:[NSDate date] forKey:#"launchTime"];
// Add the suite to -standardUserDefaults to make reading easier:
NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
[defaults addSuiteNamed:#"com.example.app.shared"];
To work with sandboxing, the viewer and the daemon must share an App Group. You can even use KVO to observe changes to shared keys.
For an app I am working on I am using CGEventPost to post some key events and I noticed that it stopped working with sandboxing enabled, even I turned on the "Enable Access for Assistive Devices" system preference.
Is there an entitlement to allow the use of CGEventPost? Or, is there another way to post key events with apps submitted to the Mac App Store?
Can Mac App Store Sandboxed apps use CGEventPost?
No.
Is there an entitlement for CGEventPost? Or is there any way to post key events with apps submitted to the Mac App Store?
No.
If you look at the developer forums, Apple has made it very clear that they will never enable an entitlement for this, because it allows a blatantly obvious way for any app to escape the sandbox.
If you have some more specific need that you can justify (not "post some key events" but "get iPhoto do to XXX, which as far as I know can only be done by posting event YYY at it"), file a bug report, and post a thread on the dev forums.
This will do two things:
Someone at Apple may suggest a workaround--possibly a private one that nobody else can tell you and/or one that isn't normally allowed on the App Store but will be accepted if you've been told to use it.
It increases the chances that Apple will invent some better way to do what you want in the future.
Old question, but accepted answer is wrong. There are apps in Mac App Store that are using CGEventPost to simulate events. For example apps "Remote Mouse" and "Mobile Mouse Server" do that. They can send input to any other app and based on symbols in those apps they are clearly using CGEventPost-function. I would like to know how are they doing it.
I'm trying to get my mac app to do something whenever Safari is launched. The obvious way to detect Safari launch is by polling for running processes. Is there a better way to do this?
I was thinking there might be some API that I could use to register callbacks on, or perhaps there's a notification center event that I can observe.
You can add yourself to NSWorkspace's notification center as an observer for NSWorkspaceDidLaunchApplicationNotification. When you receive the notification, examine the instance of NSRunningApplication it provides (object in the notification's userInfo for the key NSWorkspaceApplicationKey) to determine if it was Safari that was launched.
Check the NSDistributedNotificationCenter and NSWorkspace classes.
The following post might be helpful: How to Listen For an Application Launch Event in Mac OS X?