Skip to content

MAGE-323: safe zone handling#432

Open
amber-klaviyo wants to merge 3 commits intoMAGE-328from
MAGE-323
Open

MAGE-323: safe zone handling#432
amber-klaviyo wants to merge 3 commits intoMAGE-328from
MAGE-323

Conversation

@amber-klaviyo
Copy link
Copy Markdown

@amber-klaviyo amber-klaviyo commented Apr 6, 2026

Description

handle the safe zones on the native side- add any necessary safe zone to the user provided offset

Just safezone:
Before:
Screenshot 2026-04-09 at 11 59 25 AM

After:
Screenshot 2026-04-09 at 11 53 19 AM

Safezone + User set offset of 100:
Before:
Screenshot 2026-04-09 at 11 58 57 AM

After:
Screenshot 2026-04-09 at 11 54 05 AM

Due Diligence

  • I have tested this on an emulator and/or a physical device.
  • I have added sufficient unit/integration tests of my changes.
  • I have adjusted or added new test cases to team test docs, if applicable.
  • I am confident these changes are compatible with all Android versions the SDK currently supports.

Release/Versioning Considerations

  • Patch Contains internal changes or backwards-compatible bug fixes.
  • Minor Contains changes to the public API.
  • Major Contains breaking changes.
  • Contains readme or migration guide changes.
    • If so, please merge to a feature branch so documentation updates only go live upon official release.
  • This is planned work for an upcoming release.
    • If no, author or reviewer should account for this in a release plan, or describe why not below.

Changelog / Code Overview

Test Plan

Related Issues/Tickets

@amber-klaviyo amber-klaviyo marked this pull request as ready for review April 9, 2026 15:29
@amber-klaviyo amber-klaviyo requested a review from a team as a code owner April 9, 2026 15:29
@klaviyoit klaviyoit requested a review from ab1470 April 9, 2026 15:29
Copy link
Copy Markdown
Contributor

@dan-peluso dan-peluso left a comment

Choose a reason for hiding this comment

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

Code looks good, but could you upload some before / after screenshots just so I can see the difference

*
* @param safeAreaTop Top safe area inset in pixels
* @param safeAreaBottom Bottom safe area inset in pixels
*/
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: "Dynamic Island" is iOS terminology — on Android the equivalents are display cutouts / camera holes / punch holes. Might confuse future Android devs reading this.

FormPosition.TOP,
FormPosition.TOP_LEFT,
FormPosition.TOP_RIGHT -> screenHeight - topOffset - formHeight
FormPosition.TOP_RIGHT -> screenHeight - safeAreaTop - topOffset - formHeight
Copy link
Copy Markdown
Contributor

@evan-masseau evan-masseau Apr 9, 2026

Choose a reason for hiding this comment

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

The offset calculation logic (safe area + user offset, gravity-dependent direction, bottom gap for keyboard overlap) has enough moving parts that it'd be easy to regress. Would be nice to have unit tests covering at least the core cases — could extract the pure math into a testable helper. The PR template test checkbox is also unchecked.

(claude review pointed out this is not covered by tests, if that was incorrect, ignore this comment)

Copy link
Copy Markdown
Contributor

@evan-masseau evan-masseau left a comment

Choose a reason for hiding this comment

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

Overall this LGTM. I'd say lets try to boost the tests before the base PR goes into the feature branch, but this one's fine as-is. I will leave a comment with some analysis from Claude about test coverage.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants