The Best Architecture for Jetpack Compose in 2020 (WHAT COMPOSE IS MISSING)

in this video i'm going to talk about what i think is the ideal architecture or the ideal way to build your apps if you're going to use jetpack compose in december of 2020 and this december of 2020 thing is very important because as you'll learn as i go through this video i suspect that things are going to change i think things are definitely going to change in 2021 by the end of 2021 i think you're going to see a a pretty drastic change to the landscape of android respect with respect to how we architect our applications and how we build out the navigation first i want to paint you a picture i want you to get an idea in your mind of what an ideal application would look like in terms of architecture and navigation what would make you happy as a developer and make your life easy and i think most of you already kind of think this even if you don't already you're not already like aware that you're thinking this it's it really has to do with the android life cycle fragments and activities and the difficulties that we run into all the time because of the life cycle you know if you think about it most of the hardships most of the difficulties that we run into are because of the life cycle if you do a rotation you know all the data is lost it's not persisted by default you the screen does some weird thing and then boom your app is in some weird state it's because the fragment gets destroyed it gets recreated the activity gets destroyed it gets recreated all of most of the problems probably like eighty percent of the problems that you run into when you're building applications are due to that life cycle it just does weird things and you have to account for those weird things in the event of a rotation in the event of process death it just is not pleasant to deal with so with jetpack composed i think a lot of people are hoping that it's gonna kind of make fragments and make activities go away and it's for good reason like i said most of the problems that we encounter are what happens when you rotate the screen what happens when the process dies how does the the fragment or the activity uh cause issues to your view state how how does it change the view state because of these weird life cycle events that really don't help us they're kind of like just they were part of the framework that we had to deal with you know imagine a world imagine a world where you could open up a view and there's a list of data there you're scrolling through the list you go you know just really scrolling really really far then you decide to click on one and then you decide uh i'm going to rotate the screen at that point what happens is the data still there you know how how does that view now look so maybe now you go back and you go back to that list that you're originally at is that list position maintained is that list position still at the one that when you click that item and you went to that detail screen you know these are things that that you have to manually deal with they don't just get handled out of the box also if you're scrolling the list and you decide to rotate is that list position maintained is the data still there or is it does it get lost all by default all of all of these things get lost on rotation imagine a world where everything was just the same you rotated the screen boom i'm at the same list position everything is exactly the same the data is still there i didn't need to go and get the data again you know maybe i click on one i go to the detail screen i go back i'm still in the same position everything is exactly the same state that's a fairy tale that's a fairy tale that i think all android developers wish was true so right now as of december 2020 i think that jetpack compose is pretty close to being able to accomplish this sort of a build with their composables so being able to essentially get rid of activities and fragments almost completely and only use composables flutter actually does this already which is surprisingly surprising enough the way that they handle navigation the way that they handle you know bringing up their views and maintaining state is pretty ideal you know if you're looking at something you rotate the screen you come back everything is pretty much exactly the same even if you have a dialogue up in view you rotate the screen that dialog is still going to be there list positions are maintained all of these things just kind of work magically which is really in my opinion how they should work but it's not like anybody's faults it's not like the android team's fault or anything like that it's really i think we're just dealing with old technologies that we have been built on top of over and over again over the years and really the underlying problems haven't been solved like why do we even have a life cycle why do fragments and activities get destroyed when you rotate and then get recreated these are this is like a fundamental problem that uh that we have right now okay so now that you understand what kind of the probably the biggest problem with android development is which is pretty much all wrapped around the life cycle how will composables solve this problem and can they actually solve this problem already as of december 2020 well they're very close like i said and here i'm gonna now outline kind of the the major uh issues or the major pain points with doing that currently right now again december 2020 and what i think needs to happen in order for it to move forward and be able to pretty much design an application with all composables which would be very similar to how flutter does it with widgets it's essentially the same thing you build the screen and you have some kind of navigation routing system even navigation components which i'll talk about and uh yeah so let's talk about these problems what are the things that compose can do right now so that you could actually build your application with strictly composables and what are the issues with those those current those current methods first let's start with a diagram so you can just kind of visualize what i'm talking about so suppose we have a single activity in our application now this could be a single activity but we can also do a single fragment so i'm just going to call this main activity also you could imagine that there is you know a single fragment it doesn't really matter maybe there's one fragment in the whole app and that's in the activity but i don't know for the sake of simplicity let's just say it's a single activity because it really doesn't matter single activity single fragments whatever so what would this look like in an ideal scenario if you were using jetpack compose it would mean that you would have a bunch of screens so maybe you have like launcher you know launcher screen let me just draw a square around that maybe you have a login you know screen and these are all composables keep in mind and you know register register screen i'm gonna write fast so my writing's gonna be really bad and all of these are just kind of being composed and there's a navigation system like a custom navigation system that is built into the activity so let's just say let's just call it the navigation graph and that exists inside the activity and that's what manages the back stack that's what manages you know how to get from the launcher screen to the login screen how to get to the from the login screen to the register screen or whatever how to get to any any of the other screens in the application so currently this is technically possible you could do this with compose but what are the issues with this what kind of issues would you run into if you built your application using all composables and like a single activity or a single fragment i think naturally probably most of you will have the the question how do you handle the navigation of course you could build a custom navigation system which wouldn't be that big of a deal you would just have to manage the back stack have some kind of a you know global object that sat at the application level and managed you know what happens uh managing the backstack essentially so that's one way but there's actually an easier way that's already built navigation components has a dependency that you can add to your jetpack compose projects and it helps you to outline you build out your navigation system so very very similar to how flutter does it you can essentially design these routes which are just strings and visit those routes if any of you do web development again very similar to also web development where you have you know urls that visit certain pages it's kind of the same thing you have sort of urls almost quote unquote that live within your application and then you know calling the navigation uh kind of global object and saying navigate to this url and then it would bring up that composable so this is pretty awesome i'll actually show you the dependency and show you the the page in the documentation where that exists so if you go to developer.android.com jetpack compose and navigation this page shows navigating with compose and it shows this extra kind of dependency that you can add i'll actually increase the font size so you guys can see a little better this dependency right here android x navigation navigation compose so if you take a look at this page there's kind of a navigation controller just like with navigation component you can design this sort of nav this global sort of nav host object and have routes that define composable so this would be a route you know the profile route which will inflate the composable profile uh you know the friendlist one which would inflate the friend list and so on so this is this is one way that jetpack compose helps you to design this navigation system with composables so technically you could say that the navigation is a solved problem at this point you could design your navigation using only composables okay now so navigation is fine so that's kind of like point one navigation that seems like a solved problem with composables what about state so what about maintaining the state in each composable because when you rotate the screen that even if you have one activity it's still going to get destroyed and recreated which is going to cause the screen to be recomposed also if you have anything like if you have been using jetpack compose at all you know that changing uh you know a stateful uh composable causes it to be recomposed when that value changes so what happens when yeah when you rotate the screen is that data lost how how can you maintain state in these composables so this problem is um this this one is kind of a tricky one because what you you can't use view models in composables like you can't tie or scope a viewmodel to a particular composable that would solve you know the state problem if you rotate the viewmodel would persist and the data would persist in it and therefore show the data still that would solve the problem but currently there's no way for composables to get tied to a particular view model now this isn't the end of the world this is technically still a solvable problem there is a saved instant state kind of function that you can use inside of composables and you can just declare to the top of the composable at the top level if that composable is recomposed or you know destroyed recreated it looks into that saved instance state function looks for the thing that you saved and it will still be there essentially it will persist so technically this is a solved problem outside of um you know big lists of data of course you can't save big lists of data to the instant state there's a i believe two megabit uh limit on the instant state which is 250 kilobytes which isn't very big it's not a lot of space so you can't save like large lists of data you can't save um you know big data essentially to a saved instant state not even like i wouldn't even call that medium sized data you can't save a lot to a saved instance state so this is this is sort of a solved problem but not really and i think when it when when you really see the rest of what i have to say about compose and like you know all this topic about this video the issue really is it does almost come down to like the view model thing if you had a view model that you could scope to a composable i think this would be a real thing that we could do but i'm going to talk more about that later so so point number two is persisting state in the in the composables technically you could do it with saved instant state but if you have a complicated ui with a lot of stuff going on in it saving everything to the instant state will probably make you reach that two megabit limit pretty quickly and so so really this is like a solved problem but not really a solved problem also what about your business logic where does your business logic go you know currently the current recommended way to build your apps which is the way that i build apps is you have your view model your you know repository or your use cases get injected into your view model and all of the sort of business logic is either in your use cases or in your view model or a combination of both so what happens when the view model goes away how do you how do you handle use cases how do you handle business logic where does that go into composable now for the third point what about dependency injection and i guess also additionally we'll call it a fourth point which is testing what about dependency injection and testing now i know that technically you can do testing without dependency injection just if you don't use dependency injection and you're writing tests it becomes very tedious i guess and exponentially as your app grows it's going to become more and more difficult to write you know consistent tests because you don't have those those those dependencies that are already predefined you're not passing through the constructors it's going to make testing building out tests more difficult especially again as the app gets bigger and bigger it just is going to be more difficult to scale it's going to be more headaches so what about dependency injection and i think this is just where the the the theory of being able to build an app with only composables pretty much just falls apart you can't use dependency injection on composables you can't declare composables as dependencies you basically you know any any dependency injection framework a library dagger hilt coin coding none of them supports you know injecting dependencies into composables or providing composables as dependencies and if you can't do that it makes testing a lot more difficult technically you could do you know manual dependency injection you could build some class that holds all of your pre-built dependencies and you know instantiate it inside of a composable but what would happen is composables are pre-built or rebuilt or recomposed all the time whenever things change whenever data changes in that composable it gets recomposed that would mean that the object that you instantiate aka your dependency container or whatever it is that contains all your dependencies it's gonna get pre-built over and over and over and over again i don't think that would be very good for performance so currently right now i don't think there's any sort of way to do this uh dependency injections with composables is not a solved problem and i guess let's talk about one additional point which is we'll call it point number five is uh what about you know using the camera what about using bluetooth what about using any other sort of android internal hardware component i actually don't know the answer to this i'm actually just asking you guys uh you know how would that look in composables because these things are typically tied to the the you know start activity get results sort of uh system inside of activities and fragments sort of you know almost coupled with the life cycle it's sort of kind of built into that sort of mechanism and the way to do things i don't know how that would work with composables maybe you guys have some ideas but i i don't think that it would work particularly well at least at least yet so overall to summarize all the issues around you know building an app with complete composables having you know one activity or one fragment and then all composables uh first issue is navigation which is arguably a solved problem especially with the that navigation component dependency for jetpack and pose looks pretty good you know you can build a top level navigation file define routes navigate to those composables seems good so that would be the first problem second problem would be state which is i think really the nail in the coffin you don't have any way to persist state in composables you don't have no way to tie a view model to a composable to scope a view model to a composable so that the state in that composable will persist you can use saved instance state but as i talked about there are issues with this you can't save there's a you know a two megabit limit on the things you can save to the instance state so you're gonna you know that's gonna fill up pretty quickly you can't save lists you pretty much at all that that limit is pretty small third issue is dependency injection and the fourth issue is testing so dependency injection again no way to do dependency injection into composables the way to provide composables as dependencies which would make testing especially as your app scales more and more tedious i guess we would say so given all this information all these issues and how we really wish we could build our applications what is the way in december 2020 if you want to use jetpack compose how would you build an application and i think there actually is a really great way to do it a way that is better than the current way which would be you know building a bunch of fragments and much activities using old xml yeah i'm calling it old xml now because we have jetpack compose what is what is the way that i would build uh compose apps today right now let's actually go look at another diagram all right so number one is i would have a single activity i'm going to call it main activity and draw to the top here number two is i would have um a fragment for each screen in your application meaning if you have like a launcher screen i would have a launcher i would have a launcher fragment and that would be its own screen and then inside of well here i'll actually draw a couple of other fragments so then inside of each fragment and of course use navigation component i would use navigation component to find a you know navigation graph inside of the activity and then that would manage all of my navigation inside of each of these fragments we would have a view model a view model so each screen would have its own fragments and its own view model that way the data will persist we don't have to worry about rotations saving stuff or persisting across process death we can just save the view state to the saved instance state and we can restore that and then each fragment will have composables so just like i've showed you earlier in this course we would have composables so maybe this one has i don't know c1 and c2 maybe this one has you know just we'll just call it c3 maybe this one just has you know c4 you could have any number of composables it doesn't matter the point here is we have one activity at the very top with a navigation graph we have a bunch of fragments a fragment for each screen to be exact each fragment will have its own view model that will persist its state and then we have the composables which get their state from that view model so we don't have to worry about rotations we don't have to worry about process death because we can just save to the instance state and restore this in my opinion is the way to build applications using jetpack compose in december of 2020. now there's a couple reasons why i think this is the best way uh number one is all the reasons that i just said you know we we can persist state easily the state can be saved in the view model everything essentially that was in place before can still exist there it's very easy to transition all you would need to do is get rid of your xml and use composables instead you know your your dependency injection stuff would all be the same your activity stuff would all be the same your navigation graph would be the same your fragments are essentially the same because they have the view model and all the business logic is from the view model and then backwards in the architecture so none of that changes the only thing that changes is the fact that you're not going to use xml instead you're using composables so of course there's code changes related to that but if you were working with a big code base you could do it piece by piece you could do it fragment by fragment and all you would need to do is replace the xml this is uh this is the best way i think not only for all of the reasons that i talked about before you know persisting state the viewmodel dependency injection testing but also because it's easy to transition to it's a lot of the current android mechanisms or tools would not change you can still use all of those things so i want to give a special shout out to a youtube subscriber somebody who left a comment on one of my videos i was thinking about doing a video like this one talking about like the ideal way that i think to build an app with jetpack compose in 2020 or right now um but i i wasn't quite convinced that people would want to watch it so shout out to this guy i'm gonna butcher his name i'm sure i'm gonna attempt to say it i'll put it up on the screen here so you guys can see how it's spelt uh no i don't even know nahim najim i'm not sure how to pronounce the j if it's an if it's a or a j sheik that's probably how to say his last name so that's pretty pretty good so let's say nahim sheikh hopefully i spell i said that right shout out to him because he left a comment that said do you recommend using the compose variant of jetpack compose so the comp what he means by the composed variant is that jetpack compose navigation component dependency that i showed you at the beginning of the video and that sort of uh there's a lot there's a lot of things that i needed to say in order to answer that question so i decided to make kind of a full a full video on that so thanks for that question i'm sure a lot of people had the same question you know essentially it's it's that fairy tale thing that we all want to be true can we build an app with all composables do we still have to deal with the life cycle the answer to that right now in december 2020 is yes you still have to deal with the life cycle so having a fragment for each screen a view model for each fragment and then having composables inside of those fragments i think is the best way right now if you want to stick with all the current you know android things that we have available whether it's dependency injection with hilt using view models building out use cases for testing all these things you can still use if you build your app this way so now i'll just finish up by saying that in the future probably my guess would be by the end of 2021 this is going to be a solved problem my guess or my hope i guess is that they somehow scope view models to composables to persist state if that happens it's pretty much a done deal because almost all dependencies are injected from kind of the into the business layer and then from the business layer into the view model and then that's how everything works your ui just looks at the view model and all the dependencies are into the view model so really if they can get the view model to be scoped to composables it's a solved problem you pretty much would not have to use fragments or activities outside of some unique scenarios well you need to have one activity but outside of unique scenarios you could pretty much build your app with composables which i think would be awesome because then you don't have to deal with the life cycle well you sort of do but it's still a nicer way to do it i think in my opinion other than to rather than use fragments which is similar to how flutter does it it's almost the same way that flutter does it you know you'd find the routes the routes define the destinations and so on and so on you've heard it before probably lots of you tried flutters you know so anyway thanks for watching i hope this was helpful i know we didn't write any code in this video but there was a lot to be said a lot of beautiful diagrams were drawn by me and do not forget to leave engagement go down to the comment section right mitch here's your engagement come and eat your delicious engagement write something weird something funny i've been enjoying reading you guys comments about engagement so don't forget to do that don't forget to leave a like thanks for watching and i'll see you in the next video you

Channel: CodingWithMitch

Views: 12,446

Rating: 4.9501781 out of 5

Keywords: jetpack compose, jetpack compose android, android jetpack compose, jetpack compose architecture, jetpack compose viewmodels, jetpack compose problems, why use jetpack compose, is jetpack compose production ready, jetpack compose fragments

Id: Gi-MnWDRcmQ

Length: 22min 56sec (1376 seconds)

Published: Wed Dec 09 2020