Communicate between finder sync extension and XPC
Asked Answered
B

4

11

I am working on a Finder Sync Extension for OS X and want to use a background XPC service.

I can start in the main app and have it launch the XPC and run correctly but nothing happens when I attempt to access it from the Finder Sync. both the finder sync and the XPC are their own bundles so that may be the reason why. What I am wanting is for the finder sync to talk to the XPC about the status of the files and the main app to talk to both the finder sync and XPC about the list of folders to watch.

Has anyone had any luck with this? Is there a better way for a on demand background service? Is it possible to talk between two XPC services?

Beiderbecke answered 18/10, 2014 at 5:18 Comment(0)
B
5

Working with some Apple Engineers they realized this was a problem and suggested using a LoginItem until a better solution is in place.

So, it is sort of an XPC service, just one that constantly runs. XPC communication is available to both extension and host app.

It works, although it is not the most ideal solution. I recommend the apple sample project that deals with XPC login items for an example of how to get this working.

Beiderbecke answered 7/11, 2014 at 18:1 Comment(1)
Can you please explain this in more details? Are you using the separate application as XPC service, or bundle it together in the main app? I have a problem that NSXPCConnection doesn't seem to open from Finder plugin to my XPC service, which is bundled within the main app.Illtimed
C
2

I implemented MainApp <-> FinderSyncExtension communication via CFMessagePorts. See my question and answer for some details:

How should Finder Sync Extension and Main App communicate?

Conley answered 15/12, 2016 at 14:2 Comment(0)
L
1

You can't communicate directly between the container application and the extension, but you can do it indirectly using shared resources. I did exactly what you have done which is completely incorrect. I hope you store the file status in the database, if not store it and then share the database between the container application and the extension. I know, why do you want to use XPCService as it is in the Apple's FinderSync Doc. (Actually for the performance reason, Create a NSXPCService to the extension and from the XPCService, access the shared database)

For more information about sharing database:

http://blog.sam-oakley.co.uk/post/92323630293/sharing-core-data-between-app-and-extension-in-ios-8

Hope this helps you,

Lipolysis answered 6/11, 2014 at 17:18 Comment(2)
Is sharing-database still a recommended way to do FinderSyncExtension <-> MainApp communication? How to notify Finder it should refresh itself when database gets updated?Conley
I would strongly recommend AppleScript now. I have just blindly followed apple docs and completely forgot about AppleScript. I am using AppleScript for communication. No you dont need to use shared container, Thanks to AppleScript :)Lipolysis
K
1

I had stubbornly ignored utahwithak's answer and tried to get it to work anyway. I eventually had to ask a similar question on Apple Developer Forums and finally received a definitive answer on why connecting the Finder Sync Extension to an embedded XPC service is not a viable system design.

Essentially:

  • Finder Sync Extension essentially behaves like a third party app in that it does not have the same scope as the host app to be able to establish an XPC connection with the embedded XPC service.
  • utahwithak's answer is correct in that in order to allow the Finder Sync Extension to communicate with the XPC service, it needs to be an XPC login item. However there are some caveats to this:

    • This seems to be an accidental feature. Not sure if it's something that might eventually be fixed/removed
    • The XPC will have to be always running even if it doesn't need to, by virtue of being an login item
    • If it's a login item, the user will need to explicitly opt in for this feature and be able to opt out.

Source:

Klaxon answered 9/1, 2019 at 17:27 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.