Fix resume lesson fragment buttons scaling issue

[KevinGitonga]

Fixes #4710, #4362 and also #3833. The second 2 consecutive issues were closed as they might be possibly duplicates of #4710

• Updating width on both the buttons width 0dp actually gives them equal width enabling the button text and child drawables to scale as expected on max display and font config. Main issue is that the currently used width "144dp" doesn't work when the device's display and font config is set to max.

Essential Checklist

• The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• Any changes to scripts/assets files have their rationale included in the PR explanation.
• The PR follows the style guide.
• The PR does not contain any unnecessary code changes from Android Studio (reference).
• The PR is made from a branch that's not called "develop" and is up-to-date with "develop".
• The PR is assigned to the appropriate reviewers (reference).

For UI-specific PRs only

If your PR includes UI-related changes, then:

• Add screenshots for portrait/landscape for both a tablet & phone of the before & after UI changes
• For the screenshots above, include both English and pseudo-localized (RTL) screenshots (see RTL guide)
• Add a video showing the full UX flow with a screen reader enabled (see accessibility guide)
• Add a screenshot demonstrating that you ran affected Espresso tests locally & that they're passing

Before Fix	After Fix
Nexus 5X Api 29

Google Pixel 3XL
|

[KevinGitonga]

Hi @BenHenning the main fix for this issue seems to be replacing the constraint layout with a linear layout as this automatically fixes the weird cutting of the buttons when display and font are scaled to max. The button text is expanded horizontally which can be fixed by adding setting maxLines to "1" which instead add ellipsis to the text. The ellipsis can in turn be prevented when the device is scaled by reducing the large paddings and margins on the views. My thoughts are this issue might be caused by an internal issue with scaling when using constraint layout although i am not sure about this. PTAL and share your thoughts.

[adhiamboperes]

Hi @BenHenning the main fix for this issue seems to be replacing the constraint layout with a linear layout as this automatically fixes the weird cutting of the buttons when display and font are scaled to max. The button text is expanded horizontally which can be fixed by adding setting maxLines to "1" which instead add ellipsis to the text. The ellipsis can in turn be prevented when the device is scaled by reducing the large paddings and margins on the views. My thoughts are this issue might be caused by an internal issue with scaling when using constraint layout although i am not sure about this. PTAL and share your thoughts.

@KevinGitonga, I think ConstraintLayout scales better in these situations than LinearLayout. These two buttons in one container can scale to fit the available space if we give them both an equal and flexible width value - i.e. match_constraint or 0dp, since they are horizonatlly chained to each other.

The default text behaviour in constraint layout is to overflow to the next line, which I think we should keep since elipsizing on really small screens might mean maybe just 2 characters of the whole text being displayed, and no one will know what the button is supposed to do.

You can test this by chaining both buttons to each other and each to the start/end of the container as appropriate.

[KevinGitonga]

Hi @BenHenning the main fix for this issue seems to be replacing the constraint layout with a linear layout as this automatically fixes the weird cutting of the buttons when display and font are scaled to max. The button text is expanded horizontally which can be fixed by adding setting maxLines to "1" which instead add ellipsis to the text. The ellipsis can in turn be prevented when the device is scaled by reducing the large paddings and margins on the views. My thoughts are this issue might be caused by an internal issue with scaling when using constraint layout although i am not sure about this. PTAL and share your thoughts.

@KevinGitonga, I think ConstraintLayout scales better in these situations than LinearLayout. These two buttons in one container can scale to fit the available space if we give them both an equal and flexible width value - i.e. match_constraint or 0dp, since they are horizonatlly chained to each other.

The default behaviour in constraint layout is to overflow to the next line, which I think we should keep since elipsizing on really small screens might mean maybe just 2 characters of the whole text being displayed, and no one will know what the button is supposed to do.

You can test this by chaining both buttons to each other and each to the start/end of the container as appropriate.

Hi @adhiamboperes thanks, giving both the buttons width 0dp actually gives them equal width enabling the button text and child drawables to scale as expected on max display and font config. Also on the ConstraintLayout it is better suited since LinearLayout tends to split the text into multiple lines when scaled to max display and font. Main issue i would for sure say was usage of fixed width in dp. Updating this PR to use changes based on your comment since it makes more sense and also involves less changes to the existing codebase.