两个面板UI与Fragments vs Separate活动

Question

我正在启动一个Honeycomb应用程序,该应用程序将具有基本的两个面板布局,左侧的一个面板用于菜单,另一个面板用于每个部分的主要功能.

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

根据所选部分替换正确的片段很有诱惑力,但这意味着在整个应用中只使用一个活动,这听起来不太好.此外,片段的生命周期与活动相关联,因此在活动被杀死之前不会杀死任何碎片,导致大量碎片"活着".

但是,对于每个菜单选项,具有两个面板的不同活动意味着必须在每个活动中添加用于菜单的片段,并且在应该具有菜单的所有部分中将存在不一致的布局.

这里的最佳做法是什么？

Answer 1

此博客文章总结了在活动中选择片段的原因:

通过ActivityGroup进行嵌入式活动是个不错的主意,但由于Activity被设计为独立的自包含组件而不是与其他活动密切交互,因此一直很难处理.Fragment API是一个更好的解决方案,应该被视为嵌入式活动的替代品.

在Activity实例中保留数据可以通过Activity.onRetainNonConfigurationInstance()完成,但这是相当笨重且不明显的.Fragment通过允许您仅通过设置标志来保留整个Fragment实例来替换该机制.

Fragment的专门化称为DialogFragment,可以很容易地显示作为Activity生命周期的一部分进行管理的Dialog.这取代了Activity的"托管对话框"API.

Fragment的另一个名为ListFragment的专业化可以很容易地显示数据列表.这类似于现有的ListActivity(具有更多功能),但应减少有关如何使用其他数据显示>列表的常见问题.

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

该框架内置支持管理Fragment对象的后堆栈,从而可以轻松提供集成现有活动后备堆栈的活动内Back按钮行为.此状态也会自动保存和恢复.

碎片是相当新的,所以除了那篇文章,我不确定你会找到最好的做法.我认为您需要做出的决定是我的交互紧密耦合并且意味着共享数据,或者它们是独立的组件,没有太多的交互.

编辑,澄清:我认为对应用程序使用单个活动并不一定是错误的决定.根据应用程序的功能,您应该做出决定.根据这篇文章,一个Activity是独立的,而一个片段通常仅在与Activity的范围内的其他片段结合时才相关.您描述的情况与不同活动的组合是他们设计片段要解决的难点之一.