What is the use case for a Fragment with no UI?

Question

The Android Developer guide has a decent section on the use of Fragments. One way to use Fragments is without a UI. There are a few references to using this as a means of background processing, but what advantages do Fragments bring to this area? Where would I choose to use a Fragment over Threads, AsyncTasks, Handlers, etc. for background processing?

Answer 1

I have a large chunk of fairly complex code that handles logins for various social networks - facebook, google, twitter. This is code that I need to re-use in different activities since the user can login from different places in the app. It doesn't belong in a base activity class because you can only inherit from one class and I'm using that inheritance for other, unrelated, functionality.

A ui-less fragment is perfect for my situation and a fragment suits the need nicely since I need lifecycle callbacks, for example (facebook is notorious in this regard, needing, for example, onActivityResult, etc.).

Answer 2

A very useful feature of Headless Fragments

Headless Fragments, have one really useful feature - they can be retained by the FragmentManager across configuration changes. Since they do not have any UI related to them, they do not have to be detroyed and rebuilt again when the user rotates the device for example. In order to activate this behaviour, one just has to set the retained flag of the Fragment when it is initialized. This can be done in the onCreate method of the Fragment.

---

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setRetainInstance(true);
}

ref- https://luboganev.github.io/blog/headless-fragments/

Answer 3

These are also called Headless Fragments. You can read more here

Answer 4

I concur with Greg Ennis.

I'm working on an app right now that has to execute a series of RESTful api calls. For the most part, these are just done within a single activity. But I just used a headless fragment to deal with a case where two different activities each needed to make the same sequence of multiple calls and, of course, handle errors anywhere in the sequence. By centralizing the sequence in a fragment, I could avoid duplicating a fair amount of code.

We have another api call that gets back a LOT of data which is all being parsed on the UI thread right now and takes too long. In a future version of the backend api, the server side will page the data and our app will be required to make a series of api calls to get the complete results. I'm thinking that would be a great application for a retained headless fragment. The initiating activity can start the headless fragment and the call sequence. If there's no error from the first call, that activity can start the next activity, to display initial results, while the fragment just keeps chugging and asking the server for the next page of data. The api calls are already done on a background thread. I'm pretty sure the retained fragment will have to run on a worker thread of its own.

There's more info about retained fragments at Understanding Fragment's setRetainInstance(boolean)

Answer 5

A Fragment instance can persist through device configuration changes (like screen rotation). Because an Activity will be destroyed and recreated when a configuration change happens, it's difficult to design one that will keep track of a thread or AsyncTask. On the other hand, the system takes care of reattaching a persisted Fragment to the proper Activity at the other end (so to speak) of the configuration change. You would still be using a thread or AsyncTask, only now the Fragment is holding it instead.

There may be other uses for it, but there's the one I can think of.