一个活动和所有其他碎片

Question

我正在考虑使用Activity以及Fragments和managing all the fragments thru the activity的所有其他屏幕实现一个屏幕。

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

这个想法有哪些优点和缺点？

注意：

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

修改

以下是碎片和活动的内容：

优点：

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

缺点：

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

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

Answer 1

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

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

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

最终，我所知道的大多数开发人员都使用了Activity路由，这些开发人员已经回到多个活动来简化他们的代码。 UI智能，在平板电脑上，你有时会使用单Activity来实现你的设计师想出的疯狂交互:)

- 编辑 -

Google最终将MapFragment发布到兼容性库，因此您不再需要使用android-support-v4-googlemaps hack。在此处阅读有关此更新的信息：Google Maps Android API v2

- 编辑2 -

我刚刚读了这篇关于现代（2017）片段状态的精彩文章，并记得这个老答案。以为我会分享：Fragments: The Solution to All of Android's Problems

Answer 2

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

<强>赞成

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

<强>缺点

• 你必须学习，如何使用片段

Answer 3

首先，无论您做什么，请确保使用模型，视图，演示者进行模块化设计，而不是高度依赖于Activity或Fragment。

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

1. 生命周期事件和backstack
2. 上下文和资源

因此，请将它们用于 ONLY 。他们有足够的责任，不要过度复杂化。我认为即使在Activity或Fragment中对TextView进行实例化也是不好的做法。 公共视图findViewById（int id）等方法是 PUBLIC 的原因。

现在问题变得更简单了：我是否需要多个独立的生命周期事件和背包？如果您认为可能，请使用碎片。如果您从未想过，请不要使用碎片。

最后，你可以制作自己的背包和生命周期。但是，为什么重新创造轮子？

编辑：为什么要投票呢？单人课程的人！每个活动或片段都应该能够实例化实例化视图的演示者。演示者和视图是可以互换的模块。为什么活动或片段应由演示者负责？

Answer 4

赞成

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

缺点

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

从来没有这样，这是一个非常好的主意，好像你需要创建一个应用程序，你想要显示几个视图。通过这个想法，您将能够在单个视图中查看多个片段。

Answer 5

这取决于您应用的设计布局。假设您在设计布局中使用ActionBar中的Tabs然后在应用程序的Single Activity中，可以在Tab Click上更改片段。所以现在你有了一个Activity，并假设ActionBar中有三个Tabs，Frags提供的选项卡视图，这使得它易于管理，也是可行的。 所以，这一切都取决于你的应用程序的设计方案以及你如何决定为它构建。

Answer 6

优点：

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

缺点：

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

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

Answer 7

我支持将所有观点通货膨胀推迟到碎片以提供更好的灵活性。例如，对于平板电脑具有单个着陆活动，其聚合多个片段并且在电话上重复使用相同的片段以针对每个片段显示一个屏幕。但是在手机实现中，每个屏幕都有一个单独的活动。活动不会有太多的代码，因为他们会立即推迟他们的片段对应的视图通胀。

我认为，由于选项卡或菜单导航只会导致全新的屏幕，因此在引入标签或幻灯片菜单时，手机实施必须更改为单个着陆活动。

Answer 8

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