[Breaking Change] Update color values in CupertinoColors. Remove CupertinoSystemColors in favor of CupertinoColors.

30 views
Skip to first unread message

Weiyu Huang

unread,
Sep 17, 2019, 2:01:57 PM9/17/19
to Flutter Public Announcements (flutter-announce)
in iOS 13 some UIColor constants in the UIKit palette have been revised and updated. This proposed change (https://github.com/flutter/flutter/pull/40566/files) is to reflect these color changes. More specifically:
 
  1. CupertinoColors.activeBlue is now an alias of CupertinoColors.systemBlue, which adapts to the current BuildContext.
  2. CupertinoColors.activeGreen is now an alias of CupertinoColors.systemGreen, which adapts to the current BuildContext.
  3. CupertinoColors.activeOrange is now an alias of CupertinoColors. systemOrange, which adapts to the current BuildContext.
  4. CupertinoColors.destructiveRed is now an alias of CupertinoColors.systemRed, which adapts to the current BuildContext.

* "Adapts to the current BuildContext" means the color is an instance of CupertinoDynamicColor and can be resolved against a BuildContext. For example, CupertinoColors.activeBlue can appear differently when resolved against BuildContext that implies 
dark mode and against BuildContext that implies light mode.

In addition to the color constants change, I propose to remove CupertinoSystemColors and CupertinoSystemColorData entirely, and add iOS 13 system colors and UI element colors to CupertinoColors as constants. This would allow us to use 
these color values as default values in functions/methods/constructors, instead of having to use null to indicate default values. 

Migration Guide:

Generally the proposed changes shouldn't break apps API-wise, unless you are already making use of CupertinoSystemColors in your code. An notable exception is widget tests where colors are checked for equality. 
With the introduction of CupertinoDynamicColor (a subclass of color), two colors may not be considered equal even if they have the exact same RGBA value, as their runtimeType may be different. If it is only
the RGBA values you want to check for equality, instead of expect(widget.color, expectedColor), you can write:

expect(widget.color.value, expectedColor.value);


If you have any concerns/suggestions, or experienced problems while migrating existing code, please leave a comment in https://github.com/flutter/flutter/pull/40566/files or contact me by email. Thank you!
Reply all
Reply to author
Forward
0 new messages