How many Activities vs Fragments?
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
Fragmentsand both reside in the sameActivity. - On a phone, have a
list
Fragmentin oneActivity. - Launch a new
Activitywith 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 switching
Fragmentsin 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:
- Advocating Against Android Fragments
Solution 1:
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; or FragmentLayoutSupport in the source code.
In this demo, the logic has been moved out of the Activity and into the Fragment. The TitlesFragment 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.
/**
* Helper function to show the details of a selected item, either by
* displaying a fragment in-place in the current UI, or starting a
* whole new activity in which it is displayed.
*/
void showDetails(int index)
{
mCurCheckPosition = index;
if (mDualPane)
{
// We can display everything in-place with fragments, so update
// the list to highlight the selected item and show the data.
getListView().setItemChecked(index, true);
// Check what fragment is currently shown, replace if needed.
DetailsFragment details = (DetailsFragment) getFragmentManager()
.findFragmentById(R.id.details);
if (details == null || details.getShownIndex() != index)
{
// Make new fragment to show this selection.
details = DetailsFragment.newInstance(index);
// Execute a transaction, replacing any existing fragment
// with this one inside the frame.
FragmentTransaction ft = getFragmentManager()
.beginTransaction();
ft.replace(R.id.details, details);
ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
ft.commit();
}
}
else
{
// Otherwise we need to launch a new activity to display
// the dialog fragment with selected text.
Intent intent = new Intent();
intent.setClass(getActivity(), DetailsActivity.class);
intent.putExtra("index", index);
startActivity(intent);
}
}
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.
Solution 2:
I think you're on the right track. (And yes, the tutorials are over-simplified).
In a tablet layout, you could use a single Activity and swap in and out Fragments (in multiple 'panes'). While in a phone layout you can use a new Activity for each Fragment.
Like so:
It may seem like a lot of extra work, but by using multiple activities for phones, you enable basic Activity life-cycle and Intent passing. This also allows the framework to handle all the animations and the back-stack.
To help reduce the code you can use a BaseActivity and extend from that.
So if the user has a tablet you would use MyMultiPaneFragActivity or something similar. This activity is responsible for managing callbacks from the fragments and routing intents to the correct fragment (such as a search intent)
If the user has a phone, you can use a regular Activity with very little code and have it extend MyBaseSingleFragActivity or something similar. These activities could be very simple, 5-10 lines of code (maybe even less).
The tricky part is routing intents and whatnot. *(Edit: see more below).
I think the reason this is the recommended way is to save memory and reduce complexity and coupling. If you are swapping out Fragments, the FragmentManager maintains a reference to that Fragment for the back-stack. It also simplifies what should be 'running' for the the user. This setup also decouples the views and layout and logic in the Fragment from the Activity life-cycle. This way a Fragment can exist in a single activity, alongside another fragment (two-pane), or in a three-pane Activity, etc.
*One of the benefits of having regular intent routing is that you can launch an Activity explicitly from anywhere in the back-stack. One example might be in the case of search results. (MySearchResults.class).
Have a read here for more:
http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html
It might be a little more up-front work, because each fragment must work well across separate activities, but it usually pays off. It means that you can use alternative layout files that define different fragment combinations, keep fragment code modular, simplify action bar management, and let the system handle all the back stack work.
Solution 3:
Here is Reto Meier's answer regarding the same, taken from this video of Udacity's Android Fundamentals course.
There are a number of reasons you'd be better off breaking your app into different activities.
- Having a single monolithic activity increases the complexity of your code, making it difficult to read, test and maintain.
- Makes creating and managing intent filters much harder.
- Increases the risk of tightly coupling independent components.
- Makes it much more likely to introduce security risks if the single activity includes both sensitive information and information that's safe to share.
A good rule of thumb is to create a new activity whenever the context changes. For example, displaying a different kind of data and while switching from viewing to entering data.