I am trying to learn Fragments in Android and from various examples I have found there seems to be different ways of doing it and I just wanted to get some advice as to which is the correct way, or at least under which circumstances one way should be used over another.
One example created a layout that contained a fragment and a FrameLayout. In the code, when an item is selected from the ListFragment a new Fragment is created (with some data it requires in the constructor) and the FrameLayout is replaced with this new Fragment (using FragmentTransaction.replace()).
Another example has a layout file that declares the 2 fragments side by side. Now in the code when the user selects an item from the list in one fragment a call is made to the other fragment to update the data (based on the selected item).
So I am just wondering if either of these methods is preferred over the other or if there are certain circumstances where one should be used?
EDIT: here is the code for each of the two methods I was referring to:
1:
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);
}
2:
public void onListItemClick(ListView l, View v, int position, long id) {
String item = (String) getListAdapter().getItem(position);
DetailFragment fragment = (DetailFragment) getFragmentManager()
.findFragmentById(R.id.detailFragment);
if (fragment != null && fragment.isInLayout()) {
fragment.setText(item);
} else {
Intent intent = new Intent(getActivity().getApplicationContext(),
DetailActivity.class);
intent.putExtra("value", item);
startActivity(intent);
}
}
A Fragment represents a reusable portion of your app's UI. A fragment defines and manages its own layout, has its own lifecycle, and can handle its own input events. Fragments cannot live on their own--they must be hosted by an activity or another fragment.
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.
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).
Each tab will have a fragment to hold the products. The tabs could either held in activity or a fragment. I do find fragments a slightly faster than activities but really its not something you would really notice in most cases. Regardless if they was intended for speed or not they still seem/feel little quicker.
So I am just wondering if either of these methods is preferred over the other or if there are certain circumstances where one should be used?
If the actual fragment does not need to change (i.e., it is the same fragment class), I would have the activity call a method on that fragment rather than replace it (your scenario #2), assuming it exists. That's much less expensive at runtime, and it's probably simpler to code as well.
If, however, the fragment might need to be a different one (e.g., depending on what you click, there may be different fragments for different types of model objects represented in the list), then replacing the fragment will be needed (your scenario #1). You could optimize the case where the fragment happens for this event to be of the same class, though I'd focus first on getting it working just by replacing the fragment and worry about the optimization if/when you have the time and inclination.
I'm not a fan of your #2 code structurally, though. IMHO, fragments should not be talking with other fragments directly. My preferred pattern is for fragments to "stick to their knitting", focusing solely on things within their own widgets and models. For events that affect other parts of the UI (e.g., list click), have the fragment notify the activity (e.g., via a listener interface). The activity is the one that knows which fragments should be around, as it is the one that created them in the first place. The activity can then either talk to the other fragment (if it exists), create the other fragment (if there is room), or start up another activity. If you prefer your #2 approach, you are welcome to use it -- it's just not what I'd do in your circumstance.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With