Fix: Enable multi-line support for the deck picker footer

[Aditya13s]

Purpose / Description

The purpose of this change is to allow the footer of the deck picker to display multiple lines of text.

Fixes

• Part of UI can't be entirely read when text size is big #17100
• Fixes [BUG]: String of review count at bottom of deck picker screen overflows #14641

Approach

The setSingleLine method has been removed from the DeckPicker.kt file to allow the footer text to display across multiple lines. Additionally, a .replace function was implemented to ensure that newline characters in the text from sched.studiedToday() are replaced with spaces, preventing any text from being hidden.

How Has This Been Tested?

This change has been tested using different font sizes and languages.

Screenshot

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[Arthur-Milchior]

Thank you very much. I appreciate the improvement.

I'll admit that, having the text below the + symbol is not ideal. It's still readable, and I don't expect that this bug is worth doing more effort to find a better design to solve it!

[BrayanDSO]

Kind of similar to what was proposed in #16965, so the comments about the screen edges made by @lukstbit still stands.

Also, the screenshot in the PR description evidently shows that the text can be hidden by the Add button

[Aditya13s]

Kind of similar to what was proposed in #16965, so the comments about the screen edges made by @lukstbit still stands.

Also, the screenshot in the PR description evidently shows that the text can be hidden by the Add button

As @Arthur-Milchior mentioned, this bug isn’t worth further effort and can be addressed in #17334, which completes the migration to edge-to-edge.

[Arthur-Milchior]

@Aditya13s I don't have more authority than @BrayanDSO. I have approved this, but we usually wants to reviewer, and so if the other reivewer does not appreciate, this is up to discussion.
I'm pretty sure Brayan was able to read what I wrote, and simply disagree. He has good argument I didn't even know about (edge-to-edge).

@BrayanDSO Can I ask what would be your preferred solution regarding the button?
Moving it, by ensuring it's above the text? Having the text width be small enough that it does not overlap with the button? (I'd fear we end up needing 3 lines if we don't allow the text to cover the full width of the screen)
I guess we can use Rect.intersects on the rectangle of the text view and the FAB to check whether they intersect, and reduce the width only if it's the case. Not very elegant but it would work.

can be addressed in #17334, which completes the migration to edge-to-edge.

Yeah, but in this case, there is not even a point of landing your change if we suspect we may need to change the result soon after. We should try to fix #14641 simultaneously, given that it consider the same part of the UI.

To be clear, I still believe that your change is an improvement compared to the current state. After all, the total quantity of missing text is quite smaller. But I prefer to have a single merged change that deals with all the issues related to this text view simultaneously

[BrayanDSO]

Moving it, by ensuring it's above the text?

Yes. I believe that it can be easily done by editing only the layout files. There shouldn't be a need to do it programmatically

[lukstbit]

this bug isn’t worth further effort and can be addressed in #17334, which completes the migration to edge-to-edge.

Edge to edge becoming the default affects the interaction between the info text and the screen borders. The bug in the picture isn't related to edge to edge, it's related to the changes you've made in this PR and the interaction between the info text and the fab. So the current "fix" only fixes the issue partially and would result in a new bug report in the near future.

[Aditya13s]

Setting the CoordinatorLayout elevation of the Floating Action Button (FAB) to -1dp gives the right look, but it makes the FAB unclickable because it ends up behind other views.

[lukstbit]

There should be enough space made available for the info text between the screen margin and fab button. It shouldn't be visible below or above the fab button.

[Aditya13s]

This is the final output

[Arthur-Milchior]

Clearly this result looks nicer. I admit I regret that it moves the FAB even when the text is small. I'd have preferred if we had a way to ensure it remains at the same place if possible.

I admit I really don't know XML layout enough to know how to do that.
I guess we should have a RelativeLayout that contains the today_stats_text_view at the bottom, and a layout that contains both the deck list and the fab at the top.
But that needs a serious rewrite of deck_picker.xml

[Aditya13s]

Clearly this result looks nicer. I admit I regret that it moves the FAB even when the text is small. I'd have preferred if we had a way to ensure it remains at the same place if possible.

Fixed it by dynamically adjusting the layout's bottom margin. If the line count is greater than 1, the margin changes; if it's 1, no change occurs.

[Aditya13s]

@BrayanDSO Please review the changes

[Aditya13s]

@lukstbit Merge Conflicts Resolved. Please review this.