159

我正在考虑用 和 实现一个屏幕和Activity所有其他屏幕。Fragmentsmanaging all the fragments thru the activity

这是个好主意吗？我的回答是否定的，但我仍然想更清楚地了解这个想法。

这个想法的优点和缺点是什么？

笔记：

请不要给我片段和活动的链接。

编辑：

这是片段和活动的内容：

优点：

  1. 片段旨在作为子活动与活动一起使用。
  2. 片段不是活动的替代品。
  3. 片段意味着可重用性（需要知道以何种方式可以实现可重用性。）。
  4. 片段是编写代码以支持平板电脑和手机的最佳方式。

缺点：

  1. 我们需要实现接口来从片段中获取数据。
  2. 对于对话，我们必须走很长的路才能展示它。

如果我们不考虑平板电脑，为什么要使用片段？活动和片段之间的开始时间差是多少？

4

8 回答 8

95

这取决于您正在创建的应用程序。我已经使用这两种方法创建了几个应用程序，并且不能说一种方法总是比另一种更好。我创建的最新应用程序使用单一Activity方法和 Facebook 样式导航。从导航列表中选择项目时，我会更新一个Fragment容器以显示该部分。

也就是说，拥有一个单曲Activity也会带来很多复杂性。假设您有一个编辑表单，对于用户需要选择或创建的某些项目，需要他们转到新屏幕。对于活动，我们只是调用新屏幕，startActivityForResult但Fragments没有这样的东西，因此您最终将值存储在 上Activity并让主编辑片段检查Activity数据是否已被选择并应显示给用户。

Aravind 所说的坚持单一Activity类型也是正确的，但并不是真正的限制。您的活动将是 FragmentActivity，只要您不需要，MapView那么就没有真正的限制。如果您确实想显示地图，可以这样做，但您需要修改 Android 兼容性库以FragmentActivity扩展MapActivity或使用公开可用的android-support-v4-googlemaps。

最终，我认识的大多数走一条Activity路线的开发人员都回到了多个活动来简化他们的代码。明智的用户界面，在平板电脑上，你有时会被困在使用单个Activity只是为了实现你的设计师想出的疯狂交互:)

- 编辑 -

Google 终于发布MapFragment了兼容性库，因此您不再需要使用 android-support-v4-googlemaps hack。在此处阅读更新：Google Maps Android API v2

-- 编辑 2 --

我刚刚阅读了这篇关于现代（2017 年）片段状态的精彩文章，并记住了这个旧答案。想我会分享：片段：Android所有问题的解决方案

于 2012-08-31T19:00:05.173 回答
85

我即将完成一个项目（开发 5 个月），它有 1 个活动和 17 个片段，全屏显示。这是我的第二个基于片段的项目（之前是 4 个月）。

优点

  • 主要活动是 700 行代码，只是很好地管理片段导航的顺序。
  • 每个片段都很好地分成了自己的类，并且相对较小（大约几百行 ui 内容）。
  • 管理层可以说，“嘿，我们切换那些屏幕的顺序怎么样”，我可以很容易地做到，因为这些片段不相互依赖，它们都通过 Activity 进行通信。我不必深入研究各个活动，就可以找到他们互相称呼的地方。
  • 我的应用程序的图形非常繁重，永远不会作为 1 个屏幕 1 个活动工作。内存中的所有这些子活动都会使应用程序一直耗尽内存，所以我必须对finish()所有不可见的活动，并为导航制作相同的控制逻辑，就像我对片段所做的那样。正因为如此，还不如用碎片来做。
  • 如果我们曾经做过一个平板应用程序，我们将更容易重构东西，因为一切都已经很好地分开了。

缺点

  • 你必须学习，如何使用片段
于 2013-08-08T09:46:47.030 回答
16

首先，无论你做什么，确保你有一个使用模型、视图、演示者的模块化设计，它不高度依赖于 Activity 或 Fragment。

活动和片段真正提供了什么？

  1. 生命周期事件和回栈
  2. 背景和资源

因此，仅将它们用于此目的。他们有足够的责任，不要过度复杂化他们。我认为即使在 Activity 或 Fragment 中实例化 TextView 也是不好的做法。像public View findViewById (int id)这样的方法是PUBLIC是有原因的。

现在问题变得更简单了：我需要多个独立的生命周期事件和后台堆栈吗？如果您认为是的，请使用片段。如果您认为永远不会，请不要使用片段。

最后，您可以创建自己的 backstack 和生命周期。但是，为什么要重新创建轮子？

编辑：为什么反对这个？单目的班人！每个活动或片段都应该能够实例化一个实例化视图的演示者。演示者和视图是可以互换的模块。为什么一个活动或片段应该有一个演示者的责任？

于 2013-10-09T15:56:37.463 回答
12

优点

您可以从单个活动控制您的片段，因为所有片段都是相互独立的。片段有自己的生命周期 ( onPause, onCreate, onStart...)。通过具有生命周期，片段可以独立响应事件，通过 保存它们的状态onSaveInstanceState，并被带回（例如，在来电后恢复或用户单击后退按钮时）。

缺点

  1. 在您的活动代码中创建复杂性。
  2. 您必须管理片段的顺序。

无论如何，这是一个不错的主意，就好像您需要创建一个应用程序，您想在其中显示多个视图。通过这个想法，您将能够在一个视图中查看多个片段。

于 2012-09-06T06:59:30.863 回答
2

这取决于您的应用程序的设计布局。假设如果您在设计布局中使用 ActionBar 中的选项卡，那么在应用程序的单个活动中，可以在选项卡单击时更改片段。所以现在你有一个 Activity 并假设 ActionBar 中有三个 Tabs 和由 Fragments 提供的选项卡的视图，这使得管理变得容易，而且也是可行的。因此，这完全取决于您的应用程序的设计方案以及您如何决定为它构建。

于 2012-09-04T10:49:21.943 回答
1

优点：

  • 可用于通过 xml 布局创建可用于多种屏幕尺寸和方向的单一界面。

缺点：

  • 在您的活动中需要更复杂的代码。

我认为这是一个好主意，因为如果您计划为手机和平板电脑发布应用程序，则根据当前屏幕大小和方向使用不同的 xml 布局可以使应用程序更可用，并减少发布应用程序的多个版本的需要。如果您的应用永远不会同时被平板电脑和手机使用，那么这可能不值得麻烦。

于 2012-08-28T16:22:36.003 回答
0

我支持将所有视图膨胀推迟到片段以提供更好的灵活性。例如，平板电脑有一个单一的着陆活动，它聚合了多个片段，并在手机上重用相同的片段以每个片段显示一个屏幕。但是，在电话实现中，每个屏幕都有一个单独的活动。这些活动不会有太多代码，因为它们会立即推迟到对应的片段以进行视图膨胀。

我认为当引入选项卡或滑出菜单时，电话实现必须更改为单个登陆活动是一个坏主意，因为选项卡或菜单导航只会产生一个全新的屏幕。

于 2013-11-13T15:09:36.957 回答
-1

我不使用单一活动方法的最重要原因是可以利用活动生命周期。活动包含应用程序特定部分的上下文行为，片段补充了该行为。能够利用活动生命周期中可覆盖的步骤有助于使用 和 等方法将一个活动的行为与另一个活动onPause分开onResume。此生命周期还允许您返回到以前的上下文。使用单一活动方法，一旦你离开一个片段，你必须创建一个机制来返回它。

于 2012-08-30T19:25:57.787 回答