Status Update
Comments
al...@google.com <al...@google.com> #2
ch...@google.com <ch...@google.com> #3
cs...@gmail.com <cs...@gmail.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
al...@google.com <al...@google.com>
al...@google.com <al...@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
ap...@google.com <ap...@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
al...@google.com <al...@google.com> #7
al...@google.com <al...@google.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.
al...@google.com <al...@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
al...@google.com <al...@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}
al...@google.com <al...@google.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.
ap...@google.com <ap...@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.
al...@google.com <al...@google.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.
Description
Component used: appcompat-resources (androidx.appcompat) Version used: 1.1.0 Devices/Android versions reproduced on: OS 4.x (Jelly bean, Kitkat)
Issue Description I am trying to fetch strings via my own
Resources
object for non-English locales. In the attached project, my Hindi string is stored inassets
folder. When I run the app on OS 5 and above, the string is correctly displayed (fetched from assets), whereas, when I run the app on OS 4.3 or (OS < 5.0) it displays English string instead of the correct locale. After debugging I found that when I haveAppCompatDelegate.setCompatVectorFromResourcesEnabled(true)
, on low end devices, it wraps Resources object (my object) intoVectorEnabledTintResources
object. In this class onlygetDrawable
is overridden but the rest of the calls are passed over to the parentResources
object instead ofbaseResources
causing the issue.Suggestion Extend
VectorEnabledTintResources
fromResourcesWrapper
or delegate the rest of the calls to the passedResources
objectAttachments
AppCompatDelegate.setCompatVectorFromResourcesEnabled(false);
AppCompatDelegate.setCompatVectorFromResourcesEnabled(true);