Confused about using Fragments in the app

Question

I have a full-fledged app which is NOT developed using Fragments. My confusion is that should I change it to have Fragments instead of Activities. The thing that I would like to tell is that I'm using only portrait orientation in my application and it is built, keeping in mind only phones, not tablets. So my question is, will it do any good if I change the whole structure of app and use Fragments.

As far as I know, Fragments should be used only If we want to reuse something. Any suggestion is appreciated.

Answer 1

I've just finished converting my application to use fragments, because:

1. Wanted a tablet version
2. Wanted to use ViewPageIndicator and ViewPager with advanced views

Those are the most compelling reasons to use fragments.

It might be a little more work, but with significantly more tablets appearing on the market and fast adoption rate, perhaps it's worth considering supporting tablets with a nicer UI?

If you really don't want to do this and have no requirement for view paging using advanced views then there is no point over-engineering your project to make it use fragments for using fragments sake. You could argue you might learn about them, but when you come to use them in your next project, you can learn then (that is what I did and it worked out fine).

Answer 2

Think of fragments as a way to modularize your code into manageable pieces. Each fragment represents a small piece of functionality and UI. This allows your to easily adjust your code to fit different scenarios.

Sure you don't plan on supporting tablets now (regardless of how you feel tablet users will install the app), think of larger size 5-6" devices and the potential of extending your app over to them. It is best to provide your app to as many devices as possible and the best apps will tailor the experience to the device.

The transition to Fragments doesn't have to be difficult. Take a small piece of functionality and move it over to a Fragment. Then you will see how easy and flexible the new pattern is. You don't need to rewrite the entire application as Activities and Fragments can work together.

I believe by skipping out on Fragments you are really making your development tasks much more difficult in the long run.

Answer 3

It is easier to set interaction between fragments than between activities.

In case of activities:

1. You need to use startActivityForResult()/onActivityResult();
2. Your custom types must implement Parcelable interface in order to be passed between activities;
3. You have to free all resources when your activity is paused/stopped.

In case of fragments:

1. Passing data is as easy as getting an instance of fragment from FragmentManager and calling a method on it;
2. No need to implement Parcelable;
3. You can hold references to "heavy" resources in activity which contains all of your fragments and initialise/release them only once (no need for initialisation/release for each fragment).

Also, an instance of Fragment is more lightweight than instance of Activity and takes less time and resources to be initialised/resumed.

In general, interaction between the components of your UI is cleaner, more elegant, easier to implement when you use fragments.

Answer 4

As far as your application or any of the application is concerned , it's better to use fragments and it causes no harm to your application and it also ease your burden while further extending your application for tablets also.So, better to start with the use of fragments in your application.

Answer 5

Fragments can be used to create a dynamic and multi-pane user interface, and as such are ideally suited for tablets which have a lot more screen real estate to use up. Of course, on a phone the situation is a little different, you have a much smaller space to play with and sometimes it can be a struggle just to get one Activity fitting onto the screen without worrying about including multiple Fragments.

Fragments are very good for dynamic interfaces, and for helping with compatibility between Tablet and Phone. They are also able to communicate with each other much better than Activities can, so there are certainly advantages to using them even on a phone-only setup. (See FragmentsManager for some functionality they can be used for)

One example of use is illustrated in the diagram below (taken from Android Developer site)

This illustrates the flexibility of the Fragments, which on tablet can occupy the same screen, switching to a more Activity-like format on a phone. It is this kind of power that gives the Fragment such an advantage over an Activity.

So clearly there are advantages to switching to a Fragment orientated solution in terms of flexibility, but your original question states that you are targeting phones only, and only in portrait orientation.

Having an application that is already in existence with Activities, providing that it is a solution that you are happy with, and has good usability I would say there was no reason to switch to Fragments (unless you are looking for a challenge or have some spare time and fancy a tinker). While advantages exist, a drastic change such as adding Fragments could introduce bugs into your application and impact the user experience (at least for the short term).

Long term, if you are ever considering bringing tablet support into the fold or would like to use the landscape orientation, then it might be a good idea to start looking at what you can do with Fragments to improve the experience, and integrate this with the current flow of your phone application.

Otherwise, the current solution you have created will more than suffice, and as long as it is well received by your customer base I see no reason to change.

Of course, there is no harm familiarising yourself with the Fragment APIs for future projects, or in the event that it is time for a refresh of your current project's UI.

It is worth pointing out that Fragments are only supported natively from Android 3.0 (API level 11), and to support earlier devices you will require the Android Support package found in your installation. As such, if your current application targets 2.x devices, I would stick with an Activity based approach, for simplicity and .apk size, unless moving to a native API Level (like Android 3.0+). This is personal preference though and ultimately the answer to your original question will boil down to your personal preference.

Answer 6

If you don't plan to support tablets in the future than leave it as it is. You won't gain anything when you convert your app to fragments.

The situation is different if you start a new application. I would use fragments from the beginning in order to be more flexible should the need arise to support other form factors in the future. Note that the functionality is available in the support library so you can use it also on older devices.