3

I'm just getting to know Fragments in Android.

When you create a new blank project, by default a Fragment is included as well, although it's not really used. My impression is that Google wants you to use Fragments all the time no matter how simple the app is. Would that be a true assessment or can you think of any reasons not to use Fragments?

What I also find strange is that the documentation indicates that Fragments can also be used for stuff that is not UI related. Can you give me an example of an app that would use a Fragment but doesn't provide any UI?

Sufian
  • 6,405
  • 16
  • 66
  • 120
Johann
  • 27,536
  • 39
  • 165
  • 279
  • Have a look at this: http://stackoverflow.com/questions/21335796/android-non-ui-fragment-usage – Francesco verheye Jun 19 '14 at 07:16
  • 1
    And this too: http://stackoverflow.com/questions/11531648/what-is-the-use-case-for-a-fragment-with-no-ui – Francesco verheye Jun 19 '14 at 07:17
  • The first question is probably a matter of opinion. On the second, you could use a Fragment "just to retain data". The Android sample for "efficient bitmaps" does this http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html – matiash Jun 19 '14 at 07:18
  • @Francescoverheye Just read that link. The argument is too weak to justify using a fragment for a background task, considering that services and AsynTasks can accomplish the same thing. – Johann Jun 19 '14 at 07:23
  • @AndroidDev That's true, I only use my Fragments for UI stuff, nothing else. – Francesco verheye Jun 19 '14 at 07:36
  • I think that its not up to Google when you create new project, I assume that you are using eclipse, in new release they updated templates – user3455363 Jun 19 '14 at 07:49

2 Answers2

4

Google introduced fragments when they lunched Honeycomb (3.0). As you may know, Honeycomb was the first Android version to support tablets out-of-the-box and they use fragments to better arrange UI layouts on the screen.

With Fragments you can utilize screen property way better then with activities. One activity can run and "command" many different fragments that share same screen real-estate and the fragments can be swapped on the fly.

So yes, Google WANTS you to use fragments and it is the right way to write most scale-able applications.

As for the second question:

Fragments can persist across configuration changes - like screen orientation changes for instance. Activities gets killed and recreated when you change screen orientation and any work they might do will have to be recreated again.

If you use fragments right, then when you change screen orientation the activity might get killed but the fragment can persist its state and then re-attach itself to the newly created activity and continue where it left.

Basically, if you have an AsyncTask running from an activity and the activity gets killed because of orientation change (for example), you AsyncTask is useless now. But if you hold the AsyncTask through a fragment then it will continue because the fragment isn't destroyed.

Hope this helps

Yosi199
  • 1,745
  • 4
  • 22
  • 47
  • That seems to be the case. However, the second part of my question was about using it for non UI stuff. After reading the SO links the others have posted, I really can't see any justified reason. – Johann Jun 19 '14 at 07:32
0

It all depends on what you're developing and how. I don't think EVERY app needs to have fragments, but they are in many cases easier to work with as they can be swapped on the fly, managed by a single activity, etc. For instance, imagine your app has some background task running, and you want it to keep running while the user is still "Free to roam" around the app. Running that task in the activity and having the UI in fragments would be a very simple way to do this. The activity can also manage and send messages and data to its "children" fragments at any point, including communication between the fragments themselves.

As for fragments with no UI at all, I don't recall coming across something like this, but you can definitely implement background tasks and other methods that are not directly related to the UI in a fragment. Again, it all depends what you're developing and how. There's really no "right or wrong" here...

orenk86
  • 720
  • 9
  • 24