It's perfectly find for an action to originate from one navhost and modify the state in different one.

Example:

• NavHost1 that has a nested NavHost2 inside it, rendered inside a screen that is part of the NavHost1
• Screen rendered in NavHost2 wants to change a location in the application to a different one that is part of NavHost1, i.e. because of the way NavIntent was resolved (for example session expiry is detected in nested NavHost2. This produces a NavIntent that redirects the user to sign in screen which is part of NavHost1.

1. navIntent should produce a special type of destination
2. infix / operator functions on source destination and navIntent should produce special type of NavAction that accepts no navigate nor navigateWithController
3. Introduce new interface NavIntentMapper. Implementation(s) should be responsible for translating navigation intent into actual NavAction
4. NavActionConsumerImpl should use NavIntentMappers to translate NavIntents into actual NavActionss. It should throw an exception if mapping failed.
5. NavIntent should support arguments.
6. Current tab host navigation handling should be replaced with NavIntent. Reasoning: navigation with this component requires checking the current back stack state.
7. Change the name of NavActionConsumer to NavigationConsumer
8. Change the name of NavActionConsumerImpl to NavigationConsumerImpl

Changes

Updated AGP to 7.2.2 Other dependencies updates.

Testing

Manual testing.

Checklist

General

• [x] PR targets the develop branch
• [ ] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [ ] New code is covered by unit tests
• [ ] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Changes

TabBarIntentResolver now supports popOptions

Testing

Demo app

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [ ] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [ ] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [ ] Changelog and documentation updates reflect the modification made in this PR

Changes

Simplified navaction / intent processing. After those changes:

• each navintent is resolved only once
• each navaction is verified only once
• NavigationProcessor selects pending action dispatchers that are suitable for the resolved action.
• Made it possible to process actions with source and target destinations that belong to different graphs (#97 )

Testing

Demo apps.

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [x] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Changes

Added support for Long, Float, Double and Boolean arguments.

Testing

Unit tests + checking if apps work properly

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [x] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Changes

Added better error messages to NavStackEntry

Testing

Unit tests + manual testing

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [x] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Changes

NavStackEntry is no longer nullable in composableDestination

Testing

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [ ] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Changes

• Added dev menu demo
• NavState now has a list of NavControllerStates which gives access to information about all used NavHosts
• NavIntent has an additional field now which is called navigationId. It's just for informational purpose and doesn't influence the intents processing.
• Added signing config so that it's possible to test the apps in release build type.

Testing

In demo app by tapping the middle of the app bar twice. It will open the dev menu. Tapping the app bar like that in release build type should do nothing.

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [ ] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Changes

Made sure that it's possible to use infix functions as a builder pattern instead. Added setNavOptions method to make builder approach more convenient.

Testing

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [x] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Changes

Added support for nested nav hosts

Testing

Using the newly added proof of concept app

Checklist

General

• [x] PR targets the develop branch
• [x] PR is linked to the GitHub issue it resolves

Source code and docs

• [x] Changelog is updated (fixes section for a bug, changes for anything that has been added / modified/ removed)
• [ ] New code is covered by unit tests
• [x] Added ktdoc and updated README.md if API has changed
• [x] Made sure that unit tests pass
• [x] Made sure that ktlintCheck and detekt tasks produce no issues
• [x] Updated demo app if needed

Reviewer Checklist

• [x] Library builds
• [x] Demo app works
• [x] Changes work as expected
• [x] Changelog and documentation updates reflect the modification made in this PR

Add an optional argument navigationId: NavigationId to all offer methods.

When present, this navigationId should be used by the library to select a specific NavigationProcessor to process offered action or intent.

Goal is to remove the need for NavGraphBuilder extension declaration. Instead, NavGraphBuilder have only one generic extension that populates the graph based on provided NavGraph.

Some more details have already been described in #63

Reasoning is that destinations need args to render properly, always. NavAction's role is to simply deliver them to the new destination.

Once arguments become part of destination, it will be possible to do something like this:

// could be serialized using Gson
data class DetailScreenArgs(
    @SerializedName("itemId")
    val itemId: Int
)

object MyGraph : NavGraph("myGraph") {

    val List = navDestination("list") { ListScreen() }

    val Detail = List.nextWithArgs<DetailScreenArgs> {
        param("itemId")
    } { args -> DetailScreen(args) }
}

This way destination would declare both, the type of the used args and how it renders in one place. This could potentially make it possible to automatically build a graph with NavGraphBuilder. NavGraph methods like navDestination could remember created destiantions. This will simplify the graphs definition by a lot

Also, args should be part of the information about back stack. Currently, there is no real way to tell apart 2 instances of the same destination, even if they are launched with different set of arguments.

Potential issues:

1. How should the destination like the one below work:

   val ListDetail = List.nextWithArgs<DetailScreenArgs> {
       param("itemId")
   } { args -> DetailScreen(args) }
   
   val PicturePreview = Detail .nextWithArgs<PicturePreivewArgs> {
      path("picture")
      param("pictureId")
   } { args -> PicturePreviewScreen(args) }
   

   Args would need to carry both, "itemId" and "pictureId" fields. Should "pictureId" and "itemId" constants be defined in common module then?

Demonstrate how to achieve different versions of same feature in this app using Settings screen as an example. Goal is to have demo-ui-settings-v1 and demo-ui-settings-v2 in the project (plus demo-ui-settings-common for shared components). It should be possible to configure which version of the feature is included in the build (i.e. using project properties).