Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
Please include a sample project that reproduces your issue.
ap...@google.com <ap...@google.com> #3
Here is the sample project.
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
ap...@google.com <ap...@google.com> #4
Hello, have you checked sample project? I hope it will help find the issue.
Description
Component used: Fragment
StrictMode
We should build the same type of infrastructure for Fragments so that developers can enable runtime checking for bad behaviors and validate that they (or libraries they depend on) aren't using deprecated APIs or known potential problematic behaviors.
Importantly, this should only be as a second line of defense behind deprecation warnings or Lint warnings to catch these issues at build time or to handle cases where third party libraries / dependencies are triggering these behaviors so that bugs can be filed against them.
We should support at least
penaltyLog()
,penaltyDeath()
, andpenaltyListener()
.Given that we should maintain behavior compatibility, we should not add any
enableDefaults()
ordetectAll()
methods and instead have developers opt into exactly thedetect***()
methods they want. This should also remove the need forpermit***()
methods since they'll all default to off.Ideally, this is something that developers can either:
Set globally via
FragmentStrictMode.setDefaultPolicy(FragmentStrictMode.Policy)
Set on a specific
FragmentManager
(and its childrenFragmentManager
s) viafragmentManager.setStrictModePolicy(FragmentStrictMode.Policy)
(this would override the default policy)This API shouldn't be made public until there is at least two
detect***()
calls added. These will be filed as separate issues.