相关疑难解决方法(0)

题

我们正在Objective-C中开发一个自定义的EventEmitter灵感消息系统.对于听众提供回调,我们是否需要块或选择器以及为什么？

作为开发人员,您更愿意使用哪个第三方库？哪个最符合Apple的轨迹,指导方针和做法？

背景

我们正在使用Objective-C开发一个全新的iOS SDK,其他第三方将使用它来将功能嵌入到他们的应用程序中.SDK的很大一部分需要向侦听器传递事件.

我知道在Objective-C中做回调有五种模式,其中三种不适合:

• NSNotificationCenter - 无法使用,因为它不能保证订单观察者会收到通知,因为观察者无法阻止其他观察者接收事件(就像stopPropagation()在JavaScript中一样).
• 键值观察 - 似乎不是一个很好的架构适合,因为我们真正拥有的是消息传递,而不是总是"状态"约束.
• 代表和数据源 - 在我们的例子中,通常会有许多听众,而不是一个可以正确称为代表的听众.

其中两个是竞争者:

• 选择器 - 在此模型下,调用者提供一个选择器和一个目标,它们被共同调用以处理事件.
• 块 - 在iOS 4中引入,块允许传递功能而不必绑定到像观察者/选择器模式这样的对象.

这可能看起来像一个深奥的意见问题,但我觉得有一个客观的"正确"的答案,我只是在Objective-C中缺乏经验来确定.如果这个问题有一个更好的StackExchange站点,请帮助我将其移动到那里.

更新#1 - 2013年4月

我们选择块作为为事件处理程序指定回调的方法.我们对此选择感到非常满意,并且不打算删除基于块的侦听器支持.它确实有两个值得注意的缺点:内存管理和设计阻抗.

内存管理

块最容易在堆栈上使用.通过将它们复制到堆上来创建长寿命块会引入有趣的内存管理问题.

调用包含对象上的方法的块会隐式提升self引用计数.假设你有一个name类的属性的setter ,如果你name = @"foo"在一个块中调用,编译器将其视为[self setName:@"foo"]并保留,self以便在块仍然存在时不会释放它.

实现EventEmitter意味着拥有长期存在的块.为了防止隐式保留,发射器的用户需要创建对块外部的__block引用self,例如:

__block *YourClass this = self;
[emitter on:@"eventName" callBlock:...
   [this setName:@"foo"];...
}];

这种方法的唯一问题是this可以在调用处理程序之前释放.因此,用户必须在取消分配时取消注册其侦听器.

设计阻抗

经验丰富的Objective-C开发人员希望使用熟悉的模式与库进行交互.代表是一种非常熟悉的模式,因此规范的开发人员希望使用它.

幸运的是,委托模式和基于块的侦听器不是互斥的.虽然我们的发射器必须能够处理来自许多地方的侦听器(只有一个委托不起作用),但我们仍然可以公开一个接口,允许开发人员与发射器进行交互,就像它们的类是委托一样.

我们还没有实现这一点,但我们可能会基于用户的请求.

更新#2 …