Fixed
Status Update
Comments
ag...@wayfair.com <ag...@wayfair.com> #2
Thanks for the report. I was puzzled.
[Deleted User] <[Deleted User]> #3
The same for me. Android 4.0.4.
jb...@google.com <jb...@google.com> #4
This is intentional to reduce complexity of Spinner's API and implementation. Consider using a full-blown ListView in a dialog instead.
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #6
I just spent 3 hours on this issue and I disagree that it is "working as intended". If you want to make developers happy, fail fast.
Spinner$DropDownAdapter wraps the client's adapter and shadows getItemViewType() and getViewTypeCount() and simply returns constants. This will never work as intended if the inner adapter has more view types.
I suggest the DropDownAdapter constructor asserts if adapter.getViewTypeCount() != 1.
Spinner$DropDownAdapter wraps the client's adapter and shadows getItemViewType() and getViewTypeCount() and simply returns constants. This will never work as intended if the inner adapter has more view types.
I suggest the DropDownAdapter constructor asserts if adapter.getViewTypeCount() != 1.
ap...@google.com <ap...@google.com> #8
What's going on with this issue?
Description
Component used: Fragment Version used: 1.8.0
Devices/Android versions reproduced on: all
When using
AndroidFragment()
inside a Fragment, FragmentManager will throw an exception when re-creating the parent Fragment's View hierarchy (it cannot find the Child Fragment's View in the ComposeView).This is reproduced in this project:https://github.com/cckroets/AndroidFragmentBug with the following setup:
Navigating to First -> Second is fine. But pressing back, and recreating
FirstTopLevelFragment
will crash the app, due to no View found forNestedInComposeFragment
.