Should You Use a Navigation Library in Jetpack Compose?

Hey Philipp, just a tip for your channel: If you could use some good B-roll footage to help communicate the concepts, it might really help the communication. I got lost in the sea of words and struggled to follow, but the video footage explaining it alongside your words would really help. Hope this helps!

It bugs to hear devs making arguments like this. Just simply use the official one from Google there's a reason they did made it the way it works.

But isn't compose suppose to be purely presentational? why are people having the urge to replace fragments with it? Its meant to just replace xmls... the idea of making it handle navigation too is conflicting! I thought we preached separation of concerns? and there we go inventing hacks instead of letting it have just one single responsibility

kotlin multiplatform- Voyager❤😊

I like your videos but please try to use the previous approach of explaining through diagrams and other presentations, rather than just your face in the whole video. Some of us understand very easy with the diagrams. I don't see the reason why we should see your face for the entire video, it's the same as we just listen to your audios.

I don't understand the problem, What is so complex about compose navigation?
I use it and it's work super well i din't find any problem.

First thing first, please don't mix OOP Paradigm, and Functional Programming Paradigm. Compose is based on Functional programming "Function Compositions".
I din't find any problem parsing parcel anyway. All i need is just add lambda for "event" in the child function as function composition.

```
ScreenLogin(
val onLoginSuccess: (AuthData) -> Unit
)
```

now what is the problem? want to parse the whole object to the next screen? please don't. it's very bad approach. why would you do that.
But in case you need, you can use Use Lazy evaluation if the object is too big:

val authData = { AuthData(.....) }
Voila, lazy evaluated.

I personally recommend to never tight a function with any context, if possible. Make the function as independent as possible. How ever, we can use custom payload if we want to.
This is my approach on how i specify payload for a function, and make it un-tangled with base context. (By un-tangled i mean we not using Application's Model, because when we do, then the function is tight to the application context. It is not wrong, i just don't recomending it. I prefer make functions as independent as posible.)

```
interface LoginScreen {
@Immutable
data class Payload(
// action
var goBack: () -> Unit = {},
var onLoginSuccess: (user: AuthToken) -> Unit = {},

// context
var firebaseContext: () -> FirebaseContext
)


companion object {
@Composable
operator fun invoke(
payload: Payload
) {
Content(payload)
}
}
}

@Composable
private fun Content(
payload: LoginScreen.Payload
) { ... }
```

note: don't get it wrong. it can "requires" some context, but it's not necessary tangled to the application context. instead, the application should declares all context within that app.

fragment and compose are different.
Its different in it's base principle and paradigm.
Compose use: Functional programming paradigm and Function Composition.
Fragment: Is Java delegation. It's based on OOP. Using reversed dependency, and all that OOP paradigm.

Be careful. They are based on different paradigm, different thinking framework. If we still using OOP thinking framework, well it's very wrong.

My opinion. What ever the library is, the closest with the Theory, is the best. I found that compose navigation is very well close to the theory. what ever happen tomorrow its should not be a problem.
Because when we facing a problem, all we can do is go back to the theory. So as long as the approach is well oriented to the theory, it is good approach and should not be a problem. Because it's deprecation will have no impact to the code sctructure what so ever, (if the approach is match to the theory).

This is example only, not best approach what so ever. But i belive as long as our approach match with the theory, it is best approach.

What do you mean compose navigation doesn't support animation of screen sliding out and new screen sliding in? It feels like it was always there, and navigation graph has default animations, and you can override it for each screen....

I use Destenation honestly, it make my life easier while building native large Android apps. it has everything you really need from Animation to Navgraphes to passing Complex objects to handling NavBars and Bottom bars, for me its still the best option out there if you are building your app from scratch

I don't know is this the efficient way or not but I personally use viewmodels for passing the complex data betweeen screens , there will be mainviewmodel for the mainactivitiy and every composable screen has it;s own viewmodel . In the navhost we pass the mainviewmodel object and everything works fine for me! . Is there any problem with that ?

Is that third party library can handle nested navigation?

Defining and using a navigation viewModel which is bound to the lifecycle of your Activity or NavGraph along with compose Navigation library works in most scenario!

"Build a custom navigation system on top of Compose Navigation" sounds great! Adapting the official library by extracting the boilerplate code into reusable components and tailoring those components to your specific navigation logic is a worthy investment of time and effort for a big project, because this way you can enjoy a navigation system that is maintained by Google and you, and is perfect for your app!

I would love to see a video about sqldelight and some extra components like sqldelight pagination. Im struggling to implement a room like database and pagination that works with compose multiplatform

Any coupon code for your course.?? i just wanted to enroll course.

Wow, you are reading my mind again! I have been thinking about navigation for the last week!

Google has done a lot of good things with Jetpack. Compose Navigation is definitely not one of them.
Thx for your great video.

After get familiar with compose navigation I met Navigation destinations. I thought that this is it, it will be the finest solution, but longer work with it, I turn more into custom solution.

Oh man what a timing! I was just bashing my head with navigation on a green field project and I was having all these questions you've nicely put in perspective.

One not related question: When I click on Get your free PDF for 20 things not to do in Jetpack Compose, why it is navigating to a payment screen asking for 500+ Euros? o.O

Believe Compose Navigation will get better over time ... Google will always support it or provide a migration path to what they build next ..

I used Compose Destinations for ~6 months, made a couple of big projects with many screens. It's not that bad (better than from google), but I can't say that it is good either.
So I made my own scalable navigation system, and I can say, that using your own navigation 100 times better, that's not that hard to do, but it is so much better to work with your own navigation.

Hi Philipp, personally I use this approach to pass parcelable data between compose destinations A-B in a typesafe manner:
- create an extension of navcontroller like: navController.navigateToB(data: Obj) { currentBackStackEntry.savedStateHandle.set(key, data); navigate("routeB")}
- call this extension from destination A
- in destination B:
val data = navController.previousBackStackEntry.savedStateHandle.get(key)

If you define the extension in the same file of your destination, potentially you could set the key as private.

It works. I think there aren't problems with this approach, but I've never seen this usage on internet. What do you think about?
I saw something like this when you want a result from a destination B in a destination A. This approach is like the opposite.

Let's be honest. Google gives us a lot of great helpful tools to build an android project. However Google sucks really hard at implementing navigation. Both navigation for compose and on fragments are bad, have a lot of boiler plate, you need to draw arrows like a painter to know which fragment navigates to which. Like... why?? I just want to navigate from fragment A to B, why can't i do it inside the code?
So my personnal experience is to screw google navigation. It's bad. If you want navigation purely in compose just go for voyager appyx etc. if one library dies, the transition isn't as bad as you may think. If you think that won't be easy in larger project then you should know that for that case you will have multi module helper which will be just a coverage for the navigation library. Then the transition will be smooth and easy.
But there is another but. I've experienced a lag issue navigating purely in compose. When you navigate from screen A to screen B, and screen B will change state during the transition (loading -> data), and the data will be list of images that you need to display then on slower devices you will experience frame drop. It won't happen if you use fragment navigation, so that's why for now i recommend using compose with fragment navigation like FragNav or Enro. Enro looks really nice, but if you have to transition between main and nested navigation often then i do not recommend it.

Do you already have video for customer navigation?

In the company I work for we use a custom solution on top of compose navigation. The main benefit is that when we need a new feature for this library, we just add it and it's ready to go.

I would pick the custom navigation approach, even though initially it would take quite some time to make it, but having the full ability to customize and tailor the navigation to the project specific needs is the best option in the long run.

You should make a video about store4/store5

Hi bro, can u do tinder like swipe animation in jetpack compose please 🙏🙏🙏🙏

It would be great if you could make a video which compares the most popular navigation libraries :D

i hate the overuse of libraries ! unless it is supported by google or jetbrains, it would be the last solution i opt to when solving a problem.

I would recommend option 4. Yes, you write lots of fragments, but, it's a compromise and it works well. I've been using it for 2 yrs now, and the project has grown, but, it's not caused too many complications.

Compose navigation might be complex, but the official documentation is very helpful. I'll choose the official one over the others.

Guys that have a background on web dev are wondering what's the big deal😅

Answer: no, you shouldnt. Tying yourself to a third party library for such a simple action as navigating is an error. Unless a big company like Square, Facebook, Airbnb etc maintains it officially; then maybe you can start thinking of it. Otherwise, build your custom solution adapted to your project.

In my humble experience passing complex objects directly between screens in navigation can lead to issues like increased memory usage, tight coupling, and serialization challenges. It's generally better to pass only minimal data, like IDs, and then retrieve the full objects in each screen independently. This approach enhances modularity, makes your code easier to maintain, and is more efficient for memory management. Sharing ViewModels between screens isn't always ideal, as it can create unnecessary dependencies. Instead, fetching data independently in each screen or composable based on passed identifiers keeps components decoupled and your app's architecture clean and scalable.

Thank you Philipp for the video. I just wanted to bring to your attention that Google has released a detailed guide on achieving type-safe navigation through their library. I think it's a really good approach for most of the projects, even if there's a little bit of boilerplate code to write each time, which does not happen with Compose Destinations for example.

Google's compose NavHost and route pattern looks like web server routing. I like this way. But I still dont' know the way that pass data directly on startDestination and receive this data in ViewModel with savedHandle

What library do you recommend? You mentioned different ones, which one is better for not multiplataform ?)

Whether fragment navigation supports multiplatform?

Well isn't that good, to just take data from the database instead of passing it through arguments.

It always follows the single source of truth rule

Always use a custom navigations

Yeah. It feels like Navigation library by google is built by a web developer 😂