Fixed
Status Update
No update yet.
Comments
il...@google.com
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Steps to reproduce
Please provide a sample application or apk to reproduce the issue.
Also kindly mention the steps to be followed for reproducing the issue with the given sample application.
Steps to reproduce
Please provide a sample application or apk to reproduce the issue.
Also kindly mention the steps to be followed for reproducing the issue with the given sample application.
ma...@cyberagent.co.jp
Please provide the information as requested in
lc...@gmail.com
We are closing this issue as we don't have enough actionable information. If you are still facing this problem, please open new issue and add the relevant information along with reference to earlier issue.
il...@google.com
I'm not sure who decided there isn't enough information. The description contains the exact steps to reproduce the bug.
However if you follow the instructions here:https://developer.android.com/guide/topics/ui/dialogs#CustomLayout you also will hit this bug.
Basically the android x dialog fragment has the hook to call onCreateDialog in a callback to the layout inflater. However, accessing the layout inflater recursively triggers onCreateDialog...
However if you follow the instructions here:
Basically the android x dialog fragment has the hook to call onCreateDialog in a callback to the layout inflater. However, accessing the layout inflater recursively triggers onCreateDialog...
il...@google.com
ap...@google.com
The bug is essentially in Fragment:
LayoutInflater performGetLayoutInflater(@Nullable Bundle savedInstanceState) {
LayoutInflater layoutInflater = onGetLayoutInflater(savedInstanceState);
mLayoutInflater = layoutInflater;
return mLayoutInflater;
}
Because the layout inflator is not "set" invoking the callback onGetLayoutInflator() which is where onCreateDialog() is invoked will cause the cycle to repeat if you call getLayoutInflater in onCreateDialog()
The fix should be just reordering the code to set the inflater before invoking the callback.
LayoutInflater performGetLayoutInflater(@Nullable Bundle savedInstanceState) {
mLayoutInflater = layoutInflater;
LayoutInflater layoutInflater = onGetLayoutInflater(savedInstanceState);
return mLayoutInflater;
}
LayoutInflater performGetLayoutInflater(@Nullable Bundle savedInstanceState) {
LayoutInflater layoutInflater = onGetLayoutInflater(savedInstanceState);
mLayoutInflater = layoutInflater;
return mLayoutInflater;
}
Because the layout inflator is not "set" invoking the callback onGetLayoutInflator() which is where onCreateDialog() is invoked will cause the cycle to repeat if you call getLayoutInflater in onCreateDialog()
The fix should be just reordering the code to set the inflater before invoking the callback.
LayoutInflater performGetLayoutInflater(@Nullable Bundle savedInstanceState) {
mLayoutInflater = layoutInflater;
LayoutInflater layoutInflater = onGetLayoutInflater(savedInstanceState);
return mLayoutInflater;
}
an...@google.com
Actually that doesn't work, a better solution is to not hook onCreateDialog into the onGetLayoutInflater callback... but there is a nasty dependency between DialogFragment and Fragment that I don't have time to try and resolve.
il...@google.com
Using requireActivity().layoutInflater as is done in the Java code sample in the docs is one workaround until this can be fixed.
Description
Version used: 2.1.0-beta02
Devices/Android versions reproduced on:
When using sharedElementTransition from Fragment A to Fragment B, we call Fragment#postponeEnterTransition first at Fragment B onCreateView.
Then if we press back button or navigate to other fragment before Fragment#startPostponedEnterTransition of Fragment B was called, the following exception will happen when trying to navigate to other fragments.
StackTrace:
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.fragmenttransitionbug, PID: 8900
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean androidx.fragment.app.FragmentManagerImpl.isPrimaryNavigation(androidx.fragment.app.Fragment)' on a null object reference
at androidx.fragment.app.Fragment.performPrimaryNavigationFragmentChanged(Fragment.java:2662)
at androidx.fragment.app.FragmentManagerImpl.dispatchParentPrimaryNavigationFragmentChanged(FragmentManagerImpl.java:2805)
at androidx.fragment.app.FragmentManagerImpl.setPrimaryNavigationFragment(FragmentManagerImpl.java:2800)
at androidx.fragment.app.BackStackRecord.executeOps(BackStackRecord.java:422)
at androidx.fragment.app.FragmentManagerImpl.completeExecute(FragmentManagerImpl.java:1989)
at androidx.fragment.app.FragmentManagerImpl$StartEnterTransitionListener.completeTransaction(FragmentManagerImpl.java:3379)
at androidx.fragment.app.FragmentManagerImpl.executePostponedTransaction(FragmentManagerImpl.java:1769)
at androidx.fragment.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManagerImpl.java:1800)
at androidx.fragment.app.FragmentManagerImpl.execPendingActions(FragmentManagerImpl.java:1727)
at androidx.fragment.app.FragmentManagerImpl$2.run(FragmentManagerImpl.java:150)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Is this the correct behavior?
Since it's a common pattern when using Glide to load a remote image with sharedElementTransition.
We want to call Fragment#startPostponedEnterTransition after the remote image was ready to show.
But the loading can take some time which cause the above situation to happen.
A sample project was attached.
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).