Intro:
The basic "Fragments Tutorial" pattern goes something like this:
- On a tablet, have a list on the left, details on the right.
- Both are
Fragments
and both reside in the sameActivity
. - On a phone, have a
listFragment
in oneActivity
. - Launch a new
Activity
with the detailsFragment
.
(e.g. Android 3.0 Fragments API by Dianne Hackborn and the Fragments API Guide)
On both devices, functionality is in the Fragments
. (simple)
On the Tablet, the whole app is 1 Activity
, on the phone, there are many Activities
.
Questions:
- Is there a reason to split the phone app into many
Activities
?
One problem with this method, is that you duplicate a lot of the logic in the main Tablet Activity
, and in the separate Phone Activities
.
- Would it not be easier to retain the 1 Activity model in both cases,
using the same logic of switchingFragments
in and out (just using a different layout)?
This way most of the logic resides in the Fragments
themselves, and there is only a single Activity
– less duplication of code.
Also what I have read about the ActionBarSherlock
is that it seems to work best with Fragments
instead of Activities
(but I have not worked with it yet).
Are the tutorials oversimplified, or have I missed something major in this approach?
We have tried both approaches successfully in the office – but I am about to start a bigger project and want to make things as easy for myself as possible.
Some links to related questions:
- Dilemma: when to use Fragments vs Activities:
- Patterns when to use Activity Transition vs Dynamic Fragments
- Android – I need some clarifications of fragments vs activities and views
- Activities or fragments in Android?
- Multiple fragments and activities interaction design
- So what are the exact advantages of Fragments in Android 3.0?
Updates
Started bounty on question – still not convinced about why I need to duplicate my app logic in my tablet activity and in each phone activity.
Also found an interesting article by the guys at Square, which is well worth reading:
Best Answer
I agree that the tutorials are very simplified. They just introduce
Fragments
but I do not agree with the pattern as suggested.I also agree that it is not a good idea to duplicate your app's logic across many Activities (see DRY Principle on wikipedia).
I prefer the pattern used by the
ActionBarSherlock
Fragments Demo app (download here and source code here). The demo that most closely matches the tutorial mentioned in the question is the one called "Layout" in the app; orFragmentLayoutSupport
in the source code.In this demo, the logic has been moved out of the
Activity
and into theFragment
. TheTitlesFragment
actually contains the logic for changing Fragments. In this way, each Activity is very simple. To duplicate many very simple Activities, where none of the logic is inside the Activities, makes it very simple.By putting the logic into the Fragments, there is no need to write the code more than once; it is available no matter which Activity the Fragment is placed into. This makes it a more powerful pattern than the one suggested by the basic tutorial.
Another advantage of the ABS pattern is that you do not end up with a Tablet Activity containing lots of logic, and that means that you save memory. The tutorial pattern can lead to a very big main activity in a more complex app; since it needs to handle the logic of all the fragments that get placed in it at any time.
Overall, do not think of it as being forced to use many activities. Think of it as having the opportunity to split your code into many fragments, and saving memory when using them.