Bug 36396 - TextView.SetTextColor and SetBackgroundColor do not have overloads to take an int
Summary: TextView.SetTextColor and SetBackgroundColor do not have overloads to take an...
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 6.0.0
Hardware: Macintosh Mac OS
: --- enhancement
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2015-11-30 20:17 UTC by Jon Goldberger [MSFT]
Modified: 2017-07-06 15:38 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 36396 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Jon Goldberger [MSFT] 2015-11-30 20:17:46 UTC
## Description

In Marshmallow, the Context.Resources.GetColor(int resourceId) call was deprecated in favor of the support library ContextCompat.GetColor call. The issue is that TextView.SetTextColor only takes a Color object (or ColorStateList) and while Context.Resources.GetColor(int resourceId) returned a Color object, ContextCompat.GetColor returns an int (the resource id). It would be helpful if either:
a) TextView.SetTextColor had an overload that took an int (resource id), or 
b) ContextCompat.GetColor would return a Color object as Context.Resources.GetColor does.

## Steps to reproduce

No real steps to reproduce, but if you inspect the methods noted above you will see the different return types from Context.Resources.GetColor and ContextCompat.GetColor.

## Workaround

TextView.SetTextColor does have an overload that takes a ColorStateList, so this code works:

TextView textView = new TextView (this);
textView.SetTextColor (ContextCompat.GetColorStateList (this, Resource.Color.PureBlue));

But as noted by the reporting customer, this is overkill as often they do not need to set a ColorStateList, but just want to set the main color for the text.

## Version info

=== Xamarin Studio ===

Version 5.10 (build 871)
Installation UUID: 964c531b-d928-456b-a9ae-e1f82266b360
	Mono 4.2.1 (explicit/6dd2d0d)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 402010102

=== Xamarin.Profiler ===

Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 7.1.1 (9081)
Build 7B1005

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 3c0ec35
Branch: master
Build date: 2015-11-12 13:05:39-0500

=== Xamarin.Android ===

Version: (Business Edition)
Android SDK: /Users/apple/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.2   (API level 17)
		4.3   (API level 18)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)

SDK Tools Version: 24.4.1
SDK Platform Tools Version: 23.0.1
SDK Build Tools Version: 23.0.2

Java SDK: /usr
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)

=== Xamarin Android Player ===

Version: 0.6.5
Location: /Applications/Xamarin Android Player.app

=== Xamarin.Mac ===

Version: (Business Edition)

=== Build Information ===

Release ID: 510000871
Git revision: 4e9c5abb5ffdae12ba02ac49da83f8b2011dbb88
Build date: 2015-11-12 06:02:54-05
Xamarin addins: 55007ed0e56436f385d8e26394a45be563abc7e8
Build lane: monodevelop-lion-cycle6

=== Operating System ===

Mac OS X 10.11.1
Darwin Jons-iMac.local 15.0.0 Darwin Kernel Version 15.0.0
    Sat Sep 19 15:53:46 PDT 2015
    root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64
Comment 2 Atsushi Eno 2015-12-02 06:51:29 UTC
jonp: It is not enumification but about Color-ization that you handled (maybe through grep over sources to detect target methods and fields? It likely needs more consideration).
Comment 3 Jon Douglas [MSFT] 2017-07-06 15:38:21 UTC
For the following scenarios:

a) TextView.SetTextColor had an overload that took an int (resource id), or 
b) ContextCompat.GetColor would return a Color object as Context.Resources.GetColor does.


a) You can create a new Color object with the int constructor of the ContextCompat.getColor method.


            Button b = (Button) FindViewById(Resource.Id.buttonOne);
            var contextColor = ContextCompat.GetColor(this, Resource.Color.red);
            var color = new Color(contextColor);

(You can shorten this code as well, but I put it line by line to show the process)

However I do agree that the shorthand should be available to developers as it saves 1-2 calls and makes the APIs easier to use.

b) Since the actual library on this end only returns an int, I would be hesitant about the change being made here. However it is definitely possible to make a helper method inside the v4 binding to provide this functionality.

https://developer.android.com/reference/android/support/v4/content/ContextCompat.html#getColor(android.content.Context, int)

Thus I think that classes that inherit TextView or even TextView itself should include an overload of the int methods that implicitly convert to the Color object.

These should be quick helper additions to the framework to help prevent multiple casting calls. I think both are reasonable requests and thus I am CONFIRMING this bug.