ANDROID-17173 Add Sheet dismiss action

[dagonco]

🥅 What's the goal?

This PR refactors the sheet component's dismiss mechanism by replacing the draggable handler with a dedicated close button in the title area.

Figma Sheet Spec

🚧 How do we do it?

• Replaced the top handler ImageView with an ImageButton close button positioned in the title constraint layout
• Removed the Space element and its associated logic for managing title spacing

☑️ Checks

• I updated the documentation, including readmes and wikis. If this is a breaking change, tag the PR with "Breaking Change" label and remember to include breaking change migration guide in release notes where this version is released.
• Tested with dark mode.
• Tested with API 24.
• Sync done with iOS team for this feature to ensure alignment, if applies.
• Accessibility considerations.

🧪 How can I test this?

• 🖼️ Screenshots/Videos
• Mistica App QR or download link
• Reviewed by Mistica design team

Before	After

[Copilot]

Pull request overview

This PR refactors the sheet component's dismiss mechanism by replacing the draggable handler with a dedicated close button in the title area.

Changes:

• Replaced the top handler ImageView with an ImageButton close button positioned in the title constraint layout
• Removed the Space element and its associated logic for managing title spacing
• Updated catalog input field to use number input type

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
library/src/main/res/layout/sheet_layout.xml	Replaced draggable handler with close button; wrapped title in ConstraintLayout; removed nested ScrollView and Space element
library/src/main/java/com/telefonica/mistica/sheet/Sheet.kt	Updated references from handler to close_button; removed Space import and setSpaceOrGone extension function
catalog/src/main/res/layout/screen_fragment_sheet_catalog.xml	Added number input type to the input field

[Copilot]

Using a transparent background for an interactive button can cause touch target visibility issues. Consider using a selector drawable with a ripple effect or state-based background to provide visual feedback when the button is pressed or focused.

Suggested change

	android:background="@android:color/transparent"
	android:background="?attr/selectableItemBackgroundBorderless"

[dagonco]

Hello @aweell, @copilot has a point here.
This specific button was copied from:

mistica-android/library/src/main/res/layout/callout_view.xml

Lines 11 to 23 in d19f6f8

	<ImageButton
	android:id="@+id/callout_close_button"
	app:layout_constraintTop_toTopOf="parent"
	app:layout_constraintRight_toRightOf="parent"
	android:background="@android:color/transparent"
	android:layout_width="40dp"
	android:layout_height="40dp"
	android:layout_marginTop="8dp"
	android:layout_marginStart="8dp"
	android:layout_marginEnd="4dp"
	android:src="@drawable/icn_cross"
	android:contentDescription="@string/close_button_content_description"
	/>

Tell me if you need any changes to be made 😁
TLDR: With "transparent" there is no ripple effect on a press event.

[github-actions]

[Firebase] 📱 New catalog for testing generated:
Download from Firebase
Download from App Tester

[github-actions]

[Firebase] 📱 New catalog for testing generated:
Download from Firebase
Download from App Tester

[dagonco]

I have an important question. Previously, the A11Y navigated as follows:

• Handler: As a button to close the sheet
• Title

Now, according to the spec, it's the opposite. I understand that this is expected, although personally, as a user, I find it strange that the order has been changed. And I don't know if this might give the user the impression that there's no more information and by that the user could close the Sheet.

[hjorrod]

I don't know how the user usually navigates but I think that if you are not able to see and read the full screen, you will navigate through the screen before taking an action.

[dagonco]

Yeah, that's the dilemma I had. I'd wait until design double check that is intended/expected.

[haynlo]

Good point! The WCAG guidelines don't strictly define an ideal focus order, but rather recommend that it be logical and coherent with the content being presented, leaving some flexibility in how it's implemented.

Imho, the key point here is to ensure that this focus order is intentional and considered the best option for this scenario. @aawell, just to confirm this matches the intended a11y behavior.

Focus order is something that may be reviewed by the OB (like Vivo) or during accessibility audits, so having a clear and defensible rationale for this choice is important.

[haynlo]

Nice! 🙌🏼
I’ve just left a note with my point of view regarding the a11y focus order.

[haynlo]

Good point! The WCAG guidelines don't strictly define an ideal focus order, but rather recommend that it be logical and coherent with the content being presented, leaving some flexibility in how it's implemented.

Imho, the key point here is to ensure that this focus order is intentional and considered the best option for this scenario. @aawell, just to confirm this matches the intended a11y behavior.

Focus order is something that may be reviewed by the OB (like Vivo) or during accessibility audits, so having a clear and defensible rationale for this choice is important.