Re: Mac OS X - Inter-Application Communications
Re: Mac OS X - Inter-Application Communications
- Subject: Re: Mac OS X - Inter-Application Communications
- From: Kevin Meaney <email@hidden>
- Date: Fri, 06 Mar 2015 12:14:29 +0000
> On 6 Mar 2015, at 11:34, Dave <email@hidden> wrote:
>
> Hi,
>
>> I think you might need to provide some more info about your architecture and I also think you need to ask your questions in the xpc devforums list: https://devforums.apple.com/community/mac/coreos/xpc <https://devforums.apple.com/community/mac/coreos/xpc> because if you get an answer there it is more likely to be well informed.
>
> Thanks Kevin, I’ll take a look at the XPC forum.
>
>> I am a little confused by your terminology. I’d call an Application a process that a user interacts with (that displays the menu bar) but I wouldn’t call the four items listed above Applications.
>
>
> Yes, it is confusing and I think I called it this because it’s referred to as a “Faceless Background Application” (FBA) in some places. I’ve just started this project and I’m a little confused about some of the things I need to do myself, but I think I have it clear in my head what is needed now, there are two things that are needed:
>
> 1. Have some kind of background monitor (FBA?) that detects certain conditions and when a trigger condition is met, send it to a regular Mac Application (with a UI). There is no need for any of the Application(s) to send anything to this FBA.
This approach will awkward to implement because it is opposite to the way XPC is designed. The XPC design is intended for a process such as a (LoginItem, LaunchAgent, LaunchDaemon, XPC service) to provide a service, so when your GUI Application needs a task to be done that is provided by a service it sends that service a message which the service handles and then sends a reply back to the application using the connection initiated by the application.
It is likely possible to achieve the opposite goal by the application first sending a message to your monitor and the monitor keeps the connection open, details of how to achieve this other than just waiting to reply until the monitor trigger condition is met I can’t help with.
>
> 2. Have some kind of “Service" that owns an SQLite database and allows other applications to send read/write requests to it.
This would be a launch agent or a login item.
>
> I was confusing the two before, probably because in the specification I have, the two are shown as one unit. At the moment I am concentrating on the Monitor (1) above, as the database manager is not needed until further on in the project.
>
> Given the that I have two “applications” (for want of a better term) LTWMonitor and LTWAppX, then on the face of it and ignoring any OS requirements for the moment, this is what needs to happen:
>
> LTWMonitor will be Launched when the User Logs.
> LTWMonitor will then launch LTWAppX as part of its initialisation.
> LTWAppX will launch and do nothing, waiting for an “Event” from LTWMonitor.
If I was you I would consider putting your LTWAppX in the list of the users login items and after it starts it launches the monitor by sending the monitor a XPC request.
>
> Once this has happened:
>
> If LTWMonitor detects a Trigger condition, it will send it to LTWAppX.
> When LTWAppX receives the message from LTWMonitor, it take the appropriate Actions (e.g. display an appropriate UI) for the message received.
>
> Given this, should I be considering XPC for the UIMonitor? One concern I have it what it needs to be very responsive and as far as I know XPC is the fastest solution and is the preferred modern way of achieving this.
Performance wise I am happy with XPC but then your requirements may be different.
Kevin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden