Feature Request P2
Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #2
Please include a sample project that reproduces your issue.
lu...@gmail.com <lu...@gmail.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?
ti...@gmail.com <ti...@gmail.com> #4
Hello, have you checked sample project? I hope it will help find the issue.
Description
Component used: Activity
Version used: 1.7.0
Currently the class is almost entirely focused on the caller side - the side starting the Intent and then parsing its result.
ActivityResultContract
However, for the apps that are on the receiving side, there aren't any APIs for extracting the input back into something type safe, nor for building the Intent to send the output back to the caller.
You'd also need some method for distinguishing between an Intent that doesn't match the caller side (e.g., they didn't actually use
TakePicture
to fill in the right fields) from a null input (which could certainly be a valid input). That type of method would look at other fields in the Intent such as theaction
to verify the validity of the input field.It would be helpful if the contract APIs were extended to equally support both the caller and receiver so that both sides could be type safe.