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

feat: edge-to-edge mode on Android #52392

Merged
merged 26 commits into from
Nov 25, 2024
Merged

Conversation

kirillzyusko
Copy link
Contributor

@kirillzyusko kirillzyusko commented Nov 12, 2024

Explanation of Change

  • Enabled edge-to-edge mode (removed a patch from keyboard-controller)
  • implemented custom KeyboardAvoidingView for Android - ideally we should use the implementation from react-native-keyboard-controller, but in this case animations have a very poor performance and it's better to investigate/fix as a separate issue
  • applied a patch for Modal (that adds navigationBarTranslucent property - applied for react-native and react-native-modal)

Linked HybridApp PR: https://github.com/Expensify/Mobile-Expensify/pull/13299

Fixed Issues

$ #51673
$ #52116
PROPOSAL: #52116 (comment)

Tests

  • Go through the all screens in the app and be sure keyboard avoiding works as before (test on Android < 12 with 3 buttons navigation bar type and on Android 12+ with gesture navigation bar type);
  • Make sure that on Samsung devices when device has light theme and you turn on dark theme in app the navigtion bar has a dark color (i. e. matches the app preferences)

Offline tests

N/A

QA Steps

  • Go through the all screens in the app and be sure keyboard avoiding works as before (test on Android < 12 with 3 buttons navigation bar type and on Android 12+ with gesture navigation bar type);
  • Make sure that on Samsung devices when device has light theme and you turn on dark theme in app the navigtion bar has a dark color (i. e. matches the app preferences)
  • [HybridApp ONLY] Test app switching between NewDot and OldDot to ensure no styling bugs occur after this transition

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
    • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android: Native
    • Android: mWeb Chrome
    • iOS: Native
    • iOS: mWeb Safari
    • MacOS: Chrome / Safari
    • MacOS: Desktop
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
      • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
    • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
    • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • I verified that if a function's arguments changed that all usages have also been updated correctly
  • If any new file was added I verified that:
    • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
    • I verified that all the inputs inside a form are aligned with each other.
    • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
  • If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop

@kirillzyusko
Copy link
Contributor Author

@shawnborton would it be possible to ask you to test this PR? This PR should unify how Android app is handling insets (now it'll be identical to iOS). This PR is a logical continuation of this #51956 but the key difference is that now we don't manage color of navigation bar independtly - now we make all system bars (navigation bar, status bar) transparent by default, so it matches iOS app style.

The reason why I want you to test and give your feedback, is because some elements look good on iOS, but looks not very good on Android. For example, navigation bar padding on Android vs iOS:

Coefficient Android iOS
0.7 (default for iOS)
1

This is the one issue I spotted at the moment, but maybe you find more - your feedback is very valuable 🙏

@mountiny would it be possible to trigger a build so that @shawnborton can test the app?

@shawnborton
Copy link
Contributor

I can trigger a test build. I don't have an Android with me at the moment but I believe @dubielzyk-expensify can help us test!

@kirillzyusko
Copy link
Contributor Author

but I believe @dubielzyk-expensify can help us test!

Sounds good! Any look from UX/UI team will help a lot ❤️

@shawnborton
Copy link
Contributor

We might need to take the PR out of draft in order to run the test build. If we don't get a test build posted in the next 20 minutes or so, let's try that.

This comment has been minimized.

@shawnborton
Copy link
Contributor

Well wouldya just look at that, ready for testing.

@mountiny
Copy link
Contributor

Assigned @c3024 for c+ review

@dubielzyk-expensify
Copy link
Contributor

Tested this on Android now. Definitely agree with this comment that we should add some tiny padding above the home indicator. Scenarios where we use cards get a bit weird so hopefully that'll fix this too:
CleanShot 2024-11-13 at 11 37 18@2x

I'm not sure exactly where the padding is applied, but the footer buttons seem to get excessive padding on some screens:
CleanShot 2024-11-13 at 11 36 35@2x
CleanShot 2024-11-13 at 11 37 06@2x

Other than that, this is looking good.

I think in an ideal world, I'd prefer both home indicators on iOS and Android to be transparent instead of using appBg color, but that's probably a separate PR and issue altogether.

@shawnborton
Copy link
Contributor

Nice testing Jon, thanks for running through the screens and I agree with your feedback.

@kirillzyusko
Copy link
Contributor Author

Awesome @dubielzyk-expensify ! 🔥 Thank you for your feedback!

@mountiny
Copy link
Contributor

Do we need a new build @kirillzyusko

@kirillzyusko
Copy link
Contributor Author

@mountiny no, not yet. Tomorrow I want to test on more devices and if everything works well, then I will ask for additional testing 😊

package.json Outdated
@@ -113,6 +113,7 @@
"expo-av": "14.0.7",
"expo-image": "1.12.15",
"expo-image-manipulator": "12.0.5",
"expo-navigation-bar": "~3.0.7",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to add this library again, because we need to manage navigation bar button style (dark/light).

Since user can customize the theme of app independently to device settings we also have to manage it dynamically from JS code.

I checked and one method that we use (setButtonStyleAsync) doesn't use deprecated API. However I remember, that this particular library wasn't accepted in the first round of fixing the nav bar color management, so i'm happy to discuss further steps here 🙌

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kirillzyusko I noticed you are adding the library here again even though in Slack we agreed not to use it https://expensify.slack.com/archives/C01GTK53T8Q/p1731618817760309?thread_ts=1731092817.909359&cid=C01GTK53T8Q

Can you please come back to the thread and summarize the problems you are facing with not using the library or explain clearly why we cannot just handle this on our own? Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Vit, I missed this but agree with needing to discuss this further.

Copy link
Contributor

🚧 @mountiny has triggered a test build. You can view the workflow run here.

Copy link
Contributor

Copy link
Contributor

@mountiny mountiny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small comments

Copy link
Contributor

🚧 @mountiny has triggered a test build. You can view the workflow run here.

Copy link
Contributor

@mountiny
Copy link
Contributor

@c3024 let us know when you complete the testing please! thanks!

Copy link
Contributor

@c3024 c3024 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Android: Native
WhatsApp.Video.2024-11-25.at.20.52.49.mp4
WhatsApp.Video.2024-11-25.at.21.28.15.mp4
Android: mWeb Chrome
WhatsApp.Video.2024-11-25.at.20.57.38.mp4
iOS: Native
RPReplay_Final1732548627.MP4
iOS: mWeb Safari
RPReplay_Final1732548716.MP4
MacOS: Chrome / Safari
endChrome.mov
MacOS: Desktop
Screen.Recording.2024-11-25.at.9.23.19.PM.mov

Tests well!

@melvin-bot melvin-bot bot requested a review from Julesssss November 25, 2024 15:59
Copy link
Contributor

@mountiny mountiny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@mountiny
Copy link
Contributor

Mobile-Expensify pr merged

@mountiny mountiny merged commit 6cb0256 into Expensify:main Nov 25, 2024
18 checks passed
@OSBotify
Copy link
Contributor

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

Copy link
Contributor

🚀 Deployed to staging by https://github.com/mountiny in version: 9.0.67-0 🚀

platform result
🤖 android 🤖 false ❌
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅
🤖🔄 android HybridApp 🤖🔄 success ✅
🍎🔄 iOS HybridApp 🍎🔄 success ✅

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

Successfully merging this pull request may close these issues.

7 participants