I'm taking a look at Decompose for Wear navigation...
# confetti
y
I'm taking a look at Decompose for Wear navigation. I Looked at using the shared DefaultAppComponent, which would get Wear closer to the rest of the codebase, but it looks like reaching too far.
I need a single Nav Host, in Wear case SwipeToDismissBox, so I was flattening the recursive stack of DefaultAppComponent->ConferenceComponent->Home into a sequence, and grabbing the top 2.
But then a lot of the components, relate to the Mobile screen structure, so don't make sense for Wear.
So I'll introduce a simpler WearAppComponent structure instead.
a
Yeah, a separate WearAppComponent totally makes sense.
Will it be a standalone app requesting data on its own or will it require the main app to be installed?
y
I'm refactoring the current Wear app. So standalone, but taking the default conference from Mobile over the Data Layer (BT connection).
I'm moving from Compose Navigation.
a
Sounds interesting!
y
I'm taking the opportunity to reuse SessionsSimpleComponent, delete some code.
Early draft - a lot to still do https://github.com/joreilly/Confetti/pull/850
👀 1
Early impression, Decompose is way closer to how I think than Compose Navigation, seems really intuitive.
decompose intensifies 1
Would I use Activity.onNewIntent to intercept deeplinks? Or should I just read from the intent?
I would try configuring for onNewIntent, and in that method call setIntent + recreate for simplicity. Then parse the intent in onCreate
y
Yep, that looks right.
What about PendingIntents / TaskStacks? like
Copy code
TaskStackBuilder.create(this)
            .addNextIntentWithParentStack(Intent(
                Intent.ACTION_VIEW,
                uri.toUri()
            ))
            .startActivities()
Is that going to be just a since URI to handle. Or does the activity stack handled in some way?
Not an issue, just curious about the 1:1 mapping when converting.
a
Is it for the main app? I think it's just one activity there.
y
One activity, but Androidx Navigation is strict about recreating the synthetic backstack, even for single activity architecture.
a
Right. But there is no such an issue with Decompose
y
OK, so instead of building that into the deeplink in the PendingIntent, I can just rebuild that stack in initialStack.
a
Correct
y
I'm finding I can use SessionDetailsComponent, not sure if they are coincidentally the same, or fundamentally.
a
Who are they?
y
I had a WearAppComponent for shared AppComponent. And a Wear ConferencesComponent for shared ConferencesComponent. But now finding the specific item pages, like Speaker and Session are shareable.
a
That looks valid and what I would expect. 😀 not sure why you couldn't reuse ConferencesComponent
y
I can, just need to provide a variant of the result shape. And later come back and stop aggressive network refreshes. Good point.
👍 1
Do ViewModels still work in Decompose, or are not properly scoped?
a
In Decompose we have this: https://arkivanov.github.io/Decompose/component/instance-retaining/ But Confetti has a globally scoped repository, so it looks like retained ViewModels do not provide any benefit.
y
Thanks, it's more if I have some existing Screen that happens to use a ViewModel, will it do the wrong thing?
a
Ah, in this case you just add InstanceKeeper.Instance interface to your view model, and then use that in a component as described in the doc.
1
If you also need to save/restore state in the view model (aka SavedStateHandle), then please see: https://github.com/arkivanov/Decompose/issues/469