多少活动与碎片？

Question

介绍:

基本的"片段教程"模式是这样的:

1. 在平板电脑上,左侧有一个列表,右侧有详细信息.
2. 两者都存在 Fragments并且两者都存在于同一个中Activity.
3. 在手机上,有一个列表Fragment中的一个Activity.
4. 推出一个新Activity的细节Fragment.

(例如Dianne Hackborn的Android 3.0 Fragments API和Fragments API指南)

在这两个设备上,功能都在Fragments.(简单)

在平板电脑上,整个应用程序是1Activity,在手机上,有很多Activities.

---

问题:

• 是否有理由将手机应用程序拆分为多个Activities？

此方法的一个问题是,您复制了主平板电脑Activity和单独电话中的大量逻辑Activities.

• 使用相同的切入和切Fragments出逻辑(仅使用不同的布局),在两种情况下保留1活动模型会不会更容易？

这种方式大部分逻辑都存在于Fragments自身中,并且只有一个Activity- 更少的代码重复.

我所读到的ActionBarSherlock也是它似乎最好用Fragments而不是Activities(但我还没有使用它).

教程是否过于简化,或者我错过了这种方法的主要内容？

---

我们已经在办公室成功地尝试了这两种方法 - 但我即将开始一个更大的项目,并希望尽可能让自己变得容易.

一些相关问题的链接:

• 困境:何时使用碎片与活动:
• 模式何时使用活动过渡与动态碎片
• Android - 我需要对片段与活动和视图进行一些澄清
• Android中的活动或片段？
• 多个片段和活动交互设计
• 那么Android 3.0中Fragments的确切优势是什么？

---

更新

开始提出赏金问题 - 仍然不相信我为什么需要在平板电脑活动和每个电话活动中复制我的应用逻辑.

还找到了Square广场上一篇有趣的文章,非常值得一读:

• 倡导Android碎片

Answer 1

我同意这些教程非常简化.他们只是介绍,Fragments但我不同意所建议的模式.

我也同意在多个活动中复制应用程序逻辑不是一个好主意(请参阅维基百科上的DRY原则).

我更喜欢ActionBarSherlockFragments Demo app 使用的模式(这里下载和源代码).与问题中提到的教程最匹配的演示是应用程序中名为"布局"的演示; 或者FragmentLayoutSupport在源代码中.

在这个演示中,逻辑已被移出Activity并进入Fragment.该TitlesFragment实际上包含更改碎片的逻辑.这样,每个Activity都非常简单.要复制许多非常简单的活动,其中没有任何逻辑在活动中,这使得它非常简单.

通过将逻辑放入Fragments中,不需要多次编写代码 ; 无论片段放入哪个活动,它都可用.这使它成为比基本教程建议的模式更强大的模式.

    /**
    * Helper function to show the details of a selected item, either by
    * displaying a fragment in-place in the current UI, or starting a
    * whole new activity in which it is displayed.
    */
    void showDetails(int index)
    {
        mCurCheckPosition = index;

        if (mDualPane)
        {
            // We can display everything in-place with fragments, so update
            // the list to highlight the selected item and show the data.
            getListView().setItemChecked(index, true);

            // Check what fragment is currently shown, replace if needed.
            DetailsFragment details = (DetailsFragment) getFragmentManager()
                .findFragmentById(R.id.details);
            if (details == null || details.getShownIndex() != index)
            {
                // Make new fragment to show this selection.
                details = DetailsFragment.newInstance(index);

                // Execute a transaction, replacing any existing fragment
                // with this one inside the frame.
                FragmentTransaction ft = getFragmentManager()
                    .beginTransaction();
                ft.replace(R.id.details, details);
                ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
                ft.commit();
            }

        }
        else
        {
            // Otherwise we need to launch a new activity to display
            // the dialog fragment with selected text.
            Intent intent = new Intent();
            intent.setClass(getActivity(), DetailsActivity.class);
            intent.putExtra("index", index);
            startActivity(intent);
        }
    }

ABS模式的另一个优点是,您最终不会得到包含大量逻辑的Tablet活动,这意味着您可以节省内存.教程模式可以在更复杂的应用程序中导致非常大的主要活动; 因为它需要随时处理放在其中的所有片段的逻辑.

总的来说,不要认为它被迫使用许多活动.可以认为它有机会将代码分成许多片段,并在使用它们时节省内存.

Answer 2

我认为你走在正确的轨道上.(是的,教程过于简化).

在平板电脑布局中,您可以使用单个活动并交换进出碎片(在多个"窗格"中).在手机布局中,您可以为每个片段使用新的活动.

像这样:

这似乎是一项额外的工作,但通过为手机使用多个活动,您可以启用基本的Activity生命周期和Intent传递.这也允许框架处理所有动画和后栈.

为了帮助减少代码,您可以使用BaseActivity和扩展代码.

因此,如果用户有平板电脑,您将使用MyMultiPaneFragActivity或类似的东西.此活动负责管理来自片段的回调以及将意图路由到正确的片段(例如搜索意图)

如果用户有电话,您可以使用常规活动,只需很少的代码,并使其扩展MyBaseSingleFragActivity或类似.这些活动可能非常简单,5到10行代码(可能更少).

棘手的部分是路由意图和诸如此类的东西.*(编辑:见下文).

我认为这是推荐方法的原因是节省内存并降低复杂性和耦合.如果要交换Fragments,FragmentManager则为后端堆栈维护对该Fragment的引用.它还简化了应该为用户"运行"的内容.此设置还将Fragment中的视图,布局和逻辑与Activity生命周期分离.这样,片段可以存在于单个活动中,与另一个片段(双窗格)一起存在,或者存在于三窗格活动中等.

*定期意图路由的一个好处是,您可以从后端堆栈中的任何位置显式启动Activity.一个例子可能是搜索结果.(MySearchResults.class).

在这里阅读更多:

http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html

这可能是一个更前期的工作,因为每个片段必须在不同的活动中很好地工作,但它通常会得到回报.这意味着您可以使用定义不同片段组合的替代布局文件,保持片段代码模块化,简化操作栏管理,并让系统处理所有后台堆栈工作.

Answer 3

这里是雷托·梅尔的关于相同的答案,从拍摄这段视频的Udacity的Android基础课程.

将您的应用程序分解为不同的活动有很多原因.

• 单一的整体活动会增加代码的复杂性,使其难以阅读,测试和维护.
• 使创建和管理意图过滤器变得更加困难.
• 增加了紧密耦合独立组件的风险.
• 如果单个活动包括敏感信息和可安全共享的信息,则更有可能引入安全风险.

一个好的经验法则是在上下文发生变化时创建一个新活动.例如,显示不同类型的数据,同时从查看切换到输入数据.