Status Update
No update yet.
Comments
il...@google.com
Branch: androidx-main
commit b9b1326edfe38588a9882e1ee624798966c5686a
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Oct 06 16:49:53 2021
Clear focus on Fragments animating out
Since moving to the new state manager, fragment now explicitly handle
focus where in the old world they could ignore it altogether. This
change has the side effect that other things affected by focus (i.e.
soft keyboard input) are affect as well. In particular when we
requestFocus we update the input request, but since we never clear it
users have to manually remove the input.
When we are animating a fragment view out, since we will no longer be
using the exiting view, let clear the focus of before we remove it from
the fragment.
RelNote: "The keyboard will now close automatically when going from
a fragment with an open keyboard to a fragment with a recycler view."
Test: tested in sample app from bug
Bug: 196852211
Change-Id: I8b842dd9a421cfbc9189014b802f5e4b6b9c2a47
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
sg...@google.com
This has been fixed internally and will be available in the Fragment 1.4.0-beta01 release.
ap...@google.com
il...@google.com
We've fixed the ProGuard rules and it'll be available in the upcoming Fragment 1.3.0-alpha01 (and if we do a Fragment 1.2.3, it'll also be a part of that).
an...@google.com
tb...@gmail.com
Maybe this is intentional, but I updated my project to androidx fragments 1.2.3 (from 1.2.2), and now necessary fragments ("MyFragment" below) that used to be kept are now being stripped by R8. The fragment in question is referenced in a layout that is set using setContentView() on an activity.
<androidx.fragment.app.FragmentContainerView
android:id="@+id/fragment_id"
android:name="com.mycompany.MyFragment"
android:layout_width="match_parent"
android:layout_height="match_parent" />
AGP 3.6.1. Not sure how I'm supposed to keep it now. It has normal default constructor and has androidx.fragment.Fragment in the superclass hierarchy.
il...@google.com
Re #7 - that's unrelated and expected when using AGP 3.6.1 as per the
The only reason that it "worked" in Fragment 1.2.2 was because all Fragments were being kept if even one Fragment was being kept (which is what this bug fixed).
dy...@gmail.com
What's the reason for having Proguard rules included with the Fragment library in the first place?
I'm asking because right now, this rule is actually preventing me from obfuscating, shrinking and optimizing my fragments for reasons I don't understand. One reason I could think of is reflection. Instead, is it possible to completely remove them and suggest developers to add these rules themselves?
il...@google.com
Re #9 - please star
Description
Component used: Fragment Version used: Master as of Feb 17 2020
Just noticed the Proguard rule which was added in ag/1216798 (and updated in ag/1227696), which looks like this:
I think the
**in the conditional-keepshould have been<1>to refer back to the class implementingandroidx.fragment.app.Fragment(and then theextendspart does not matter then). Otherwise if one class extendsandroidx.fragment.app.Fragmentthen the default constructor for all classes extendingandroidx.fragment.app.Fragmentwill be kept.Like this: