Cleaned up some of the code relating to default colors

[squarefrog]

NOTE: please don't feel like you have to merge this. It's unfinished, I'm just sending you this PR so you can see one way of tackling some of the code cleanup.

I have removed all the setDefaultXX color methods, and replaced them with a simple ternary operator. Have a look and see what you think. If you think you like it I'll finish it up.

But again, don't merge this this is just an option for you!

[tandavas]

Looking great 👍 Please do continue working on it. Thank you, Paul.

[squarefrog]

Does it make sense to you? If a user wants to revert to the default color, they can always [button setButtonColor:nil];

[herinkc]

@squarefrog Won't the default color be applied anyway without doing [button setButtonColor:nil]?

[squarefrog]

Yes - if a user never sets a value to the buttonColor property it will just use the default.

Just as a marker for anyone else that views this, this was originally discussed in #17

[squarefrog]

OK I'm done. You can clone a copy of my fork and check it out. If you're happy, then it can be merged in if you'd like.

[squarefrog]

I spoke too soon! I just discovered a bug with HTPressableButtonStyleCircular brought about by my previous changes in this pull request. It seems so obvious now, but if you look at the init method:

- (instancetype) initWithFrame:(CGRect)frame buttonStyle:(HTPressableButtonStyle)style
{
    if (self = [super initWithFrame:frame])
    {
        [self setDefaultShadowHeight];
        [self setStyle:style];
    }
    return self;
}

the default shadow height method wants to know the button style, which isn't set yet. Initially I just swapped the two method calls over, but setStyle: also calls createButton. So I've adapted the init method to:

- (instancetype) initWithFrame:(CGRect)frame buttonStyle:(HTPressableButtonStyle)style
{
    if (self = [super initWithFrame:frame])
    {
        [self setDefaultShadowHeightForStyle:style];
        [self setStyle:style];
    }
    return self;
}

Now all is well! This is also a stark reminder that #30 should be the top of the to-do list next. I have testing experience, so I'm happy to walk you guys through it.

[herinkc]

@squarefrog Looks really clean! One question though, why do we have to keep the part #pragma mark - Deprecated Methods?

[squarefrog]

Good questions. So if we just remove those old methods, and someone is using them in their project, then it will produce unrecognised selector errors. Setting them as deprecated means it warns them that the method is going away soon so gives them a chance to remove reliance on those methods.

That way in a future release we can delete them all together and we've given people enough warnings that the method is due to go away.

[herinkc]

Oh, that makes sense. So it's like warning before completely removing it. Then here we go!

I'll be editing the README and let's move to issue #30.

[tandavas]

I was away for a few hours, and both of you are already did an awesome work! Thank you @squarefrog. This looks extremely nice 😄 👍