Back vs. Up - 预期行为答案

【问题标题】：Back vs. Up - Intended behaviorBack vs. Up - 预期行为
【发布时间】：2018-08-23 18:49:54
【问题描述】：

导航设计指南说明：

当先前查看的屏幕也是当前屏幕的父级层次结构时，按“后退”按钮与按“向上”按钮的结果相同——这是很常见的情况。 up vs back - navigation guide

我有一个 MainActivity A，当触摸 NavigationDrawer 中的导航条目时，它会打开另一个活动 B。 Activity A 在 AndroidManifest 中设置为 Activity B 的父级：android:parentActivityName=".MainActivity"

我按照这个android documentaion添加了到活动B的导航。它展示了如何在活动B中实现onOptionsItemSelected：

override fun onOptionsItemSelected(item: MenuItem): Boolean {
when (item.itemId) {
    android.R.id.home -> {
        // Respond to the action bar's Up/Home button
        NavUtils.navigateUpFromSameTask(this)
        return true
    }
}
return super.onOptionsItemSelected(item)

}

当我从 Activity B 按下返回时，Activity A 的状态被保存并且 NavigationDrawer 被打开。但是，如果我使用向上导航，则会调用 onCreate()of 活动 A 并且它会丢失其状态（抽屉已关闭等）。

这不是引用的“相同结果”。

当我将 NavUtils.navigateUpFromSameTask(this) 替换为简单的 finish() 时，它的行为与按回键相同 - 活动 A 的状态被保留。

我自然更喜欢使用finish的方式。那么预期的行为是什么？指南是否相互矛盾或遗漏了什么？

【问题讨论】：

标签： android navigation back

【解决方案1】：

不幸的是，Google 将文档搁置的时间超过了相关时间，甚至会发布两个直接相互矛盾的不同文档。

对于向上按钮，您的链接显示

向上按钮出现在应用栏中，用于根据屏幕之间的层次关系在应用内导航。 [...]

后退按钮出现在系统导航栏中，用于按时间倒序浏览用户最近使用过的屏幕的历史记录。它通常基于屏幕之间的时间关系，而不是应用程序的层次结构。

不过，还有this article，上面写着

当系统后退按钮不会退出您的应用程序时，例如当您在自己的任务上而不是在开始目的地时，向上按钮的功能应该与系统后退按钮相同。

那么...你应该相信哪一个？

我断言你应该相信第二个。第一个是几年前发布的；我不知道它的确切年代，但你可以看出它很旧，因为截图都使用了 Holo 主题。另一方面，第二个是 Android 架构组件的一部分，因此明显更新。一般来说，我会使用最新的文档。

此外，我认为 Google 多年来一直说“向上”按钮应该与“返回”按钮的工作方式不同是错误。作为一个在我的应用程序中花费大量时间思考导航的人，我知道它们来自哪里，但是当 Up 做了一些“不同”的事情时，现实世界的用户总是会感到困惑。

所以当用户按下向上按钮时，我会继续 finish() 你的活动，而不用担心你找到的那两篇文章。

【讨论】：

我在这里找到了解决这两个冲突文档的解决方案。我喜欢“备份与备份”的概念，它实际上是一个不同的东西，应该表现不同，但（如前所述）“现实世界”用户不理解它，因此期望相同的结果。因此，谷歌似乎会放弃向上按钮并（当保留而不是删除时）让它表现得就像返回按钮一样（这是可悲和重复的）。

【解决方案2】：

我认为建议在向上图标和系统后退按钮之间保持一致性的政策更改是一个好主意。但是，您应该建议： “按时间倒序浏览屏幕历史” 太粗略了，或者至少应该澄清一下他们所说的“屏幕”是什么意思。例如。当您有一个底部导航栏时，后退按钮/向上图标应该让您在跳转到之前访问的部分之前备份选项卡部分中的层次结构。并且您应该在重新访问选项卡部分时保留以前的状态（可能会向下钻取到较低级别的屏幕）。

【讨论】：