Every day iOS apps become more cumbersome and bulky, which makes MVC approach not sufficient.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
[[RequestManager sharedInstance] loadResourcesAtPath:@\"http:\/\/example.com\/resources\" withDelegate:self];\n\/\/ or\n[[DatabaseManager sharedManager] saveResource:resource];\n<\/pre>\n\n\n\nA lot of projects use this approach, but it entails a few flaws:<\/p>\n\n\n\n
The first problem is easy to solve – use object property:<\/p>\n\n\n\n
@interface ViewController : UIViewController\n\n@property (nonatomic, strong) RequestManager *requestManager;\n\n@end\n<\/pre>\n\n\n\nBut this approach entails another issue – someone should ‘fill’ this property.<\/p>\n\n\n\n\n\n\n\n
Dependency Injection<\/h2>\n\n\n\n
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)<\/a>.<\/p>\n\n\n\n
DI allows injecting requestManager<\/span> as a singleton in the application, but uses mock object while testing. No one is aware of singleton however – neither RequestManager<\/span>, nor ViewController<\/span> – because all this stuff is managed by DI framework.<\/p>\n\n\n\n
You can find a lot of Objective-C implementations of the Dependency Injection pattern on GitHub, but they have some disadvantages:<\/p>\n\n\n\n
- description of dependencies via macros or string constants<\/li>
- 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)<\/li>
- injected class should implement some protocol (this would not work with third party libraries)<\/li>
- initialization can’t be placed into a separate module<\/li>
- uses XML to describe dependencies<\/li><\/ul>\n\n\n\n
BloodMagic<\/h2>\n\n\n\n
So, let’s look into another framework (also with its set of disadvantages) – BloodMagic<\/a>.<\/p>\n\n\n\n
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<\/a>.<\/p>\n\n\n\n
This attribute allows to initialize objects on demand with a minimum of boilerplate code. Therefore, instead of the following sheets:<\/p>\n\n\n\n
@interface ViewController : UIViewController\n\n@property (nonatomic, strong) ProgressViewService *progressViewService;\n@property (nonatomic, strong) ResourceLoader *resourceLoader;\n\n@end\n\n@implementation ViewController\n\n- (void)loadResources\n{\n [self.progressViewService showProgressInView:self.view];\n \n self.resourceLoader.delegate = self;\n [self.resourceLoader loadResources];\n}\n\n- (ProgressViewService *)progressViewService\n{\n if (_progressViewService == nil) {\n _progressViewService = [ProgressViewService new];\n }\n \n return _progressViewService;\n}\n\n- (ResourceLoader *)resourceLoader\n{\n if (_resourceLoader == nil) {\n _resourceLoader = [ResourceLoader new];\n }\n \n return _resourceLoader;\n}\n\n@end\n<\/pre>\n\n\n\nwe can simply write:<\/p>\n\n\n\n
@interface ViewController : UIViewController\n \n\n@property (nonatomic, strong) ProgressViewService *progressViewService;\n@property (nonatomic, strong) ResourceLoader *resourceLoader;\n\n@end\n\n@implementation ViewController\n\n@dynamic progressViewService;\n@dynamic resourceLoader;\n\n- (void)loadResources\n{\n [self.progressViewService showProgressInView:self.view];\n \n self.resourceLoader.delegate = self;\n [self.resourceLoader loadResources];\n}\n\n@end\n<\/pre>\n\n\n\nAnd that’s it. Both @dynamic<\/span> properties are created by a call to self.progressViewService<\/span> and self.resourceLoader<\/span>. They are released in the same way as a standard properties – after ViewController<\/span> is deallocated.<\/p>\n\n\n\n
BloodMagic and Dependency Injection<\/h2>\n\n\n\n
+new<\/span> 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.<\/p>\n\n\n\n
Creating custom initializer is a bit cumbersome, but works well:<\/p>\n\n\n\n
BMInitializer *initializer = [BMInitializer lazyInitializer];\ninitializer.propertyClass = [ProgressViewService class];\ninitializer.initializer = ^id (id sender){\n return [[ProgressViewService alloc] initWithViewController:sender];\n};\n[initializer registerInitializer];\n<\/pre>\n\n\n\npropertyClass<\/span> – initializer registers for property of this class.<\/p>\n\n\n\n
initializer<\/span> – block, which is called to initialize property. If this block is nil<\/span>, or initializer is not found for concrete property, then object is created via +new<\/span> class method.<\/p>\n\n\n\n
sender<\/span> – container class instance.<\/p>\n\n\n\n
Also, initializer has a containerClass<\/span> property, which allows us to describe creation of the same property based on class container. For example:<\/p>\n\n\n\n
BMInitializer *usersLoaderInitializer = [BMInitializer lazyInitializer];\nusersLoaderInitializer.propertyClass = [ResourceLoader class];\nusersLoaderInitializer.containerClass = [UsersViewController class];\nusersLoaderInitializer.initializer = ^id (id sender){\n return [ResourceLoader usersLoader];\n};\n[usersLoaderInitializer registerInitializer];\n\nBMInitializer *projectsLoaderInitializer = [BMInitializer lazyInitializer];\nprojectsLoaderInitializer.propertyClass = [ResourceLoader class];\nprojectsLoaderInitializer.containerClass = [ProjectsViewController class];\nprojectsLoaderInitializer.initializer = ^id (id sender){\n return [ResourceLoader projectsLoader];\n};\n[projectsLoaderInitializer registerInitializer];\n<\/pre>\n\n\n\nThus, for UsersViewController<\/span> and ProjectsViewController<\/span> different objects are created. By default containerClass<\/span> equals to NSObject<\/span> class.<\/p>\n\n\n\n
Initializers help to get rid of various shared*<\/span> methods and hardcoding, described in the beginning:<\/p>\n\n\n\n
BMInitializer *initializer = [BMInitializer lazyInitializer];\ninitializer.propertyClass = [RequestManager class];\ninitializer.initializer = ^id (id sender){\n static id singleInstance = nil;\n static dispatch_once_t once;\n dispatch_once(&once, ^{\n singleInstance = [RequestManager new];\n });\n return singleInstance;\n};\n[initializer registerInitializer];\n<\/pre>\n\n\n\nOrganize initializers<\/h2>\n\n\n\n
We may have a lot of initializers, so it makes sense to move them into a separate place.<\/p>\n\n\n\n
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<\/span>. We should simply create a source file without header and add it to the compilation phase.<\/p>\n\n\n\n
Here is an example:<\/p>\n\n\n\n
\/\/ SomeInitializer.m\n\n#import <BloodMagic\/Lazy.h>\n\n#import \"ResourceLoader.h\"\n#import \"UsersViewController.h\"\n#import \"ProjectsViewController.h\"\n\nlazy_initializer ResourseLoaderInitializers()\n{\n BMInitializer *usersLoaderInitializer = [BMInitializer lazyInitializer];\n usersLoaderInitializer.propertyClass = [ResourceLoader class];\n usersLoaderInitializer.containerClass = [UsersViewController class];\n usersLoaderInitializer.initializer = ^id (id sender){\n return [ResourceLoader usersLoader];\n };\n [usersLoaderInitializer registerInitializer];\n \n BMInitializer *projectsLoaderInitializer = [BMInitializer lazyInitializer];\n projectsLoaderInitializer.propertyClass = [ResourceLoader class];\n projectsLoaderInitializer.containerClass = [ProjectsViewController class];\n projectsLoaderInitializer.initializer = ^id (id sender){\n return [ResourceLoader projectsLoader];\n };\n [projectsLoaderInitializer registerInitializer];\n}\n<\/pre>\n\n\n\nlazy_initializer<\/span> will be replaced with __attribute__((constructor)) static void<\/span>. Attribute constructor<\/span> means that this method will be called before main<\/span> function (here are details: GCC. Function Attributes<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"
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…<\/p>\n","protected":false},"author":55,"featured_media":5921,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["AlexDenisov"],"class_list":["post-5836","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t