一个 Activity 和所有其他 Fragments

我正在考虑实现一屏包含 Activity和所有其他屏包含 Fragments和 managing all the fragments thru the activity。

这是个好主意吗？我的答案是 没有，但我还是想更清楚地了解这个想法是否有问题。

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

备注:

请不要给我 fragment 和 activity 的链接。

编辑:

下面是一些关于 fragment 和 activity 的内容:

优点:

  1. Fragments 意味着作为子 activities 与 activities 一起使用。
  2. Fragments 不能替代 activities。
  3. Fragments 意味着可重用性(需要知道以何种方式可以实现可重用性)。
  4. Fragments 是编写同时支持平板电脑和手机的代码的最佳方式。

缺点:

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

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

62809 次浏览
小开

优点:

  • 可以通过 xml 布局创建可用于多种屏幕大小和方向的单个接口。

缺点:

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

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

小开

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

小开

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

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

阿拉文德所说的关于坚持使用单一 Activity类型的说法也是正确的，但并不是真的那么有限。您的活动将是一个片段活动，只要您不需要 MapView，那么就没有真正的限制。如果您确实想要显示地图，这是可以做到的，但是您需要修改 Android 兼容性库以使 FragmentActivity扩展 MapActivity，或者使用公开可用的 Android-support-v4-google 地图。

最终，我认识的大多数开发人员都回到了一个 Activity路线，回到了多个活动，以简化他们的代码。在用户界面方面，在平板电脑上，有时候你只能使用一个 Activity来实现你的设计师想出来的那些疯狂的交互:)

编辑

Google 终于将 MapFragment发布到兼容库中，这样你就不必再使用 android-support-v4-googlemap 黑客技术了。阅读更新在这里: 谷歌地图 Android API v2

——编辑2——

我刚刚读了这篇关于现代(2017年)碎片状态的文章，想起了这个古老的答案。我想我会分享: 片段: Android 所有问题的解决方案

小开

这取决于你的应用程序的设计布局。假设您在设计布局中使用 ActionBar 中的 Tab，那么在应用程序的 Single Activity 中，可以在 Tab 单击时更改片段。现在您有了一个 Activity，假设 ActionBar 中有三个标签，并且片段提供了标签的视图，这使得管理 plus 变得更加容易，这也是可行的。 因此，这完全取决于你的应用程序的设计方案以及你如何决定为它构建。

小开

优点

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

缺点

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

尽管如此，这是一个相当不错的主意，就好像你需要创建一个应用程序，你想显示多个视图。通过这个想法，您将能够在一个视图中查看多个片段。.

小开

我即将完成一个项目(5个月的开发) ，有1个活动，17个片段，全屏幕。这是我的第二个基于片段的项目(之前是4个月)。

优点

  • 主要活动是700行代码，很好地管理了片段导航的顺序。
  • 每个片段被很好地分隔成它自己的类，并且相对较小(大约有几百行 ui 内容)。
  • 管理人员可以说，“嘿，我们把这些屏幕的顺序调整一下怎么样”，我可以很容易地做到这一点，因为这些片段并不相互依赖，它们都通过活动进行交流。我不需要仔细研究每个人的活动，找出他们在哪里互相称呼。
  • 我的应用程序是非常图形沉重，永远不会作为1屏幕1活动。所有这些内存中的子活动，会使应用程序一直耗尽内存，所以我必须将所有不可见的活动 finish()，并为导航制作相同的控制逻辑，就像我对片段所做的那样。就因为这个，还不如用碎片来做呢。
  • 如果我们做一个平板电脑应用程序，我们将有一个更容易的时间重构的东西，因为一切已经很好地分离。

缺点

  • 你必须学会，如何使用片段
小开

首先，无论你做什么，确保你有一个模块化的设计，使用模型，视图，展示器，而不是高度依赖于一个活动或片段。

活动和片段到底提供了什么？

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

因此，使用它们，仅此而已。他们有足够的责任，不要让他们过于复杂。我认为，即使在活动或片段中实例化 TextView 也是不好的做法。像 Public View findViewById (int id)这样的方法之所以是 公众是有原因的。

现在问题变得更简单了: 我是否需要多个独立的生命周期事件和回栈？如果你觉得可能，那就用片段。如果你认为从来没有，不要使用片段。

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

小开

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

我认为这是一个坏主意，对于手机实现必须改变到一个单一的着陆活动时，标签或滑出菜单引入，因为标签或菜单导航只导致一个全新的屏幕。


提交答案