在竞争模式视图控制器之间切换
我的应用程序有三种状态：
- A）连接到服务器
- B）连接到wifi，但没有互联网
- C）没有连接
第一个状态是应用程序的默认操作模式，其他两个（B和C）显示为模态视图控制器。在各种可达性变化上，应该出现正确的模态视图。
不幸的是，在某些情况下，B＆amp; C 都尝试同时呈现，或者 B 当前已呈现并且距离关闭可能还有一毫秒，但 C 已经在尝试展示自己。
我的解决方案基本上是为每个模态视图创建一个带有一些委托的信号量 - 当模态视图打开时，它通过委托发送一条消息以转到主视图以打开标志。然后，当第二个模态视图尝试打开时，它会看到第一个模态视图已打开并等待直到它关闭。对于我试图制作一个非常基本的状态机来说，这似乎是一个荒谬的黑客行为。
有什么想法吗？
My app has three states:
- A) connected to server
- B) connected to wifi, but no internet
- C) no connection
The first state is the default mode of operation of the app, and the other two (B & C) are presented as modal view controllers. On various reachability changes, the correct modal view should appear.
Unfortunately, in certain cases B & C both attempt to be presented at the same time, or B is currently presented and may be a millisecond away from closing, but C is already trying to show itself.
My hack of a solution is to basically create a semaphore with some delegates for each modal view- when a modal view opens, it sends a message via the delegate to go to the main view to turn a flag on. Then when the second modal view tries to open, it sees the first is on and waits until it is off. That seems like a ridiculous hack for me trying to make a very basic state machine.
Any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会折叠单独的 B& C 案例到单个视图控制器中，该控制器根据在任何给定时刻是否发生 B 或 C 来更改其视图。这样你就不会让它们竞争，因为只有一个视图控制器。
I'd collapse the separate B & C cases into a single view controller that changes its view based on whether B or C is happening at any given moment. That way you don't have them competing, because there's only ever one view controller.
您没有指定在哪些情况下 B & C 可以同时出现，因此您首先想到的是，您可以寻找一种不同的方法来检查您是否属于 B 或 C 情况，以便更好地消除歧义。
谈到您正在使用的标志，我想丑陋的部分与您提到的等待有关。这对我来说似乎太过分了。一种替代方法是让第一个模态视图发送第二个视图正在观察的通知，而不是让第二个模态视图等待标志重置。实现这一点非常简单，您可以在 SO 中找到许多示例（例如 这个）。
You don't specify in which cases B & C could present themselves both, so the first thing that comes to mind is that you could look for a different way to check whether you are in case B or C so that you can disambiguate better.
Speaking about the flag you are using, I guess the ugly part has to do with the waiting you mention. This seems overkill to me. One alternative is instead of letting the second modal view to wait for the flag to be reset, you make the first modal view send a notification which the second view is observing. Implementation of this is pretty trivial and you can find many examples in S.O. (e.g., this one).