从滑动菜单进行Android导航 - 片段还是活动？

Question

我正在将使用仪表板模式的Android应用程序升级到滑动菜单，并使用library by jfeinstein。

最初我有一个DashboardActivity，它有6个按钮，每个按钮都会启动相应的Activity。我还有大约30项其他活动可以从这些“顶级”活动开始。

现在，我有两种可能的方法：

1. 定义某种MenuActivity，其中包括SlidingMenu片段，以及所选菜单项的启动活动，如旧版本。
2. 仅定义一个活动并将现有活动转换为片段，并在内容框架中显示它们。

在查看滑动菜单库的示例时，我认为它可能是最好的方法，因为它使用了切换片段，但我仍然认为一个Activity对于屏幕比片段更好。

是否有任何理由对内容使用单个活动和片段？

Answer 1

Fragments API是你的朋友。不完全是。

（改编自interwebs和Glenn Bech对SO的回答）

1。可重复使用的

片段是Android创建可重用用户界面的解决方案。您可以使用活动和布局（例如使用包含）来实现某些相同的功能。然而;片段从HoneyComb连接到Android API，然后再上传。

2。重量轻

对于Activity而言，还有很多额外的责任，因为它是一个主要组件。就像提供上下文等一样。如果没有这些额外的责任，片段是轻量级的，并且因为你有许多片段（当活动被重构为片段时）特别有用。我提到他们是轻量级的吗？

3。使用API​​，而不是反对它

ActionBar。如果你想在那里导航你的应用程序，你很快就会看到ActionBar.TabListener下图为你提供了一个FragmentTransaction作为onTabSelected方法的输入参数。你可能会忽略这一点，并做一些别的和聪明的事情，但你会反对API而不是它。

4。聪明的BackStack也可以自定义

FragmentManager以非常聪明的方式为您处理“后退”。返回并不意味着回到最后一个活动，就像常规活动一样。它回到了之前的片段状态。由于您可以控制何时以及如何使用背板，因此这更令人敬畏（是的，它的一句话）。

5。闪光和魅力

你认为所有的好莱坞影响都来自于呃？您可以使用酷炫的ViewPager和FragentPagerAdapter来创建滑动界面。 FragmentPagerAdapter代码比常规适配器更清晰，并且它控制各个片段的实例化。您可以应用于片段的过渡和滑动动画是活动无法做到的一些事情。

6。平板电脑和手机

更大的手机？不，这是一个平板电脑。如果在尝试为手机和平板电脑创建应用程序时使用Fragments，您的生活将会轻松许多。由于片段与Honeycomb + API紧密相关，因此您还需要在手机上使用它们以重用代码。这就是兼容性库派上用场的地方。

7。电话只有男人吧？

您甚至可以而且应该将片段用于仅适用于手机的应用。如果你有可携带性。我使用ActionBarSherlock和兼容性库来创建“ICS外观”应用程序，这些应用程序看起来一直回到1.6版本。您可以获得Actionbar等最新功能，包括标签，溢出，分割操作栏，viewpager等。

还有一件事

8。交叉通信

片段之间进行通信的最佳方式是意图。当您在Fragemnt中按某些内容时，通常会使用其中的数据调用StartActivity（）。意图将传递给您启动的活动的所有片段。这更容易。

Answer 2

  

我仍然认为一个活动对于一个屏幕比一个屏幕更好   片段。

不在我看来。我承认可以处理这么多片段有点复杂，但使用片段有其优点。

1。优势：跨多种屏幕尺寸缩放。

您可以使用多窗格布局模式，让您的应用用户对平板电脑用户更友好。 现在您提到，您的6个活动也在调用其他活动。也许可以通过并排使用多个屏幕（片段）来缩短用户点击屏幕的时间（如前所述;多窗格布局）。我不知道你的应用是什么，但我可以想象，用户必须从列表中选择一些东西，你将根据他决定选择的内容将他重定向到另一个Activity。在平板电脑上，您可以使用两个片段并在一个屏幕上显示内容（无需启动新的），同时您可以选择仅在手机上显示一个片段设备（您可以通过使用动态和静态片段以及使用layout-sw600等文件夹来完成所有这些操作）。如果您决定这样做，您将保持良好的用户流程和使用平板电脑的屏幕区域。这将使您的应用程序灵活和动态。

以此为参考：

2。优点：减少代码重复。

如果您选择多个活动而不是在应用程序中使用片段，则需要为所有您的活动提供SlidingMenu，因为用户（作为用户自己说话）希望使用应用程序中的SlidingMenu无处不在。这将是一个糟糕的用户体验，如果用户必须“向上”活动backstack，只是为了使用SlidingMenu。这肯定会打破用户流程。所以你必须重新实现每个Activity中的菜单。当然你可以通过创建一个基本活动来做到这一点，但是只使用一个Activity并让该Activity处理这个问题要容易得多。

我现在想不出其他优势。但我相信还有很多其他的。

Answer 3

伙计们我一直在阅读所有帖子，我认为你没事。一项活动（有很多片段）与几项活动。

一个充满碎片的主要活动并不是很好。相信我，如果您的项目有很多屏幕，活动过渡，生命周期，片段之间的通信可能会变得一团糟。您可以分享侧面菜单，这是为了这样做。

另一方面，每个屏幕类型只有一个活动，没有碎片是另一个问题。您必须为每个活动创建一个侧边菜单。当然使用基类似乎很容易，但您还必须每次都恢复菜单的状态。

我们目前解决此问题的方法是将迁移次数减少到最小，并尽可能多地使用碎片。我们将将共享某些功能的片段分组到活动中。在我们引入适当的平板电脑支持时，我们需要去寻找片段。

最后一条评论。我已设法反编译googlePlay商店并查看层次结构。我对它的内部组织非常好奇。我真的以为谷歌家伙只会使用一个主要活动和几个片段 - ＆gt;错误。他们还使用许多活动。

结论：我们不应该是极端分子。我认为只有一个活动只适用于小项目或简单的导航层次结构。同时，使用太多活动会使导航变得混乱。