2

I am a newbie to objective-c and I have an architectural or design pattern question. I am building an ios app and like most ios apps, it uses various colors, font, patterns etc. Perhaps I am currently writing code incorrectly but I find myself rewriting things like color settings. And as a result, changing colors becomes an exercise in finding all of the color settings in the code, rewriting them, etc. Seems a bit inefficient to me.

For example, I use a dark red color in multiple places in my app. I tend to write the [UIColor colorWithRed...] method rather frequently. However, I curious if creating a singleton that returns my custom colors (as a UIColor) is a reasonable approach to "modularizing my style package." Thus I could write something like this 

[label setTextColor:[[MyStyleSingletonClass sharedStyler] myDarkRed]];

Thus, if the designers suddenly want myDarkRed to be a touch darker, I change it once and it is good to go across the app. Clearly there is more to style and UX than color, but I am curious if this approach makes sense or if I am setting myself up for issues in the future. Or maybe this capability exists in objective-c already and I am missing the point. Thanks in advance.

natenash203
  • 699
  • 6
  • 15

2 Answers2

8

I think a better approach to something like this is a category of class methods on UIColor itself. I often write categories of colors for projects with lots of custom colors.

Something like this:

// UIColor+AppAdditions.h
@interface UIColor (AppAdditions)

+ (UIColor *)myDarkRed;

@end

// UIColor+AppAdditions.m

#import "UIColor+AppAdditions.h"

@implementation UIColor (AppAdditions)

+ (UIColor *)myDarkRed
{
    return [UIColor colorWithRed:0.1 green:0.0 blue:0.0 alpha:1.0];
}

@end

That way you don't need a whole Singleton and its more portable incase the Singleton does other things. And you can cleanly access your colors like this:

[label setTextColor:[UIColor myDarkRed]];

Note

As mentioned by Rob and Paul. It is best to name them appropriately. I took the name you had but it would be best to name them specifically for their use and follow conventions such as prefixing and suffixing.

Ryan Poolos
  • 18,421
  • 4
  • 65
  • 98
  • Very good thinking though :) Its awesome to have a consistent color scheme throughout the app and having something like this really really helps. – Ryan Poolos Mar 15 '13 at 14:41
  • 1
    I also often use a category. One advantage to a "style" object, however, is that it can be replaced at runtime to change the style. For instance, rather than "myDarkRed" it is often better to have methods like "errorColor" and that's something that may want to be modified. (But I often still use the category approach since it's so easy; I just make `errorColor` a method on `UIColor`.) – Rob Napier Mar 15 '13 at 14:44
  • 2
    I'm a fan of the category approach and agree with @RobNapier on naming the colour for it's use rather than it's actual implementation (where possible). Something to consider though is that it's often better to stick to a consistent naming style - in this case following `UIColor` it should be `Color`. Another point on naming is that you should use a prefix for methods added with a category to avoid method name collisions e.g. I might end up with `pas_lightBackgroundColor`. – Paul.s Mar 15 '13 at 15:19
  • Good points. I added a note to the answer for others that come along looking. – Ryan Poolos Mar 15 '13 at 15:35
5

Why not use macro?

in YourHelperClass.h

#define DARK_RED    [UIColor colorWithRed:0.1 green:0.0 blue:0.0 alpha:1.0]

and you can use like this(do not forget import YourHelperClass.h) :

[label setTextColor:DARK_RED];

I think it is better use macro

Guo Luchuan
  • 4,729
  • 25
  • 33
  • I second using a macro for this. In this way, Styles.h can easily be used for colors, fonts, etc. The Category approach means that only colors could be stored in a `UIColor+Style` category - not to mention it's more verbose. – cleverbit Jul 31 '13 at 08:58