One Activity and all other Fragments [closed]

Question

I am thinking of implementing one screen with Activity and all other sreens with Fragments and managing all the fragments thru the activity.

Is it a good idea? and my answer is NO but 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:

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.

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.

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

Answer 1

Pros:

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

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.

Answer 2

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.

What do Activities and Fragments really provide?

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

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.

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??

Answer 3

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.

Answer 4

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.

Answer 5

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).

Cons

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

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..

Answer 6

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 onPause and 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.