NSXPCConnection zwischen 2 Apps

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • NSXPCConnection zwischen 2 Apps

    Hi,

    ich möchte, dass zwei macOS Apps miteinander kommunizieren. Über NSDistributedNotifications habe ich es schon probiert. Klappt soweit ganz gut.
    Aber über NSXPC wäre meiner Meinung nach die schönere Möglichkeit.

    Im Grunde habe ich zwei Cocoa Apps.
    Eine GUIApp soll die andere GUIApp "was fragen" oder "um Daten bitten". Die zweite GUIApp soll die Anfrage hören und beantworten.

    Leider klappt das nicht so wie gehabt.

    Funktioniert das überhaupt?
    Oder klappt XPC nur mit einem XPC Service und nicht zwischen zwei Apps?


    Ich hab das Projekt als Anhang.
    Dateien
  • Ich hätte gar nicht erst probiert, mit einem nicht-XPC über NSXPC zu kommunizieren. Es wird ja einen Grund geben, warum das so heißt. Außerdem gibt da ja so Sachen wie launch on demand, die zwischen zwei GUI-Apps nicht so richtig Sinn machen. Darunter liegen natürlich mutmaßlich mach ports. Ob du die aber selbst bedienen möchtest …?

    Das Mittel der Wahl dürften Distributed-Objects sein. Schon angeschaut?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
  • Hi Amin,

    mein Problem war ziemlich kompliziert.

    Ein App läuft als LaunchDaemon(LD) die andere als LaunchAgent(LA). Die GUI von LA läuft in der StatusBar von macOS.

    Nun sollte LD mit LA kommunizieren z.B. eine neue Software steht zum download bereit, LA soll dann eine NSUserNotification and den User schicken. Der User hat die Möglichkeit über die Notification sich zu entscheiden, ob er die Installation der Software zulässt oder nicht (DND wird auch beachtet etc).

    Entscheidet sich der User soll LA das nun an LD weitergeben, LD installiert oder installiert nicht daraufhin die Software.


    Das ganze ist nun so implementiert:

    LD hat einen LD-XPC dazubekommen (beide im root Kontext, da über LaunchDaemons laufen)
    LA hat einen LA-XPC dazubekommen (beide im User Kontext, da über LaunchAgents laufen)

    Die Besonderheit: LD/LA startet nicht selbst seinen XPC-Service, sonder launchd startet die Apps und die XPCs

    LD öffnet mit initWithService:@"hier.die.LA-XPC.Bundle.Id" eine Verbindung zu LA-XPC und schickt eine Nachricht. Der LA-XPC schickt daraufhin per NSDistributedNotification die Nachricht weiter an den LA. Das ist die Lösung die funktioniert, da LD in root Kontext und LA im User Kontext laufen.

    Möchte LA and LD eine Nachricht schicken so muss LA eine Verbindung zu LD-XPC mit Hilfe von initWithMachService:@"hier.die.LD-XPC.Bundle.Id" option:0 herstellen. LD-XPC schickt dann an LD die Nachricht weiter per NSDistributedNotification.
    Dateien
  • gritsch schrieb:

    Am besten verdongelst du das ganze auch noch so dass nur die programme untereinenader die messages schicken können (über die pid kommst du ja an das programm und darüber an die signatur)

    Kann ich machen.
    Ich weiß nur nicht ob überhaupt der Ansatz schlau ist den ich da gegangen bin.

    Ich würde auch gerne eine bessere Alternative zu NSDistributedNotification haben wollen.
  • Miralem23 schrieb:

    gritsch schrieb:

    Wozu brauchst du die distributed notification überhaupt?
    du kannst doch auch gleiche eine XPC-connection aufbauen?
    Baut dann der XPC-Service z.B. der LD-XPC zu LD dann auch über NSXPCConnection eine Verbindung auf? Somit müsste LD auch einen Listener bekommen.
    warum nicht? du kannst xpc-verbindungen ka zwischen root- und user-context aufbauen und umgekehrt.
  • Hast du das hier nshipster.com/inter-process-communication/ schon gefunden?
    Beantwortet zwar nicht deine konkreten Fragen, aber ist ein guter Überblick über die Alternativen (und bestätigt meine Meinung, dass Distributed Objects nicht mehr zeitgemäß ist - wirklich verbreitet war es afaik eh nie).
    NSXPC scheint imho ähnliche "Akzeptanzprobleme" zu haben wie DO; aber wahrscheinlich wird es einfach nur selten benötigt und gehört deswegen nicht zum Standardrepertoire (es muss ja nicht für alles ein fertiges Tutorial geben ;-).
  • DO ist einzig und allein deshalb nicht weit verbreitet, weil man es selten benötigt. Ebenso XPC.

    Du siehst aber selbst, welchen verqueren Aufwand du betreibst. Du siehst auch im von t-no verlinkten Artikel, dass DO nur minimalen Aufwand benötigt. Die dort angesprochene "Problematik" mit Proxies ist schlicht gar keine, wenn du dein Model nicht verteilen möchtest, sondern ein paar Controllernachrichten verschickst, was offensichtlich dein Wunsch ist. (Und im Übrigen ist es bei jeder Kommunikationstechnik eine, weil es sich um ein denkgesetzliches Problem handelt. DO gibt dir bloß Mittel an die Hand,damit umzugehen.)

    Nimm DO. Das heißt, wenn es kein Problem ist, dass die Dinger in verschiedenen Kontexten laufen. Das habe ich noch nie probiert und weiß es aus dem Effeff nicht. Aber mit Do hast du das ja auch in ein paar Minuten probiert.

    BTW: In der Entwicklungsphase liefen Apps auf Objective-Cloud als XPC. Wir haben das bleiben lassen, weil es eigentlich keinerlei Vorteil versprach. Und so dürfte das bei dir aussehen. Launch on demand? Brauchst du nicht. Encrypted Link? Brauchst du nicht. Was soll's also?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()