向上导航破软糖？ [英] Up navigation broken on JellyBean?

问题描述

来源$ C ​​$ C可以在这里找到： https://github.com/novemberox/NavigationTest 它的修改版本，这示例：<一href="http://developer.android.com/training/implementing-navigation/ancestral.html">http://developer.android.com/training/implementing-navigation/ancestral.html

Source code is available here: https://github.com/novemberox/NavigationTest It's modified version of this sample: http://developer.android.com/training/implementing-navigation/ancestral.html

我有三个活动：

• 主要活动只是主入口应用
• 分类活动它的父的详细活动
• 详细活动

• Main Activity just main entry to application
• Category Activity it's parent for Detail Activity
• Detail Activity

主要活动有按钮，打开分类活动和详细活动。 类别Activty 只有一个按钮，打开详细活动。 最后详细活动，显示一些文本并拥有高达按钮，模拟点击动作条了。

Main Activity has button that opens Category Activity and Detail Activity. Category Activty has just one button that opens Detail Activity. And finally Detail Activity that shows some text and has up button that simulates click on ActionBar up.

我的点击路径是：

• 开启主要活动
• 开启详细活动
• 单击向上按钮
• 在类别Activty应该出现
• 在回来点击使我们为主要活动与国家恢复

这是流程，是将期望和它的工作只是罚款果冻豆之前，每一个机器人（对Galaxy Nexus的4.1.1和仿真器4.2谷歌EXP包检测）。它的工作原理，即使在ICS。我使用的是支持lib和类像NavUtils和TaskStackBuilder，像样，我指着开头。

And this is flow that is would be expecting and it's working just fine on every Android before Jelly Bean (tested on Galaxy Nexus 4.1.1 and emulator 4.2 Google exp pack). It works even on ICS. I'm using support lib and classes like NavUtils and TaskStackBuilder, like in sample that I pointed at beginning.

在JB当我点击向上按钮它可以追溯到主要活动与国家正确还原。我看着源$ C ​​$支持库的C和我看到 NavUtils.navigateUpTo 方法调用本机JB code像活动＃navigateUpTo 。我想这两个 NavUtils＃navigateUpTo（）和 NavUtils.navigateUpFromSameTask（）与不合格的结果相同。

On JB when I click "up button" it goes back to Main Activity with state restored correctly. I looked into source code of support library and I saw that NavUtils.navigateUpTo method calls native JB code like Activity#navigateUpTo. I tried both NavUtils#navigateUpTo() and NavUtils.navigateUpFromSameTask() with the same unsatisfactory result.

你有一些建议，怎样做才能有这样好的流量？

Do you have some suggestion what to do to have this nice flow?

推荐答案

首先第一件事情，如果你的目标设备高达API 17（安卓4.2），将 targetSdkVersion 在你的清单17。这对老设备不破的支持，它只是使事情变得正常了较新的设备。当然，这并不解决您的问题 - 这是刚刚好做到这一点

First things first, if you are targeting devices as high as API 17 (Android 4.2), set the targetSdkVersion to 17 in your manifest. This doesn't break support for old devices, it just makes things work properly for newer devices. Of course, that doesn't fix your problem -- it's just good to do it.

我假设你是你的基础code折此页。你已经使用了第二个例子：

I assume you are basing your code off of the Ancestral Navigation example on this page. You've used the second example:

Intent upIntent = new Intent(this, MyParentActivity.class);
if (NavUtils.shouldUpRecreateTask(this, upIntent)) {
    // This activity is not part of the application's task, so create a new task
    // with a synthesized back stack.
    TaskStackBuilder.from(this)
        .addNextIntent(new Intent(this, MyGreatGrandParentActivity.class))
        .addNextIntent(new Intent(this, MyGrandParentActivity.class))
        .addNextIntent(upIntent)
        .startActivities();
    finish();
 } else {
     // This activity is part of the application's task, so simply
     // navigate up to the hierarchical parent activity.
     NavUtils.navigateUpTo(this, upIntent);
 }

有关你想要的行为，但是，你需要替换 NavUtils.navigateUpTo 与

For the behavior you want, however, you would need to replace NavUtils.navigateUpTo with:

upIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(upIntent);
finish();

为什么它在ICS工作，早些时候？

在一般情况下，支持库正试图为大概的在以后的API引入的行为。在 NavUtils 的情况下，支持库正试图近似于API 16（又名安卓4.1）推出的bahavior。对于pre-16的API平台，<一href="https://android.googlesource.com/platform/frameworks/support/+/57ff0548ba991652576d81adaaa8baf4c028de39/v4/java/android/support/v4/app/NavUtils.java">NavUtils用途：

Why does it work on ICS and Earlier?

In general, the support library is trying to approximate the behavior introduced in later APIs. In the case of NavUtils, the support library is trying to approximate the bahavior introduced in API 16 (a.k.a. Android 4.1). For pre-API 16 platforms, NavUtils uses:

@Override
public void navigateUpTo(Activity activity, Intent upIntent) {
    upIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
    activity.startActivity(upIntent);
    activity.finish();
}

这看起来循回堆栈中 upInent 规定的活动的一个实​​例。如果找到一个，它清除一切都交给它，并恢复它。否则，它只是启动该活动。

This looks through the back stack for an instance of the activity specified in upInent. If it finds one, it clears everything up to it and restores it. Otherwise it just launches the activity.

在API 16+更高版本的平台，支持库手里的东西掉在活动的本地通话 API。根据文档：

On API 16+ later platforms, the support library hands things off to the native call in the Activity API. According to the docs:

公共布​​尔navigateUpTo（意向upIntent）

public boolean navigateUpTo (Intent upIntent)

导航，整理的过程中这项活动。如果由upIntent指示的活动已经存在于任务的历史记录，该活动和所有其他在历史堆栈指示的活动之前将完成

Navigate from this activity to the activity specified by upIntent, finishing this activity in the process. If the activity indicated by upIntent already exists in the task's history, this activity and all others before the indicated activity in the history stack will be finished.

如果指定的活动不会出现在历史堆栈，这将在此任务完成每一项活动，直到任务的根系活力达到，导致在应用程序的家的行为。当一个活动可以由路径不穿过一个规范父活动达到此可与一复杂的导航层次的应用程序是有用的。

If the indicated activity does not appear in the history stack, this will finish each activity in this task until the root activity of the task is reached, resulting in an "in-app home" behavior. This can be useful in apps with a complex navigation hierarchy when an activity may be reached by a path not passing through a canonical parent activity.

这是，目前还不清楚是否将推出 upIntent 中指定的行为，如果它不是在后面的堆栈。读<一href="https://github.com/android/platform_frameworks_base/blob/master/core/java/android/app/Activity.java#L4965">the来源$ C ​​$ C 并不有助于澄清事情无论是。然而，从您的应用程序显示的行为来看，似乎它的不试图启动 upIntent 的活动。

From that, it is unclear whether or not it will launch the activity specified in upIntent if it is not in the back stack. Reading the source code doesn't help clarify things either. However, judging from the behavior your app is showing, it appears that it does not attempt to launch the upIntent activity.

无论哪个实施是对还是错，最终的结果是你想要的 FLAG_ACTIVITY_CLEAR_TOP 行为，而不是本机API 16的行为。不幸的是，这意味着你将不得不重复支持库逼近。

Regardless of which implementation is right or wrong, the end result is that you want the FLAG_ACTIVITY_CLEAR_TOP behavior, not the native API 16 behavior. Unfortunately this means that you will have to duplicate the support library approximation.

免责声明：我不为谷歌工作，所以这是我最好的猜测

Disclaimer: I don't work for Google, so this is my best guess.

我的猜测是，API 16+行为是预期的行为;这是一个内置的实现，可以访问Android的内部，可以做的事情，是不可能通过API。 pre-API 16，我不认为这是可能的放松这种方式比使用意向的标志以外的backstack。因此， FLAG_ACTIVITY_CLEAR_TOP 标志是API 16行为提供给pre-16的API平台的最接近。

My guess is that the API 16+ behavior is the intended behavior; it's a builtin implementation that has access to the Android internals and can do things that are not possible through the API. Pre-API 16, I don't think it was possible to unwind the backstack in this fashion other than by using intent flags. Thus, the FLAG_ACTIVITY_CLEAR_TOP flag is the closest approximation of the API 16 behavior available to pre-API 16 platforms.

不幸的是，结果是本机实现和支持库实现之间存在违反最小惊讶原则>在您的方案。这使我不知道这是一个意外的使用API​​。也就是说，我不知道Android的期待，你遍历完整的导航路径的活动，而不是直接跳过去。

Unfortunately the result is that between the native implementation and the support library implementation there is a violation of the principle of least astonishment in your scenario. That leads me to wonder if this is an unanticipated use of the API. I.e., I wonder if Android expects that you to traverse the full navigation path to an activity, not jump directly to it.

只是为了避免一个可能的误解，也可能有人会想到 shouldU precreateTask 神奇地确定父是不是在后面的堆栈和去通过使用合成为你的一切的过程中， TaskStackBuilder 。

Just to avoid one possible misconception, it is possible that someone might expect shouldUpRecreateTask to magically determine that the parent isn't in the back stack and go through the process of synthesizing everything for you using the TaskStackBuilder.

不过， shouldU precreateTask 基本决定，如果你的活动是由您的应用程序直接启动（在这种情况下，它返回假），或者如果它是从另一个应用程序启动（在这种情况下，它返回真）。从<一个href="http://books.google.ca/books?id=6aGS01sC33gC&pg=PA660&lpg=PA660&dq=android+shouldu$p$pcreatetask&source=bl&ots=gdWuFMWdp2&sig=M9m-AZ6fUt4MK8t1vs21sFSo72g&hl=en&sa=X&ei=cMMWUf73IuiKiAKp9YEg&ved=0CEUQ6AEwAzgK#v=onepage&q=android%20shouldu$p$pcreatetask&f=false">this本书，支持库检查是否意图的行动是不是 ACTION_MAIN （我不完全理解），而在API 16平台上，执行此基于任务关联性检查。不过，在此应用程序的情况下，工作的事情出来 shouldU precreateTask 返回false。

However, shouldUpRecreateTask basically determines if your activity was launched directly by your app (in which case it returns false), or if it was launched from another app (in which case it returns true). From this book, the support library checks if the intent's "action" is not ACTION_MAIN (I don't fully understand that), whereas on API 16 platforms it performs this check based on task affinity. Still, in the case of this app, things work out to shouldUpRecreateTask returning false.

这篇关于向上导航破软糖？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！