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.

[Coeur]

OK, so here is my review:

1. 👍Thank you for the protocol, it's welcomed.

2. 👎The removal of setTextValue is a regression in the usability of this pod. People could previously just define a format conversion between a CGFloat and a String, but now they have to explicitly set the String to a label.text or button.setTitle, which also requires them to write a reference to self which they may not do correctly. So I've done a pull to attempt to remedy partially to that issue by keeping support for the existing formatBlock, attributedFormatBlock and completionBlock in Adding a partial compatibility layer with previous version Kirow/EFCountingLabel#1.

3. I'm not sure that we should use [unowned self], as when one will release a UIView, it may call update(value, self) in the deinit block itself. Maybe it's OK, or maybe we could use [weak self] to be absolutely safe. I could try to investigate that a bit more. Let's note that even if we're sure it won't crash, there is no performance difference between weak and unowned here considering the refresh rate is only about 30 frames/secondes.

4. 👍I won't cry at the loss of public var format: String, because there were too much prediction attempt on it done with hasIntConversionSpecifier. Using formatBlock+String(format: format, ...) should be good for everybody.

[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, Adding a partial compatibility layer with previous version Kirow/EFCountingLabel#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.