Duration 45:39
16+
Play
Video

Android Jetpack: how to smartly use Fragments in your UI

Ian Lake
Android Software Engineer at Google
+ 1 speaker
  • Video
  • Table of contents
  • Video
2018 Google I/O
May 8, 2018, Mountain View, USA
2018 Google I/O
Video
Android Jetpack: how to smartly use Fragments in your UI
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
87.89 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Ian Lake
Android Software Engineer at Google
Adam Powell
Software Engineer at Google

Ian is a software engineer on the Android Toolkit team, working on Architecture Components and Fragments. Previously, Ian worked in Android Developer Relations at Google and, before that, built Android apps at Facebook and Phunware. Ian has a MS in Computer Science from University of Southern California and a BS in Computer Science and Physics from Montana State University.

View the profile

About the talk

With Architecture Components, the role of Fragments has evolved. This session will explore the changing responsibilities of a Fragment and talk about ongoing API changes.

Share

Tell everyone good morning and welcome to fragments in an architecture components world. So over time fragment API, so it's kind of involved and as of the release of architecture components a lot of people have been asking of questions like Siri, how do all these things fit together? So hopefully we'll be able to answer some of those questions today, but first just a little bit of History like the fragment apis go back to 2010 was when they were first initially written 2011 when they had so little bit more widespread availability and really kind of comes down to the idea that at the very

beginning everybody just kind of started with the activity when you're writing Android app. It was kind of your main method with a life cycle. It's the entry point to your application from the system. The launcher will launcher activity you get on create on start resume Etc events that you all know and love no Cream reviews for you to create the window like gives you a place to inflate your view hierarchy where you do most of your you I work at Barnes The View content from your apps to release. This is where people tended to do it. Keep in mind that this was fairly early on an Android

public life cycle here. Everybody kind of had this habit of piling everything into one activity because I have for a lot more simple than they are today. And of course you listen to you I events and update that App State from there as well. So there's so many incoming events. It's really kind of became his Plumbing exercise to try to break it up yourself. So people ended up with these very monolithic activities. And then something else happened to Android tablets kind of became a thing. So we kind of thought you know, how do you make a tablet UI well take one phone UI you take

another phone UI and you smack him together and you have a tablet UI right? I mean what could go wrong? So we needed to answer this question of how do I stick to phone Eli's together and make sure that it still works on a phone. And fragments for kind of our answer to this question. So as an example here this approach actually worked pretty well for some applications. Gmail's a great example. So if you take a look here, you have the list of conversations to your conversation that you're taking a look at and there's not a whole lot of difference here between the the phone

version that you drill into versus something that you can show side by side in a to paint ey so fragments were really designed to make sure that you could do one thing and that was to allow splitting up these huge activity classes. This was something that again we were seeing the pain that developers were feeling that their activity class. We're getting really big and hard to manage. So we wanted to see couldn't we allow for you to decouple some of the various things that your activity classes are doing to deserve relieve a little bit of that pressure. So that

means that anything a fragment can do or anything an activity can do a fragment had to be able to do too and that guy did a whole lot of the API design from the beginning. That man that you needed to have life cycle events that needed meant that you needed to be able to manage a view hierarchy. A man that you needed to be able to deal with saved instant state. So packaging everything up into a bundle order parcel the bowls so that if your application got killed in the background you could restore from that in a clean way. And other things as well, like known configuration instance

object passing and that's always kind of a mouthful but I mean this is kind of the way that you can pass any old object back and forth across a configuration change that doesn't actually kill your process. BAC stock for another really big one because suddenly if you were dealing with a single activity where you were navigating between fragments we wanted to make sure that we preserve that same back sack behavior that you're used to from. Just calling start activity from screen to screen. so Along the way we ask question. Can we fix some other apis that we're really kind of a pain in

the neck in Android to use On retainer non configuration instance again kind of a mouthful this method kind of had some problems because you only got one object that you can pass from activity and since activity and we didn't give you any easy or standardized way to Multiplex different objects together. So for example, if you were composing multiple libraries, we didn't give you a whole lot of help. This was all boilerplate that you had to write yourself. Activity show dialogues anybody remember this? A few people. Okay, please

please. Please forget it away to get the activity itself to sort of do something that we knew was with missing and kind of a pain in the neck. This allowed you to make the activity on the other side after a configuration change the nuances of your activity reshow. What is semantically the same dialogue? Wheels are displaying local activity manager tab host. Does anybody remember this one? Wow, that is a lot more hands than I thought I was safe. So some of you might remember this from for example, the original I'd dialer and contacts app

back into the Android 2.0 days. And as you've swapped between tabs between the the normal number pad in your contact list or call log Etc actually separate activity showing within a smaller window within an activity this idea of nesting activities with something that we started offering very early. It had a lot of other issues though activities made a whole lot of promises that look like tivity manager had a lot of trouble trying to uphold so we wanted to try and tighten that interface a little bit better for something composable like fragments that would be able to do the same thing

with a little bit more expected Behavior. Right. So this whole idea of being able to break up your activity and make it into a kind of composable pieces. Now, we have this giant Model S of an activity and there's other methods of kind of factory it out into different pieces, but for fragments basically approach was you move that Loosely related code right those View and all of the states around that view into a separate fragments and you basically just keep doing this until you've kind of segmented out your activity into something that looks slightly more reasonable, right? You

may have a couple of fragments in here that kind of have their own specific requirements and their own specific URI and your activity just becomes more of a shell for this. But soon after we started getting into this and then when it came up to round Jelly Bean on people were like but this isn't enough like what if one of my fragments has a viewpager in but also has fragments as he's one of those pages so we got into this. All right. Well now let's break up the fragments into smaller pieces. So, of course, you know, it's the only way well if fragments aren't enough

then you just add more fragments in this case child fragment became a thing. So now each one of these fragments could then be broken up into smaller pieces. So this a lot of the kind of again kind of D couple things and we built a lot of code around trying to make this nested State work really well to varying levels of degree of success, but it's gotten a lot better over time. So with these things in mind every one of those fragments whether it's a small thing just managing of you or if it's a retained instance

fragment every single one of these fragments give you life hype cycle hook every single one of them has that stack management associated with them every single one of them has a retained object that I can do a cost configuration changes and all of them are stored safely in your fragment manager. That means that the existence of that fragment is actually part of the state of your out. So when you're out dies and comes back that existence in the fragment manager is actually a really important part that at least from fragments perspective that we're going to do on your

behalf. And of course, they all have their own ability to have a view subtree that piece of your UI that they manage themselves. And of course, we also allow things like fragments being inflatable and put it right into your XML files and be able to reuse them across multiple layouts. And again, this is also kind of hooking into these same processes, but the biggest issue we found is that all of these fragments do all of these things. at 1 whether you want them to or not

and most of the time you're only actually using one or two of these things and not the full 16 things that fragments do that you get a kind of a bundle of deal. So that means that some of these things like the state full restoration means you have a lot of patterns that look like this where you have to make sure that the fragment manager is in the right state. So in this case, we're actually checking well at all, right, is there no save Denson State I eat are we in a fresh run of this activity and now I need to add my fragments to my life. So if

you've ever gotten this approach re of one fragment over another one, yeah, that's is this kind of state full restoration actually being something that was a useful bit. But at the same point like maybe not exactly what you were expecting or something that you even wanted in some cases but for fragments you kind of got all of them together in a package deal. But last year, we kind of took a more holistic approach to how we do API on this really kind of started with a lot of the work we did on architecture components. So all of the

architecture components have really tried to focus in on doing one thing. Well rather than being kind of the kitchen sink Kaizen approach. So for example lifecycle observers the ability to have light cycle and that on resume on start as kind of a piece that is completely independent from other thing something that you can register. Just if you care about life cycle. Similarly for viewmodel you created a new primitive a new object specifically for that kind of retained instance States across configuration changes. And of course this year just yesterday.

We announce the new navigation architecture component. I'm kind of working out they have much higher level architecture on how you build your UI and put these things together and I'm really trying to tackle just be specific problem of how do you move from one screen to the next screen all these things were kind of really focused on doing one thing well, and we're trying to bring a lot of that to fragments but that means that you know, we kind of have a lot of legacy to go along with that. So part of this is that fragments were really designed around this idea of very loose

dependencies and loose guarantees about some of the interaction between them. So another kind of quest for the audience how many of you know, the answer to this question does a child fragments on create method run before or after its parents on create method how many of you are confident that you know the answer? Not a whole lot. No idea. How many of you thought you knew the answer before I asked the question and then you started questioning yourself. Yeah, okay. I'll fully admit that sometimes I have to double-check this

as well because the answer really kind of depends on whether the parent is an activity or if the parents are fragment. What version are you running on? Are you talking about Android. App. Fragments or the support Library fragments because the answer has been different over time. We've changed this around and if you were trying to design a fragment that worked across all versions of Android that was writing to the framework fragments you had to deal with these rules kind of changing out from under you a little bit you couldn't count on anything. So one of the things that we allowed for here

with lifecycle observers is that we really wanted to give a very strict ordering of the callbacks strict last in first out callback ordering for all life cycle observers in any given life cycle. This is important because it means that you can set up dependencies between lifecycle observers and use life cycle of servers as the implementation details of a particular activity instance or fragment instances case, maybe you can make sure to maintain guarantees between certain lifecycle event. So that any other life cycle observers that other libraries you may be using can take advantage of those

guarantees that you configured. Lifecycle observers are created by you. We don't try to recreate them by a reflection which means that you can use any sort of creation pattern that you may find useful within your app. So it seems like a really small thing but it was a big piece of feedback that we got with fragments. The implication of that though is that you no longer get stateful restoration by the system now again in some cases, this is exactly what you want. You want to make sure that you have a single control flow path as your configuring what your life cycle

observers. You don't want to be checking. Hay is my instant State going to bring this back for me. I don't end up with two of these things so on and so forth. Right. So one of these really common patterns that we saw a lot of app developers using is actually a headless fragment a fragment without a UI that was used basically only to receive on start on stop lifecycle event. So for a lot of these kind of approaches lifecycle observers are going to give you the same kind of API service, but with a lot smaller kind of API that you

don't actually need all of the things of fragment. So what is this actually look like? You might have just a simple life cycle Observer that does analytics call send your analytics Library might one on start on stop of a particular life cycle. So the thing here is that this is an independent piece from fragments from activities that has a couple of super important things in that one. You can test it independently. You don't have to spin up the whole world just to test this piece. You can text it in isolation also because you

can create this Observer you can use whatever methods you want. If you want to use in your dependency injection kind of model and injected in your dependencies like that is really easy to do in this model rather than trying to do it in the scope of an activity or fragments are doing that kind of thing. So it gives you a lot more power to kind of split out listen to it composable piece. So if you're building a library, you can just use this same lifecycle Observer across all of your fragments are all of your activities and not have to duplicate that data or

worry about like, okay. Well what state is my instant stay then you can just always stay at the Observer and we're done. It's no more no more work you need to do here. So that offers a lot simpler alternative for this specific use case. I forgot some glowing slides to get there. Okay? Silver cane distance fragments were really designed to outlive an activity. These were basically just a set her on a fragment to say hey and state across across configuration changes.

This was a pretty useful thing because it meant that you could save handles too expensive data or operations. You start some sort of query that might take a little bit to complete you don't want to restart that just because somebody rotated the screen or something. Resized. It meant that you can reconnect to the same operations after that configuration change. But really please don't DUI during this this was another one of those kind of headache pain points are two things fragments do everything all at once. But these were two things that really did not taste great together the

reasoning for this is of course that views hold onto the contacts that created them. Well what context do you use to create views most of the time while it ends up being the activity you don't want to hold onto a reference to an old activity after a configuration change ended up using the same views now technically it's possible to do this, right? You can go ahead and drop all your references in on Destroy view recreate the view after after you come around the other side. This was way too difficult to to get right all the time. Just because references to these views end up leaking out and

getting everywhere no matter what you try to do. So this was something that was it was really just kind of gun waiting to waiting to hurt people. But of course in the architecture component world, there's a different solution for this retained instance pattern and that's comes in the model of view models. I'm so this is kind of a brand new class and be honest. The class doesn't really do a whole lot. It's how it connects to the overall system. So instead of being Again part of the fragments apis, this is a more general purpose thing something that you can attach to

any activity or any fragments or any viewmodel store owner. If you're building your own framework and the main thing that's different here just kind of like the life cycles of hers is that we are not the owner of creating those objects. So by default, we provide a factory that just creates a new instance or trade to new instance and attaches your application context to it. But the same point this is a super powerful hook for again kind of adding in those extra. Dependencies. So if you're using dependency injection, like again, you have kind of the

hooks. You need to hook into the viewmodel creation and passed those in just as a Constructor parameter really doesn't need to be a more complicated structure than that. So but you got into the same problem of like, okay. Well, how do I connect my UI? And the other piece of the puzzle here is a different architecture to find a called live data and data is kind of all about a life cycle aware of the server. So in this model in this world, your view model is the one who storing the data, right and it's the live data that

it has that it can then pass to the activity or fragment as they get created and recreated and that fragment or activity can just observe the live data theft model. This model kind of separates things out wear instead of it being the view model that needs to hold onto a reference to views the activity. Can I pull the information out of the few model? So I think for a lot of use cases where you're using a retained in some states specifically to kind of store this expensive data and do

that kind of work do models offer really good alternative to retained instance fragments. So what's a super simple one look like? Well, in this case we're going to use an Android viewmodel. So here we get a reference to your application your application context. I'm so this is really useful. If you're doing things like a service locator kind of pattern, but the important thing here is that the view model stores and incidence of a live data, in this case. I live data that has a list of our fancy names expensive data class

from a room database simple or end database. But you can really get the stayed up from anywhere or set up kind of the correct lifecycle event here so that your life data can kind of get into the right state. But that means that your actual fragments or activities don't need to know where this data came from brightest encapsulated in the view model. And again when the same thing where we can now test this view model in isolation, you don't need to create activities. We don't need to create fragments to get to the same. Do you model we can just

use them in isolation and make sure that all of the work we need here to get her expensive data and make sure that it's in the right State can all be done kind of separate from the actual you buy pieces of the frame. All right. So everybody's favorite topic when it comes to the fragment apis fragment transactions because this is a statement that said by, you know, pretty much no one ever Franklin transactions are asynchronous by default. If you call commit on a fragment transaction, then that ends up getting posted for later

and it'll occur kind of on the next normal Handler pulse of your main thread or if another life cycle event is coming up we'll go ahead and execute all the pending transactions bring it to a consistent State before we move to that next day. Did they actually have a few benefits do it believe it or not for as much as everybody gets kind of frustrated about it. And the biggest one is that you don't have any reentrant fragment operations. This means that if you end up manipulating fragments within Sadie on Creative another fragment, then you don't start getting into a state where you have a

half initialise fragment while you're waiting to bring another fragments up to speed. Now this is a sort of countless bugs. I think that it was even just earlier this week last week that we were helping developers troubleshoot some other re-entrant Behavior bugs that we're coming from view call backs for example, and can be really really subtle and the asynchronous fragment transactions sidestep all of it. And that was kind of convenient the drawbacks, of course that the observe State at any given point in time doesn't actually reflect any of the cube

transactions. So this is a huge problem. This basically means that if one piece of your code Samantha fragment transaction another piece of your code tries to read something out of state that fragment would have set up for you whether that's another view hierarchy that would have gotten attached to its a service of hierarchies hear you why or whether that's just some data about a pending operations. They for one of these retained instance fragments. This essentially means that you can't trust anything about the current state of the app. It means that you can have various data races.

Just within the normal main thread Handler of your application. We've even seen people running to the issues of sort of the Laird fragments on top of one another because of this issue because they were checking the fragment manager to see hey, what is my current said you I paying for example, that's currently there. It's a towel look nothing. I don't have anything to do. Let me go ahead and make a new fragment transaction and stick something there. But there was already something in flight. So this was something that was really kind of a pain in the neck and everybody loved when they come

it Now API was added because it let you do something right immediately as long as you promise that you weren't going to do anything with your current fragment manager as part of that transaction. But we kind of get to this point. We're okay. Now, we have all these fragment transaction code in your out and very subtle changes that you may not pick up in a simple yell all the time. They're changing the whole behaviour of your out and we really took a look at this and we said well, like should you really have to be writing all of these fragment transactions by hands

like 4 or so many of the use cases we can do a little bit better here we can do a lot better here, especially for the really common cases. So we built navigation brand new architecture components. It's really kind of focused on that screen to screen transition between fragments or other you like pieces. I'm cuz we really wanted to make it work. Well with fragments on fragments are a really great way of getting access to my cycle observers and view models and also, you know being an owner of a view and those are really kind of the main pieces you need. when you're trying to build a

good Android app at the same point we realize there's a lot of things that fragments do that. We don't really want you to have to deal with yourself. So one of the things with navigation that we're really focused on was actually being able to take ownership of the back stack make sure that the navigation component can actually handle that back stuff for you. Whether using fragments are using something else the ownership of that backs that kind of lays with navigation that gives us a lot more flexibility and a lot more ability to you.

I'll be a little bit more prescriptive a little bit more opinionated on what is a good thing to do. And what's a not so great thing to do and kind of give you a lot of the same power of fragment transactions without actually having to touch one with your bare hands because again, we're trying to make things so that you have all of the Power without Necessarily be headache and the problems that run across some of the things that Adam pointed out. So we're going to be talking in detail about navigation tomorrow morning

at 8:30. I know you're all early risers, but I wanted to give you a little bit of evil kind of how simple this could be us. We actually offer a helper method where if you want to click a button and do a full screen transition to another fragment. We have a great navigate on click listener that literally does does that all you need to do is pass in the ID of one of those destinations that you set up in navigation. Now this looks a little bit magical. So what is this actually doing under the cover? Well, really what it's doing. Is it using this nav controller object

and one of the things that I find super useful about navigation is you can actually find that nav controller from any of you or any fragments that's been created by navigation. So here in which makes it a lot easier if you're in the devil and it's just a static method but here we can find from any of you we can just a find out controller and get it instance of are now controller and then just call navigate and this navigate call knows how to do fragment transaction. So are now controller in this case is set up with a

fragment Navigator our own class that knows all about the correct behavior of doing fragment transactions and how to do all of that work for you so that from your codes for spective. You can just call navigate and we'll do the right thing for you. So obviously there's a lot more here. Like if you want to pass arguments like you can do a bundle approach. We also have a lot more things around that specific case that will be talkin about tomorrow as well. I'm as well as setting things like separate animations and other objects in here. So you have a lot of the same power, but you can also make

it really easy to use and move a lot of the code that used to be a fragment transaction that you'd have to make you really sure that you got right into something that navigation can understand and helpless. So Adam talked a lot of things about why not fragments, but this is kind of a fragment talk right? So what why is my 2018 it is 2018. So what's what are fragments is still good for after we serve carved out of some of these other extension points. So before we talk about that, I think it's kind of important go into a little bit about the package layering involved in the Android

framework specifically Android. Widget versus Android. App. Android. Widget is really kind of designed to hold all the mechanism for your UI. That means that this is all the stuff that shows state to the user and things that reports user interaction events back to other high-level portions of your app. And really that's it anything that's in the widget package is really meant only do these two things are as Android. App, which is where fragments live activities live. So on and so forth. That's where your policy goes. This is what defines what states to bind to widgets. This is what

defines how you should respond to those user interaction events. And how did Issue changes to your data model any kind of it. Later or above no matter how you may Factor it this kind of how it how it breaks down. So it's also brings us to this idea of inflatable components, which is something that comes up quite a bit since you can inflate a fragment from a layout people found out really quickly that you can use a fragment so I can post some of your views together and create basically like a custom you but with a fragment and really some of this kind of comes in because people start asking,

you know, just if this view had a life cycle I could do something but really you kind of want to use that as a as a stopping point and just kind of ask yourself like what is it about this particular view? Remember mechanism only that needs a life cycle. You should really only be showing data that they're given or publishing user interaction events if user clicks touches or performs any other action on the on the views themselves. None of these things need lifecycle events to accomplish that goal. So you should really kind of watch out and figure out. Okay. Do you need some sort of

policy layer that sits above that? This is where fragments are really useful because you can compose them of higher-level controls. It means that they can be self-sufficient. They have their own life cycle. They know how to hook into some of these things. They need it means that inflated attribute can actually become fragment arguments. So you can make these thing as a super self-sufficient and Implement cross-cutting UI policies that you don't have to worry about in terms of like for the overarching top-level parent context. This ends up being really useful for things like I mean even just

something as simple as at something where you really do need to control for for life cycle about when a user comes and goes performer request out to the network to its effects the content that you're going to show but really you don't want that code getting all over throughout the rest of your application logic. You can use this for other sorts of like independent info cards things that are again fully self-contained. And the parent doesn't actually need to be involved in any of the data routing from your central repository or whatever other sort of model you're using under the hood in

order to get that on-screen and get the user interacting with it. So one example of using the fragment Arguments for this is on screen here. We can probably benefit from some extensions or helpers, but overall it's it's not too bad. If you define styleable to go ahead and play some of those arguments assign the values of the bundle set it there and then you can route all of this logic through your normal fragment argument handling. It appears throughout the rest of your fragment implementation. One of the other accused cases that we found really useful for using fragments. Is

this kind of apple screen kind of model so that where a fragment is taking the vast majority of the screen. It's really the main content of your app and this is really kind of where navigation comes in and really kind of takes away a lot of the rough edges of fragment. So you're just left with your extra component hook and a view. Self in this model. It's a lot easier to move towards a single activity out. If you listen to chat yesterday on this is kind of our recommendation going forward. I'm too kind of views activities. This is an entry point

into your app. And then your content the actual things that the UI the pieces that developer users actually worked with our key fragments of your a flight. The actual content is in fragments. So with this model, the only thing the activity needs to do is handle kind of common app from so if you're using an action bar still or if you're using like Bottom now for a side now have to be good things that the activity can manage but the rest of it can be decoupled destination decoupled screens. All of these fragments can be much more independent from

one another rather than being tightly coupled together. So this allows us to kind of move a lot of the things that normally you'd have to deal with manually into a system that we can help you out a lot more on so4 navigation. For example, I'm weird going to give you the hooks that you need to set up their Transitions and animations needed to transition between the screen and it's something that can be done and navigation rather than something you have to do by hand. Of course, like these aren't mutually exclusive right? You can still add a fragment to

your layout or have nested fragments underneath these things. So it's not an all-or-nothing kind of approach. It's just one method that yes, this larger kind of content-based fragments is still really good way of kind of Bridging the Gap between the Android app world and the widget world. Another excuse case that is still super useful is around dialogfragment. Again, we talked about kind of the activity show dialogue. I hope everyone forgot that by now but a large fragment is really kind of the same approach wear

instead of it being something that you need to manage and make sure is visible Are Not Invisible. I'm in really kind of helps encapsulate the interaction between a floating you I like you have a really important question to ask. The user a dialogue is probably a useful case in some manner but it's also something that we started to see a lot more in Android P for instance. The biometric prompt for fingerprint is now something that is in a dialogue kind of model. So this is actually something that we found really useful. I'm part of it is

that we can leverage some of that instant State restoration that you got for free as part of fragments with your dialogue. This means that you've asked a really important question. Otherwise, why would you show a dialog on an interrupt the user but you really don't want that to disappear when you resize your screen on the pixelbook or rotate your device on your phone. It's a really important question. We want to make sure that we do some of this insensate restoration for you. At the same plant light dialogues aren't just a floating UI, right? There's also

bottom sheets and bottom sheet dialogfragment. I'm specifically built around kind of having different kinds of floating, ui's you eyes that live above your main content on without necessarily being just the elect in the background kind of traditional dialogue of your so we really trying to get to this point. We're yes using a dialog fragment is great. If you had this DUI that you really don't want to lose but it's really important for the user know obviously for things that these are good news could lose. It's probably not a dialogue. Do you want to use this?

Probably a snack bar or another approach here? This is my favorite part. Dialogfragment. There's literally nothing more you need to do you call show or show now for the synchronous method and that's it very much kind of this model where we're going to do the fragment transactions for you again, like we don't want to be in a model where you have to do a lot of complicated work yourself for a dialogfragment. You can literally just tell show and it'll do the right thing and it'll get you back into the right States.

Alright, so one of the other things that people tend to use fragments for quite a bit is managing options menus and specifically merging some menus into some common into a common tool bar into an action bar Global to your activity Support options menus because activity Support options menus this kind of calls back to that initial design goal or fragments had to be able to do anything that an activity could do. And the most common use case in this today is for calling set support action bar for your toolbar, which of them served Vines whatever your current context is 2 to a particular

to a bar within your UI. This is really great. If you have some fixed common Chrome, so in the navigation world, if your toolbar never changes between screens, then this is really handy because this means that you can populate that with whatever actions are relevant for what's in your main content. Fragment pager adapter is another really great one that people use this for quite a bit if he actions change across Pages then all of this is just kind of handled for you. This system takes care of it. Now that the alternative to this is that you can go ahead and directly manage the menus as

toolbar view data. So most of the time today you're you eyes are such that the toolbar or other sort of mini management is really kind of part of the contents. I mean, this was something that you saw back in a lot of Holo UI is where the action bar was always fixed common crumb, but now you have these collapsing half our layouts and things are much more sophisticated to the point. We're doing this sort of global wire up is almost jumping through hoops that you don't really need so don't make it more complicated than it needs to be. If you don't have common Chrome for this then directly

managing some of the toolbars menus as view data is a simple as this like it's a couple lines of code. There's not a whole lot to it you inflate your menu you attach a click listener and you can keep all of this a little bit more self-contained rather than having this leak out into the whole activity options menu at that point. So one of the other things that we could ask the waters about testing fragments testing fragments is a whole lot easier than texting activities. You don't have to spin up the entirety of the world and an entire new activity with

sore back and forth in an instrumentation test to the activity manager to make this work the nice part about this is that from quite a few years ago. We've had this class fragment controller that is able to drive the life cycle. So you can go ahead and you can create just a test fragment manager test fragments the controller that can test those larger fragment components in isolation away from everything else that might be happening in the activity manager. We usually pretty extensively for the existing support Library test ourselves. Now, we make this possible, but truth be told this is

really not the best interface for doing it. It ends up looking a little bit like this or you could go through some of the support Library tests in AOSP and see kind of example of some of the utility methods that we set up for this. New we should really probably wrap this in some better move to States type of method. This is one of those cases where we we falling into a trap ourselves of some things possible. It's maybe not great the rarest kind of left as an exercise for the reader in the week kind of just need to do better on this park. Yeah, so one of the other pieces that kind of came

alongside of fragments more from a convenience method than anything else were loaders a kind of precursor to a lot of what we've done in architecture components on doing retained its in States and one of the things we've done recently actually tried to decouple them from fragments. So how do we actually do this? Well, instead of being their own special thing actually rebuilt them on a lot of the architecture components using these New Primitives we have of live data and viewmodel to kind of make this a totally independent think so now you can actually use loaders in any life cycle

owner. If you model store owner class self activity fragment, if you're building your own kind of thing, it works equally well in all of those cases. so what does this mean well it really just means that you have the same loader you always do but instead of calling that support fragment or loader manager if you can just call that instance and will do all the hook up for you we know that you're in a lifecycle Observer so we know how to hook all that stuff up for you and Yuri we really were able to kind of cut out a lot of the stuff a lot of the custom Behavior here so that you'll be

can kind of rely on these new things to give you stronger guarantees around life cycle So we talked a lot about fragments and we talked a lot about fragments in the past and we've talked about fragments in 2018. But there's another question where we going with what are we still have to do? So some of this is just coming down to building in those stronger guarantees trying to separate the desired Behavior things that we specifically set out to put in versus incidental behaviour or behavior that has just been around for six years and it's

not necessarily something that is a codified standards. We're trying to move towards more of a model where you can be very confident in exactly what's going to happen when you're using fragments. Another replace is trying to do the same thing with that we did with loader manager in in re implementing some of these existing apis on top of these New Primitives for example, like being able to rewrite a lot of the internals of fragment. So they're actually using lifecycle observers under the covers right? These kind of things allow us to kind of make sure that all of our components are

on the same page and really doing the same thing. So if you other things again trying to move towards the world where we have the correct set of signals and activity called back so that any interested components can be a that means that fragments are not a special snowflake anymore. They're just another component another tool in your toolbox using the same composable hooks that you always have the really trying to play well with other components so that it's not an either-or. It's a belief that we can work together

that you can use fragments alongside other components and it just works. All right. So options menus Air Force one other thing that we still don't have a great answer for this in terms of how we want to decouple this. I mean in a lot of ways I would like for options menus just kind of is a concept to be deprecated. But for right now we still need to make sure that we meet all those same use cases for when you do have common Kromer for when your paging through some different content. Next one may be. Okay. So

Android manager sum of even noticed is now officially deprecated. So no more of this kind of behavior changing out from under you having a design against different variants of it just works a whole lot better in the Android X packages and support library before it because this means that you no longer have to worry about all the bugs that were fixed over time allows us to make larger changes in behavior. And if you please send us your wish list for the things that you like to see us do for some of this too. We are going to be over in the sandbox area right after this, so please come say

hello. Tell us what you'd like to see next and thank you very much for coming.

Cackle comments for the website

Buy this talk

Access to the talk “Android Jetpack: how to smartly use Fragments in your UI”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “2018 Google I/O”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “Software development”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
159
app store, apps, development, google play, mobile, soft

Similar talks

Yigit Boyar
Software Engineer at Google
+ 1 speaker
Chris Craik
Software Engineer at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Romain Guy
Senior Staff Software Engineer at Google
+ 1 speaker
Chet Haase
Leads the Android Toolkit team at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Rachel Been
Creative Director, Material Design at Google
+ 2 speakers
Josh Estelle
Software Engineer at Google
+ 2 speakers
Rich Fulcher
User Experience (UX) director at Google
+ 2 speakers
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Android Jetpack: how to smartly use Fragments in your UI”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
558 conferences
22059 speakers
8190 hours of content