Fix scale bar text being cut

[jush]

Summary of changes

Fixes rendering issues where the scale bar text was being cut on the sides:

Before:

After:

Also added a new example activity to showcase scale bar customization.

User impact (optional)

Pull request checklist:

• Briefly describe the changes in this PR.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality. If tests were not written, please explain why.
• Optimize code for java consumption (@JvmOverloads, @file:JvmName, etc).
• Add example if relevant.
• Document any changes to public APIs.
• Run make update-api to update generated api files, if there's public API changes, otherwise the verify-api-* CI steps might fail.
• Update CHANGELOG.md or use the label 'skip changelog', otherwise check changelog CI step will fail.
• If this PR is a v10.[version] release branch fix / enhancement, merge it to main firstly and then port to v10.[version] release branch.

Fixes: < Link to related issues that will be fixed by this pull request, if they exist >

PRs must be submitted under the terms of our Contributor License Agreement CLA.

[paulrenn67]

Fix looks good, but wondering about the alignment of the start/end labels, at least the "100m" seems to be differently aligned than in the original screenshot. Should we try to centrally align the labels above the start/end of the scalebar? In this case, the "0" should be more slightly to the left (does not look correctly aligned even in the original) and the "100m" should be more to the right. The "50m" label seems to be correctly centred.

[jush]

Fix looks good, but wondering about the alignment of the start/end labels, at least the "100m" seems to be differently aligned than in the original screenshot. Should we try to centrally align the labels above the start/end of the scalebar? In this case,

The alignment has not changed, but in order for the text to fix we need to "move" it away from the margins. See this video of the behaviour:

scale_bar.mp4

The scale bar layout has a defined width that we should honour. Therefore, the only way I could think to easily fix it is to move the label. If we want a more advanced solution we could try to figure out if the labels fit and if not then reduce the amount of unit bars we show. We will probably need to do that to fix the issue where the labels overlap each other. But that I'd say is for another PR.

the "0" should be more slightly to the left (does not look correctly aligned even in the original) and the "100m" should be more to the right. The "50m" label seems to be correctly centred.

The "0" is left aligned but given the horizontal bearing it renders it a bit to the right. (See https://stackoverflow.com/a/7579469)

[kiryldz]

is it ok that we check x here but operate with safeX below?

[jush]

You're right. It's better to use safeX.

[kiryldz]

and also for better readability I'd use if (x < trokePaint.strokeWidth / 2) similar to L316

[jush]

Hmmm I personally think that:

if (x < trokePaint.strokeWidth / 2)

it's a bit obscure.
I need to think more to figure out why we're comparing a position (x or safeX) with a width (strokeWidth). Somehow, to me, mine reads easier: to position safeX I remove a width and then check if it goes beyond the left minimum position (0).

But happy to change it to your proposal if others also prefer it.

[kiryldz]

should we create similar activity on iOS for parity and making sure that our scalebar customizations are aligned? @mapbox/maps-ios

[kiryldz]

Would be nice to have dedicated pixel match as the tailwork, otherwise LGTM