Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
ap...@google.com
Please include a sample project that reproduces your issue.
il...@google.com
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
Hello, have you checked sample project? I hope it will help find the issue.
Description
Version used: 1.2.4
Devices/Android versions reproduced on: any
Fragment.getDefaultViewModelProviderFactory() makes a call to requireActivity() in order to obtain an instance of Application. This will fail if the Fragment is hosted in a FragmentHostCallback that doesn't reference an Activity (i.e. its context is not an Activity). getDefaultViewModelProviderFactory() and onCreateContextMenu() (which doesn't make sense for non-Activity Fragments) are the only places requireActivity() is used. Everywhere else uses get/requireContext() or allows getActivity() to return null.
Because Fragments are so prevalent, this makes the entire HasDefaultViewModelProviderFactory interface untrustworthy in codebases that may have non-Activity Fragments.
A simple fix would be to return a NewInstanceFactory() if mFragmentManager is non-null but getActivity() is null. This wouldn't support AndroidViewModels, but other ViewModels would still be able to be instantiated. Expanding SavedStateViewModelFactory to not require an Application would also help since the SavedStateHandler infrastructure doesn't appear to require the Application for anything else. Ideally, the Application would be able to be obtained elsewhere for non-Activity Fragments, but not supporting AndroidViewModels would be an acceptable trade off if that's not possible.
A less ideal solution would be to add another constructor to AndroidViewModels that takes a Context for use when an Application is not available, but that would clutter the API and is probably not worth it.