我有两个活动A和B. A具有ListFragment它使用LoaderManager，而B的活性显示了一个关于A的ListFragment选择的项目细节。我刚才注意到，当我使用后退按钮从B返回到A，在ListFragment preserve的位置，但是当我在操作栏中使用的按钮（左点符号）在A活性的重建和列表视图从而位置丢失。

I have two activities A and B. The A has a ListFragment which uses LoaderManager, whereas B activity shows a details about the item selected in the A's ListFragment. I've just noticed that when I use a back button to get from the B back to the A, the position in the ListFragment preserve, but when I use the up button (left-point caret) in the action bar, the A activity is recreated and thus position in list view is lost.

我想解决这个问题，但我不知道怎么做是正确的最好方法。

I would like fix this issue, but I am not sure about the best way how to do it right.

我想出了这个解决方案：

I come up with this solutions:

a）使用 onBack pressed（）

a) Use onBackPressed()

替换为 android.R.id.home （向上操作栏按钮）的缺省实现在B活性，而不是 NavUtils.navigateUpFromSameTask（本）函数调用 onBack pressed（）活动的方法。我测试了它和它的作品。

Replace the default implementation for the android.R.id.home (the up action bar button) in the B activity, and instead of the NavUtils.navigateUpFromSameTask(this) function call the onBackPressed() activity method. I've tested it and it works.

二）请使用 NavUtils.navigateUpFromSameTask（本）

b) Keep use NavUtils.navigateUpFromSameTask(this)

但落实的onSaveInstanceState 和使用的A活性的ListFragment的的onCreate 方法，在还原过程中的ListView位置。 （我没有测试过这种方法还）

But implement the onSaveInstanceState and restore listView position during onCreate method of the ListFragment used by the A activity. (I've not tested this approach yet)

哪这个解决方案是更好？或者有没有其他的（更多更好）的解决方案？

Which of this solutions is better? Or is there any other (much more better) solution?

解决方案）是pretty的简单和直接的，但 B）可能是更好，因为的默认的实施起来插入符使用。

Solution a) is pretty simple and straight forward, but b) is probably better because the default implementation of the up caret is used.

任何想法是值得欢迎的。谢谢你。

Any ideas are welcome. Thanks.

推荐答案

解决方案的 C 的是正确的选项。不过，首先是与解决方案的问题的解释的在的。

Solution c is the correct option. First, though, an explanation of the problem with solution a.

有具有在活动二后退按钮完全没有意义的。此外，选择的在的正式爆发向上按钮。向上按钮的一点是要提供一种方法让用户留在你的应用程序中，当他们从外部来源降落在你的应用程序。例如，如果从外部活动丙地b活动上，如果您使用的是选项的在的，那么在b活动pressing涨会导致活动C为显示。显示到你想会是活性的行为。

There is absolutely no point in having two back buttons in your Activity. Furthermore, option a actually breaks the up button. The point of the up button is to provide a way for users to stay within your app when they have landed in your app from an outside source. For example, if you land on activity B from an outside activity C and if you are using your option a, then pressing "up" in activity B will result in activity C being shown. The behavior you would want would be for activity A to be shown.

正如你所看到的，解决方案的 B 的是在正确的轨道。你一定要去的了的A和没有的回的给C.然而，简单地贮存状态的onSaveInstanceState 将不会导致要保留的状态。这是因为的onSaveInstanceState 只被调用，如果您的应用程序可能会被系统杀死。它不能保证，如果您的应用程序手动销毁被调用，它当然是创建了一个新的活动实例时不会被调用。如果打算启动一个新的活动，那么它不会有来自其他活动的状态恢复。

As you can see, solution b is on the right track. You definitely want to go up to A and not back to C. However, simply storing the state in onSaveInstanceState will not cause the state to be retained. This is because onSaveInstanceState only gets called if your application may be killed by the system. It is not guaranteed to be called if your application was destroyed manually, and it certainly won't be called when a new instance of your Activity is created. If the Intent starts a new activity, then it will not have its state restored from the other activity.

有解决方案，那么，就是你必须写任何东西执着共享preference文件（或自定义持久性的替代）。如果这样做，你可以保证的活动共享多个任务的所有实例的相同状态的只要他们onResume（或任何你恢复状态）被称为的。 OR：

There solution, then, is that you must write anything persistent to a shared preference file (or a custom persistent alternative). When doing this you can guarantee that all instances of an Activity share the same state across multiple tasks so long as their onResume (or wherever you restore state) is called. OR:

如果你知道你到底怎么想你的导航工作，你能避免使用意向标志和活动的任务亲和力的组合写的一切持久状态。如果你想使用相同的活动，即使你导航到从外部源的应用程序了，然后你可以离开的活动为您的默认（链接到应用程序）的亲和力，使用类似Intent.FLAG_ACTIVITY_CLEAR_TOP。

If you know exactly how you want your navigation to work, you can avoid writing everything to persistent state by using a combination of Intent flags and Activity task affinities. If you want to use the same activity as up even if you navigate into the application from an outside source, then you can leave your Activity A's affinity as default (linked to the application) and use something like Intent.FLAG_ACTIVITY_CLEAR_TOP.

就个人而言，我想尝试的意图标志的方法第一，如果做不到这一点回落到坚持写作状态。你刚才真的不希望滚动位置坐在持久存储，如果你能避免它。

Personally, I'd try the Intent flag approach first and failing that fall back to writing the state persistently. You just don't really want scroll location sitting on persistent storage if you can avoid it..