Skip to content

build(deps): bump navigation3 from 1.0.1 to 1.1.0 - #639

Closed
dependabot[bot] wants to merge 2 commits into
code/cashfrom
dependabot/gradle/code/cash/navigation3-1.1.0
Closed

dependabot[bot] wants to merge 2 commits into
code/cashfrom
dependabot/gradle/code/cash/navigation3-1.1.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Apr 10, 2026

Copy link
Copy Markdown
Contributor

Bumps navigation3 from 1.0.1 to 1.1.0.
Updates androidx.navigation3:navigation3-runtime from 1.0.1 to 1.1.0

Updates androidx.navigation3:navigation3-ui from 1.0.1 to 1.1.0

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps `navigation3` from 1.0.1 to 1.1.0.

Updates `androidx.navigation3:navigation3-runtime` from 1.0.1 to 1.1.0

Updates `androidx.navigation3:navigation3-ui` from 1.0.1 to 1.1.0

---
updated-dependencies:
- dependency-name: androidx.navigation3:navigation3-runtime
  dependency-version: 1.1.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: androidx.navigation3:navigation3-ui
  dependency-version: 1.1.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file java labels Apr 10, 2026
@bmc08gt bmc08gt closed this Apr 20, 2026
@dependabot @github

dependabot Bot commented on behalf of github Apr 20, 2026

Copy link
Copy Markdown
Contributor Author

OK, I won't notify you again about this release, but will get in touch when a new version is available. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot
dependabot Bot deleted the dependabot/gradle/code/cash/navigation3-1.1.0 branch April 20, 2026 19:54
bmc08gt added a commit that referenced this pull request Aug 24, 2026
The Android swipe was ours, not a port: the gesture sat on the card, it took
half the travel to close, and pushing an expanded card down did nothing. iOS
PR #639 settled all three differently. Bringing them across:

- Attach the drag to the page, not the card. Expanded, the card is 302dp of a
  wider display, so a pull that lands in the margin missed entirely. Nothing
  scrolls while the card is up, so there is no scroll to contend with.
- Close at 0.3 of the travel rather than halfway.
- Give the card 0.25 resistance when it is pushed down past full screen, and
  return it on the shorter spring iOS uses for a pull that fell short
  (response 0.3, so stiffness 439).
- Hand back the touch slop the recogniser swallowed on the first delta, so the
  card starts where the finger did instead of jumping the slop distance.

Two divergences stay. The settle still carries a capped release velocity,
because Android has a swipe where iOS only has a tap and so has no velocity to
carry. The page content still fades on progress rather than on the boolean,
because our card is opaque at this call site and a boolean fade shows through
a translucent one.
bmc08gt added a commit that referenced this pull request Aug 24, 2026
* feat(menu): swipe to minimize the full-screen tip card

Full screen on the "You" tab could only be left through the Close row. The
expansion is now one 0..1 progress rather than a boolean: card size, its
travel out of the slot, the page fading beneath it and the Close row all
read the same value, so a drag can park the transition part-way through and
hand it back where it found it. Every reader takes the progress inside a
graphicsLayer lambda, so a drag redraws rather than recomposing the page.

A release settles on the spring iOS already uses for this transition
(response 0.45, damping fraction 0.85), carrying the gesture's velocity into
it. Uncapped, the hardest flick sailed about 18% of the travel past the
resting end, which lifts the card clear out of its slot and up under the
status bar. Capping the carried velocity holds that to 5.6%, roughly 10dp,
without flattening the bounce into a cut. TipCardOvershootTest drives the
animation a frame at a time off a BroadcastFrameClock and holds both bounds:
some bounce, and not much.

The "Full Screen" caption is a later sibling than the card, so it paints on
top of it while the growing card travels down across its slot. It now fades
out over the first 8% of the expansion, ahead of the card reaching that spot
at around 11%.

One gap: the tab bar still switches on the committed intent rather than
tracking the drag, because HideTabBar is boolean rather than progress-driven.

* fix(menu): match iOS's pull-to-minimize thresholds and feel

The Android swipe was ours, not a port: the gesture sat on the card, it took
half the travel to close, and pushing an expanded card down did nothing. iOS
PR #639 settled all three differently. Bringing them across:

- Attach the drag to the page, not the card. Expanded, the card is 302dp of a
  wider display, so a pull that lands in the margin missed entirely. Nothing
  scrolls while the card is up, so there is no scroll to contend with.
- Close at 0.3 of the travel rather than halfway.
- Give the card 0.25 resistance when it is pushed down past full screen, and
  return it on the shorter spring iOS uses for a pull that fell short
  (response 0.3, so stiffness 439).
- Hand back the touch slop the recogniser swallowed on the first delta, so the
  card starts where the finger did instead of jumping the slop distance.

Two divergences stay. The settle still carries a capped release velocity,
because Android has a swipe where iOS only has a tap and so has no velocity to
carry. The page content still fades on progress rather than on the boolean,
because our card is opaque at this call site and a boolean fade shows through
a translucent one.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant