I am using Swinject for Dependency Injection. I have created a DependencyManager which has a shared instance of container.
internal class DependencyManager {
private static let sharedInstance = DependencyManager()
private var assembler: Assembler
private let container: Container
class func getResolver() -> Resolver {
return self.sharedInstance.assembler.resolver
}
class func getContainer() -> Container {
return self.sharedInstance.container
}
private init() {
self.container = Container()
let assembler = Assembler([
LoginFactory()
])
self.assembler = assembler
}
}
LoginFactory class implements Assembly
internal class LoginFactory: Assembly {
func assemble(container: Container) {
container.register(LSViewModel.self) { res in
return LSViewModel()
}
container.register(LSCoordinator.self, factory: { res in
let lsc = LSCoordinator(window: AppDelegate.mainWindow!)
lsc.viewModel = res.resolve(LSViewModel.self)
return lsc
})
}
}
I read Assembly documentation where it says that it is better used for organization - https://github.com/Swinject/Swinject/blob/master/Documentation/Assembler.md. If I had not been using Assembly then I would have used commands like
DependencyManager.getContainer().register(LSViewModel.self) { _ in LSViewModel() }
DependencyManager.getContainer().register(LSCoordinator.self, factory: { (res) in
let lsc = LSCoordinator(window: AppDelegate.mainWindow!)
lsc.viewModel = res.resolve(LSViewModel.self)
return lsc
})
let lsCoordinator: LSCoordinator = DependencyManager.getContainer().resolve(LSCoordinator.self)!
Both the implementations are working as expected, without any crashes. I wonder why Assembly is even an advantage? I am doing the same thing without using Assembly without an overhead.
Benefits of organising your code using Assembly will start to out-weight the "no overhead" system once the project gets big enough. One way of keeping your code modularised and reusable is (amongst other stuff):
Keep DI code for different features separately
Features do not have the knowledge of how the final app is put together (e.g. DependencyManager)
IMO 1. is quite intuitive. 2. less so, but is free when using assemblies and gives you a lot of flexibility - for example you might want to reuse the feature in multiple apps (e.g. Networking).
Using assemblies you would have something like
let assembler = Assembler([
LoginAssembly(), // each assembly contains DI code for one feature
HomepageAssembly(),
UserProfileAssembly(),
// ...
])
while using the intuitive approach might get quite messy.
Related
So I have a class that comes from one of our internal frameworks. It is defined as follows:
// This lives within a framework
class ExternalClass: ExternalClassProtocol {
// implementation here
}
// This lives within my test target
class MockExternalClass: ExternalClassProtocol {
// Mock implementation here
}
// This lives within the same external frame work as ExternalClass
protocol ExternalClassProtocol: AnyObject {
// Protocol methods here
}
During my test cases, if I try to cast MockExternalClass as? ExternalClassProtocol, the test case crashes.
However, during live app runtime, there is no problem casting ExternalClass as? ExternalClassProtocol.
Is this an issue with trying to implement a protocol from an external module? Is there a way around this?
The class is being accessed through dependency injection (see below dependency injection implementation). The crash occurs on the resolve function.
If you actually debug to this point, you can see that the mock dependency IS in my dependency root (the services array below).
So I know its not failing to cast due to the dependency being missing.
#propertyWrapper
struct Injected<Value> {
var key: String
var wrappedValue: Value {
get { return Dependency.root.resolve(key: self.key) }
set { Dependency.root.add(key: self.key, newValue) }
}
init(key: String) {
self.key = key
}
}
class Dependency {
static let root = Dependency()
var services: [String : Any] = [:]
func add<T>(key: String, _ service: T) {
services[key] = service
}
func resolve<T>(key: String) -> T {
guard let component: T = services[key] as? T else {
// The test crashes here. It works fine on other mocks that are internal to the project
fatalError("Dependency '\(T.self)' not resolved!")
}
return component
}
func clearDependencies() {
self.services.removeAll()
}
private init() {}
}
In my test case:
#testable import MyProject
import ExternalDependency
class TestCase: XCTestCase {
private var subject: ClassWithService!
private var mockInternalClass: MockInternalClassProtocol!
private var mockExternalClass: MockInternallClassProtocol!
func setUp() {
mockExternalClass = MockExternalClass() // This one crashes when trying to cast to its parent protocol
mockInternalClass = MockInternalClass() // This one does not crash when casting to parent protocol.
Dependency.root.add(key: "internal_class", mockInternalClass)
Dependency.root.add(key: "external_class", mockExternalClass)
}
}
Some things I've tried:
Adding AnyObject to the protocol (this fixed a similar issue for internally defined classes that I mock).
changing mockExternalClass type to be the protocol
changing mockExternalClass type to be the implementation
Aside from one protocol being defined in one of our pods, there is no difference between the external protocol and the one we have defined in our own project.
One thing I have noticed is that the cast does not fail if you set a break point inside one of my test case functions. But if you try the same cast within the Dependency.resolve function it crashes. Which leads me to believe there is an issue with the generics.
Any ideas?
I have recently heard that using dependency injection is "the only socially acceptable way to use a singleton in today's software development world". I don't necessarily want to debate the accuracy of this statement right now, as it is mostly opinion-based. My goal right now is to understand how exactly I can use dependency injection with the singleton pattern.
For example, in my latest iOS app, I have a Service layer where I keep my URLSession code. I created this layer as a singleton:
struct ServiceSingleton {
private init()
static let shared = ServiceSingleton()
func fetchJSON() {
// URLSession code
}
}
I then use shared in my ViewController, as below:
class ViewController: UIViewController() {
override viewDidLoad() {
super.viewDidLoad()
fetchData()
}
fileprivate func fetchData() {
ServiceSingleton.shared.fetchJSON()
}
}
Of course, the code above uses a singleton, but it does not use dependency injection. I am aware that if I wanted to use dependency injection in general, I would add something like this to ViewController:
// Dependency Injection Constructor
override init(someProperty: SomePropertyType) {
self.someProperty = someProperty
super.init()
}
TL;DR:
(1) Could you show me how to properly use dependency injection with the singleton pattern in Swift?
(2) Could you explain to me what this achieves?
(3) Should I always use DI when I use the singleton pattern in my iOS projects from now on?
Could you show me how to properly use dependency injection with the singleton pattern in Swift?
Rather than accessing ServiceSingleton.shared directly, you access an instance variable that is injected into your object, usually in the initializer if possible, otherwise as a settable property, post-initialization:
protocol FooService {
func doFooStuff()
}
class ProductionFooService: FooService {
private init() {}
static let shared = ProductionFooService()
func doFooStuff() {
print("real URLSession code goes here")
}
}
struct MockFooService: FooService {
func doFooStuff() {
print("Doing fake foo stuff!")
}
}
class FooUser {
let fooService: FooService
init(fooService: FooService) { // "initializer based" injection
self.fooService = fooService
}
func useFoo() {
fooService.doFooStuff() // Doesn't directly call ProductionFooService.shared.doFooStuff
}
}
let isRunningInAUnitTest = false
let fooUser: FooUser
if !isRunningInAUnitTest {
fooUser = FooUser(fooService: ProductionFooService.shared) // In a release build, this is used.
}
else {
fooUser = FooUser(fooService: MockFooService()) // In a unit test, this is used.
}
fooUser.useFoo()
Typically initialization of ViewControllers is done by your storyboards, so you can't ingect your dependancies via initializer parameters, and will have to instead use stored properties that are set after object initialization.
Could you explain to me what this achieves?
Your code is no longer coupled to ProductionFooService.shared. As a result of this, you can introduce different implementations of FooService, such as one for a beta environment, a mock one for unit testing, etc.
If all your code pervasively directly uses your prod dependancies, you'll...
find that it's impossible to instantiate your objects in a test environment. You don't want your unit tests, CI test environments, beta environments, etc. connecting to prod databases, services and APIs.
Have no true "unit" tests. Every test will be testing a unit of code, plus all of the common dependancies that it transitively depends on. If you were to ever make a code change to one of these dependancies, it would break most of the unit tests in your system, which makes it harder to pin down exactly what failed. By decoupling your dependancies, you can use mock objects that do the bare minimum necessary to support a unit test, and ensure that each test is only testing a particular unit of code, and not the transitive dependancies it relies on.
Should I always use DI when I use the singleton pattern in my iOS projects from now on?
It's a good habit to pick up. Of course, there are qucik-and-dirty-projects for which you just want to move fast and won't really care, but it'll surprise you how many of these supposed qucik-and-dirty-projects actually take off, and pay the cost down the road. You just need to be cognizant of when you're hindering yourself by not taking some extra time to decouple your decencies.
I am reading a lot about the Singleton Pattern. I am currently using it to store groups of global state in my first app. I am reaching a point where I wonder which approach to implement API client classes and similar with.
Are Structs with static vars and static functions having the same issues?
To illustrate what I mean, I've tried to write the same heavily simplified and exact same(?) scenario twice.
1. A singleton being worked with by a view controller:
struct APIClientSingletonClass {
static let shared = APIClientSingletonClass()
var stateOfSomehting: Bool = true
var stateOfSomehtingMore: Bool = false
var stateNumber: CGFloat = 1234
var stateOfSomehtingComputed: CGFloat {
return stateNumber * 10
}
func convertSomethingToSomethingElse() {
// calling method in self like this:
otherMethod()
}
func otherMethod() {
// doing stuff here
}
}
// Calling APIClient from outside:
class ViewControllerTalkingToSingleton: UIViewController {
var api = APIClientSingletonClass.shared
override func viewDidLoad() {
super.viewDidLoad()
api.convertSomethingToSomethingElse()
api.stateOfSomehting = false
}
}
2. Another approach:
struct APIClientStruct {
static var stateOfSomehting: Bool = true
static var stateOfSomehtingMore: Bool = false
static var stateNumber: CGFloat = 1234
static var stateOfSomehtingComputed: CGFloat {
return stateNumber * 10
}
static func convertSomethingToSomethingElse() {
// calling method in self like this:
APIClientStruct.otherMethod()
}
static func otherMethod() {
// doing stuff here
}
}
// Calling APIClient from outside:
class ViewControllerTalkingToStruct: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
APIClientStruct.convertSomethingToSomethingElse()
APIClientStruct.stateOfSomehting = false
}
}
What do you guys think? Is approach 2 falling into the same traps that seem to make Singletons such a double-edged sword?
Any input is really appreciated!
Best from Berlin
EDIT:
This thread is pretty interesting, but I'm not sure it really relates to my question:
Difference between static class and singleton pattern?
Since there are many perspectives on this topic, let me specify:
Does my approach 2 have the same problem implications with testing and code maintainability?
A class-based singleton is the way to go, provided you accommodate for dependency injection for your tests. The way to do this is to create a single singleton for your app, called, say, DependencyManager. In your AppDelegate (or from other classes if needed), you'd create whatever controllers, network services, realm models, etc you want to hang on your DependencyManager, and then assign them to the DependencyManager. This code would be skipped by your unit tests.
Your unit tests can then access the DependencyManager (and thus instantiate the DependencyManager during first access), and populate it with mock versions of those controllers and services to whatever degree each unit test desires.
Your UIViewControllers, your MVVM view models, etc... can access the DependencyManager as a singleton, and thus get either the real controllers and services, or a mock version of them, depending on if you're running the app or unit tests.
If you're doing MVVM, I also recommend that when a UIViewController is about to create its view model class, that it first checks a special property in the DependencyManager to see if a mockViewModel exists. A single property can serve this purpose, as only one of your UIViewControllers ever would be tested at once. It'd use that property instead of creating a new view model for itself. In this way, you can mock your view models when testing each UIViewController. (There's other tricks involved to being able to prop up a single UIViewController for testing, but I won't cover that here).
Note that all of the above can work very nicely with an app that also wants to use storyboards and/or nibs. People are so down on storyboards because they can't figure out how to do dependency injection of mock services for their view controllers. Well, the above is the solution! Just make sure in your AppDelegate to load the storyboard AFTER setting up the DependencyManager. (Remove the storyboard name from your info.plist, and instantiate it yourself in AppDelegate).
I've written a few shipped apps this way, as well as some sample apps for an SDK, along with the tests. I highly recommend the approach! And be sure to write your unit tests and viewController tests either during or at least immediately after development of each such class, or you'll never get around to them!
What generally makes sinlgetons hard to test is that the singleton objects are typically always accessed directly . Because of this, you don't have a means to substitute the real singleton object (e.g. a data-store that's backed by a database) with a mock object for testing (e.g. a data-store that's backed by an easily-configurable array of predefined test data).
Using static members has the same fundamental issue. When referencing a static member directly, you don't have a means of substituting a mock object in place of the real prod implementation.
The solution to this is quite simple: don't access singleton members directly. What I do is something like this:
// An example of a dependency.
protocol DataAccessLayer {
func getData() -> [Int]
}
// A real implementation of DataAccessLayer, backed by a real production database
class ProdDB: DataAccessLayer {
static let instance = ProdDB()
private init() {}
func getData() -> [Int] {
return [1, 2, 3] // pretend this actually queries a DB
}
}
// A mcok implementation of DataAccessLayer, made for simple testing using mock data, without involving a production database.
class MockDB: DataAccessLayer {
func getData() -> [Int] {
return [1, 2, 3] // The mock *actually* hardcodes this data
}
}
// A protocol that stores all databases and services used throughout your app
protocol ServiceContextProtocol {
var dataAccessLayer: DataAccessLayer { get } // Present via protocol, either real impl or mock can go here
//var fooAPIGateway: FooAPIGateway { get }
//... add all other databases and services here
}
// The real service context, containing real databases and service gateways
class ProdServiceContext: ServiceContextProtocol {
let dataAccessLayer: DataAccessLayer = ProdDB.instance
//var fooAPIGateway: ProdFooAPIGateway { get }
//... add all other prod databases and services here
}
// A mock service context, used in testing, which provides mocked databases and service gatways
class MockServiceContext: ServiceContextProtocol {
let dataAccessLayer: DataAccessLayer = MockDB()
//var fooAPIGateway: MockFooAPIGateway { get }
//... add all other mock databases and services here
}
let debug = false // Set this true when you're running in a test context
// A global variable through which you access all other global state (databases, services, etc.)
let ServiceContext: ServiceContextProtocol = debug ? MockServiceContext() : ProdServiceContext()
// Always reference ServiceContext.dataAccessLayer, ServiceContext.fooAPIGateway, etc.
// and *never* reference ProdDB.instance of MockDB directly.
I would use a Class based Singleton. Just remember the 2 criteria for having a singleton. You want GLOBAL ACCESS and SINGLE INSTANCE in your program. There is a couple problems where struct based singleton would fail. Once you assign a struct to a new variable, Swift makes a complete copy under the hood.
Another useful snip of information can be found using this link.
What's the difference between Struct based and Class based singletons?
I have developed a struct that generates random data for testing purposes in my app but only does so if the Realm database is empty. The service class responsible for CRUD operations returns outcomes / results as RxSwift Observables.
Generating new data is predicated on the contents of the Realm - using guard is the logical choice but requires adding a new method to the service that returns Int rather than an Observable which seems to be an unnecessary duplication of code and somewhat inconsistent.
i.e.
class Service {
let realm = try! Realm()
...
// Existing reactive code
func patients() -> Observable<Result<Patient>> {
let results = realm.objects(Patient.self)
return Observable.collection(from: results)
}
func objectCount() -> Int {
let realm = try! Realm()
return realm.objects(Patient.self).count
}
}
struct DataGenerator() {
...
func createRandomPatients() {
let service = Service()
guard service.objectCount() == 0 else { return }
...
//go on to generate patients
The only way I can figure to replicate this control flow using the reactive service method is to bind the Observable to a Variable
i.e.
... service code as above ...
func createRandomPatients() {
let isEmpty = Variable<Bool>(false)
service.patients().map{ $0 == 0 }.bind(to: isEmpty)
guard isEmpty.value else { return }
// etc
It seems like a bit of a fudge as it perhaps isn't quite as clear, but it avoids adding code to the service class that won't be used in the production app. Is this bad practice or just personal preference? I'm open to alternative solutions if anyone has one...
Faking is definitely something that should be handled with polymorphism.
A good design would be to define a common interface; for example it can be PatientsSource:
protocol PatientsSource {
func patients() -> Observable<Result<[Patient]>>
}
Than you can take advantage of polymorphism by defining:
class PatientsService: PatientsSource... {
//w/e
}
struct FakePatients: PatientsSource {
//your random patients generation
}
If you use a Service style architecture then you should pass the Service and the PatientsSource to the user (like your controller) separately even though they might end up to be the same object.
I've run into an issue when generating code coverage with Xcode for view models in an MVVM environment.
Our basic setup is the view controller makes requests to the view model, which in turn calls methods on a data manager that talks to web services.
I came up with what I thought was a reasonably elegant way to test the view models by creating a fake data manager that subclasses the actual data manager and overrides the function called by the VM.
The problem is that for this to work, the VM must be part of the app target and the test target. An apparent side effect of this is that code coverage is not generated for items belonging to two or more targets, even though the unit tests pass. Code coverage is enabled in the project.
Here is a excerpted view model:
import Foundation
class BoosViewModel: BaseViewModel {
convenience override init() {
self.init(dataManager: BoosDataManager(), andModel: nil)
}
func getUnlinkedBoos(_ cardType: CardType) {
(dataManager as! BoosDataManager).getUnlinkedBoos(cardType) { result, error in
...stuff happens here...
}
}
}
... and the data manager
class BoosDataManager: DataManager {
static let SharedInstance: BoosDataManager = {
var manager = BoosDataManager()
return manager
}()
func getUnlinkedBoos(_ cardType: CardType = .loyalty, completion: #escaping ((_ result: BoosModel?, _ error: NSError?) -> Void)) {
...stuff happens here...
}
}
...and the test
class BoosViewModelTests: XCTestCase {
func testGetUnlinkedBoosHappyPath() {
class FauxDataManager: BoosDataManager {
override func getUnlinkedBoos(_ cardType: CardType = .loyalty, completion: #escaping ((_ result: BoosModel?, _ error: NSError?) -> Void)) {
...stuff happens here...
}
}
let viewModel = BoosViewModel()
let dataManager = FauxDataManager()
viewModel.dataManager = dataManager
viewModel.getUnlinkedBoos(.loyalty)
XCTAssertTrue(testObserver.updated)
XCTAssertEqual(testObserver.newViewModel.getBoos().count, 1)
}
}
As I noted earlier the unit tests in this scenario complete successfully, but unit coverage does not get generated.
I have older tests where I actually created an external fake data manager class that was used by the test, the class under test is not part of the test target, and coverage works fine.
The drawback to that is that I have to create multiple data managers to handle specific cases for its returns. If I can't encapsulate the classes, I would need to create a bunch of swift data managers, one for each scenario.
That's why I came up with the internal class.
Now, the problem comes in if I remove the view model under test from the testing target. After doing this, I add #testable import BoosApp to the unit test so that the view model under test can be resolved. When I do this, I get the following error:
Could not cast value of type 'BoosTests.BoosViewModelTests.(testGetUnlinkedBoosHappyPath () -> ()).(FauxDataManager #1)' (0x11f673d18) to 'Boos.BoosDataManager' (0x10444b128).
Aug 30 20:43:01 Pay[19025] : Could not cast value of type 'BoosTests.BoosViewModelTests.(testGetUnlinkedBoosHappyPath () -> ()).(FauxDataManager #1)' (0x11f673d18) to 'Boos.BoosDataManager' (0x10444b128).
I'm not sure what I'm missing. Is there a way to make this scenario work, or am I stuck creating multiple data managers outside of the test code?
Ultimately, I figured out the main issue was that the view model and data manager had somehow gotten added to the test target. After removing them from the test target I was able to make a couple of minor changes and everything is running fine. FYI.