Fixed
Status Update
No update yet.
Comments
il...@google.com
I proposed this which I think it is better than the actual behavior, and could let the developers work with more room to be creative.
https://code.google.com/p/android/issues/detail?id=58318
t....@gmail.com
The presentation link doesn't work.
il...@google.com
In Custom Notification Layouts section of the Notification API Guides, it states: "The height available for a custom notification layout depends on the notification view. Normal view layouts are limited to 64 dp, and expanded view layouts are limited to 256 dp". I guess it means the width is 512 dp and the height is 256 dp (if following the 2:1 aspect ratio)?
http://developer.android.com/guide/topics/ui/notifiers/notifications.html#CustomNotification
t....@gmail.com
Any update on this?
si...@gmail.com
Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here https://goo.gl/TbMiIO and reference this bug for context.
il...@google.com
This has been fixed internally and will be avilable in Fragment 1.3.0-alpha08.
Note: this fix relies on using the
t....@gmail.com
Excellent. Thanks so much!
sm...@gmail.com
I'm experiencing a similiar issue with version 1.3.1. I wrote some instrumented tests using androidx.fragment:fragment-testing:1.2.5 which are supposed to simulate Fragment being minimized (home button) and brought back again. I perform that by calling FragmentScenario.moveToState() to go RESUMED -> CREATED -> RESUMED. With 1.2.5 everything was fine, but after upgrade to 1.3.1 these tests started failing due to onCreateView() being called twice. I've described my problem with greater detail on SO https://stackoverflow.com/questions/66629817/testing-androidx-fragment-lifecycle-by-stopping-and-resuming-with-fragmentscenar .
This issue is already fixed in 1.3.1, so this probably is a problem in my configuration. Or maybe it's a regression ? It'd be helpful if someone experienced in this topic would take a look. I could provide sample project reproducing the issue on github if needed.
This issue is already fixed in 1.3.1, so this probably is a problem in my configuration. Or maybe it's a regression ? It'd be helpful if someone experienced in this topic would take a look. I could provide sample project reproducing the issue on github if needed.
il...@google.com
Re #11 - going from RESUMED -> CREATED will destroy your view (the CREATED state is the state immediately after onCreate() - i.e., before onCreateView()), moving back to up RESUMED will recreate the View. It sounds like Fragment 1.3.1 is working as intended.
Description
Version used:
androidx.navigation:navigation-fragment-ktx:2.2.0-rc01
androidx.navigation:navigation-ui-ktx:2.2.0-rc01
Devices/Android versions reproduced on:
Pixel 3
Android 10
When switching tabs (using BottomNavigation / setupWithNavController()), when the destination Fragment contains a call to postponeEnterTransition() in onCreate() or onCreateView(), the onCreateView() lifecycle method gets called twice. This behavior is visible to the user, via a sort of 'flicker' (depending on the layout), as the fragment's view is recreated.
I suspect this may be due to some code in
`FragmentManager.addAddedFragments(@NonNull ArraySet<Fragment> added)`
It appears the destination Fragment (which invoked postponeEnterTransition()) has moveToState() called on it twice (vie addAddedFragments()). My guess, is that the destination fragment hasn't completed its first moveToState() before the second moveToState() is called, so the secondMoveToState() is attempting to move from a stale state.
I'm not able to provide a sample project for you at this stage.