This document discusses dependency injection and inversion of control principles in iOS development. It outlines common anti-patterns like singletons and service locators that tightly couple code. The document then explains how to apply dependency injection and inversion of control using either a manual assembly or frameworks like Typhoon and Swinject. Dependency injection frameworks allow defining object relationships and wiring dependencies while keeping code loosely coupled and testable.

1. Dependecy injection
in iOS
Iurii Mozharovskyi, iOS engineer

2. Agenda
1. Anti-patterns
2. SOLID, DIP, IoC, DI
3. DI in practice
2

3. Sorry, but your code is
STUPID!
It is offending. Nobody would like to hear that.
3

4. What makes code STUPID?
Singleton
Tight coupling
Untestability
Premature optimization
Indescriptive naming
Duplication
4

5. Singleton
• Single instance of class
• Global access
class WeatherService {
static let sharedInstance = WeatherService()
}
5

6. Why Singleton is bad?
• Global access and lifetime
• Difficult to replace/mock implementation
• Dependencies are hidden in code
• Tight coupling
6
class WeatherViewController {
func update() {
let weatherService = WeatherService.sharedInstance
weatherService.loadData { ... }
}
}

7. Service locator
7

8. Service locator
class ServiceLocator {
static let sharedInstance = ServiceLocator()
func weatherService() -> WeatherService {...}
func settingsService() -> SettingsService {...}
func adService() -> ADService {...}
func analytics() -> Analytics {...}
}
class WeatherViewController {
func update() {
let weatherService =
ServiceLocator.sharedInstance.weatherService
weatherService.loadData { ... }
}
}
8

9. Why Service Locator is bad?
• Classes are dependent from Service Locator
• Dependencies are hidden in code
• Access to all available services of Service Locator
9

10. Don’t be STUPID: GRASP
SOLID!
Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle
10

11. Dependency Inversion
Principle
• High-level modules should not depend on low-level
modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details
should depend on abstractions.
11

12. Dependency Inversion
Principle
12

13. Inversion of control
13

14. Inversion of control
class WeatherViewController: UIViewController {
init(weatherService: WeatherService) {}
}
...
class Assembly {
private let weatherService: WeatherService =
WeatherServiceImpl()
func weatherViewController() -> WeatherViewController {
return WeatherViewController(
weatherService: weatherService)
}
}
14

15. Dependency injection
Way of passing dependency to class:
• Constructor injection
• Method injection
• Property injection
15

16. Constructor injection
protocol WeatherService {}
class WeatherServiceImpl: WeatherService {}
class WeatherViewController: UIViewController {
init(weatherService: WeatherService) {}
}
16

17. Method injection
protocol WeatherService {}
class WeatherServiceImpl: WeatherService {}
class WeatherViewController: UIViewController {
func update(weatherService: WeatherService) {}
}
17

18. Property injection
protocol WeatherService {}
class WeatherServiceImpl: WeatherService {}
class WeatherViewController: UIViewController {
var weatherService: WeatherService?
}
18

19. DIP, IoC, DI
• DIP - recommendations for dependencies design
• IoC - how dependencies are managed
• DI - way of passing dependency
19

20. DI
Pros:
• Splits app into loosely-coupled components
• Removes dependency creation/search responsibility
• Reusable Code
• Testable Code
Cons:
• You need to manage dependencies
20

21. Example app “Weather”
21
• https://github.com/iuriimoz/Weather
• Client for OpenWeatherMap API (http://
openweathermap.org/api)

22. 22

23. Assembly
• Creates UI & business logic
objects
• Injects dependencies
• UI & business logic classes
don’t know about assembly
23
User
interface
Business
logic
Assembly

24. Inversion of control
24

25. Subassemblies
25

26. Master Assembly
• Instantiates subassemblies
• Wires connections between subassemblies
• Keeps strong references to subassemblies
26

27. Master Assembly
class MasterAssembly {
private let _servicesAssembly = ServicesAssemblyImpl()
private let _mainStoryAssembly = MainStoryAssemblyImpl()
private let _settingsStoryAssembly = SettingsStoryAssemblyImpl()
init() {
let storyAssemblies: [AbstractStoryAssembly] =
[_mainStoryAssembly, _settingsStoryAssembly]
storyAssemblies.forEach { storyAssembly in
storyAssembly.servicesAssembly = _servicesAssembly
}
_mainStoryAssembly.settingsStoryAssembly = _settingsStoryAssembly
}
var mainStoryAssembly: MainStoryAssembly {
return _mainStoryAssembly
}
}
27

28. Where Assembly starts
class AppDelegate: UIResponder, UIApplicationDelegate {
...
private let masterAssembly = MasterAssembly()
func application(_ application: UIApplication,
didFinishLaunchingWithOptions
launchOptions: …) -> Bool {
...
window?.rootViewController =
masterAssembly.mainStoryAssembly.initialScren()
...
}
}
28

29. UI & business logic classes
don’t know about assembly
• How to implement transition from view controller A
to view controller B?
• Does A know about B?
• Who creates B?
29

30. Transition between modules
30

31. Classes are developed
independently
31

32. Assembly establishes
connections
32

33. DI-framework
• removes boilerplate code
• helps to wire up complex object relationships
• auto injection when possible
33

34. DI-framework
• Java - Spring
• Android - Dagger
• iOS - Typhoon, Swinject
34

35. Typhoon
• DI-framework for Objective-C & Swift.
• https://github.com/appsquickly/Typhoon (★2282)
35

36. Typhoon features
• Written in Obj-C with extensive usage of runtime
• Initializer/Property/Method Injections
• Circular Dependency Injection
• Storyboards auto-injection support
• Modularity
36

37. Typhoon example
@protocol WeatherService
@end
@interface WeatherServiceImpl: NSObject<WeatherService>
@end
@interface WeatherViewController: UIViewController
- (instancetype)initWithWeatherService:(id<WeatherService>)weatherService;
@end
37

38. Create a sub-class of
TyphoonAssembly
@interface MyTyphoonAssembly : TyphoonAssembly
- (id<WeatherService>)weatherService;
- (UIViewController *)weatherViewController;
@end
38

39. Define instances to be built
@implementation MyTyphoonAssembly
- (id<WeatherService>)weatherService {
return [TyphoonDefinition withClass:WeatherServiceImpl.class];
}
- (UIViewController *)weatherViewController {
return
[TyphoonDefinition withClass:WeatherViewController.class
configuration:^(TyphoonDefinition *definition) {
[definition useInitializer:@selector(initWithWeatherService:)
parameters:^(TyphoonMethod *initializer) {
[initializer injectParameterWith:[self weatherService]];
}];
}];
}
@end
39

40. Obtain built instances from the
assembly
MyTyphoonAssembly *assembly = [[MyTyphoonAssembly new] activated];
UIViewController *weatherVC = [assembly weatherViewController];
40

41. Typhoon cons
• Swift classes should be subclassed from
NSObject.
• Need to understand how it works internally
• No compile time checks
• Hard to debug
41

42. Typhoon debugging
42

43. Swinject
• Dependency injection framework for Swift
• https://github.com/Swinject/Swinject (★1963)
43

44. Swinject features
• Written in Swift for Swift without runtime usage
• Initializer/Property/Method Injections
• Circular Dependency Injection
• Optional storyboards auto-injection extension
• Modularity
• Thread safety
44

45. Swinject example
let weatherVCID = "WeatherVC";
let container = Container()
container.register(WeatherService.self) { _ in WeatherServiceImpl() }
container.register(UIViewController.self, name: weatherVCID) {
resolver in
let weatherService = resolver.resolve(WeatherService.self)!
return WeatherViewController(weatherService: weatherService)
}
let weatherVC = container.resolve(UIViewController.self,
name: weatherVCID)!
45

46. Swinject cons
• Need to understand how it works internally
• No compile time checks
46

47. Handmade Assembly vs DI-
frameworks
• Try handmade Assembly
• Try DI-frameworks
• Make your personal choice
47

48. Summary
• DI is good, it makes everyone happy
• Use DI in your projects
48

49. Thank you!
Questions?
49

50. References
https://github.com/iuriimoz/Weather
http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/
https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
https://martinfowler.com/bliki/InversionOfControl.html
https://martinfowler.com/articles/injection.html
http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
http://sergeyteplyakov.blogspot.com/2014/11/di-vs-dip-vs-ioc.html
https://habrahabr.ru/company/rambler-co/blog/258325/
https://github.com/appsquickly/Typhoon
https://github.com/Swinject/Swinject
50