Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use DialogFragment for Phone Number Integration #3738

Merged
merged 2 commits into from
Mar 22, 2024
Merged

Conversation

parneet-guraya
Copy link
Contributor

Fixes: #3737

πŸ–ΌοΈ Screenshots

Record_2024-03-20-22-05-33.mp4

🏁 Checklist

  • ⛑️ Tests (unit and/or integration) are included or not needed
  • πŸ”– Capability is checked or not needed
  • πŸ”™ Backport requests are created or not needed: /backport to stable-xx.x
  • πŸ“… Milestone is set
  • 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

@parneet-guraya parneet-guraya requested a review from mahibi March 20, 2024 16:39
@parneet-guraya parneet-guraya self-assigned this Mar 20, 2024
@parneet-guraya parneet-guraya added the 3. to review Waiting for reviews label Mar 20, 2024
@parneet-guraya parneet-guraya changed the title Use dialog fragment for Phone Number Integration Use DialogFragment for Phone Number Integration Mar 20, 2024
@mahibi
Copy link
Collaborator

mahibi commented Mar 21, 2024

Good question from @parneet-guraya copied from public chat:

"Hi πŸ‘‹ . In some places we are using AlertDialog Builder to show a dialog instead of a DialogFragment. As a result neither they retain state nor they survive configuration changes. I was wondering if we should convert those to use DialogFragment as well?
Or should we keep the simpler ones (yes/no) as is (to avoid creatingseparate files but again they won't survive config change) and convert those which have some state to retain?"

@mahibi
Copy link
Collaborator

mahibi commented Mar 21, 2024

Good question from @parneet-guraya copied from public chat:

"Hi πŸ‘‹ . In some places we are using AlertDialog Builder to show a dialog instead of a DialogFragment. As a result neither they retain state nor they survive configuration changes. I was wondering if we should convert those to use DialogFragment as well? Or should we keep the simpler ones (yes/no) as is (to avoid creatingseparate files but again they won't survive config change) and convert those which have some state to retain?"

I am still undecided. Maybe this behavior could be fixed when switching to more modern solutions like Jetpack Compose etc.?
So maybe it's worth it to keep it like it is until then, instead to create more xml layouts.
Anyone with opinions on this?

@parneet-guraya
Copy link
Contributor Author

I am still undecided. Maybe this behavior could be fixed when switching to more modern solutions like Jetpack Compose etc.? So maybe it's worth it to keep it like it is until then, instead to create more xml layouts. Anyone with opinions on this?

I think we should atleast use DialogFragment for Dialogs those have some state. Otherwise it is bad experience for the user if the dialog loose state for eg. Dialogs with Text fields like this one. It should retain whatever user has typed in.

let me know your thoughts :-)

@sowjanyakch
Copy link
Contributor

sowjanyakch commented Mar 22, 2024

@parneet-guraya I agree that it is a bad user experience.

If there are many AlertDialogs, I prefer to use Jetpack Compose. In Jetpack Compose, we can reuse the composable with custom styles and content. Managing state also becomes easier.

The approach you are mentioning creates many xml layouts. These files will be anyways converted to Jetpack Compose eventually.

parneet-guraya and others added 2 commits March 22, 2024 12:56
Signed-off-by: rapterjet2004 <[email protected]>
Signed-off-by: Marcel Hibbe <[email protected]>
@mahibi
Copy link
Collaborator

mahibi commented Mar 22, 2024

Lets merge this one as it definitely improves the dialog.
I did not have a look how many other dialogues may be affected. From my side it's not high priority and i would prefer to wait to check this after we migrated to Jetpack Compose.

@mahibi mahibi merged commit 7a64c53 into master Mar 22, 2024
14 of 16 checks passed
@mahibi mahibi deleted the set-mob-dialog branch March 22, 2024 12:01
Copy link
Contributor

Codacy

Lint

TypemasterPR
Warnings8081
Errors1010

SpotBugs

CategoryBaseNew
Bad practice66
Correctness88
Dodgy code110110
Internationalization33
Malicious code vulnerability33
Performance66
Security11
Total137137

Lint increased!

Copy link
Contributor

APK file: https://www.kaminsky.me/nc-dev/android-artifacts/3738-talk.apk

qrcode

To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud Talk app.

@AndyScherzinger AndyScherzinger added this to the 19.0.0 milestone Mar 22, 2024
Copy link
Contributor

github-actions bot commented Apr 4, 2024

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Dialog's Text Field does not adapt to dark/light modes and does not retain state.
5 participants