Reworked module

[Kirow]

well...pretty much changes. Only core logic left.

core interface:

public protocol EFCount {
    func countFrom(_ startValue: CGFloat, to endValue: CGFloat, withDuration duration: TimeInterval)
    func countFromCurrentValueTo(_ endValue: CGFloat, withDuration duration: TimeInterval)
    func stopCountAtCurrentValue()
    func countFromZeroTo(_ endValue: CGFloat, withDuration duration: TimeInterval)
    func countFrom(_ startValue: CGFloat, to endValue: CGFloat)
    func countFromCurrentValueTo(_ endValue: CGFloat)
    func countFromZeroTo(_ endValue: CGFloat)
}

main counter class EFCounter adopt EFCount

to implement counter into any other classes I've added:

public protocol EFCountAdapter: class, EFCount {
    var counter: EFCounter { get }
    func setUpdateBlock(_ update: ((_ value: CGFloat, _ sender: Self) -> Void)?) 
    func setCompletionBlock(_ completion: ((_ sender: Self) -> Void)?)
}

So in most cases it will be like:

open class EFCountingButton: UIButton, EFCountAdapter {
    public private(set) var counter = EFCounter()

    deinit {
        counter.invalidate()
    }
}

most protocol methods are implemented in extensions.

Also there were a lot of renaming compared to previous version. So there will be no backward compatibility.

Updated example project.

TODO:

• [ ] update README.md
• [ ] update .podspec
• [ ] timing from UITimingCurveProvider (i.e. UICubicTimingParameters and UISpringTimingParameters)
• [ ] timing from CAMediaTimingFunction

Please review/discuss or apply changes if acceptable.

[EyreFree]

@Coeur

It looks great. What do you think?

[Coeur]

@EyreFree if we're going to break the API, then I believe that a new protocol should be "minimal" and not include methods that can be achieved with other methods from the same protocol.

For instance, countFromZeroTo(...) shouldn't be in the protocol, because it can be built from count(from: 0, ...) and it's even shorter like that.

I need more time to review the rest.

[Kirow]

For instance, countFromZeroTo(...) shouldn't be in the protocol, because it can be built from count(from: 0, ...) and it's even shorter like that.

I've made it via protocol extensions. So no need to implement them any more.

extension EFCount {
    public func countFromZeroTo(_ endValue: CGFloat, withDuration duration: TimeInterval) {
        countFrom(0, to: endValue, withDuration: duration)
    }

    public func countFrom(_ startValue: CGFloat, to endValue: CGFloat) {
        countFrom(startValue, to: endValue, withDuration: 0)
    }

    public func countFromCurrentValueTo(_ endValue: CGFloat) {
        countFromCurrentValueTo(endValue, withDuration: 0)
    }

    public func countFromZeroTo(_ endValue: CGFloat) {
        countFromZeroTo(endValue, withDuration: 0)
    }
}

Something like syntactic sugar. But yes...naming could be better. I'm not good at it.

[Kirow]

3. Personal preference. If developer mess with retain cycles - he must be punished with the crash. Otherwise issue may be unnoticed or ignored. As a compromise I will change to weak, but add assert to crash in debug configuration. 2,4, Kirow#1 - I have an idea about backward compatibility. I will add some changes on the weekends. Basic idea is to follow your advice

new protocol should be "minimal" and not include methods that can be achieved with other methods

and add compatibility layer similar to Kirow#1 but via protocol. In result we should have new minimal interface for EFCount and new classes (class CustomClass: EFCountAdapter) and current interface for old classes (EFCountingButton, EFCountingLabel). But EFCountingButton may behave slightly different because of #22.

[Coeur]

As the changes start to be too big in my eyes, I'm cherry picking the early commits in a separate PR. See #26.