Releases: raamcosta/compose-destinations
1.5.34-beta
Changes
- #352 : Adds support for navigation extras when navigating to an ActivityDestination
- Fixed issue with launchSingleTop destinations not receiving the result from a ResultBackNavigator in certain scenarios
Full Changelog: 1.5.33-beta...1.5.34-beta
1.8.33-beta
- Feature - Destination Wrappers
With this feature, you can set a number of wrapper composables to your screens, extracting common logic or UI you need in multiple screens.
Imagine you have a number of screens that should be behind a PIN. How would you implement that so that you don't repeat yourself and you avoid adding complexity to each of these screens?
Well, after this update you can do this:
@Destination(
wrappers = [PinEntryWrapper::class] // 👈
)
@Composable
fun YourScreen() { //...And define what your wrapper does like:
object PinEntryWrapper : DestinationWrapper {
@Composable
override fun <T> DestinationScope<T>.Wrap(
screenContent: @Composable () -> Unit
) {
val vm = viewModel<PinEntryWrapperViewModel>()
val correctPinEntered by vm.correctPinEntered.collectAsState()
if (pinEnteredCorrectly) {
screenContent()
} else {
// SHOW YOUR PIN ENTRY HERE
}
}
}And now you have a reusable piece of logic and UI which can be easily reused in how many screens you need and with very little intrusion to the screen itself! 🙌
The DestinationScope receiver of the Wrap function will give you anything you might need here including the destination
being wrapped at the moment (since you can Wrap multiple ones), its arguments, dependencies (provided via dependencyContainerBuilder etc.
- Fixed #339
Full Changelog: 1.7.33-beta...1.8.33-beta
1.7.33-beta
- Feature - Destination Wrappers
With this feature, you can set a number of wrapper composables to your screens, extracting common logic or UI you need in multiple screens.
Imagine you have a number of screens that should be behind a PIN. How would you implement that so that you don't repeat yourself and you avoid adding complexity to each of these screens?
Well, after this update you can do this:
@Destination(
wrappers = [PinEntryWrapper::class] // 👈
)
@Composable
fun YourScreen() { //...And define what your wrapper does like:
object PinEntryWrapper : DestinationWrapper {
@Composable
override fun <T> DestinationScope<T>.Wrap(
screenContent: @Composable () -> Unit
) {
val vm = viewModel<PinEntryWrapperViewModel>()
val correctPinEntered by vm.correctPinEntered.collectAsState()
if (pinEnteredCorrectly) {
screenContent()
} else {
// SHOW YOUR PIN ENTRY HERE
}
}
}And now you have a reusable piece of logic and UI which can be easily reused in how many screens you need and with very little intrusion to the screen itself! 🙌
The DestinationScope receiver of the Wrap function will give you anything you might need here including the destination
being wrapped at the moment (since you can Wrap multiple ones), its arguments, dependencies (provided via dependencyContainerBuilder etc.
- Fixed #339
Full Changelog: 1.7.32-beta...1.7.33-beta
1.6.33-beta
- Feature - Destination Wrappers
With this feature, you can set a number of wrapper composables to your screens, extracting common logic or UI you need in multiple screens.
Imagine you have a number of screens that should be behind a PIN. How would you implement that so that you don't repeat yourself and you avoid adding complexity to each of these screens?
Well, after this update you can do this:
@Destination(
wrappers = [PinEntryWrapper::class] // 👈
)
@Composable
fun YourScreen() { //...And define what your wrapper does like:
object PinEntryWrapper : DestinationWrapper {
@Composable
override fun <T> DestinationScope<T>.Wrap(
screenContent: @Composable () -> Unit
) {
val vm = viewModel<PinEntryWrapperViewModel>()
val correctPinEntered by vm.correctPinEntered.collectAsState()
if (pinEnteredCorrectly) {
screenContent()
} else {
// SHOW YOUR PIN ENTRY HERE
}
}
}And now you have a reusable piece of logic and UI which can be easily reused in how many screens you need and with very little intrusion to the screen itself! 🙌
The DestinationScope receiver of the Wrap function will give you anything you might need here including the destination
being wrapped at the moment (since you can Wrap multiple ones), its arguments, dependencies (provided via dependencyContainerBuilder etc.
- Fixed #339
Full Changelog: 1.6.32-beta...1.6.33-beta
1.5.33-beta
- Feature - Destination Wrappers
With this feature, you can set a number of wrapper composables to your screens, extracting common logic or UI you need in multiple screens.
Imagine you have a number of screens that should be behind a PIN. How would you implement that so that you don't repeat yourself and you avoid adding complexity to each of these screens?
Well, after this update you can do this:
@Destination(
wrappers = [PinEntryWrapper::class] // 👈
)
@Composable
fun YourScreen() { //...And define what your wrapper does like:
object PinEntryWrapper : DestinationWrapper {
@Composable
override fun <T> DestinationScope<T>.Wrap(
screenContent: @Composable () -> Unit
) {
val vm = viewModel<PinEntryWrapperViewModel>()
val correctPinEntered by vm.correctPinEntered.collectAsState()
if (pinEnteredCorrectly) {
screenContent()
} else {
// SHOW YOUR PIN ENTRY HERE
}
}
}And now you have a reusable piece of logic and UI which can be easily reused in how many screens you need and with very little intrusion to the screen itself! 🙌
The DestinationScope receiver of the Wrap function will give you anything you might need here including the destination
being wrapped at the moment (since you can Wrap multiple ones), its arguments, dependencies (provided via dependencyContainerBuilder etc.
- Fixed #339
Full Changelog: 1.5.32-beta...1.5.33-beta
1.8.32-beta
#104 - Added value class navigation argument support.
You can now use value classes as navigation arguments 🙌
Some limitations: (checked at compile time)
- Value class has to have a public constructor
- Value class has a public non nullable field
- Value class "inner type" needs to be a "non value class" navigation argument type.
Updated dependencies for compose 1.4
Full Changelog: 1.7.30-beta...1.8.32-beta
1.7.32-beta
#104 - Added value class navigation argument support.
You can now use value classes as navigation arguments 🙌
Some limitations: (checked at compile time)
- Value class has to have a public constructor
- Value class has a public non nullable field
- Value class "inner type" needs to be a "non value class" navigation argument type.
Full Changelog: 1.7.30-beta...1.7.32-beta
1.6.32-beta
#104 - Added value class navigation argument support.
You can now use value classes as navigation arguments 🙌
Some limitations: (checked at compile time)
- Value class has to have a public constructor
- Value class has a public non nullable field
- Value class "inner type" needs to be a "non value class" navigation argument type.
Full Changelog: 1.6.30-beta...1.6.32-beta
1.5.32-beta
#104 - Added value class navigation argument support.
You can now use value classes as navigation arguments 🙌
Some limitations: (checked at compile time)
- Value class has to have a public constructor
- Value class has a public non nullable field
- Value class "inner type" needs to be a "non value class" navigation argument type.
Full Changelog: 1.5.30-beta...1.5.32-beta
1.7.30 - Wear OS support! 🙌
What's Changed
To use it, import the corresponding core dependency:
implementation 'io.github.raamcosta.compose-destinations:wear-core:1.7.30-beta'
Then create a wear os NavHostEngine and pass it to the DestinationsNavHost composable:
val engine = rememberWearNavHostEngine()
DestinationsNavHost(
engine = engine,
//... same thing as with normal lib usage
)New Contributors
Full Changelog: 1.7.27-beta...1.7.30-beta
