CHANGELOG

Develop

7.1.1

• Fixed using StoryboardInstantiatable with SPM (#233).

7.1.0

• You can now use a shorthand syntax for resolving a single property using a key path, i.e. resolvingProperty(\.value).
• Swift 5.0 support (#224).
• Fixed resolving nested types with the same local names (#221).
• @Injected and @IntectedWeak property wrappers (#225).
• Thread safety can be disabled on container level.

7.0.1

• Added a workaround for Swift 4.2 regression related to retaining weak properties (#214). For that auto-injection can be disabled or enabled for the whole container or individula registrations.

7.0.0

• Swift 4.2 support.
• Fixed some issues when reusing instances previously resolved as optionals.
• Dip-UI is now part of Dip.

6.1

• Swift 4.1 support.
• Fixed crashes resolving singletons using collaborating containers. #179, @trimmurrti #182, @tapsandswipes

6.0

• Swift 4 support
• Fixed unneeded reuse of singletons in collaborating containers. Containers now first attempt to autowire components and fallback to collaboration when it fails.
  #169, @ilyapuchka

5.1

• Dropped Swift 2.3 support.
  #150, @ilyapuchka
• Added custom logging function.
  #146, @Pr0Ger

Fixed

• Fixed Swift 3.1 warnings.
  #145, @DenHeadless
• Fixed collaboration shared references.
  #151, @ilyapuchka
• Fixed autowiring when using tags.
  #154, @ilyapuchka

5.0.4

Fixed

• Fixed broken compatibility for Swift 2.3 API in resolve(tag:arguments:) method.
  #135, @ilyapuchka

5.0.3

• Added Swift 2.3 compatibility. swift2.3 brunch is no longer maintained.
  #127, @ilyapuchka

Fixed

• Fixed reusing instances registered with WeakSingleton scope
  #129, @ilyapuchka

5.0.2

Fixed

• Fixed Swift 3 issues related to reflection and IUO
  #125, @ilyapuchka

5.0.1

This release is the same as 5.0.0 and only fixes CocoaPods speck pushed to trunk without macOS, tvOS and watchOS deployment targets. Please use this release instead of 5.0.0 if you integrate Dip via Cocoapods.

5.0.0

• Migrated to Swift 3.0
  #120, @patrick-lind, @mark-urbanthings, @ilyapuchka
• Renamed DefinitionOf to Definition and some other source-breaking refactoring.
  #113, @ilyapuchka
• Added invalidType error when resolved instance does not implement requested type.
  #118, @ilyapuchka
• Added optional type parameter in register methods to be able to specify type when registering using method literal instead of closure. #115, @ilyapuchka
• Added implements family of methods in to Definition to register type-forwarding definitions.
  #114, @ilyapuchka
• Shared scope is now the default scope.
  #112, @ilyapuchka
• Single target project setup.
  #121, @ilyapuchka
• Simplified implementation of auto-wiring.
  #117, @ilyapuchka

Fixed

• Auto-injected properties inherited from super class are now properly injected when resolving subclass. Added resolveDependencies(_:DependencyContainer) method to Resolvable protocol to handle inheritance when resolving.
  #116, @ilyapuchka

4.6.1

Fixed

• Fixed sharing singletons between collaborating containers.
  #103, @ilyapuchka
• Renamed some public API's (see release notes for more info).
  #105, @ilyapuchka

4.6.0

• Containers collaboration. Break your definitions in modules and link them together.
  #95, @ilyapuchka
• Added WeakSingleton scope.
  #96, @ilyapuchka
• Properties Auto-injection now is performed before calling resolveDependencies block
  #97, @ilyapuchka
• Fixed updating container's context when resolving properties with auto-injection.
  #98, @ilyapuchka
• Improved logging.
  #94, #99, @ilyapuchka
• Fixed warning about using only extensions api.
  #92, @mwoollard

4.5.0

• Added weakly-typed API to resolve components when exact type is unknown during compile time.
  #79, @ilyapuchka
• Added type forwarding feature. You can register the same factory to resolve different types.
  #89, @ilyapuchka
• Container now can resolve optional types 🎉
  #84, @ilyapuchka
• Added container context that provides contextual information during graph resolution process.
  #83, @ilyapuchka
• Added method to validate container configuration.
  #87, @ilyapuchka
• Added method to manually set value wrapped by auto-injection wrappers.
  #81, @ilyapuchka
• Added separate error type for failures during auto-wiring.
  #85, @ilyapuchka

4.4.0

• Added .EagerSingleton scope for objectes requiring early instantiation and bootstrap() method on DepenencyContainer.
  #65, @ilyapuchka
• Reverted order of Resolvable callbacks.
  #67, @ilyapuchka

4.3.1

• Fix Swift 2.2 compile errors in tests.
  #62, @mwoollard

4.3.0

• Added DependencyTagConvertible protocol for better typed tags.
  #50, @gavrix
• Auto-wiring. DependencyContainer resolves constructor arguments automatically.
  #55, @ilyapuchka
• Added Resolvable protocol to get a callback when dependencies graph is complete.
  #57, @ilyapuchka
• Removed DipError.ResolutionFailed error for better consistency.
  #58, @ilyapuchka

4.2.0

• Added support for Swift Package Manager.
  #41, @ilyapuchka
• Added Linux support.
  #42, #46, @ilyapuchka
• Fixed the issue that could cause singleton instances to be reused between different containers.
  #43, @ilyapuchka
• Added public AutoInjectedPropertyBox protocol for user-defined auto-injected property wrappers.
  #49, @ilyapuchka

4.1.0

New features

• Added auto-injection feature.
  #13, @ilyapuchka
• Factories and resolveDependencies blocks of DefinitionOf are now allowed to throw. Improved errors handling.
  #32, @ilyapuchka
• Thread safety reimplemented with support for recursive methods calls.
  #31, @mwoollard

4.0.0

New Features

• Added support for circular dependencies:
  • Added ObjectGraph scope to reuse resolved instances
  • Added resolveDependencies method on DefinitionOf class to resolve dependencies of resolved instance.
    #11, @ilyapuchka
• Added methods to register/remove individual definitions.
  #11, @ilyapuchka
• All resolve methods now can throw error if type can not be resolved.
  #15, @ilyapuchka
• DependencyContainer is marked as final.
• Added support for OSX, tvOS and watchOS2.
  #26, @ilyapuchka

Breaking Changes

• Removed container thread-safety to enable recursion calls to resolve.
  Access to container from multiple threads should be handled by clients from now on.

• All resolve methods now can throw.

  Note on migration from 3.x to 4.0.0:

  • Errors

  In 4.0.0 each resolve method can throw DefinitionNotFound(DefinitionKey) error, so you need to call it using try! or try?, or catch the error if it's appropriate for your case. See #15 for rationale of this change.

  • Thread safety

  In 4.0.0 DependencyContainer drops any guarantee of thread safety. From now on code that uses Dip must ensure that it's methods are called from a single thread. For example if you have registered type as a singleton and later two threads try to resolve it at the same time you can have two different instances of type instead of one as expected. This change was required to enable recursive calls of resolve method to resolve circular dependencies.

  • Removed methods

  Methods deprecated in 3.1.0 are now removed.

3.1.0

New

• Added name for the first runtime argument in resolve(tag:withArguments: … ) methods to make more clear separation between tag and factory runtime arguments.

Depreciations

• resolve(tag:_: … ) methods are deprecated in favor of those new resolve(tag:withArguments: … ) methods.
• Deprecated register(tag:instance:) method in favor of register(.Singleton) { … }.

3.0.0

• Added support for factories with up to six runtime arguments.
  #8, @ilyapuchka

• Parameter tag is now named in all register/resolve methods.

• Playground added to project.
  #10, @ilyapuchka

  Note on migration from 2.0.0 to 3.0.0:

  If you used tags to register and resolve your components you have to add tag name for tag parameter. Don't forget to add it both in register and resolve methods. If you forget to add it in resolve call then tag value will be treated as first runtime argument for a factory, but there is no such factory registerd, so resolve will fail.

  Example:

  This code:

  container.register(tag: "some tag") { SomeClass() as SomeProtocol }
  container.resolve("some tag") as SomeProtocol

  becomes this:

  container.register(tag: "some tag") { SomeClass() as SomeProtocol }
  container.resolve(tag: "some tag") as SomeProtocol

2.0.0

• Moved from generic tag parameter on container to Tag enum with String and Int cases
  #3, @ilyapuchka

This API change allows easier use of DependencyContainer and avoid some constraints. For a complete rationale on that change, see PR #3.

1.0.1

• Improved README
• Imrpoved discoverability using keywords in podspec

1.0.0

Dip

• Added Unit Tests for SWAPIPersonProvider and SWAPIStarshipProvider

All work in progress is now done. I consider Dip to be ready for production and with a stable API, hence the 1.0.0 version bump.

Example Project

• Using func fetchIDs and func fetchOne instead of lazy var for readability

0.1.0

Dip

• Dip is now Thread-Safe
• Added a configuration block so we can easily create the container and register the dependencies all in one expression:

let deps = DependencyContainer() {
  $0.register() { x as Foo }
  $0.register() { y as Bar }
  $0.register() { z as Baz }
}

• Source Documentation

Example Project

• Code Cleanup
• Added more values to HardCodedStarshipProvider so it works when the PersonProviderAPI uses real pilots from swapi.co (SWAPIPersonProvider)

0.0.4

Example Project

• Added SWAPIPersonProvider & SWAPIStarshipProvider that use http://swapi.co

0.0.3

Example Project

• Revamped the Sample project to a more complete example (using StarWars API!)
• Using Mixins & Traits in the Sample App for FetchableTrait and FillableCell

0.0.2

Dip

• Switched from class methods to instance methods (#1). This allows you to have multiple DependencyContainers
• Renamed the class from Dependency to DependencyContainer
• Renamed the instanceFactory: parameter to factory:
• Made the DependencyContainer generic of the type of tag. We are no longer limited to tags of type String, we can now use anything that's Equatable.

0.0.1

Initial version to release the early proof of concept.

Ready to use, but API may change, documentation and unit tests are missing, and thread-safety is not guaranteed.