Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How Fragments affect the Activity "single, focused thing that the user can do" principle?

As Android documentation states: "An activity is a single, focused thing that the user can do."

However with Fragments we will be able to do many "things" within the same Activity as Reto Meier suggest. His suggestion is to replace a selection fragment by a content fragment within the same Activity (section "Within our code this produces a dilemma").

Lets say my application is a "bit" more complex, with many activities, with a complex navigation tree and designed with the "single, focused thing that the user can do" principle in mind.

Lets say now I have to adapt it to Fragments and large screens... and that I don't want to create a second application, neither have two completely different logics (one for phones other for tables) inside one application.

Should I have one Activity to manage all the application fragments and fragment transactions? Like Retro Meier suggest above. Is that the recommended path to follow? Thus breaking with the "single, focused thing that the user can do" principle for Activities?

Or am I missing something? I hope ;)

BTW, I think Fragments looks great, but from what I have seen till now, only if you are creating an application from the scratch. Because making applications to be compatible with phone and tablet looks like going to be a bit tedious. Hope to be wrong :)


Dianne Hackborn already has answered (thx for the link mgv):

you could put your entire application in one activity in which you change the fragment structure as its state changes

So then Activity becomes a sort of container where you will be able to plug Fragments. I like the approach, but... in my app there are about 30 different operations available, each one requires about 2 to 4 screens steps to be performed(forms and selection lists), all of them differ and there are also navigation restrictions. It works fine with Activities each one handling one screen/step behaviour.

So then to port to Fragments I should move each screen logic to Fragments and use Activities as containers for each operation. Thus leaving Activities as the ones managing the navigation between Fragments for every operation, right? Looks like going to be a pain to adapt long applications. :(

Current Activity definition should change a bit btw. :)

like image 202
Axel M. Garcia Avatar asked Apr 19 '11 14:04

Axel M. Garcia


1 Answers

Should I have one Activity to manage all the application fragments and fragment transactions?

That is impossible to answer in the abstract. However, most applications will have multiple activities, even in a fragment-based world. Some of that will be to accommodate smaller screen sizes, where it will tend to be one fragment per activity. Some of that will be required by the framework (e.g., inheriting from PreferenceActivity). And, some of that will be by GUI design.

Thus breaking with the "single, focused thing that the user can do" principle for Activities?

That portion of the documentation was written in 2008, perhaps earlier. Had fragments existed back then, I imagine the documentation would state that a fragment is a "single, focused thing that the user can do", with activities serving as an orchestration layer, determining what fragments are visible in what circumstances.

The documentation will not in all places be updated to reflect fragments, and even if it does, it will take some time. For the balance of 2011, at minimum, you will need to perform your own translations of 2008-era instructions to convert them to 2011-era fragment-based UIs.

Lets say now I have to adapt it to Fragments and large screens... and that I don't want to create a second application, neither have two completely different logics (one for phones other for tables) inside one application.

I have no idea what you consider "completely different logics" to be. In a fragment-based app, most of your business logic will be in the fragments themselves. The activities, again, serve as an orchestration layer, determining what fragments should be visible and coordinating event handling. The latter will get a bit more complicated than it used to be, since sometimes clicking on an item in a list will bring up a new fragment and sometimes clicking on an item in a list will start a new activity, depending on screen size.

Or am I missing something?

To be honest, you are missing enough concreteness to your question to make it reasonably answerable.

like image 121
CommonsWare Avatar answered Oct 24 '22 11:10

CommonsWare