Android 一个活动和所有其他片段

One Activity and all other Fragments

提问by Vineet Shukla

I am thinking of implementing one screen with Activityand all other sreens with Fragmentsand managing all the fragments thru the activity.

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

Is it a good idea?and my answer is NObut still I want to know more clearly about this thought.

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

What are the pros and cons of the idea?

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

Note:

笔记：

Please don't give me the link for fragment and activity.

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

EDIT:

编辑：

Here is something over Fragments and activity:

这里有一些关于 Fragments 和 Activity 的内容：

Pros:

优点：

1. Fragments are meant to be used with activities as a sub activity.
2. Fragments are not the replacement for activities.
3. Fragments are meant for reusability(Need to know in what way reusability can be achieved.).
4. Fragments are the best way to write code to support both tablets and phones.

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

Cons:

缺点：

1. We need to implement the interface to get the data from fragments.
2. For dialog we have to go a long way to show it.

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

Why should we use fragments if we are not considering tablets? What is the starting time difference between activity and fragment?

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

回答by JustinMorris

It depends on the app you are creating. I've created several apps using both approaches and can't say one way is always better than the other. The latest app I created I used the single Activityapproach and a Facebook style navigation. When selecting items from the navigation list I update a single Fragmentcontainer to display that section.

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

That said, having a single Activityalso introduces a lot of complexities. Let's say you have an edit form, and for some of the items the user needs to select, or create, requires them to go to a new screen. With activities we'd just call the new screen with startActivityForResultbut with Fragmentsthere is no such thing so you end up storing the value on the Activityand having the main edit fragment check the Activityto see if data has been selected and should be displayed to the user.

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

What Aravind says about being stuck to a single Activitytype is also true but not really that limiting. Your activity would be a FragmentActivity and as long as you don't need a MapViewthen there are no real limitations. If you do want to display maps though, it can be done, but you'll need to either modify the Android Compatibility Library to have FragmentActivityextend MapActivityor use the the publicly available android-support-v4-googlemaps.

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

Ultimately most the devs I know that went the one Activityroute have gone back to multiple Activities to simplify their code. UI wise, on a tablet, you are some times stuck using a single Activityjust to achieve what ever crazy interaction your designers come up with :)

最终，我认识的大多数走一条Activity路线的开发人员都回到了多个活动来简化他们的代码。UI 方面，在平板电脑上，您有时会卡在使用单一工具Activity来实现您的设计师想出的任何疯狂的交互 :)

-- EDIT --

- 编辑 -

Google has finally released MapFragmentto the compatibility library so you no longer have to use the android-support-v4-googlemaps hack. Read about the update here: Google Maps Android API v2

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

-- EDIT 2 --

-- 编辑 2 --

I just read this great post about the modern (2017) state of fragments and remembered this old answer. Thought I would share: Fragments: The Solution to All of Android's Problems

我刚刚阅读了这篇关于碎片的现代（2017）状态的好文章，并记住了这个旧答案。我想分享：Fragments: The Solution to All Android's Problems

回答by Tamas

I'm about to finish a project(5 months in development), that has 1 activity, and 17 fragments, all full screen. This is my second fragment based project(previous was 4 months).

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

Pros

优点

• The main activity is 700 lines of code, just nicely managing the order of the fragments navigation.
• Each fragment is nicely separated into it's own class, and is relatively small (~couple hundred lines of ui stuff).
• Management can say, "hey, how about we switch the order of those screens", and I can do it very easily, as those fragments don't depend on each other, they all communicate through the activity. I don't have to dig through individual activities, to find where they call each other.
• my app is very graphics heavy, and would never work as 1 screen 1 activity. All those sub activities in the memory, would make the app run out of memory all the time, so I would have to finish()all non visible activities, and make the same control logic for navigation, as I would do with fragments. Might as well do it with fragments just because of this.
• if we ever do a tablet app, we will have an easier time re-factoring stuff, because everything is nicely separated already.

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

Cons

缺点

• you have to learn, how to use fragments

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

回答by beplaya

First, whatever you do, make sure you have a modular design using model, view, presenter that is not highly dependent on an Activity or a Fragment.

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

What do Activities and Fragments really provide?

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

1. Life cycle events and backstack
2. Context and resources

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

Therefore, use them for that, ONLY. They have enough responsibility, don't over complicate them. I would argue that even intantiating a TextView in an Activity or Fragment is bad practice. There is a reason methods like public View findViewById (int id)are PUBLIC.

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

Now the question gets simpler: Do I need multiple, independent life cycle events and backstacks? If you think yeah maybe, use fragments. If you think never ever, don't use fragments.

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

In the end, you could make your own backstack and life cycles. But, why recreate the wheel?

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

EDIT: Why down vote this? Single purpose classes people! Each activity or fragment should be able to instantiate a presenter that instantiates a view. The presenter and view are a module that can be interchanged. Why should an activity or fragment have the responsibility of a presenter??

编辑：为什么投反对票？单目的类人！每个 Activity 或 Fragment 都应该能够实例化一个 Presenter 来实例化一个视图。演示者和视图是一个可以互换的模块。为什么 Activity 或 Fragment 要有演示者的责任？？

回答by Sahil Mahajan Mj

Pros

优点

You could control your fragments from a single activity, beacause all fragments are independent of each other. The fragments have a lifecycle (onPause, onCreate, onStart...) of their own. By having a lifecycle, fragments can respond independently to events, save their state through onSaveInstanceState, and be brought back (i.e. such as when resuming after an incoming call or when the user clicks the back button).

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

Cons

缺点

1. Create complexity in your code of activity.
2. You have to manage the order of the fragments.

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

Never the less, it is quite a good idea, as if you need to create an app, where you want to show several views. By this idea, you'll be able to view several fragments in a single view..

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

回答by ASH

It depends on the design layout of your app. Suppose if your using Tabs in ActionBar in the design layout then in the Single Activity of the app one can have fragments being changed on Tab click. So now you have an Activity and say suppose three Tabs in the ActionBar and the view for the tabs being provided by the Fragments, which makes it easy to manage plus is feasible also. So, it all depends on the design scheme of your app and how you take the decision to build for it.

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

回答by Ski

Pros:

优点：

• Can be used to create a single interface usable by multiple screen sizes and orientations via xml layouts.

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

Cons:

缺点：

• Requires more complex code in your activity.

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

I believe it's a good idea, because using different xml layouts based on the current screen size and orientation can make the app more usable and reduce the need to release multiple versions of your app if you plan on releasing your app for both phones and tablets. If your app will never be used by both tablets and phones, it's probably not worth the trouble.

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

回答by user1679130

I'm a proponent of deferring all view inflation to fragments to provide better flexibility. For example having a single landing activity for a tablet which aggregates multiple fragments and reusing the same fragments on a phone to show one screen per fragment. However in the phone implementation I'd have a separate activity for each screen. The activities would not have too much code as they would immediately defer to their fragment counterpart for view inflation.

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

I think it's a bad idea for the phone implementation to have to change to a single landing activity when tabs or a slide out menu is introduced since the tab or menu navigation just results in a completely new screen.

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

回答by japino

The most important reason I would give for not using the single activity approach is so that the activity lifecycle can be taken advantage of. Activities contain contextual behavior of a certain portion of the application and fragments supplement that behavior. Having the ability to take advantage of the overridable steps in the activity lifecycle helps to separate one activity's behavior from another with methods such as onPauseand onResume. This lifecycle also allows you return to previous context. With the single activity approach, once you leave a fragment you have to create an mechanism to return to it.

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