Cwa-app-android: Use ContextCompat when accessing color resources

Created on 16 Dec 2020  路  5Comments  路  Source: corona-warn-app/cwa-app-android

Avoid duplicates

  • [x] This enhancement request has not already been raised before
  • [x] Enhancement request is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
  • [x] If you are proposing a new feature, please do so in CWA-Wishlist

Current Implementation

You are already using ContextCompat when accessing color resources at some locations, but Context.getColor in most others, which is not compatible with API < 23.

In our fork of the app, where I am working on Android 5 support, it is a lot of manual work for me to spot calls to Context.getColor and to replace them with a call that has the same functionality but supports API 21 (like Context.getResources().getColor).

Suggested Enhancement

Use the utility class ContextCompat when accessing color resources everywhere.

Expected Benefits

This would not change any functionality, but it would make things a lot easier for me as a maintainer of our fork, because there would be less discrepancies to keep track of.

If such a PR would get merged, I would like to open one to use this utility class every time color resources are accessed.

Thank you for your consideration.


Internal Tracking ID: EXPOSUREAPP-4419

enhancement mirrored-to-jira

Most helpful comment

Hello @dsarkar, thank you for your input; I have updated the issue to follow the template instead of closing and reopening, I hope that's okay as well.

All 5 comments

Hi @fynngodau, Thanks for contributing here. I order to improve the workflow, I would like to suggest to submit this request using the Enhancement Request template when opening here an issue in this context. If you would be so kind, please, to close this issue and submit a new one using the template. Many thanks and best wishes, DS


Corona-Warn-App Open Source Team

Hello @dsarkar, thank you for your input; I have updated the issue to follow the template instead of closing and reopening, I hope that's okay as well.

@fynngodau, many thanks for updating the post. Issue is forwarded to the developer team. Any news on this issue will be reported here. Best, DS


Corona-Warn-App Open Source Team

I did a quick search through the project and it looks okay to change. I'm not 100% sure how to handle this in unit tests, where the getColor calls also appear.

Mock static? Or maybe mocking an extension function Context.getColorCompat :thinking: .

What would be your preferred solution @fynngodau ?

If such a PR would get merged, I would like to open one to use this utility class every time color resources are accessed.

Should be against release/1.11.x and preferably after #1912 is merged to avoid conflicts.

I am inexperienced with mockk, though as I'm seeing it, you are telling Context what getColor means with these lines:

        every { context.getColor(R.color.colorTextSemanticGreen) } returns R.color.colorTextSemanticGreen
        every { context.getColor(R.color.colorTextSemanticRed) } returns R.color.colorTextSemanticRed

Since ContextCompat calls either Context.getColor or Context.getResources.getColor depending on the SDK version, it looks like it should suffice to add these lines:

        every { context.resources.getColor(R.color.colorTextSemanticGreen) } returns R.color.colorTextSemanticGreen
        every { context.resources.getColor(R.color.colorTextSemanticRed) } returns R.color.colorTextSemanticRed

Depending on the assumption regarding SDK version under which the tests are operating, it might also suffice to replace the first two lines with the second two lines.

Was this page helpful?
0 / 5 - 0 ratings