fix: calculate the better contrasting color

[rros]

…he contrast of both foreground colors against the background color.

Type of change(s)

• Bug fix
• Feature / enhancement
• Infrastructure / tooling (CI, build, deps, tests)
• Documentation

What changed and why

Fixed the way the contrast color is calculated. The old method uses the current color DARK_GREY and WHITE. The new overload allows for arbitrary colors, so we can i.e. also compare BLACK and WHITE in the consuming app without changing the colors for every consumer.

Tests performed

I tested this implementation in the Calendar app at a single location.

Before & after preview

Before with a background #66C791:

After with the same background:

Closes the following issue(s)

This change is needed to properly address: FossifyOrg/Calendar#992

Checklist

• I read the contribution guidelines.
• I manually tested my changes on device/emulator (if applicable).
• I updated the "Unreleased" section in CHANGELOG.md (if applicable).
• I have self-reviewed my pull request (no typos, formatting errors, etc.).
• I understand every change in this pull request.

[naveensingh]

Looks good. Commons will be updated soon.

[rros]

@naveensingh I just realised two things that might have some impact:

1. for calculateContrast() to work, the background must be opaque. When the alpha channel for a background color is not opaque. The method will throw an IllegalArgumentException. It seem to break at least the Calendar widget, because the background of those widgets are partially transparant. I'll look into a solution for this.
2. The calculation might be heavier than the old calculation. This might have an impact if the method is called many times without caching any result.

[naveensingh]

for calculateContrast() to work, the background must be opaque. When the alpha channel for a background color is not opaque. The method will throw an IllegalArgumentException. It seem to break at least the Calendar widget, because the background of those widgets are partially transparant. I'll look into a solution for this.

Sadly, I found out about that after the merge.

The calculation might be heavier than the old calculation. This might have an impact if the method is called many times without caching any result.

It should be light enough. We'll see.