Implementation should be explicit

[astrokin]

// MARK: Singleton
    private static let sharedInstance = SwiftyStoreKit()

There is no any reason to do this. Please think about about it in unit-tests perspective and Open/closed principle. I would recommend to let users of your software have more control and modify it's state.

[bizz84]

Slowly getting there: #131

I think having an init() method with default parameters for dependencies would help with unit tests, however I would still leave the public facing API as is (with any singleton / state private inside the library). What do you think?

[astrokin]

@bizz84 you did a really great job. from the development perspective it would be greate to refactor a little. I did already in my fork because without these changes i got a crash in release configuration with RxSwift wrapper around your library. We can discuss even more deep refactoring to avoid singleton instance.

[bizz84]

I think it's nicer to write:

SwiftyStoreKit.methodName(params)

rather than:

SwiftyStoreKit.shared.methodName(params)

In the SwiftyStoreKit class, I am planning to have each public class method call a corresponding instance method via the shared singleton.

By exposing a public init() method as well as other public methods, it would be possible to create an instance of SwiftyStoreKit and bypass the singleton entirely.

The question is: is this desirable from an API usage standpoint? This would mean that client code would have to create and retain an instance of SwiftyStoreKit somewhere. In my use cases I always call SwiftyStoreKit from the app delegate as well as from specific view controllers where the purchase flows are hooked up, so having class methods and an internal singleton is quite nice.

Feedback?

[bizz84]

@astrokin I'm slowly making all components inside SwiftyStoreKit testable and adding unit tests.

Eventually I would like SwiftyStoreKit to be just a facade that forwards all the method calls to the right components via composition.

[bizz84]

Closing this issue due to inactivity. Thanks for the feedback @astrokin, more suggestions are welcome.