NSTask:由于没有提供 userInfo 字典,如何在结论时获取上下文?
我正在尝试通过 NSTask 使用命令行实用程序来压缩文件。
伪代码:
controller:
init:
register_self_as_observer_of_nstask_notifications
startZip(file):
file = somefileobject
task = "zip" with file path as argument
task.launch
notification_listener(notification):
task = notification.get_object
file = task.???
那么我怎样才能找出通知属于哪个文件对象呢?我通常使用 userInfo 字典来做这样的事情,但 NSTask 没有这样的选项。 来自Apple Dev :此通知不包含 userInfo 字典。
谢谢!
I'm trying to zip files using the command-line utility through NSTask.
pseudocode:
controller:
init:
register_self_as_observer_of_nstask_notifications
startZip(file):
file = somefileobject
task = "zip" with file path as argument
task.launch
notification_listener(notification):
task = notification.get_object
file = task.???
So how can I find out which file object the notification pertains to? I usually use the userInfo dictionary for such things, but NSTask has no such option. From Apple Dev: This notification does not contain a userInfo dictionary.
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
使用关联对象 API 将用户信息字典附加到任务实例。这将是最干净的方法,但在 Mac OS X 10.6 引入关联对象 API 之前不能使用它。
或者,您可以使用从任务映射到用户信息的字典。创建从任务到用户信息的字典映射并不像听起来那么简单:
[taskInfoDict setObject:userInfo forKey:task]
因为NSTask
不符合到NSCopying
,但NSDictionary
依赖于复制其键。使用任务对象的地址似乎是最好的解决方案:
假设引用计数环境,任务对象的地址将在其生命周期内保持稳定,并且其生命周期完全由您的应用程序控制。复制垃圾收集器会在此解决方案中带来麻烦,但在这种情况下,您可以使用可以直接处理指针的集合类(
NSMapTable
)。Use the associated object API to attach a user info dictionary to the task instance. This would be the cleanest approach, but it cannot be used prior to the introduction of the associated object API with Mac OS X 10.6.
Alternatively, you can use a dictionary that maps from task to user info. Creating a dictionary mapping from task to user info is not as straightforward as it sounds:
[taskInfoDict setObject:userInfo forKey:task]
becauseNSTask
does not conform toNSCopying
, butNSDictionary
relies on copying its keys.NSNumber
as a proxy for the task object mostly works. But process IDs can be reused, and a task doesn't get a PID till after it's been launched. The root of the problem is: You don't control the process ID; the underlying OS does.Using the address of the task object seems to be the best solution:
Assuming a reference-counted environment, the task object's address will be stable for its lifetime, and its lifetime is entirely under control of your application. A copying garbage collector would throw a wrench in this solution, but in that case, you could use a collection class that can handle the pointer directly (
NSMapTable
).考虑使用关联引用来关联每个任务实例的文件 URL/路径。每个对象可以有多个关联对象,每个关联对象都有一个对应的键,用于在需要时引用关联对象。
在控制器中,创建一个表示文件 URL/路径键的
static
变量:创建
NSTask
实例时,将相应的文件 URL 关联到该实例:当任务具有执行完毕,从通知对象中获取任务,然后从任务中获取文件URL:
Consider using associative references to associate the file URL/path to each task instance. Every object can have multiple associated objects, and each associated object has a corresponding key that is used to reference the associated object when needed.
In your controller, create a
static
variable that represents the file URL/path key:When creating an
NSTask
instance, associate the corresponding file URL to that instance:When the task has finished executing, get the task from the notification object and then get the file URL from the task: