{"id":5836,"date":"2013-10-15T20:45:10","date_gmt":"2013-10-15T17:45:10","guid":{"rendered":"http:\/\/railsware.com\/blog\/?p=5836"},"modified":"2021-08-12T13:19:54","modified_gmt":"2021-08-12T10:19:54","slug":"dependency-injection-in-objective-c-with-blood-and-magic","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/dependency-injection-in-objective-c-with-blood-and-magic\/","title":{"rendered":"Dependency Injection in Objective-C with Blood and Magic"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">MVC is not sufficient<\/h2>\n\n\n\n<p>Every day iOS apps become more cumbersome and bulky, which makes MVC approach not sufficient.<\/p>\n\n\n\n<p>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 &#8211; what is more important &#8211; there are now a lot of dependencies that need to be managed somehow.<\/p>\n\n\n\n<p>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<pre class=\"wp-block-preformatted\">[[RequestManager sharedInstance] loadResourcesAtPath:@\"http:\/\/example.com\/resources\" withDelegate:self];\n\/\/ or\n[[DatabaseManager sharedManager] saveResource:resource];\n<\/pre>\n\n\n\n<p>A lot of projects use this approach, but it entails a few flaws:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>it&#8217;s hard to mock or stub Singletons while testing classes that use it<\/li><li>Singleton is a global variable by the nature<\/li><li>from the SRP point of view, object should not control his Singleton behaviour<\/li><\/ul>\n\n\n\n<p>The first problem is easy to solve &#8211; use object property:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">@interface ViewController : UIViewController\n\n@property (nonatomic, strong) RequestManager *requestManager;\n\n@end\n<\/pre>\n\n\n\n<p>But this approach entails another issue &#8211; someone should &#8216;fill&#8217; this property.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading\">Dependency Injection<\/h2>\n\n\n\n<p>These issues are not unique for Objective-C. If we take a look at more &#8216;industrial&#8217; languages, e.g. Java or C++, we can find a solution. Widely used approach in Java &#8211; <a href=\"http:\/\/en.wikipedia.org\/wiki\/Dependency_injection\">Dependency Injection(DI)<\/a>.<\/p>\n\n\n\n<p>DI allows injecting <span class=\"lang:objc decode:true crayon-inline \">requestManager<\/span> as a singleton in the application, but uses mock object while testing. No one is aware of singleton however &#8211; neither <span class=\"lang:objc decode:true crayon-inline\">RequestManager<\/span>, nor <span class=\"lang:objc decode:true crayon-inline\">ViewController<\/span> &#8211; because all this stuff is managed by DI framework.<\/p>\n\n\n\n<p>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<ul class=\"wp-block-list\"><li>description of dependencies via macros or string constants<\/li><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><li>injected class should implement some protocol (this would not work with third party libraries)<\/li><li>initialization can&#8217;t be placed into a separate module<\/li><li>uses XML to describe dependencies<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">BloodMagic<\/h2>\n\n\n\n<p>So, let&#8217;s look into another framework (also with its set of disadvantages) &#8211; <a href=\"https:\/\/github.com\/railsware\/BloodMagic\">BloodMagic<\/a>.<\/p>\n\n\n\n<p>BloodMagic provides some sort of custom attributes. It&#8217;s designed to be extensible, so more features are coming soon. Currently, only one attribute is implemented &#8211; <a href=\"https:\/\/github.com\/railsware\/BloodMagic#lazy-initialization\">Lazy<\/a>.<\/p>\n\n\n\n<p>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<pre class=\"wp-block-preformatted\">@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\n<p>we can simply write:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">@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\n<p>And that&#8217;s it. Both <span class=\"lang:objc decode:true crayon-inline \">@dynamic<\/span> properties are created by a call to <span class=\"lang:objc decode:true crayon-inline \">self.progressViewService<\/span> and <span class=\"lang:objc decode:true crayon-inline\">self.resourceLoader<\/span>. They are released in the same way as a standard properties &#8211; after <span class=\"lang:objc decode:true crayon-inline \">ViewController<\/span> is deallocated.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">BloodMagic and Dependency Injection<\/h2>\n\n\n\n<p><span class=\"lang:objc decode:true crayon-inline \">+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<p>Creating custom initializer is a bit cumbersome, but works well:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">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\n<p><span class=\"lang:objc decode:true crayon-inline \">propertyClass<\/span> &#8211; initializer registers for property of this class.<\/p>\n\n\n\n<p><span class=\"lang:objc decode:true crayon-inline \">initializer<\/span> &#8211; block, which is called to initialize property. If this block is <span class=\"lang:objc decode:true crayon-inline \">nil<\/span>, or initializer is not found for concrete property, then object is created via <span class=\"lang:objc decode:true crayon-inline \">+new<\/span> class method.<\/p>\n\n\n\n<p><span class=\"lang:objc decode:true crayon-inline \">sender<\/span> &#8211; container class instance.<\/p>\n\n\n\n<p>Also, initializer has a <span class=\"lang:objc decode:true crayon-inline \">containerClass<\/span> property, which allows us to describe creation of the same property based on class container. For example:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">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\n<p>Thus, for <span class=\"lang:objc decode:true crayon-inline \">UsersViewController<\/span> and <span class=\"lang:objc decode:true crayon-inline \">ProjectsViewController<\/span> different objects are created. By default <span class=\"lang:objc decode:true crayon-inline \">containerClass<\/span> equals to <span class=\"lang:objc decode:true crayon-inline \">NSObject<\/span> class.<\/p>\n\n\n\n<p>Initializers help to get rid of various <span class=\"lang:objc decode:true crayon-inline \">shared*<\/span> methods and hardcoding, described in the beginning:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">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(&amp;once, ^{\n    singleInstance = [RequestManager new];\n  });\n  return singleInstance;\n};\n[initializer registerInitializer];\n<\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Organize initializers<\/h2>\n\n\n\n<p>We may have a lot of initializers, so it makes sense to move them into a separate place.<\/p>\n\n\n\n<p>Nice solution is to store them in different files and use attributes of a compiler (it&#8217;s a normal practice). BloodMagic has also a simple macros that hides this attribute &#8211; <span class=\"lang:objc decode:true crayon-inline \">lazy_initializer<\/span>. We should simply create a source file without header and add it to the compilation phase.<\/p>\n\n\n\n<p>Here is an example:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">\/\/  SomeInitializer.m\n\n#import &lt;BloodMagic\/Lazy.h&gt;\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\n<p><span class=\"lang:objc decode:true crayon-inline \">lazy_initializer<\/span> will be replaced with <span class=\"lang:objc decode:true crayon-inline \">__attribute__((constructor)) static void<\/span>. Attribute <span class=\"lang:objc decode:true crayon-inline \">constructor<\/span> means that this method will be called before <span class=\"lang:objc decode:true crayon-inline \">main<\/span> function (here are details: <a href=\"http:\/\/gcc.gnu.org\/onlinedocs\/gcc\/Function-Attributes.html\">GCC. Function Attributes<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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 &#8211; what is more important &#8211; there are now&#8230;<\/p>\n","protected":false},"author":55,"featured_media":5921,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":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":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/themes\/railsware\/vendors\/images\/article-thumbnail-default.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/55"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=5836"}],"version-history":[{"count":63,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5836\/revisions"}],"predecessor-version":[{"id":13966,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5836\/revisions\/13966"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/5921"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=5836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=5836"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=5836"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=5836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}