MVC is not sufficient
Every day iOS apps become more cumbersome and bulky, which makes MVC approach not sufficient.
We are seeing more and more classes for different purposes: app logic extracts into services, models extends with decorators, view separates into partials and so on. And – what is more important – there are now a lot of dependencies that need to be managed somehow.
Singleton is often used to resolve this problem; this is a kind of global variable that everyone can access. How many times have you seen such a code:
[[RequestManager sharedInstance] loadResourcesAtPath:@"http://example.com/resources" withDelegate:self]; // or [[DatabaseManager sharedManager] saveResource:resource];
A lot of projects use this approach, but it entails a few flaws:
- it’s hard to mock or stub Singletons while testing classes that use it
- Singleton is a global variable by the nature
- from the SRP point of view, object should not control his Singleton behaviour
The first problem is easy to solve – use object property:
@interface ViewController : UIViewController @property (nonatomic, strong) RequestManager *requestManager; @end
But this approach entails another issue – someone should ‘fill’ this property.
Dependency Injection
These issues are not unique for Objective-C. If we take a look at more ‘industrial’ languages, e.g. Java or C++, we can find a solution. Widely used approach in Java – Dependency Injection(DI).
DI allows injecting requestManager as a singleton in the application, but uses mock object while testing. No one is aware of singleton however – neither RequestManager, nor ViewController – because all this stuff is managed by DI framework.
You can find a lot of Objective-C implementations of the Dependency Injection pattern on GitHub, but they have some disadvantages:
- description of dependencies via macros or string constants
- injection occurs only if object is created in a special way (this would not work at least with UIViewController from Storyboard and with UIView from Nib)
- injected class should implement some protocol (this would not work with third party libraries)
- initialization can’t be placed into a separate module
- uses XML to describe dependencies
BloodMagic
So, let’s look into another framework (also with its set of disadvantages) – BloodMagic.
BloodMagic provides some sort of custom attributes. It’s designed to be extensible, so more features are coming soon. Currently, only one attribute is implemented – Lazy.
This attribute allows to initialize objects on demand with a minimum of boilerplate code. Therefore, instead of the following sheets:
@interface ViewController : UIViewController
@property (nonatomic, strong) ProgressViewService *progressViewService;
@property (nonatomic, strong) ResourceLoader *resourceLoader;
@end
@implementation ViewController
- (void)loadResources
{
[self.progressViewService showProgressInView:self.view];
self.resourceLoader.delegate = self;
[self.resourceLoader loadResources];
}
- (ProgressViewService *)progressViewService
{
if (_progressViewService == nil) {
_progressViewService = [ProgressViewService new];
}
return _progressViewService;
}
- (ResourceLoader *)resourceLoader
{
if (_resourceLoader == nil) {
_resourceLoader = [ResourceLoader new];
}
return _resourceLoader;
}
@end
we can simply write:
@interface ViewController : UIViewController
@property (nonatomic, strong) ProgressViewService *progressViewService;
@property (nonatomic, strong) ResourceLoader *resourceLoader;
@end
@implementation ViewController
@dynamic progressViewService;
@dynamic resourceLoader;
- (void)loadResources
{
[self.progressViewService showProgressInView:self.view];
self.resourceLoader.delegate = self;
[self.resourceLoader loadResources];
}
@end
And that’s it. Both @dynamic properties are created by a call to self.progressViewService and self.resourceLoader. They are released in the same way as a standard properties – after ViewController is deallocated.
BloodMagic and Dependency Injection
+new method is used for object creation here by default. But it also has a capability of writing custom initializers which is a key feature of BMLazy as a DI framework.
Creating custom initializer is a bit cumbersome, but works well:
BMInitializer *initializer = [BMInitializer lazyInitializer];
initializer.propertyClass = [ProgressViewService class];
initializer.initializer = ^id (id sender){
return [[ProgressViewService alloc] initWithViewController:sender];
};
[initializer registerInitializer];
propertyClass – initializer registers for property of this class.
initializer – block, which is called to initialize property. If this block is nil, or initializer is not found for concrete property, then object is created via +new class method.
sender – container class instance.
Also, initializer has a containerClass property, which allows us to describe creation of the same property based on class container. For example:
BMInitializer *usersLoaderInitializer = [BMInitializer lazyInitializer];
usersLoaderInitializer.propertyClass = [ResourceLoader class];
usersLoaderInitializer.containerClass = [UsersViewController class];
usersLoaderInitializer.initializer = ^id (id sender){
return [ResourceLoader usersLoader];
};
[usersLoaderInitializer registerInitializer];
BMInitializer *projectsLoaderInitializer = [BMInitializer lazyInitializer];
projectsLoaderInitializer.propertyClass = [ResourceLoader class];
projectsLoaderInitializer.containerClass = [ProjectsViewController class];
projectsLoaderInitializer.initializer = ^id (id sender){
return [ResourceLoader projectsLoader];
};
[projectsLoaderInitializer registerInitializer];
Thus, for UsersViewController and ProjectsViewController different objects are created. By default containerClass equals to NSObject class.
Initializers help to get rid of various shared* methods and hardcoding, described in the beginning:
BMInitializer *initializer = [BMInitializer lazyInitializer];
initializer.propertyClass = [RequestManager class];
initializer.initializer = ^id (id sender){
static id singleInstance = nil;
static dispatch_once_t once;
dispatch_once(&once, ^{
singleInstance = [RequestManager new];
});
return singleInstance;
};
[initializer registerInitializer];
Organize initializers
We may have a lot of initializers, so it makes sense to move them into a separate place.
Nice solution is to store them in different files and use attributes of a compiler (it’s a normal practice). BloodMagic has also a simple macros that hides this attribute – lazy_initializer. We should simply create a source file without header and add it to the compilation phase.
Here is an example:
// SomeInitializer.m
#import <BloodMagic/Lazy.h>
#import "ResourceLoader.h"
#import "UsersViewController.h"
#import "ProjectsViewController.h"
lazy_initializer ResourseLoaderInitializers()
{
BMInitializer *usersLoaderInitializer = [BMInitializer lazyInitializer];
usersLoaderInitializer.propertyClass = [ResourceLoader class];
usersLoaderInitializer.containerClass = [UsersViewController class];
usersLoaderInitializer.initializer = ^id (id sender){
return [ResourceLoader usersLoader];
};
[usersLoaderInitializer registerInitializer];
BMInitializer *projectsLoaderInitializer = [BMInitializer lazyInitializer];
projectsLoaderInitializer.propertyClass = [ResourceLoader class];
projectsLoaderInitializer.containerClass = [ProjectsViewController class];
projectsLoaderInitializer.initializer = ^id (id sender){
return [ResourceLoader projectsLoader];
};
[projectsLoaderInitializer registerInitializer];
}
lazy_initializer will be replaced with __attribute__((constructor)) static void. Attribute constructor means that this method will be called before main function (here are details: GCC. Function Attributes).