Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Confused about using Fragments in the app

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.

like image 789
Rookie Avatar asked Jan 05 '13 20:01

Rookie


People also ask

Why we use fragments instead of activities?

Like activities, they have a specific lifecycle, unlike activities, they are not top-level application components. Advantages of fragments include code reuse and modularity (e.g., using the same list view in many activities), including the ability to build multi-pane interfaces (mostly useful on tablets).

What is a fragment and what is an advantage of using fragments?

January 5, 2021. According to the Android documentation, a fragment is a part of applications user interface that is bound to an activity. Fragments have their lifecycle and layouts or UI components. Fragments help enrich your UI design, pass data between different screens, and adapt to different device configurations.

What is fragment explain with example?

In Android, the fragment is the part of Activity which represents a portion of User Interface(UI) on the screen.


1 Answers

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) Fragments across Tablet and Phone

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.

like image 157
biddulph.r Avatar answered Oct 04 '22 22:10

biddulph.r