Open dblock opened 10 years ago
I'm not sure if it has an advantage to combine all the color libraries in a single project. This is often too much overhead and CocoaPods makes it really easy to implement exactly what you really need. But perhaps I am wrong and you could tell me the benefits.
The first advantage is discoverability. There're so many color libraries out there that duplicate functionality and, really, all they do is map names to UIColor
. Just wait till there's another flat color library that does the same thing :)
The disadvantage of overhead is pretty trivial. These categories are extremely tiny and you can select them one-by-one in EDColor.
ASCFlatUIColor has a at least one problem that should be fixed either way. You're doing [UIColor colorWithRed:26/255.f green:188/255.f blue:156/255.f alpha:1.000];
, which produces different results on 32-bit and 64-bit. It's a problem for testing with libraries like these. So your next step would be to define the colors in hex-terms, so now you're really duplicating conversion code that exists in EDColor.
Finally, I think we could all benefit from more eyes that care about colors :) I had ported one of the libraries and found 3 bugs. EDColor won't take contributions without tests.
Of course, it's up-to-you. If you do plan to contribute this color map to EDColor (we would love you to), great, otherwise I'll port it sometime this week.
Please excuse my late reply. What do you think about making Subspecs for each color library? Then you could select only what you really need. In addition, you could keep all libraries in a separate repository and add it as a dependency in the EDColor Podspec. And of course I would help you.
Another question, should we convert the ASCFlatUIColor class to an UIColor Category with prefixed method names, such as: [UIColor iOS7yellowColor]
. I think that would be consistent.
Then we would have [UIColor flatUIemeraldColor]
and [UIColor colorWithFlatColor:FlatUIEmeraldColor]
. If we also prefix it with EDColor it gets ugly.
BTW: Nice to see that you have adopted the flat status badges.
Sub-specs seem excessive IMO, it gets hard to make changes because you are now bringing in things from all these multiple places. However I've seen other projects (eg. ARAnalytics) do that successfully. I don't have too strong of an opinion.
I like the colorWithFlatColor:
concept quite a bit.
Ace. I hope I find time for it on the weekend.
We've been trying to create a single color library to rule them all. Check out https://github.com/thisandagain/color