[ViewPager2] Verify ViewPager2 with Navigation [127538952]

Duplicate

of 133640271

Bug

Status Update

No update yet.

Description

sa...@gmail.com

created issue #1

Mar 6, 2019 05:27PM

Hello.

I tried to use new ViewPager2 with FragmentStateAdapter. I found bug and created sample project to show it.

First screen is fragment with ViewPager with 2 fragment pages and button to open second screen.
Second screen is just empty fragment.

Steps:
1) Run app
2) Press button to open second screen
3) Press back button
4) Crash: java.lang.IllegalStateException: Observer androidx.viewpager2.adapter.FragmentStateAdapter$1@f8b5102 is already registered.

I did a little search and that's what I found:

This happens because the adapter did not called unregisterAdapterDataObserver(mDataObserver) which call only when recyclerView call FragmentStateAdapter.onDetachedFromRecyclerView.

This call happens only if we change adapter for new or set null for recyclerView ( for viewPager in this case ).

To fix it I tried set null adapter for viewPager in onDestroyView.
Then another exception occurs: java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
RecyclerView calls FragmentStateAdapter.onViewRecycled and FragmentStateAdapter tries to removeFragment but fails, because "Can not perform this action after onSaveInstanceState".

Is it bug or I missed something?
This behavior is not listed in the API changes.
Also if you try to change ViewPager2 to old ViewPager this sample will work fine.

Here is sample project to reproduce bug:

https://github.com/sanekyy/viewPager-fragments-bug-sample

Thanks in advance for the answer and help.

Comments

jg...@google.com <jg...@google.com> #2Mar 6, 2019 05:49PM

Assigned to jg...@google.com.

I don't think this falls under pointer input so this is simply less tied to the area I've been focusing on. I think this should be considered open for anyone else to start working on. I think the two main areas of work for keyboard input are building out the equivalent of focusableInTouchMode and routing keyboard input events to the appropriate node/modifier.

Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.

sa...@gmail.com <sa...@gmail.com> #3Mar 6, 2019 07:50PM

Hey Shep, thanks for the info.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).

Happy to hear from Ryan and Ralston in case this subject was discussed before.

sa...@gmail.com <sa...@gmail.com> #4Mar 7, 2019 12:34PM

I don't think this is/should be within Semantics's domain. Hardware keyboard input should, as far as I know, follow the same path as (and is, as far as I understand it, indistinguishable from) soft keyboard input (in fact, Gboard actually interacts with hardware keyboards).

I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).

jg...@google.com <jg...@google.com> #5Mar 7, 2019 12:47PM

Ah, I based on Siyamed's comment, this bug is intended to track the work necessary to handle keyboard events that aren't related to IME. (like menu shortcuts). I'm not sure what is needed here.

jg...@google.com <jg...@google.com> #6Mar 7, 2019 12:47PM

Oh I see. There's probably some overlap there. For instance, the accessibility focus traversal ordering is probably pretty similar to the input focus traversal ordering (though a11y would likely focus things that input would not).

I think one question is probably at what level these things live. There are a bunch of keys that probably don't need to go to substantially all widgets with keyboard input, like volume/menu/search/back. Then there are things like tab, which some input widgets will want, but others should ignore and pass through to another handler (to, say, move input focus).

I think Android's model for this is pretty decent - an intercept pass down the hierachy, then a pass back up for normal handling. It handles both cases well, as each component can decide which keys it cares about, rather than us trying to predict all use-cases in advance. We would, of course, handle these correctly in our controls, and we'd need to make it easy (no internals or copy-pasting of internals) to implement, say, correct tab behavior.

All of which is a long-winded way of saying: "I think we should handle these like any other keyboard input."

sa...@gmail.com <sa...@gmail.com> #7Mar 7, 2019 01:54PM

bulk comment, fyi: we have added icebox to all the tickets because it was suggested by blintz in order to prevent auto-close tickets. we want to keep our Compose tickets to remain opened.

see

b/123001228#comment6

sa...@gmail.com <sa...@gmail.com> #8Mar 7, 2019 02:13PM

Looks like there is currently a ticket assigned to Ralston. Will keep this ticket active for testing as well. Ralston feel free to dup this ticket, or we can use it as a reminder to test.

jg...@google.com <jg...@google.com> #9Mar 7, 2019 02:29PM

Let's keep this ticket open. I can see that it is already marked as blocked by the keyboard Input ticket that I am working on right now.

sa...@gmail.com <sa...@gmail.com> #10Mar 7, 2019 09:58PM

Project: platform/frameworks/support
Branch: androidx-main

commit 072a880c9ab1a245711fe9e67e9a56f2da04b790
Author: Andrey Rudenko <andrei.rudenko@jetbrains.com>
Date: Fri Feb 05 22:43:02 2021

Hardware Keyboard support in TextField

It adds onKeyEvent Modifier to CoreTextField and sets up the handling of KeyEvent in a uniform way across Android and Desktop. This includes support of all main keyboard shortcuts to edit, navigate and select text in TextField.

This CL doesn't touch any of the existing APIs and doesn't introduce the new ones. On Desktop in changes significantly how hardware keyboard events are handled. PlatformInput is responsible only for interaction with IM.

Most of the text operations in this CL were abstracted to TextFieldPreparedSelection and TextPreparedSelection, the latter one can be used in future CL to implement similar keyboard shortcuts for CoreText.

It's incomplete, we have to define better the Compose behavior on Android with a hardware keyboard, possibly it has to react to TouchMode changes and, for example, do not show software keyboard when hardware one is in action

Relnote: N/A
Bug: 139322105
Test: ./gradlew :compose:foundation:foundation:connectedAndroidTest
Change-Id: I2d5d462ec1f57de41ddfd9218411e695fe4bb2e2

M compose/desktop/desktop/samples/src/jvmMain/kotlin/androidx/compose/desktop/examples/example1/Main.jvm.kt
M compose/foundation/foundation/api/1.0.0-beta02.txt
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_1.0.0-beta02.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_1.0.0-beta02.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/build.gradle
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/HardwareKeyboardTest.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/KeyMapping.android.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.android.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/CoreTextField.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyCommand.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyMapping.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/StringHelpers.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/selection/TextPreparedSelection.kt
M compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/DesktopCoreTextField.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/KeyMapping.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.desktop.kt
A compose/foundation/foundation/src/jvmMain/kotlin/androidx/compose/foundation/text/StringHelpers.jvm.kt
M compose/ui/ui-text/src/desktopMain/kotlin/androidx/compose/ui/text/platform/DesktopParagraph.desktop.kt
M compose/ui/ui-text/src/desktopTest/kotlin/androidx/compose/ui/text/DesktopParagraphTest.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/desktop/ComposeLayer.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/input/key/Key.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwner.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwners.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopPlatformInput.desktop.kt

https://android-review.googlesource.com/1578803

sa...@gmail.com <sa...@gmail.com> #11Mar 7, 2019 10:10PM

Andrei, can you please share with us

overall requirements
what is implemented
what is to be implemented
what are we planning in the near team to support those requirements

jg...@google.com <jg...@google.com> #12Mar 8, 2019 11:31AM

Overall requirements

I can formulate some general goals:

it should be as much "native" for the user as possible. The definition of "native" is not very clear, for desktop, for example, it differs from platform to platform, and on Linux is anarchy. On Android keyboard was some sort of a second-class citizen for a long time, as I understand, so I'm not sure how it's "native" at all for most of the users. Should we use the original text field implementation as a reference? Or Chrome one?
full first-class rtl/bidi support
CoreText interaction with the keyboard and especially mouse is very similar to TextField interaction, so I guess they have to share both experience and implementation, where it's possible / needed.
exotic shortcuts like ctrl-t (emacs-like transpose) and kill-"ring" (in quotes because this "ring" is of size 1) ctrl-k/ctrl-y. Most users have no idea of them. But Chrome supports it
undo/redo functionality
uniformed implementation between Android and Compose for Desktop platforms

what is implemented

Adding support of key events was the easy part, thanks to the current state of focus and KeyEvent in compose. A small addition to KeyEvent interface (isTypedEvent) allowed uniform handling between Android and Desktop. Few dozens of basic keyboard commands are implemented and abstracted to the separate internal interface (TextPreparedSelection).

what is to be implemented

rtl/bidi support is broken currently (the separate issue is here https://partnerissuetracker.corp.google.com/u/1/issues/181900696)
better mouse support, at least double / triple clicks (the separate issue is here https://partnerissuetracker.corp.google.com/u/1/issues/180639271)
make CoreText supports the same selection capabilities, including keyboard shortcuts
undo/redo

what are we planning in the near term to support those requirements

Proper support of keyboard and mouse in textfield is essential for desktop experience, so we gonna continue to work on it. Everything described in "general goals" should be implemented before the beta release of CfD. With exception of "exotic shortcuts", maybe :) It would be great to hear thoughts/vision from Google, especially about Android platform.

Before the next steps I want to finish the current iteration, address some of the comments in merged CL, first of all, better test coverage, then RTL/bidi support.

I also going to write undo/redo doc, where we can discuss options that we have.

jg...@google.com <jg...@google.com> Aug 5, 2019 03:13PM

Status: Duplicate of

133640271