【问题标题】:Xcode Extension + Helper Mac App + Launch Arguments?Xcode Extension + Helper Mac App + Launch Arguments?
【发布时间】:2016-10-30 21:05:22
【问题描述】:

注意:这里似乎存在类似的问题:Launch Helper Application with Launch Arguments in the Sandbox,但我在下面提供了一个更详尽的示例,其中包含源代码。

简短的前言:

我想编写一个 Xcode 源代码编辑器扩展(Xcode 8 中的新功能),当它被触发时,它会启动我正在编写的配套 Mac 应用程序,并将用户正在查看的源文件的行传递给 Mac 应用程序触发了扩展。

帮助 Mac 应用程序随后会为用户提供一个用于执行其编辑功能的界面。当用户完成更改后,他们按下某种“保存”或“提交”按钮,然后更改会传播回 Xcode 扩展,然后返回到原始源文件本身。

我目前所拥有的:

我已经为我的助手 mac 应用程序创建了一个简单的 Mac 应用程序。它目前所做的只是,在它的 Application Delegate 中的 applicationDidFinishLaunching(...) 实现中,尝试构建传入的启动参数的字符串,并将该字符串显示为警报的消息正文。见下文(注意我尝试使用 ProcessInfo.processInfo.arguments 和 CommandLine.arguments):

func applicationDidFinishLaunching(_ aNotification: Notification) {  

    let args = ProcessInfo.processInfo.arguments  

    var argString = ""  
    for arg in args {  
        argString += ", \(arg)"  
    }  

    let alert = NSAlert()  
    alert.addButton(withTitle: "OK")  
    alert.messageText = argString  
    alert.runModal()  

}  

我创建了一个相当样板的 Xcode 扩展,当通过 perform(with ...) 函数调用它时,会启动我的配套 Mac 助手应用程序。我尝试了多种方式启动帮助应用程序,包括:

使用 NSWorkSpace 的 launchApplication(at: options: configuration:) :

class SourceEditorCommand: NSObject, XCSourceEditorCommand {  

    func perform(with invocation: XCSourceEditorCommandInvocation, completionHandler: @escaping (Error?) -> Void ) -> Void {  

        defer {  
            completionHandler(nil)  
        }  

        guard let url = NSWorkspace.shared().urlForApplication(withBundleIdentifier: "com.something.TestMacApp") else {  
            print("Couldn't find URL")  
            return  
        }  

        let options: NSWorkspaceLaunchOptions = NSWorkspaceLaunchOptions()  

        var configuration: [String: Any] = [String: Any]()  
        configuration["foo"] = "bar"  
        configuration[NSWorkspaceLaunchConfigurationArguments] = ["foobar"]  
        configuration[NSWorkspaceLaunchConfigurationEnvironment] = ["innerFoo" : "innerBar"]  

        do {  
            try NSWorkspace.shared().launchApplication(at: url, options: options, configuration: configuration)  
        } catch {  
            print("Failed")  
        }  

    }  

}  

使用自定义 Process 实例运行 bash 命令,同时尝试“open”和“fork”:

class SourceEditorCommand: NSObject, XCSourceEditorCommand {  

    func perform(with invocation: XCSourceEditorCommandInvocation, completionHandler: @escaping (Error?) -> Void ) -> Void {  

        defer {  
            completionHandler(nil)  
        }  

        runCommand(command: "open -b com.something.TestMacApp --args --foo=\"bar\"")  

    }  

    func runCommand(command: String) {  
        let task = Process()  
        task.launchPath = "/bin/sh"  
        task.arguments = ["-c", command]  
        task.launch()  
    }  

}  

问题

我已将帮助程序 Mac 应用程序存档/导出,并将其放在 Applications 文件夹中。当我构建并运行 Xcode 扩展并对其进行测试时,帮助程序 Mac 应用程序成功启动,但它从未在 applicationDidFinishLaunching(...) 中获取自定义启动参数。

我在几个地方阅读过,包括此处的 NSWorkSpace 配置选项的常量键的文档:https://developer.apple.com/reference/appkit/nsworkspacelaunchconfigurationarguments“此常量不适用于沙盒应用程序。”

当我从终端运行相同的 bash 时:

open -b com.something.TestMacApp --args --foo="bar"

帮助应用程序成功读取传递的 --args 并将它们显示在警报中。我担心的是,由于应用沙盒,这根本不可能,但我希望还有另一个我缺少的解决方案。如果可能的话,其他一些也可以使用的替代方法:

  1. 如果可以让 Xcode 扩展本身具有接口,而不是帮助 Mac 应用程序,那么就可以解决问题。但是我不相信这是可能的。

  2. 我也可以启动帮助程序 Mac 应用程序,然后在启动后与它进行通信,尽管我再次认为沙盒问题可能会发挥作用。

不管怎样,我主要是一名 iOS 开发人员。

感谢您的帮助,

  • 亚当·艾斯菲尔德

【问题讨论】:

标签: macos cocoa permissions arguments xcode-extension


【解决方案1】:

首先,你做错了。启动容器应用程序的正确(如苹果所说的那样)方法是执行以下操作:

  1. 在容器应用程序的 Info.plist 中,输入类似于以下内容的内容(将 com.cannasoftware.RoboDocument 更改为适当的应用程序名称,并将 robodocument007 更改为适合您产品的字符串):

  2. 在您的插件代码中使用以下代码来启动应用程序:

    let customurl = NSURL.init(string: "robodocument007://")
    NSWorkspace.shared().open(customurl as! URL)
    
  3. 使用标准的进程间通信在您的应用程序和插件之间进行聊天(DistributedNotificationCenter 在这里工作得很好)。

这不像使用启动参数那么简单或微不足道,但我认为您会对结果更满意。

【讨论】:

  • 虽然我同意我应该使用 URL Schemes 来启动我的应用程序 - 特别是因为它也允许其他应用程序以标准化方式这样做 - 问题的核心是传递某种应用程序打开时的“启动”或“启动”数据。使用 DistributedNotificationCenter 可能是一种解决方案,但是昨晚我发现我可以使用 App Groups 和共享的用户默认值来为正在启动的应用程序提供相关信息,这非常适合我的需求。当我下班回家时,我会发布一个答案来证明这一点。
  • @AdamEisfeld,我很想看看您的应用组解决方案!介意张贴吗?
  • 我猜它并没有他想象的那么好。有时,尽管您可能想要什么,但遵循 Apple 禁止的文档会更好,而且痛苦更少。
猜你喜欢
  • 2017-03-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-10-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多