两个面板UI与片段vs独立的活动

我正在启动一个Honeycomb应用程序,该应用程序将具有基本的两个面板布局,左侧为面板菜单,右侧为每个部分的主要function。

与Fragments API的可用样本相反,右侧面板上显示的内容包含针对每个菜单选项的完全不同的UI。

根据所select的部分来replace正确的片段是诱人的,但是这意味着在整个应用中只使用一个活动,这听起来不太好。 此外,片段的生命周期与活动相关联,因此在活动被杀死之前不会有片段被杀死,导致大量片段“活着”。

然而,每个菜单选项有两个面板的不同活动意味着用于菜单的片段将不得不在每个活动中添加,并且将在所有应该有菜单的部分中受到不一致布局的影响。

这里最好的做法是什么?

Solutions Collecting From Web of "两个面板UI与片段vs独立的活动"

这个博客文章总结了select片段活动的原因:

通过ActivityGroupembedded的活动是一个不错的主意,但一直很难处理,因为活动被devise成一个独立的独立组件,而不是与其他活动密切相互作用。 碎片API是一个更好的解决scheme,应该被视为embedded式活动的替代品。

在Activity实例中保留数据可以通过Activity.onRetainNonConfigurationInstance()完成,但是这样做非常简单而且不明显。 片段replace了这个机制,只需要设置一个标志就可以保留整个片段实例。

一个名为DialogFragment的片段专门化可以很容易地显示一个作为Activity生命周期一部分进行pipe理的对话框。 这取代了Activity的“托pipe对话框”API。

另一个名为ListFragment的片段专业化可以很容易地显示数据列表。 这与现有的ListActivity类似(具有更多的function),但应该减less有关如何显示>列表与其他一些数据的常见问题。

当前附加到活动的所有片段的信息将由框架保存在活动的已保存实例状态中,并在重新启动时为您恢复。 这可以大大减less你自己编写的状态保存和恢复代码的数量。

该框架内置了对pipe理Fragment对象后备堆栈的支持,因此可以轻松地提供集成了现有活动后退堆栈的内部活动后退button行为。 此状态也会自动保存并恢复。

碎片是相当新的,所以除了那篇文章,我不确定你会find很多的最佳做法。 我认为你需要作出的决定是我的交互紧密耦合,意味着共享数据,或者是独立的组件,这些组件没有太多的互动。


编辑,澄清 :我认为使用单个活动的应用程序不一定是一个坏的决定。 这是一个你应该根据你的应用程序的function做出的决定。 根据这篇文章,一个Activity是独立的,而一个片段通常只在与Activity的范围内的其他片段结合时才有意义。 您所描述的情况以及不同活动的组合是他们devise碎片来解决的难点之一。