Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Things not to do in Fragments?

In Google's developer documentation for Fragments they mention the following:

In order to reuse the Fragment UI components, you should build each as a completely self-contained, modular component that defines its own layout and behavior. Once you have defined these reusable Fragments, you can associate them with an Activity and connect them with the application logic to realize the overall composite UI.

Which sounds really good. However they don't go into much more detail than:

All Fragment-to-Fragment communication is done through the associated Activity. Two Fragments should never communicate directly.

Are there any things that I should avoid using/calling/doing in my Fragments?

I suppose that using a Singleton would break the re-usability by introducing external dependencies/expectations?

Is it okay to call Log.*, SharedPreferences, Toast, and AlertDialog from inside a Fragment, or is that something you should avoid doing?

Is it okay to call getActionBar() or would it be foolish to assume that the hosting Activity does have a ActionBar?

If the Fragment needs to output something to the user, be it an error or whatever, should it make the decision itself how to output this (Log, Toast, AlertDialog, etc) or should it send the string to a callback and let the hosting Activity decide how/what it should do?

A ListFragment needs to get populated with data to present to the user. Should it fetch the data itself (over a network request in a AsyncTask inner class), or should it request the hosting Activity to fetch the data for it?

like image 899
Fred Avatar asked Feb 13 '14 21:02

Fred


1 Answers

This is a very good question. But, as you mentioned in your question, the official documentation specifies only not to have fragments communicate with each other directly.

Now, depending on your implementation, you might want complex methods and functionalities to be executed trough callbacks by the associated Activity. Especially if it's a functionality that is common to more Fragments.

As for the simple stuff, like calling Log.*, SharedPreferences, Toast, and AlertDialog I find it works very good if you have it done in your Fragment. You don't want to have high coupling between your classes.

Also, a Fragment should be able to fetch data and output something to the user by itself, but again, it depends a lot on your implementation and the degree of complexity you are dealing with.

I would suggest to learn by example. Especially form samples from the official Android documentation. They should get it right :)

EDIT

Just make sure that you always use callbacks when navigating trough Fragments. Like if you select a List item from a Fragment and you want to see the details in another one.

The following code is from the official documentation at http://developer.android.com/training/basics/fragments/index.html

@Override
public void onAttach(Activity activity) {
    super.onAttach(activity);

    // This makes sure that the container activity has implemented
    // the callback interface. If not, it throws an exception.
    try {
        mCallback = (OnHeadlineSelectedListener) activity;
    } catch (ClassCastException e) {
        throw new ClassCastException(activity.toString()
                + " must implement OnHeadlineSelectedListener");
    }
}

Fragments can communicate directly between them as well but the above solution is more elegant and easy to maintain.

like image 67
Bandreid Avatar answered Sep 17 '22 15:09

Bandreid