后退按钮返回到不同的 UITableViewController 从它来的地方

发布于 2024-08-18 21:57:27 字数 274 浏览 4 评论 0原文

假设我有 UITableViewController A 和 UITableViewController B。 A 和 B 都加载 UIView C。 在 C 的后退按钮上,如何确保它总是返回到 B,而不是它来自的地方?

这是一个具体的例子: A=iPhone Skype 中的联系人窗口。 B=聊天窗口,每一行都是与不同人的聊天记录 C = 聊天窗口显示与同一个人的对话。

C 可以从 A 或 B 加载,但我希望聊天窗口 ( C ) 上的后退按钮仅返回到聊天 (B) 窗口。

干杯。

Say I have UITableViewController A, and UITableViewController B.
Both A and B loads UIView C.
At the back button in C, how do I make sure it always goes back to B, rather than where it came from?

Here is a concrete example:
A=Contacts window in iphone skype.
B=Chats window, each row is a chat history with a different person
C = Chat window displays a conversation with the same person .

C can be loaded from A or B, but I want the backbutton on the Chat window ( C ) goes back to Chats (B) window only.

Cheers.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

无言温柔 2024-08-25 21:57:27

您会发现这很难实现,很大程度上是因为这是一个糟糕的 UI 设计,并且 API 不支持它。

您的用户会期望后退按钮能够将他们“返回”到上一个视图,就像他们使用的其他应用程序一样。转到任何其他视图都会让他们更加困惑,因为它不是层次结构而是循环。用户有时会去B-->C-->B,但有时会去A-->C-->B-->C。 (他们如何返回 A?)

您应该在右侧设置一个按钮,而不是在 C 中使用后退按钮,无论您如何到达 C,该按钮始终会将您带到 B。相同上下文中的相同按钮应该总是产生相同的结果。用户不必记住他们所处的隐形模式来预测按钮将执行什么操作。


Edit01:(回复下面的评论)

(这都是我的想法,所以要持保留态度。)
您将需要放弃使用导航控制器,而是自己管理视图。您需要通过选项卡栏交换视图,方法是在每个选项卡的视图属性中用 C 视图替换 A 和 B 视图。

我认为您必须从不可见的主视图开始,然后向其中添加选项卡栏。在主视图控制器中,为每个视图创建属性/出口。在每个视图中,都有一个链接到主视图控制器的属性/出口。然后在 A 和 B 中使用 C 视图调用方法的“后退按钮”(我强烈建议您将其标记为“聊天”),然后调用主视图控制器中的方法,该方法(1)从选项卡 A 或选项卡中删除 C 视图tab B (2) 将选项卡切换到 B 选项卡,然后 (3) 将视图 B 加载到选项卡 B 中。

我无法强调我认为这个设计有多么难看。其他应用程序是否使用它并不重要。根据我的经验,大公司更有可能犯界面错误,因为他们的营销部门希望用户界面看起来独特。

通过比较,看看手机应用程序如何处理相同的情况。无论您使用哪个选项卡、收藏夹、联系人、键盘等来拨打电话,通话结束后您仍然会返回该选项卡的视图。如果您想使用其他方法进行调用,只需点击相应的选项卡即可。

忽略别人的坏榜样。为什么要花这么多时间和精力试图重现别人的错误呢?

Your going to find this hard to implement largely because this is a bad UI design and the API does not support it.

You user will expect a back button to take them "back" to the previous view just as in every other app they use. Going to any other view will confuse them all the more so because it isn't a hierarchy but a loop. Users will sometimes go B-->C-->B but other times, A-->C-->B-->C. (How do they get back to A?)

Instead of a back button in C, you should have a button on the right hand side that always takes you to B regardless of how you got to C. The same button in the same context should always produce the same result. Users shouldn't have to remember what invisible mode they are in to predict what action a button will have.


Edit01:(Response to comments below)

(This is all off the top of my head so take it with a grain of salt.)
You will need to abandon using the navigation controller and instead manage the views yourself. You will need to swap the views out via the tabbar by substituting the C view for the A and B views in each tab's view property.

I think you will have to start with master view that is invisible and then add the tabbar to that. In the master view controller, create attributes/outlets for each view. In each view, have an attribute/outlet linked to the master view controller. Then have the "back button" (which I strongly suggest you label "Chats") of C view call method in A and B that then calls a method in the master view controller that (1)removes the C view from either tab A or tab B (2) switches the tab to the B tab and then (3) loads view B into tab B.

I can't emphasis how ungainly I think this design is. It doesn't matter if other apps use it. In my experience major companies are more likely to make interface mistakes because their marketing departments want the UI to look unique.

By comparison, look at how the phone app handles the same situation. No matter which tab you use to make a call, favorites, contacts, keypad etc, you still come back that tab's view when the call is done. If you want to make a call with another method, you just hit the appropriate tab.

Ignore the bad example of others. Why spend so much time and effort trying to reproduce someone else's mistake?

时光匆匆的小流年 2024-08-25 21:57:27

您总是会返回到名为 pushViewController 的视图,

您能让 A 向 B 发送一条消息,导致 B 调用 pushViewController 吗?
我可能不理解你的架构,但我相信那会起作用。

You'll always wind up going back to the view that called pushViewController

Could you have A send B a message that causes B to call pushViewController?
I may not understand your architecture, but I believe that would work.

七婞 2024-08-25 21:57:27

如果你真的想这样做,你可以在 B 中创建一个方法来推送 C,然后从 A 推送 B(没有动画)并调用推送 C 的方法。当然,当你将 C 弹出到 B 时,A 仍然会在它下面。

If you really want to do this you could create a method in B that pushes C then push B from A (without animation) and call the method that pushes C. Of course when you pop C to B, A will still be under it.

我还不会笑 2024-08-25 21:57:27

我从 google group 并遵循了他的建议,它有效:

来自 Sukima:
我相信(虽然我不太清楚)像 Skype 和 Beejive 这样的应用程序正在做的是,当视图 A 想要视图 C 时,它会向你的 UITabBar 发送消息,要求其移动到聊天选项卡,然后推入详细视图 C。这实际上更好因为这样用户将通过选项卡栏已更改突出显示这一事实看到视图已更改。来自:我进一步阅读了 stackoverflow 线程。我现在明白你的要求了。

I got the answer from google group and followed his suggestion, it works:

From Sukima:
I believe (although I have no real idea) that what these applications like skype and Beejive are doing is when view A wants view C it will message your UITabBar to move to the chats tab then push in the detail view C. This is actually better because then the user will see that the view has changed via the fact that the tabbar has changed highlights. from: I further read the stackoverflow thread. I understand now what your asking.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文