Skip to content

feat: add Android floating tab bar - #104

Open
huhuanming wants to merge 1 commit into
mainfrom
feat/android-floating-tab-bar
Open

huhuanming wants to merge 1 commit into
mainfrom
feat/android-floating-tab-bar

Conversation

@huhuanming

Copy link
Copy Markdown
Contributor

Summary

  • add an Android-only androidTabBarStyle prop with default and floating modes
  • render the floating mode as a rounded, inset tab bar with a native selected-item capsule
  • engage the capsule immediately on touch, drag without changing pages at intermediate tab centers, and select the nearest tab once on release
  • preserve the existing default Android appearance and leave iOS behavior unchanged

Validation

  • yarn workspace @onekeyfe/react-native-tab-view typecheck
  • yarn workspace @onekeyfe/react-native-tab-view prepare
  • JAVA_HOME=$(/usr/libexec/java_home -v 17) ANDROID_HOME=/Users/huhuanming/Library/Android/sdk ./gradlew :onekeyfe_react-native-tab-view:compileDebugKotlin
  • downstream app-monorepo Android emulator acceptance: immediate touch engagement, no page switch while crossing tab centers, one nearest-tab switch on release, and normal tap regression
  • git diff --check

Notes

  • Blur material is intentionally out of scope.
  • The package-local lint script currently cannot resolve its eslint command in this workspace; no lint dependency or unrelated configuration was changed in this PR.

floatingDragOriginalItemId = item.itemId
floatingDragCandidateItemId = item.itemId
view.isPressed = true
beginFloatingDrag(item.itemId)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: [Selected-tab long press is swallowed in floating mode]

When androidTabBarStyle is floating, a touch on the selected tab reaches this branch and returns true from ACTION_DOWN. That prevents Android from running the item's existing OnLongClickListener; a stationary hold later falls through ACTION_UP to performClick(), so onTabLongPress never fires.

Keep a stationary-hold path that invokes performLongClick() (or let the existing long-click listener own that gesture), and consume the sequence for drag only after movement has activated the drag gesture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants