25

I am going through the Android documentation on Fragments . The layout that defines the UI of a Fragment may be defined in the layout of the Activity, in a separate .xml file or not at all.

According to the documentation

you can also use a fragment to provide a background behavior for the activity without presenting additional UI.

Why would I need to use another Fragment to add functionality to an Activity instead of defining a few more functions within the Activity? Would such a non-UI Fragment be used just for the sake of modularity? Is there another reason for adopting such an approach? I would appreciate an example of when it is suitable to use a non-UI fragment.

Thank you in advance for your assistance.

anna
  • 585
  • 1
  • 6
  • 22
  • 5
    Imo one of the reason is because the fragment can persist also if the hosting activity is destroyed (when you rotate the screen), so managing background task is simpler if the task is inside a fragment and the fragment is not destroyed – Blackbelt Jan 24 '14 at 15:10
  • Have a look at this: http://stackoverflow.com/questions/11531648/what-is-the-use-case-for-a-fragment-with-no-ui – Francesco verheye Jan 24 '14 at 15:18
  • @blackbelt If you need a background task, use either a service, AsyncTask or Runnable spawned by some global class. Your argument for using a fragment for background tasks really don't seem to be justified when mechanisms have already long existed for that. – Johann Jun 19 '14 at 07:20
  • @AndroidDev service and runnable runs on the UI Thread. They are not background task. – Blackbelt Jun 19 '14 at 07:21

1 Answers1

30

I suppose this is about retained fragments, Inside fragment you can call setRetainedInstance(true), this way your fragment will not be recreated during configuration changes. Normally when you rotate your device, all fragments will be recreated. If you call setRetainedInstance(true) inside onCreate(), then your fragment instance will not be recreated.

Whats use of it? - you can put some data, arrays etc. inside your fragment and it will not be destroyed during configuration changes. You can also put async task inside such fragment, and after main activity rotates, your async task in your fragment will still be able to deliver its results.

Another usefull feature of fragments is that you can easily reuse them in multiple activities. This means you can put some common logic inside your non UI fragment. You could lets say accomplish it with base class for your activity, but you can extend only one class.

and simple example from google (actually using Thread inside retained fragment):

https://android.googlesource.com/platform/development/+/master/samples/ApiDemos/src/com/example/android/apis/app/FragmentRetainInstance.java

marcinj
  • 48,511
  • 9
  • 79
  • 100
  • For the sake of completeness, can you think any other such configuration change apart from rotation where a retained fragment would prove to be useful? – anna Jan 24 '14 at 16:24
  • just to complete the answer: another use case I developed. The fragment had a menu with a collapseActionView that could trigger a search task, display auto-complete suggestions and trigger new fragments to the main UI. Iguess it could have been done on the activity, but it's just so much more organised and modular to have SearchBarFragment.java and just instantiate it on which activity I want. – Budius Jan 24 '14 at 16:45
  • 2
    @alig Screen Rotation is the most common you will encounter, for a full list look here: http://developer.android.com/guide/topics/manifest/activity-element.html#config – marcinj Jan 24 '14 at 16:49
  • But There are 2 other ways to store activity data, to make available after screen destroy during screen rotation... 1. By making a class and creating its object in Application class, You can also keep state of an activity during Screen rotation. 2. You can use Activity onSavedInstanceState() and onRestoreInstanceState() method to keep state. – Imran Khan Saifi May 18 '17 at 05:53
  • @ImranKhanSaifi with 1 you need to be careful, if system decides to kill your app (because memory is low) then when it will get recreated then object stored in application object will no longer exists. Using onSaveInstanceState is better solution. – marcinj May 18 '17 at 16:57