Cocoa Exposed

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{ //spawn a slave //you will typically have a singleton from which //you can access the master (in this example SPM) NSManagedObjectContext* slave = [SPM.localMaster spawnSlave]; NSManagedObjectContext* ui = SPM.localMaster.uiMOC; __weak typeof(slave) weakSlave = slave; __weak typeof(ui) weakUi = ui; __block NSArray* resultIDs; //perform the fetch on the slave's thread [slave performBlockAndWait:^{ NSFetchRequest *request=[[NSFetchRequest alloc] initWithEntityName:@"Entity"]; request.predicate=[NSPredicate predicateWithFormat:@"Complex fetch predicate"]; request.resultType = NSManagedObjectIDResultType; NSError *error; resultIDs = [weakSlave executeFetchRequest:request error:&error]; //check the error }]; [ui performBlock:^{ //do something on the main thread with the results NSManagedObject* firstObject = [weakUi objectWithID:[resultIDs firstObject]]; }]; });

There you go, this little gem just saved you from a lot of tangled ifs and cases.

Let's take the code below: CGRect rect = button.frame; rect.origin.x = tableView.frame.origin.x; rect.origin.y = tableView.frame.origin.y + tableView.frame.size.height; button.frame = rect; Assuming `button` and `tableView` are in the same superview, the code aligns `button` just below `tableView` and to the left. That's grand, but there's a lot of boilerplate code around and if you're not using nib files, you'll be writing a lot of code like this. Actually, even if you do use nib files you'll probably going to write this stuff often enough to become a nuisance. So here: [.h](https://raw.github.com/valentinradu/UIViewEasyPositioning/master/UIViewEasyPositioning/UIView+VRAlign.h) and [.m](https://raw.github.com/valentinradu/UIViewEasyPositioning/master/UIViewEasyPositioning/UIView+VRAlign.m) is a category that makes things smoother. It provides a simple way of aligning your views relative to siblings or to arbitrary points. So the above code becomes: button.topLeft = tableView.bottomLeft; Which basically translates to: *The top left anchor point of `button` will be in the same position as the bottom left anchor point of `tableView`.* Here you go, a graphical representation of each anchor point for a better understanding:  It comes in many other flavours: //centers the views vertically, aligns on top horizontally button.topCenter = tableView.topCenter; //aligns on right vertically, centers horizontally button.middleRight = tableView.middleRight; button.bottomCenter = CGPointMake(10, 20); [Here](https://github.com/valentinradu/UIViewEasyPositioning)'s a Github project that demonstrates some other types of alignment.

I stumbled upon [this](http://drj11.wordpress.com/2007/04/08/sizeofchar-is-1/) post today, and while the author did some very good remarks: char i; size_t iSize = sizeof i; it's easier to maintain and read than: char i; size_t iSize = sizeof(char); I'm outraged sadden by his belief that since `sizeof(char)` (or `sizeof i` in our first example) is always 1 as per C standard we should always write code like this: aChar = malloc(kCharsCount); instead of: aChar = malloc(kCharsCount*sizeof(*aChar)); //aChar = malloc(kCharsCount*sizeof(char)); as he puts it Because, "It adds clutter and it suggests that you don’t know enough C". That's utterly rubbish. First of all, it's not about portability, yes, a `char` is always 1 byte as per C standard, no matter if the byte has 8 bits or not. However, there are other things to consider, namely, readability and maintainability. Obviously, `aChar = malloc(kCharsCount*sizeof(*aChar));` is easier to maintain since if you change the type of `aChar` it will still work as expected. Also, in a function someFunction(aChar, sizeof(*aChar), kMultiplier); is easier to read and more maintainable than someFunction(aChar, 1, kMultiplier);//what's with the 1? Finally, even `sizeof(char)` is better than `1`. In #define buff_size (8 * sizeof(char)) is clear that `buff_size` is the size needed to hold up to 8 `chars`, whereas #define buff_size (8) tells you absolutely nothing.

The motivation =========== Xcode's OpenGL Game template is not quite the cleanest way to start your OpenGL project. It adds a lot of code you don't initially need and by the time you will need it, you'll probably structure it in a different manner, which means you'll have to clean it form the template. The good news is that, to set up the most basic GLKView to handle your drawing routines you only need 3 lines of code. The example project for this article can be found [here](https://github.com/valentinradu/Simple-OpenGL-Init) The solution ========= So, here are the three lines of code that get you started. //these are the only three lines you //need to write in order to init your GLKView //while there are several options you could set here too, //you can actually skip them and go straight ahead to //SGLView (which is a subclass of GLKView by the way) drawRect: method //and start drawing in it //we create the context using the latest API EAGLContext * context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2]; [EAGLContext setCurrentContext:context]; //we init our GLKView subclass with our newly created context SGLView * view = [[SGLView alloc] initWithFrame:self.window.frame context:context]; After this, you should be able to override your view's `drawRect:` method and draw. Let's try something that doesn't need preliminary setup. - (void)drawRect:(CGRect)rect { //clear the screen glClearColor(0.0f, 1.0f, 1.0f, 1.0f); } **That's it**, your GLKView is set up, from here the additional settings depend on how you plan to use OpenGL (2D, 3D, on screen, off screen, etc.). A little extra ========= To make the matter complete, let's try to draw a simple 2D square. So, in our GLKView subclass we will use `GLKBaseEffect` to handle the projection and the drawing colour. For more details, refer to the comments below. - (id)initWithFrame:(CGRect)frame context:(EAGLContext *)context { self = [super initWithFrame:frame context:context]; if (self) { //the effect makes our life easier //we need not worry about the colour array nor the projection effect = [[GLKBaseEffect alloc] init]; effect.useConstantColor = GL_TRUE; //nor for the projection //which will be orthogonal for the sake of simplicity //the parameters are for 4-inch retina, 3.5 retina would have been //-1.0f, 1.0f, -1.5f, 1.5f, 1.0f, -1.0f GLKMatrix4 projectionMatrix = GLKMatrix4MakeOrtho(-1.0f, 1.0f, -1.7f, 1.7f, 1.0f, -1.0f); effect.transform.projectionMatrix = projectionMatrix; //set a color for our drawing effect.constantColor = GLKVector4Make(190.0f/255.0f, 182.0f/255.0f, 171.0f/255.0f, 1.0f); //generate and bind each of the vertex and index buffer //upload data to them glGenVertexArraysOES(1, &vertexArray); glBindVertexArrayOES(vertexArray); glGenBuffers(1, &vertexBuffer); glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer); glBufferData(GL_ARRAY_BUFFER, kVertexNum*sizeof(GLKVector3), &vertexData, GL_STATIC_DRAW); glGenBuffers(1, &indexBuffer); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexBuffer); glBufferData(GL_ELEMENT_ARRAY_BUFFER, kIndexNum*sizeof(GLbyte), &indexData, GL_STATIC_DRAW); glBindBuffer(GL_ARRAY_BUFFER,0); glBindVertexArrayOES(0); } return self; } And then the drawing code. - (void)drawRect:(CGRect)rect { //clear the screen glClearColor(1.0f, 1.0f, 1.0f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glBindVertexArrayOES(vertexArray); //draw glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer); glEnableVertexAttribArray(GLKVertexAttribPosition); glVertexAttribPointer(GLKVertexAttribPosition, 3, GL_FLOAT, GL_FALSE, sizeof(GLKVector3), (void*)0); [effect prepareToDraw]; glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexBuffer); glDrawElements(GL_TRIANGLE_STRIP, kIndexNum, GL_UNSIGNED_BYTE, (void*)0); glBindBuffer(GL_ARRAY_BUFFER,0); glBindVertexArrayOES(0); } And finally, we have two `static const` buffers that provide the necessarily drawing data. static const GLbyte kVertexNum = 4; static const GLbyte kIndexNum = 6; //the vertex data is added from the left bottom corner //towards right, up and finally left //as the ascii art suggests static const GLKVector3 vertexData[kVertexNum] = { {-0.5f, -0.5f, 0.0f},//0 3-----2 {0.5f, -0.5f, 0.0f},//1 | | {0.5f, 0.5f, 0.0f},//2 | | {-0.5f, 0.5f, 0.0f},//3 0-----1 }; //we basically draw 2 triangles //as described in the ascii art static const GLbyte indexData[kIndexNum] = { 0, 3, 1, 3, 2, 1 /* 3--2 |\ | | \| 0--1 */ };

The motivation =========== You probably wrote the following lines in your view controllers plenty of times: self.tableView.delegate = self; self.tableView.dataSource = self; *Usually*, that's fine. However, if you have another table view in your app which has more or less the same look and feel, but a different controller managing it, a problem rises. It would be nice to reuse all the delegation code you wrote in your initial controller. And only change the data and do other small customisations. You could tackle this problem in several ways. But before we start, know that you can find the Github project for this article [here](https://github.com/valentinradu/UITableView-Decorator-Example). The inheritance solution ================= So, one way would be to have a generic view controller, make it the superclass of both of your controllers and implement the delegation methods in it. Than would solve the initial problem, however if for example the two table views have a different header and footer and you override `tableView:viewForHeaderInSection:` and `tableView:viewForFooterInSection:` a third table view that would like to have the footer from the first and the header from the second would have no way to get it without duplicating code. [^1] The aggregation solution ================== Another way to do it would be to create and use some delegate objects instead of passing `self` as a delegate. dataSourceObject = [[VRDataSource alloc] init]; delegateObject = [[VRDelegate alloc] init]; self.tableView.dataSource = dataSourceObject; self.tableView.delegate = delegateObject; The objects are of a different class, so multiple table views can use different instances of it. That sounds nice, the delegates can even have their own inheritance structure, which means no code will ever be duplicated, which is even greater. However, our objects don't have direct access to the controller's properties and methods, which means there will be one handling method on the delegate side and one on the controller side: - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath { //the controller is our resolver in this case [self.resolver didSelectRowAtIndexPath:indexPath]; } Also, this means we will need a generic controller to respond to those messages, or a protocol which has to be implemented by all the controllers wishing to delegate responsibilities to our objects. The decorator solution ================ A nice way to solve all the problems above and also have the freedom to implement parts of your delegates in different classes is by using the [decorator design pattern](http://en.wikipedia.org/wiki/Decorator_pattern). [^2] So, we want the delegates to be different objects, but still be able to message **transparently** our controller. They sound like proxies to me [^3]. So, we first init our delegate objects keeping a reference to our decorated object, which in our case is the controller. - (id)initWithDecoratedObject:(id) decObj { self = [super init]; if (self) { self.decoratedObject = decObj; } return self; } Then, every message we receive in our decorators (delegates) and we can't respond to, we forward towards our decorated object (controller). Each method override is explained in the code below. //the first thing the forwarding mechanism does //is calling this method if there is no selector //found //we override it and try to send the same message to our //decorated method //if that fails too, we have nothing better to do than let //the system rise the exception by returning self - (id)forwardingTargetForSelector:(SEL)aSelector { if ([_decoratedObject respondsToSelector:aSelector]) { return _decoratedObject; } return self; } //objective-c is smart enough to know the //difference between inheritence and this 'fake //inheritence' we're trying to do //methods like respondsToSelector: and isKindOfClass: look only //at the inheritance hierarchy, never at the forwarding chain //so we force them to consider it by overriding them - (BOOL)respondsToSelector:(SEL)aSelector { if ( [super respondsToSelector:aSelector] ) return YES; else { if ([_decoratedObject respondsToSelector:aSelector]) { return YES; } } return NO; } - (BOOL)isKindOfClass:(Class)aClass { if ([super isKindOfClass:aClass]) { return YES; } else { if ([_decoratedObject isKindOfClass:aClass]) { return YES; } } return NO; } This way, we will be able to implement some of the methods in our designated delegates and some in our view controller. Which saves us the trouble of forwarding the messages ourselves manually, like in the aggregate solution. Another nice thing about this technique is that you can add or remove a delegate method from your delegate at runtime, which makes it very easy to customise. Also, a nice chain of delegates objects can be formed to give you extra control on how our table view looks. To better visualise all this, here is the set up code: //init the controller //this is just a basic UIViewController subclass implementing //DEDecoratedViewControllerProtocol protocol //a nice thing about this method is that you can keep //your model-controller relation intact //so, even if the controler will not be the table view delegate, //it will still hold the model data for us DERootViewController * viewController = [[DERootViewController alloc] init]; //our model data is simply a dictionary for the sake of simplicity viewController.tableItems = @[@{@"title": @"Africa"}, @{@"title": @"America"}, @{@"title": @"Asia"}, @{@"title": @"Europe"}]; //decorate the text label with a color dec = [[DERedDecorator alloc] initWithDecoratedObject:viewController]; //is as easy as this to change it to another color //DEAbstractDecorator * dec = //[[DEGrayDecorator alloc] initWithDecoratedObject:viewController]; //then decorate the table view with a footer //notice that we pass the prev decoration as parameter //this is really nice because we can have a chain of decorations on //the same decorated object dec = [[DEFooterDecorator alloc] initWithDecoratedObject:dec]; //maybe we want a header too dec = [[DEHeaderDecorator alloc] initWithDecoratedObject:dec]; //create the tableview UITableView * tableView = [[UITableView alloc] initWithFrame:self.window.frame style:UITableViewStylePlain]; //delegate to decorator tableView.delegate = dec; tableView.dataSource = dec; For a better overview on how all this works [here](https://github.com/valentinradu/UITableView-Decorator-Example) is a Github project with all the code within a working example. [^1]:I know, that's unlikely to happen, probably not the best example, but bear with me, the implications of the decorator pattern lay beyond this type of delegation. [^2]:Is not a pure implementation, but it's pretty close. [^3]:When it comes to implementation, I choose not to use `NSProxy` because [Apple's Documentation](https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html) states that `forwardInvocation:` is much more expensive than `forwardingTargetForSelector:` which is not implemented for NSProxy.