一个活动和所有其他片段

我想实现一个屏幕，Activity和所有其他sreens与Fragments和managing all the fragments thru the activity。

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

这个想法有什么优点和缺点？

注意：

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

编辑：

以下是有关片段和活动的一些信息：

优点：

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

缺点：

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

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

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

就是说，一个人Activity也带来了很多复杂性。假设您有一个编辑表单，对于用户需要选择或创建的某些项目，要求它们进入新屏幕。在进行活动时，我们只会使用来调用新屏幕，startActivityForResult但Fragments在没有这种情况的情况下，您最终将值存储在上，Activity并让主编辑片段检查，Activity以查看是否已选择数据并将其显示给用户。

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

最终，我所知的大多数开发者都走了一条Activity路，然后又回到了多个Activity来简化他们的代码。在平板电脑上，UI明智的做法是，有时您只能使用一个Activity插件来完成您的设计师想出的疯狂互动：)

-编辑-

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

-编辑2-

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

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

优点

• 主要活动是700行代码，只是很好地管理了片段导航的顺序。
• 每个片段都很好地分成了自己的类，并且相对较小（〜几百行ui东西）。
• 管理层可以说：“嘿，我们如何切换这些屏幕的顺序”，我可以很容易地做到这一点，因为这些片段彼此不依赖，它们都通过活动进行通信。我不必深入研究各个活动，也不必查找彼此之间的联系。
• 我的应用程序的图形非常繁琐，因此永远无法用作1屏幕1活动。内存中的所有这些子活动都会使应用程序始终耗尽内存，因此，我将不得不处理finish()所有不可见的活动，并为导航创建相同的控制逻辑，就像处理片段一样。正因为如此，也可以对片段进行处理。
• 如果我们使用平板电脑应用程序，我们将可以更轻松地进行重构，因为一切都已经很好地分离了。

缺点

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

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

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

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

因此，仅将它们用于此目的。他们有足够的责任，不要过分复杂化。我认为即使在Activity或Fragment中初始化TextView也是不好的做法。诸如public View findViewById（int id）之类的方法是PUBLIC是有原因的。

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

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

编辑：为什么对此投反对票？单目的班人！每个活动或片段都应该能够实例化用于实例化视图的演示者。演示者和视图是可以互换的模块。为什么活动或片段应由主持人负责？

优点

您可以通过单个活动控制片段，因为所有片段都彼此独立。该片段有一个生命周期（onPause，onCreate，onStart自己的...）。通过具有生命周期，片段可以独立响应事件，通过保存片段的状态onSaveInstanceState并被带回（例如，在传入呼叫后恢复或用户单击“后退”按钮时）。

缺点

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

不管怎样，这是一个好主意，好像您需要创建一个要显示多个视图的应用程序一样。通过这种想法，您将能够在一个视图中查看多个片段。

这取决于您的应用程序的设计布局。假设如果您在设计版式的ActionBar中使用Tabs，则在应用程序的Single Activity中，可以在单击Tab键时更改片段。因此，现在您有了一个Activity，并假设ActionBar中的三个选项卡以及Fragments提供的选项卡的视图，这使得易于管理以及可行也是可行的。因此，这完全取决于应用程序的设计方案以及您如何决定为其构建应用程序。

优点：

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

缺点：

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

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

我赞成将所有视图的膨胀推迟到各个片段上以提供更好的灵活性。例如，针对平板电脑进行一次登陆活动会汇总多个片段，然后在电话上重复使用相同的片段，以显示每个片段一个屏幕。但是在电话实现中，每个屏幕都有一个单独的活动。这些活动将没有太多的代码，因为它们将立即顺应其零碎的内容以查看通货膨胀。

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

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