iPhone - 更改委托可能会导致异步调用崩溃？
我有一个类实例化另一个类并作为第二个类的代表。第二类是“免费”的，不会被第一类保留。
第二个类发送异步 HTTP 请求并侦听它们的响应。
当收到响应时，将对其进行解析，并将结果重新打包并发送到委托方法之一。一旦调用委托，第二个类实例就会释放自身。演出结束。
为了确保获得服务器答案，当第一个类进入 dealloc 时（出于任何原因），它会更改第二个类的 delegate 属性以将答案路由到 applicationdelegate。
但是......当更改该委托属性时，我认为异步的http答案有可能与第一类的dealloc过程发生冲突。因此，第一类在释放时会收到答案。在这种情况下，第一个类将收到它无法管理的答案（可能会崩溃），而第二个类永远不会看到委托在调用发送到第一个类后发生了更改。
您将如何具体解决这个问题？
以下是该过程的架构：
- AppDelegate 创建 A1、A2、A3。
- 每个 Ax 都被定义为 Bx 的委托
- 每个 Ax 创建一个 B 实例对象（发送 HTTP 请求的 B1、B2、B3），此时
- ，如果 Ax 实例死亡，所有 A 和 B 类实例都可能有生命， Bx 类可以将答案发送给 appdelegate 而不是 Ax 实例
I have a class that instanciate another class and works as a delegate for that second class. That second class is "free" and is not retained by the first one.
That second class sends async HTTP requests and listen for their response.
When a response is received, it is parsed, and the result is repackaged and sent to one of the delegate methods. Once the delegate is called, the second class instance release itself. End of the show.
To be sure to get the server answer, when the first class enters in dealloc (for any reason), it changes the delegate property of the second one to route the answer to the applicationdelegate.
But... when changing that delegate attribute, I think there is a chance that the http answer that is async may collide with the dealloc process of the first class. So the first class would receive an answer while it is deallocating. In that case, the first class would receive an answer it cannot manage (may probably crash), and the second one would never see that the delegate had changed just after the call has been sent to the first class.
How would you concretly manage that problem ?
Here is a schema of the process :
- AppDelegate creates A1, A2, A3.
- each Ax create a B instance object (B1, B2, B3 that send HTTP requests), and each Ax is defined as a delegate of Bx
- at this point, all A and B class instance may have their lives
- if a Ax instance dies, the Bx class may send the answer to the appdelegate instead of the Ax instance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果 A 是 B 的代表，但不允许 A 保留 B，则会出现问题。
nil。因此，要么删除保留限制，然后让 A 正确保留 B。
或者使用通知来寻求耦合度较低的解决方案。
Your have a problem if A is a delegate for B, but A is not allowed to retain B.
nilwhen needed.So either remove the retain restriction and let A properly retain B.
Or go for a less coupled solution using notifications.
对我来说，这听起来不像是一个明智的架构。没有必要像你一样应付代表们。将与服务器通信的代码分解为它自己的类，只要您需要它，该类就会持续存在。不要将网络代码分散在整个应用程序中不断进出的对象中，并且当您需要在多个位置提供可用的东西时，不要将应用程序委托视为包罗万象。
This doesn't sound like a sensible architecture to me. Juggling delegates in the way that you are shouldn't be necessary. Factor out the code that communicates to the server to its own class that persists for as long as you need it to. Don't spread your networking code throughout your app in objects that are coming and going all the time and don't treat your app delegate as a catch all whenever you need something available in more than one place.