Should You Use a Navigation Library in Jetpack Compose?

hey guys and welcome back to a new video navigation in Jetpack compos is difficult especially when it comes to choosing what you should choose for navigation because there are so many different options and libraries out there on Instagram I made a survey sometime ago what you use at work what kind of navigation approach in Jetpack compos and the results were really mixed 36% of you said you are using a library to do navigation 43% said they are using the normal jetpack navigation which comes from Google and 20% set they are using using their very own custom navigation system they've built and in this video I will go through four approaches of handling navigation in Jetpack compos and highlight their advantages and disadvantages and at the end I will then give you a clear recommendation what you should do in your situation so the default navigation library for compose is pretty bad because it uses routes for navigating to different screens which we know from web so simple URLs these routes are just strings however Android isn't web on Android we're typically in a lot more typesafe environment and we also often have to pass around complex objects and navigating with routes makes that really hard to pass around these complex objects unless we really serialize them on our own and to fix this problem there are just plenty of navigation libraries out there nowadays a very popular one I already covered on my channel is called compos destinations which makes use of annotations and code generation to on the one hand reduce the boiler plate code of our navigation code by a lot and it also allows us to have type safe navigation arguments even with Pur levels which the normal navigation library from Google does not allow us to do but there are also other popular alteratives like Voyager or decompose which also support coton multiplatform so you can have one place where you define your navigation logic and then share that between multiple platforms on the one hand libraries can of course make our life easier but on the other hand they are still libraries and we shouldn't just blindly flood our projects with the libraries especially not with third party ones but let's now talk about about the raw facts and I want to start with the official way of navigating and that is with Google's Library which is just called navigation compose so the clear Advantage here is that you don't have to use a thirdparty library to implement navigation because it's very unlikely that Google suddenly stops the support for this library and that is something that can just happen with third party libraries and also the documentation about navigation compos is really good you will find plenty of examples about this out there because it's probably just the most popular way of navigating and since it is what Google offers us it also allows us to just customize it to our needs coming to the disadvantages of using the official navigation library on the one hand as I already said it relies on these route strings and that on the one hand can just lead to routes that are very hard to read because you have very long strings with lots of placeholders that you put into these for navigation arguments and these navigation arguments are in type safe so when extracting these on a different screen then you have to know what type a specific navigation argument is otherwise you will get a runtime error also the the official Library does not support passing around complex objects in form of a person LEL for example that is simply not supported if you want that you have to implement your own kind of solution with a serialization strategy maybe Powers an object into adjacent string or so but by default the library does not support that and last but not least the library just comes with a lot of boilerplate code even implementing a simple navigation between two screens involves a nav host involves these composable blocks it involves specifying which arguments you have what kind of how how these arguments are actually received on the other screen there's a lot of code involved for very simple things so let's go over to approach number two using a navigation Library so this could be composed destinations this could be Voyager this could be decomposed using such a library has clear advantages on the one hand you have much less boiler plate code usually because if we take a look at the library compos destinations it actually uses code generation so you really only have to work with with some annotations you say hey this is a screen this is a screen and the the library generates all the code you don't need to write on your own behind the scenes for you so this leads to an overall clearer code base and makes your code easier to understand and also libraries typically have more features by default for example passing around types of arguments is a typical feature that these libraries add but also more advanced screen transition animations that is something the official composed and navigation Library still has its issues with so there are only a few very basic animations you can perform at the moment but these more Advanced navigation libraries let you choose how you want to animate the transition to a different screen and a big Advantage is of course that some of these libraries like Voyager and decompose support cotland multiplatform so you only need to Define your navigation logic once and you can reuse that for iOS for Android for desktop and later probably even for web but using libraries also has disadvantages of course on the one hand if you're using a library that involves code generation that of course leads to some extra build time especially when you have libraries with code generation ation um also typically known from room or dagger Hill then it's very common that you run into build errors because of that code generation and the more Gradle confli your project actually has for example you have a multimodule project where you have a lot of Gradle files and then a lot of modules you have to use this code generation from a library the more likely it also is that you will run into build errors and last but not least you just got another third-party Library even though it's probably unlikely for these very popular libraries which are used across the industry but if the authors of that Library decide to stop the support you will have to migrate your whole project okay so far so good let's get to the next approach how you could handle navigation and that is building your very own navigation Solution on top of composed navigation on top of the already existing library from Google of course that has the clear advantage that it's tailored to your needs to the needs of your app specifically also you don't need any third party libraries because you have your very own codebase and your very own logic of just making that whole topic of navigating easier and you're also only minimally affected by changes to the navigation library and I think the disadvantage to the solution um should be pretty obvious and that is of course that it takes a lot of initial effort to build such a custom navigation system and also you of course need to keep everything in check you need to you need to test that everything works which otherwise the authors of a library would of course do for you and coming to the last solution you could pick which also a lot of you wrote me on Instagram that you are using that at work is just using fragments with XML navigation and then using composed views in these fragments so each of your app screens would still be a fragment but you still build the UI of each screen in Jetpack compost on this solution you wouldn't use the compost navigation library from Google but rather for example navigation component which was meant for XML and that is of course on the one hand much more mature uh than composed navigation and on the other hand it's also much more feature Rich because with navigation component for XML you can pass around type safe arguments you can pass around complex data in form of power syllables all that is possible with that Library also that Library does support more complex screen transition animation so if you maybe have some kind of um transition animation that moves from the left to the right all that is possible with the old library but not yet with compos navigation and an advantage is that that way you don't need any extra thirdparty library and you still have the advantages that most thirdparty libraries bring you however the disadvantages of this approach is on the one hand that you have to use fragments so even if you're building a pure jic compos app then you have to go back and use fragments which also introduces a lot more boiler plate code because just to implement the screen you need a fragment you need a compos view inside of that fragment and then finally put your your screen UI inside of that composed screen so we've now covered all these four ways of navigating on the one hand compos navigation the official one and then we have using a library for navigation we have building your own custom navigation system and last but not least using fragments with XML navigation and compos views what do I know recommend you to pick as so often it depends there are just multiple scenarios where you could be in scenario one you are building a cotton multiplatform app in that case my recommendation is super Crystal Clear user navigation library that supports cotton multiplatform the advantage of sharing navigation logic between multiple platforms is just too big to not use it scenario number two you are mic creating an XML app to a jetpack compose app in that case micro condition is also very clear just use XML navigation together with fragments and migrate the project step by step migrate it screen by screen and just keep the XML navigation that way and scenario number three you plan to build a large native and pure compos app and here I mainly recommend either using a navigation library or building your own navigation system so generally the larger your app gets the more you will benefit from your own navigation system it's very hard to put this in numbers at which point such a custom navigation solution pays off compared to using readymade libraries but this graph might help you to illustrate this so on the one hand we have the green line illustrating a navigation Library so you can see it shows that the maintenance effort of using a navigation library is close to zero when you start your project because a navigation Library just make sure that you don't have to implement M balla plate code you can just start right away with implementing navigation logic so everything is fine the library does make your life easier but typically the larger an app gets the more unexpected problems you will face when using a library and in addition by using a library you just have the constant risk that the authors of the library change something in the API which will cause major refactorings in your codebase or they just stop the support entirely which would of course be the worst case because then you would need to switch the library for a potentially huge app and that is also why this green line Rises the bigger the project gets the orange line line illustrates a custom navigation system which is built on top of the already existing composed navigations library that way you just have a much more fine-tuned solution to navigation which you can manage in your project as you can see on that line that requires a lot of initial effort since you first of all need to set up that custom navigation system but over time it really starts to pay off because you get to decide which changes have to be made to that navigation system and which you can rather leave out for your individual project and if there are changes to be made you can also offer can structure them in a way that causes a minimal effort of refactoring for the existing code base and again I can't put this in numbers but there is some point where these lines cross and that is the point where a custom navigation system tends to pay off more than using a navigation library but I would be very interested in what you use at work in a larger app what kind of navigation approach do you stick to let us know that in the comments and other than that if you like these videos then you will definitely also like my more advanced Android premium courses which you can all find by clicking the first link in this this description all these are really structured to prepare you as an end developer for the industry for a job that you always wanted to have so check them out other than that thanks so much for watching this video I will see you back in the next one have an amazing rest of your week bye-bye

Channel: Philipp Lackner

Views: 24,199

Keywords:

Id: JAGLOaWztBc

Length: 11min 26sec (686 seconds)

Published: Wed Dec 13 2023