[Refactoring] Exude color variables to resources

[programmerr47]

I think it will be better to move color variables into resource file.

1. It will reduce code duplication

2. it will increase readability, since I thought through code that warning and error colors are constants, also actualy they not

3. It will give the user more flexibility to config toast. They will able to rewrite your color resources in their own complex resources files. Suppose, we have aaplication, that for different regions use different color schemes. With code-config-aproach it will request for library user more effort to adjust colors by config changes, that if colors were in resource file

[programmerr47]

If you don't mind, I can do that

[GrenderG]

What do you mean with 2.?

[GrenderG]

ping @programmerr47

[programmerr47]

@GrenderG Hi. Sorry for such delay.

I mean next:
private int DEFAULT_TEXT_COLOR = Toasty.DEFAULT_TEXT_COLOR;
Here is an example of a config field. Since it is written in ALL_CAPS_SNAKE_CASE and it is a common practice for naming constants, you may not notice lack of static final keywords and thus erroneously assume, that it is a constant.
Situation is become more obscure, when you see, that:
private static int DEFAULT_TEXT_COLOR = Color.parseColor("#FFFFFF");
is not just a field of an object, but a field of a class, written in a constant style

See jls for more information. For more easy search page 138, item Field Names :)

[GrenderG]

You are right, go ahead with the PR.

[sami286]

Hi, im working on that.
Should I continue supporting to change default color by Toasty.Config? Or should it be done entirely from resources?

[sami286]

Just tell me what do you want your library to do and I will implement it :)
@GrenderG

[GrenderG]

I'm just not sure about how to implement this. I don't want to remove support for @ColorInt, but I know that it would be good to exclude default color variables to resources and / or support theming via color resources, although this can actually be done at this moment using getColor(...) / ContextCompat.getColor(...) methods.

What do you guys think?

[sami286]

Have a look to the way I implement it, it is now by default getting default color from resources but it is also posible to override them throught the config at run time.

Maybe we shouldn't give an option to override default colors at run time and instead the developers would use Toasty.custom (?)

[GrenderG]

Maybe we shouldn't give an option to override default colors at run time and instead the developers would use Toasty.custom (?)

Okay! I agree with this.

[sami286]

Maybe we shouldn't give an option to override default colors at run time and instead the developers would use Toasty.custom (?)

Okay! I agree with this.

Done! Have a look at it and tell me what you think 😄
#93