Status Update
Comments
jo...@gmail.com <jo...@gmail.com> #2
ar...@google.com <ar...@google.com>
je...@google.com <je...@google.com>
ga...@google.com <ga...@google.com> #3
ga...@google.com <ga...@google.com> #4
Branch: androidx-master-dev
commit d3c7e85f798b804ef66da955f79f2d162aa20452
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Dec 17 11:27:36 2019
Ensure StrictFragment does not ascend state with destroyed activity
Added a check to make sure that when a StrictFragment is going up in
state, its activity is not destroyed. Put checks in onCreateView and
onCreatedView of StrictViewFragment too.
Test: all tests pass
BUG: 144309266
Change-Id: Iefe2031c0c40ba603dd83d257a255bf5df278dc3
M fragment/fragment/src/androidTest/java/androidx/fragment/app/StrictViewFragment.kt
M testutils/testutils-runtime/src/main/java/androidx/fragment/app/StrictFragment.kt
ga...@google.com <ga...@google.com> #5
Branch: androidx-master-dev
commit c03c0e0ebfaca4b1b342dad0270489107ea4c73d
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Dec 17 11:35:33 2019
Change FragmentFinishEarlyTest to use StrictFragment
The goal of the FragmentFinishEarlyTest is to ensure that the Fragment
state is not raised while the activity is being destroyed.
StrictFragment now checks if the activity is being destroyed in all of
the upward states (onCreate, onStart, etc.) so we should just use that
instead of a custom Fragment with booleans.
Test: all tests pass
BUG: 144309266
Change-Id: Ic47a178c50bcbba246b91e2e25d969dd6931d765
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentFinishEarlyTest.kt
ga...@google.com <ga...@google.com> #6
Branch: androidx-master-dev
commit 3d9b247656fd46ebd17b1cd9743e163afe85f3d6
Author: Ian Lake <ilake@google.com>
Date: Thu Jan 09 11:15:06 2020
Remove most usages of onActivityCreated()
Update demos and tests to use onViewCreated()
instead of onActivityCreated().
Test: ./gradlew bOS
BUG: 144309266
Change-Id: Icc0d43554f014c42db1068dfe6410cc191e21818
M fragment/fragment/src/androidTest/java/androidx/fragment/app/LoaderTest.kt
M samples/Support4Demos/src/main/java/com/example/android/supportv4/app/FragmentLayoutSupport.java
M samples/Support4Demos/src/main/java/com/example/android/supportv4/app/FragmentListArraySupport.java
M samples/Support4Demos/src/main/java/com/example/android/supportv4/app/FragmentPagerSupport.java
M samples/Support4Demos/src/main/java/com/example/android/supportv4/app/FragmentStatePagerSupport.java
M samples/Support4Demos/src/main/java/com/example/android/supportv4/app/LoaderCursorSupport.java
M samples/Support4Demos/src/main/java/com/example/android/supportv4/app/LoaderCustomSupport.java
M samples/Support4Demos/src/main/java/com/example/android/supportv4/app/LoaderThrottleSupport.java
ga...@google.com <ga...@google.com> #7
i....@gmail.com <i....@gmail.com> #8
With the removal of this what is the proper and easy way to know when the view is actually attached to parent?
Going edge to edge with BottomSheetDialogFragment force us to get the view parents to disable fitsSystemWindows and handling this properly.
Unfortunately the view is not yet attached during the call to onViewCreated and onActivityCreated is the best place.
From your initial post I suppose onViewStateRestored is the new proper callback, but the name is counter intuitive and I initially thought that this would not have been called on first creation as nothing to restore.
so...@google.com <so...@google.com> #9
Re #8 - onActivityCreated()
runs onViewCreated()
, so the state you're in would be exactly the same between the two calls.
We've been meaning to make it more consistent whether you're attached or not in onViewCreated()
for a while here (as it turns out right now you could be in either case), I've created
so...@google.com <so...@google.com> #10
It seems the new beta tracker does not automatically watch issues on comment did not receive this answer :(.
Anyway with Fragment 1.2.1 in BottomSheetDialogFragment this is not the case.
override fun onActivityCreated(savedInstanceState: Bundle?) {
super.onActivityCreated(savedInstanceState)
logError("TAG") { "onActivityCreated: ${view?.parent?.parent?.parent}" }
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
logError("TAG") { "onViewCreated: ${this.view?.parent?.parent?.parent}" }
logError("TAG") { "onViewCreated: ${view.parent?.parent?.parent}" }
}
override fun onViewStateRestored(savedInstanceState: Bundle?) {
super.onViewStateRestored(savedInstanceState)
logError("TAG") { "onViewStateRestored: ${this.view?.parent?.parent?.parent}" }
}
Always and consistently gives:
2020-02-10 18:48:24.498 31061-31130/XXX E/TAG: BaseBottomSheetDialogFragment.onViewCreated@63: onViewCreated: null
2020-02-10 18:48:24.499 31061-31130/XXX E/TAG: BaseBottomSheetDialogFragment.onViewCreated@64: onViewCreated: null
2020-02-10 18:48:24.519 31061-31129/XXX E/TAG: BaseBottomSheetDialogFragment.onActivityCreated@58: onActivityCreated: android.widget.FrameLayout{f46459f V.E...... ......I. 0,0-0,0 #7f0a0137 app:id/container}
2020-02-10 18:48:24.520 31061-31129/XXX E/TAG: BaseBottomSheetDialogFragment.onViewStateRestored@70: onViewStateRestored: android.widget.FrameLayout{f46459f V.E...... ......I. 0,0-0,0 #7f0a0137 app:id/container}
i....@gmail.com <i....@gmail.com> #11
So Ian the issue is about DialogFragment:
Seems this is also not changed in your 1.3.0 commit listed here, would be nice that it is and that onViewCreated works in that case too if possible or find a proper common ways that works for all cases.
so...@google.com <so...@google.com> #12
Work hasn't completed on this bug (which is why it isn't marked as 'Fixed') - DialogFragment
is one of the things we're still looking at.
i....@gmail.com <i....@gmail.com> #13
Was just commenting about the fact that those 2 events are not the same for dialog fragment despite the link you gave.
Since I'm rewriting a lot of stuff, I wonder what will be the final target for 1.3?
- onViewCreated will be attached for every cases
- onViewStateRestored will be attached for every cases
- This is still not determined and maybe not done for 1.3 so I should not bother yet.
so...@google.com <so...@google.com> #14
This bug is solely about onActivityCreated
. If you want to talk about onViewCreated
, let's move the conversation onto
If you want a foolproof signal for the View being attached, you should look at the View layer and doOnAttach
from core-ktx
. You don't need anything at the Fragment layer.
so...@google.com <so...@google.com> #15
I think there's a communication issue here :) My issue is about onActivityCreated
I don't care what is the replacement I just need to know what it will be :)
You tell me that onActivityCreated
and onViewCreated
are the same as called side by side, this is as proven unfortunately not true for dialog fragments that are fragments.
onActivityCreated
is the only callback that is made after the view is properly attached and things are all tied up.
Since you deprecate onActivityCreated
my question is unchanged what is / will be the proper callback for dialog fragment that ensure the same state as currently.
Description
When trying to targeting the new Android 14 beta version on my Android project, I get build errors trying to compile modules with Java classes containing lambda functions (like the one attached).
I know there was a recent issue in JDK 11 that caused these compilation error.
However, I'm using the latest OpenJDK 11 version (11.0.18).
I confirmed that this only occurs when trying to target Android 14. When targeting Android 13 this does not occur.
This is problematic since I've not found any other way to fix this build issue other than upgrading Java version to 12 or above, which is not feasible on my project.
STEPS TO REPRODUCE:
1. Build an app containing lambda functions, targeting Android 14 and using Java 11
ATTACH SCREENSHOTS/RECORDINGS OF THE ISSUE
ATTACH LOG FILES (Select Help > Show Log in Files, or Show Log in Finder on a Mac)
------------------
IMPORTANT: Please read
all required information.
------------------
Studio Build: Android Studio Flamingo | 2022.2.1 (Build #AI-222.4459.24.2221.9862592)
Version of Gradle Plugin: 7.4.2
Version of Gradle: 7.5
Version of Java: 11.0.18
OS: Mac OS 13.3.1