Manage it better.
Since I started work commercially I met an opinion that working with Fragments is not always intuitive, at least not as much as working with Activities. Especially after watching this video your mindset in context of Fragments might change significantly. Complicated lifecycle, hard management will not change the way of thinking about it.
Few weeks ago I had to deal with really big thing. I’ve moved big app built in 95% on Activities to Fragments. I was very long way, very hard one. I’ve learnt a lot, so wanted to share this knowledge with you.
Toolbar for Fragment. What is wrong with it ?
Let’s assume that we have only one Activity with bottom navigation and the rest of views are Fragments. Normally on every Fragment change toolbar is set as supportActionBar which gives you possibilities to use methods to create, prepare, manage toolbar options menu. It looks simple, doesn’t it?
But it also creates some problems:
- Before creating new toolbar on another Fragment you need to clear the old one.
- If you are clearing it, indeed you are losing state and all data.
- When you are going back to previous Fragments you have to recreate whole action bar.
As you can see it is a very inconvenient process, hard to maintain and generates a lot of boilerplate code. Especially if you are using searchView all those disadvantages mentioned above are unacceptable.
What is the solution ?
Assuming that we have few types of toolbar in app, you can build it using Builder Pattern and handle all cases in one place. All work comes down to choosing options for your Toolbar.
Starting point is to select one of two possible solutions. First one suggests to create one Toolbar and add it from code to your views. The second, which I have chosen is to implement toolbar in every Fragment’s .xml file. Basically, it was much easier for me because it was already done (refactoring code from Activities), so code below will match the second option.
Lets create FragmentToolbar Builder which contains all options we need in our app. I’m using Kotlin to achieve it, but my Fragments are still in Java, so I had to use implementation readable for Java.
Nothing revealing, let’s add those options to our toolbar.
Create BaseFragment which will be inherited by every Fragment.
Finally we are prepared to create Toolbars for our Fragments! Now every Fragment must specify which options will be used or if the Toolbar should even exist. Following the simple example:
To more complex:
Everyone knows how much time we spend on adding menu options and how many lines in code we need to write or copy/paste. This solution saves your time and keeps code clean. No need to set toolbar as supportActionBar. You don’t have to worry about keeping state and data for menu when Fragment changes (it lives as long as your Fragment). To sum up, management is as simple as possible and fragmentManager backstack changes (adding / removing Fragments) has no effect on toolbar at all.
Personally I feel better when I’m dealing with Activities. Working with Fragments pushed me to simplify this process. So when you’ll be in the same situation - don’t fight with it, just do it by your own.
If you like my work hit clap button and let me know what you think in comments!