TheAlmightyBob
Fill in alpha value for calendar color on Android if omitted
If you give iOS an RGB color, you get back an ARGB color with the alpha set to FF.
If you give Android an RGB color, you get back an ARGB color with the alpha set to 00.
It would probably be nice if we added an alpha of FF to the color on Android if the caller did not provide it.
(it's been reported that calendars might wind up displaying as black due to this, although I personally haven't been able to repro that problem..)
Is it an idea to change the color parameter from string to Color in order to work with Color.FromARGB and have it more strong typed?
I have not cloned/forked the code, but perhaps you have tried it already. What happends when you use
int colorInt = unchecked((int)0x0000FF); on line 279?
https://github.com/TheAlmightyBob/Calendars/blob/master/Calendars/Calendars.Plugin.Android/CalendarsImplementation.cs#L279
Seems to be so hard to change the colors of an Android calendar that someone made a special application for it. https://play.google.com/store/apps/details?id=org.bojo.calendarcolors I have also read somewhere in the documentation that you need special rights or a special type to specify a custom color because it is in some other table? I will google some more...
edit: the whole Android color section seems so read-only to me: https://developers.google.com/calendar/v3/reference/colors/get can only be updated by the sync adapter... https://developer.android.com/reference/android/provider/CalendarContract.Colors.html
Using Color requires NETStandard 2.0. That didn't exist when this was originally implemented, and I'm not in a rush to take that dependency just yet... but it's something to consider.
Your suggestion on line 279 would have the opposite effect. That line works properly. This problem is if you pass in your own custom color to the API so that color isn't used. The library requires you to include the alpha value yourself. This issue is just about making that optional, for convenience.
That "special application" very likely uses the same API that this library is using, and would have the same capabilities/issues (such as Google overriding your attempt to change the color of one of their calendars). It was likely only written more due to the UI/feature limitations of common calendar apps, which seem more related to trying to make things simple and user-friendly than any sort of technical complexity.
The complication is really just that it might not work well to change the color of a calendar that is "owned" by another app, especially something like a Google Calendar that is being synced from the cloud. I haven't tested this a ton myself, but I see people complaining that it doesn't work with that org.bojo.calendarcolors app and I'm not surprised. If you're creating a new local calendar for your app and setting the color it's fine.