In this article, we will analyze the interesting points of the Fragment API, I think that it will be of interest to all developers who develop an application for Android. First, you need to add dependencies: dependencies {    
	def fragment_version = "1.5.4"
	implementation "androidx.fragment:fragment-ktx:$fragment_version"
} Fragment-ktx FragmentManager Now you can describe transactions in a DSL style and the functions and or are called under the hood: beginTransaction() commit() commitAllowStateLoss() fun FragmentManager.commit(
  allowStateLoss: Boolean = false, 
  block:  FragmentTransaction.() -> Unit
) Example: fragmentManager.commit {
  // transaction
} FragmentTransaction Added replacement for method overloads. A similar extension has been added for : FragmentTransaction.add(Int, Class<out Fragment>, Bundle?) FragmentTransaction.replace() fun <reified T: Fragment> FragmentTransaction.add(
  containerId: Int, 
  tag: String? = null, 
  args: Bundle? = null
): FragmentTransaction

fun <reified T: Fragment> FragmentTransaction.replace(
  containerId: Int, 
  tag: String? = null, 
  args: Bundle? = null
): FragmentTransaction Example: fragmentManager.commit {
  val args = bundleOf("key" to "value")
  add<FragmentA>(R.id.fragment_container, "tag", args)
  replace<FragmentB>(R.id.fragment_container)
} Transaction optimization Optimization is a pretty important thing. To figure out how FragmentManager can do everything for us, let's try to optimize transactions by hand. fragmentManager.commit {
  add<FragmentA>(R.id.fragment_container)
  replace<FragmentB>(R.id.fragment_container)
  replace<FragmentC>(R.id.fragment_container)
} How to speed up a transaction? During the most complex technical analysis, we see that, following its results, the user will see . We are simple people and just throw out the extra two actions, immediately showing . Another example is with two transactions running one after the other: FragmentC FragmentC // 1
fragmentManager.commit {
  add<FragmentA>(R.id.fragment_container)
}

// 2
fragmentManager.commit {
  replace<FragmentB>(R.id.fragment_container)
} In this case, we could abort the addition of and immediately add . We cannot do this, but the problem is rather theoretical. All of the above FragmentManager can do on its own. We just need to allow it by adding to the transaction we want to optimize. FragmentA FragmentB setReorderingAllowed(true) fragmentManager.commit {
  setReorderingAllowed(true)
  add<FragmentA>(R.id.fragment_container)
  replace<FragmentB>(R.id.fragment_container)
  replace<FragmentC>(R.id.fragment_container)
} In the second place, you need to set the focus in the first place, because it is her permission to interrupt, and the second, in turn, must be fully controlled: // 1
fragmentManager.commit {
  setReorderingAllowed(true)
  add<FragmentA>(R.id.fragment_container)
}

// 2
fragmentManager.commit {
  replace<FragmentB>(R.id.fragment_container)
} In fact, we allow the to behave lazily and not execute unnecessary commands, which gives some performance gain. Moreover, it helps to handle animations, transitions, and back stack correctly. FragmentManager It is worth remembering that an optimized can: FragmentManager do not create a fragment if it is replaced in the same transaction; interrupt the life cycle at any time before , if a transaction to replace the added fragment has begun; RESUMED cause of the new fragment to be called before of the old one. onCreate() onDestroy() During a transaction, there are several ways to manage the life cycle of a fragment, in some cases, this may be useful. Change visibility We can hide and show a fragment without changing its lifecycle state. This behavior is similar to and . View.visibility = View.GONE View.visibility = View.VISIBLE We can just hide the container. This is true, but hiding the container in the back stack will not work, and a transaction with a similar command is easy. To hide a fragment from prying eyes, just call the method: FragmentTransaction.hide(Fragment) fragmentManager.commit {
  setReorderingAllowed(true)
  fragmentManager.findFragmentById(R.id.fragment_container)?.let {  
    hide(it) 
  }
} To show it again, you need to call the method: FragmentTransaction.show(Fragment) fragmentManager.commit {
  setReorderingAllowed(true)
  fragmentManager.findFragmentById(R.id.fragment_container)?.let { 
    show(it) 
  }
} Destroying the View We can destroy the Fragment's View, but not the itself, by calling the method. As a result of such a transaction, the fragment will enter the state: Fragment FragmentTransaction.detach(Fragment) STOPPED fragmentManager.commit {
  setReorderingAllowed(true)
  fragmentManager.findFragmentById(R.id.fragment_container)?.let { 
    detach(it) 
  }
} To recreate the Fragment View, just call the method: FragmentTransaction.attach(Fragment) fragmentManager.commit {
  setReorderingAllowed(true)
  fragmentManager.findFragmentById(R.id.fragment_container)?.let { 
    attach(it) 
  }
} FragmentFactory In Fragments 1.1.0, we can control the creation of fragment instances, including adding any parameters and dependencies to the constructor. To do this, it is enough to replace the standard implementation of with our own, where we are our kings and gods. FragmentFactory fragmentManager.fagmentFactory = MyFragmentFactory(Dependency()) The main thing is to have time to replace the implementation before the needs it, that is, before the first transaction and restoring the state after re-creation. The sooner we replace the bad implementation, the better. FragmentManager For Activity, the best scenario would be to replace: before ; super.onCreate() in the block. init Fragments do not immediately have access to their . Therefore, we can only perform the substitution between and inclusive, otherwise, we will see terrible red text in the logs after launch. FragmentManager onAttach() onCreate() But it's important to remember that is the through which the commit was made. parentFragmentManager FragmentManager Therefore, if you previously replaced in it, you do not need to do this a second time. FragmentFactory Now let's figure out how we can implement our factory. We create a class, inherit from , and override the method. FragmentFactory instantiate() class MyFragmentFactory(
  private val dependency: Dependency
) : FragmentFactory() {
  
  override fun instantiate(classLoader: ClassLoader, className: String): Fragment {
    return when(className) {
      FirstFragment::class.java.name -> FirstFragment(dependency)
      SecondFragment::class.java.name -> SecondFragment()
      else -> super.instantiate(classLoader, className)
    }
  }
} We get a as input, which can be used to create a , and is the full name of the desired fragment. We determine which fragment we need to create and return based on the name. If we do not know such a fragment, we transfer control to the parent implementation. classLoader Class<out Fragment> className This is what looks like under the hood of : super.instantiate() FragmentFactory open fun instantiate(classLoader: ClassLoader, className: String): Fragment {
  try {
    val cls: Class<out Fragment> = loadFragmentClass(classLoader, className)
    return cls.getConstructor().newInstance()
  } catch (java.lang.InstantiationException e) {
    …
  }
} LayoutId in the constructor Let's remember how we learned to work with fragments. We create a class, create a markup file, and inflate it in : onCreateView() override fun onCreateView(
  inflater: LayoutInflater,
  container: ViewGroup?,
  savedInstanceState: Bundle?
): View? = inflater.inflate(R.layout.fragment_example, container, false) We've typed these familiar strings hundreds of times, but in version 1.1.0 of , the folks at Google have decided they won't take it anymore. They added a second constructor to fragments that take as input, so you no longer need to override . Fragments @LayoutRes onCreateView() class ExampleFragment : Fragment(R.layout.fragment_example) And under the hood, the same boilerplate works: constructor(@LayoutRes contentLayoutId: Int) : this() {
  mContentLayoutId = contentLayoutId
}

open fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?) : View? {
  if (mContentLayoutId != 0) {
    return inflater.inflate(mContentLayoutId, container, false)
  }
  return null;
} The less code we have to write, the better. If suddenly you have previously initialized the View in , it is more correct to use a special callback called immediately after . onCreateView() onViewCreated() onCreateView() override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
   button.setOnClickListener {
      // do something
   }
   // some view initialization
} Summary This article looked at the features and new features of creating Fragments and how you can pass LayoutId in the Fragment constructor. In the next part of the article, we will look at animations during the transition and closing of the Fragment.

Google

Initialized

Super

Understanding Fragments in Android: Part 3

Understanding Fragments in Android: Part 1

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Understanding Fragments in Android: Part 2

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

3 Quick Ways to Optimize RecyclerView

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

3 Quick Ways to Optimize RecyclerView

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps