https://kotlinlang.org logo
Join Slack
Powered by
Just went through navigation-compose <samples> an...
# compose
k
Just went through navigation-compose samples and have rather silly doubt: in sealed class for Screens, why can't we just have computed property called "route" which will call 
stringResource(resId)
in its 
get()
method
j
The first thing I did was create my own 
navigate
extension and use my own Route 
enum class
as route argument
z
@Javier do you just have a single level of navigation? Or do further levels down have their own `enum class FooRoute`s?
j
Until now just one level, but I have to experiment with multiple levels and multiple nav graphs
Maybe I have to move from 
enum
to 
sealed
🤔 but if a destination is shared two screens...?, I have to think about this when I "crash" with those use cases
@Zach Klippenstein (he/him) [MOD] did you have modeled something like this when you developed your own navigation library?
The easiest thing of the enum is I can use its name as string, and it is unique, if I move to a 
sealed class
maybe I had to add a required 
Id
and I have to set manually which add more boilerplate
a
I think one benefit I found with sealed classes was that I could provide functions for a screen for just the value of the argument. So the caller didn't need to know the key for it.
j
Did you use some mechanism to autogenerate the route string?
a
lol, this:
Copy code
sealed class Screen(val route: String) {
 object Dashboard : Screen("Dashboard") {
   val routeWithArg: String = "$route?arg={arg}"
   fun withArg(arg: String): String = routeWithArg.replace("{arg}", arg)
 }
}
👀 1
j
I am trying with 
simpleName
(impossible because you can get duplicated routes) and 
qualified
of 
jvmName
have the entire file, and I think there is an open issue about 
sealed classes
where you can extend a sealed class from a different file and this, maybe, can have problems
z
Don't want to detail the thread, but I'm curious what value you're getting out of the jetpack navigation library if you're not using it for backstack management and just have a simple enum/sealed class defining your screens. Is it just transitions? It seems to me like backstack management and transitions are the two main value props of using the navigation library with compose.
👍 1
did you have modeled something like this when you developed your own navigation library?
Not sure exactly what you’re referring to. 
compose-backstack
tries to do as little as possible, the only reason it even has a backstack at all (in contrast to something like 
Crossfade
, which only takes the “current” screen key) is to figure out whether a forward or backward transition animation should be shown.
👍 1
i
FWIW, route names absolutely should never be translatable strings (they don't change as the user's language changes). That's why they're separate things
k
@Zach Klippenstein (he/him) [MOD] what do you mean by this?
if you're not using it for backstack management
navigation-compose
does support the backstack management right?
@Javier could you please explain a bit why 
javaclass.simpleName
won't work?
z
i’m not convinced you need a whole library to write 
myBackstack += newScreen
, 
myBackstack.dropLast()
especially because it forces you to manipulate your backstack as a list, and maybe your navigation itself is declarative and not a series of push/pop calls
j
Because if your sealed class has nested sealed classes you can have multiple objects or classes with the same simpleName
k
@Javier is there any example of using 
navigation-compose
for nested graphs? was just curious how we need to deal with those scenarios. I'm aware of the one by @ Afzal Najam
j
Sample
About an example with nested graph I don't know if there was one in Gerrit samples, maybe @Ian Lake can help us
k
@Zach Klippenstein (he/him) [MOD] but since we're already getting away from the fragments, I thought we need something to support those jetpack navigation functionalities (backstack, safeargs, deeplinks, etc.) in compose
j
Currently there is no safe args with compose, so I don't know if we should just go for deep links all the time or there is some benefit using "the normal approach"
i
I don't think we have an example of nested graphs, but the DSL already supports the 
navigation
element for nested graphs. We could certainly add an overload of that which lets you define it with a route (rather than an int ID as is required in the base Navigation DSL)
Definitely feel free to file feature requests as you find them (this is only alpha01, after all): https://issuetracker.google.com/issues/new?component=409828&amp;template=1093757
👍 4
z
@Kshitij Patil If this library is a good fit for you, then don’t mind me 😅 All i was trying to say is that Compose allows for navigation idioms which wouldn’t be possible, or at least easy, in classic Android, and you might not need the full power of this library, and all the “magic” it brings along. E.g. a backstack is just a stack, and can be implemented with a basic kotlin List. Safeargs is solving a problem that is specific to this library in the first place – e.g. if you use a sealed class for your routes + args, they’re already strongly typed. Deep linking depends on your use case.
2 Views
Open in Slack
PreviousNext
Powered by