Tag Archives: Objective-c

Architecting with Blocks part 2

(Note: This is part 2 of a series of posts about Architecting an application using blocks in objective-c. By no means I am an expert on using blocks, and also it’s not the intention of this series to teach you how to use blocks. You can check this for that. To finalise, I am sure there are better ways to use blocks while architecting an app: use this at your own risk. :))

This is the final post from a 2 parts series that I start a long ago. In this case I won’t show any snippet of code, I will give away an entire sample. My approach about this matter, change in the meantime, nonetheless hope you enjoy it. You can find it here .

Tagged , , , , , , ,

Item 3, Prefer Literal Syntax over the Equivalent Methods

Note: This post is part 3 of a series of posts I will do about the new book of Matt Galloway.

Prefer Literal Syntax over the Equivalent Methods

Literals have been around objective-c since a long time:

NSString *aString = @"Hello World";

With the latest versions of Clang, this sugar syntax has been extended to NSNumbers, NSArrays & NSDictionaries. Since we deal with this kind of objects every day, this new feature is well appreciated. In a nutshell this allow us to:

  • Reduce the boilerplate
  • Cleaner code
  • Faster typing

While using NSNumbers, you can use literals in the following way:

  • @15 => [NSNumber numberWithInt:15]
  • @15.6 =>[NSNumber numberWithFloat:15.6]
  • @15.123123 => [NSNumber numberWithDouble:15.123123]
  • @YES => [NSNumber numberWithBool:YES]

As you can see, in this case, the amount of extra code is reduced in more than 75%.

You can also use literals in collections with subscripting. With NSArray you can do the following:

  • @[@"One", @"Two"] => [NSArray arrayWithObjects:@"One",@"Two"];
  • By Array subscripting: myArray[1] => [myArray objectAtIndex:1];

And finally with a NSDictionary:

  • @{@"key1":@"object1", @"key2":@"object2"} => [NSDictionary dictionaryWithObjectsAndKeys:@"object1",@"key1",@"object2",@"key2" nil];
  • myDictionary[@"key1"] = @"newObject1"; => [dic setObject:@"newObject1" forKey:@"key1"];

And if you want a mutable object:

  • [@[@"1",@"2" ] mutableCopy];
  • [@{@"key1":@"object1"}mutableCopy];

Although with collections the end result seems the same, if an object is nil, it won’t. While using the common operations adding a nil wouldn’t crash anything, with literals it will:

  • [NSArray arrayWithObjects:@"object1",nil, @"object2", nil] => It’s “ok”.
  • @[@"object1",nil, @"object2"] => It will raise an exception.

In theory it would be better if the first option would crash, because it doesn’t make much sense to have a nil in the middle of an array and work with it in that state. Most of the time, you would prefer that would crash, so you could see immediately where the problem is.

Literals are an awesome addition in a very verbose language like objective-c. Knowing how to use them and their caveats is a must have for every programmer.


Tagged , , , , , , , , ,

Item 2, Minimize Importing Headers in Headers

Note: This post is part 2 of a series of posts I will do about the new book of Matt Galloway.

Minimize Importing Headers in Headers

The second item, unfortunately a short one, talks about importing classes: the where and the how. One should be careful when importing things he doesn’t need on the .h file. Most of the time, specifying @class (forward declaration) instead of an #import is  the best choice. Importing creates dependences between classes that should be avoided (when possible). So what does this @class actually means?

“The @class directive minimizes the amount of code seen by the compiler and linker, and is therefore the simplest way to give a forward declaration of a class name. Being simple, it avoids potential problems that may come with importing files that import still other files. For example, if one class declares a statically typed instance variable of another class, and their two interface files import each other, neither class may compile correctly.” – Abizern, http://stackoverflow.com/a/323510/491239.

So in a nutshell (from Mr. PeyloW, http://stackoverflow.com/a/1350029/491239):

  • Only #import the super class, and adopted protocols, in header files.
  • #import all classes, and protocols, you send messages to in implementation.
  • Forward declarations for everything else.

And a quick example:

“The reasoning behind forward declarations in header files is that it avoids unnecessary dependencies. i.e. Imagine B.h forward declares A and B.m imports A.h. Then imagine C.m, D.m, E.m and F.m import B.h. After all this is done, A.h changes. Since A is only forward declared in B.h, only B.m needs to rebuild. Without forward declarations, C.m, D.m, E.m and F.m would all need to be rebuild if A changes” – Jacob Relkin, http://stackoverflow.com/a/2770246/491239

Hope you enjoyed this quick reference to how to import in objective-c.

Tagged , , , , , , , ,

Item 1, Familiarize Yourself with Objective-C’s Roots

Note: This post is part 1 of a series of posts I will do about the new book of Matt Galloway.

Familiarize Yourself with Objective-C’s Roots

Dynamic language

In this item, the author starts by delving into how Objective-c send messages as opposed of function calling (in this case comparing to C++)  and when one should be used instead of the other (you can still use function calling in objective-c).  The dynamic nature of objective-c, binds the messaging to the corresponding piece of code that will be called, at runtime; as opposed to C++ (for example) that is done at compile time.

Memory Management

One should understand how related objective-c is to c (it’s a superset) and how/where the allocations are made:

NSString *aString = @"BlahBlah";

In this case “aString” is a pointer to a piece of memory allocated on the heap. Although this is mostly true for allocating objects in objective-c, blocks for example are allocated on the stack, but can be  passed to the heap (block_copy()).  An excellent post by Mike Ashe explains this as well.  Plus when you alloc, new, retain or copy an object, you are responsible for them.  It’s important as well to know how the memory is managed in objective-c:

 ” (..) that any single object can have multiple “owners”, and the system won’t allow the object to be destroyed until all owners have relinquished ownership.” – Mike Ashe,  Stack and Heap Objects in Objective-C

In one hand with manual memory management, you are responsible for cleaning the house, with ARC the cleanup is being made for you. Do remember, that ARC is not a Garbage collector, so you should need to understand when you have to do something (circular references for example) and when you don’t.

You will find plenty of variables that will be create on the stack, for example:

CGPoint point = CGPointMake(12.0f,10.0f);

CGPoint is a structure and it’s defined like this on CGGeometry.h from CoreGraphycs.framework:

struct CGPoint {

CGFloat x;

CGFloat y;

typedef struct CGPoint CGPoint;

It’s important to measure if you are going to use objects (vars that point to something that has being allocated on the heap) and, in this case, structures (vars that might be using stack space), or non-objects int,float, char, etc. Allocating objects  can incur on an unnecessary overhead, so chose the right tool for the job in hand.

The first item, is a very well written intro into how objective-c works internally versus other languages, and how you can take advantage of the C language . As it is build upon it, some time should be taken to understand it.

Tagged , , , , , , ,

Effective Objective-c 2.0, by Matt Galloway

Over the next weeks, I will be making a small comment about the new book of Mr. Matt Galloway. This comments will be about each chapter’s item, so we are talking about 52 small posts. I prefer to do so, instead of dissecting 7 chapters. So godspeed!

The goal here is not to, in no way, transcript the book, but to be a guide for me, to study and retain what the book is trying to transmit.

Tagged , , , , , ,

Pointer to a Pointer

I came to a point (the irony…) where I needed the following:

// Declare the queue
dispatch_queue_t workingQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

NSError *parsingError = nil;

if (condition == YES)
    [self doSomethingLongWithError:&parsingError];
    [self doSomethingElseLongWithError:&parsingError];

dispatch_async(dispatch_get_main_queue(), ^{

// Check if we got an error

if (parsingError)

So what’s happening?

– I have one working thread doing some heavy stuff (in this case parsing)
– Once that work is done I want to update my UIViewController, by executing the block success() or the block error(parsingError).

The idea here is to be able to actually do something heavy, not expecting a return, and also be able to know if something went wrong.

As you might imagine the signature of the methods is:

- (void)doSomethingLongWithError:(NSError **)error;
- (void)doSomethingElseLongWithError:(NSError **)error;

If you notice, I am passing an &parsingError in both methods. Why? Well that’s where it becomes interesting the use of pointers to pointers. The powerful aspect of it is that I am able to declare the parsingError on the scope of the working thread, pass it’s pointer to a different scope (in this case of the methods) and once that working thread is done I can rely on the value of the parsingError on the main thread to take the appropriate action.

Tagged , , , , , , ,


While I do prefer to use JSON, instead of XML. I use to prefer it, but for the wrong reasons. Well, not wrong, but you can always improve right? So why do I love it?

– Lighter than XML

NSDictionary *dictionary = [NSJSONSerialization JSONObjectWithData:myJsonData options:kNilOptions error:&error];

Well the first is really nice, but it doesn’t really help us out, at least directly. The second is just glorious. You get a NSDictionary, that you can use across all your app, with one single line. What’s the catch? In terms of visibility is just wrong. I know I have my data there, but does the next guy that is going to support my app knows that? I can leave some comments…. I promise.. Instead, just create a class to hold that data, and give it some meaning. What I would recomment is something like this:

- (id)initWithDictionaryFromJSON:(NSDictionary*)dictionary;

It is boring, but it gives visibility, helps maintenance,  and gives meaning to your data.

Tagged , , , ,

Architecting with Blocks part 1

(Note: This is part 1 of a series of posts about Architecting an application using blocks in objective-c. By no means I am an expert on using blocks, and also it’s not the intention of this series to teach you how to use blocks. You can check this for that. To finalise, I am sure there are better ways to use blocks while architecting an app: use this at your own risk. :))

On most of the applications out there ( I would say 60%, not counting with games), a normal application follows the same pattern:

  •  Server Request
  •  Handle Response
  •  Parse it
  •  Show to the user
  • Handle any error that might appear

What I have been using, so far, to handle this typical problem is:

  • ViewController complying to a protocol
  • Pass reference to the Server Requester Class (normally like this @property(weak,nonatomic) id <myProtocol> delegate)
  • Request Data
  • Take care of data (Parsing usually)
  • Using the reference passed before, call the most appropriate method from the protocol (normally either success or failure)

It’s the usual pattern, but it can become a bit verbose, if you happen to have a lot of different UIViewControllers, requesting and expecting different things. So, on my last project I tried to rely mostly on blocks.

I had three different kind of resources to get from the server, one of them would rely on the other two (to make the 3rd request I would need that the user had choose the other two). I started by creating a typedef enum:

// Used to know which request we are using
typedef enum



} kRequest;

You use the typedef enum so you can better understand your code ( kFirstRequest, kSecondRequest and kFinalRequest are nothing more than integrals). Next, you define four blocks:

// Block that will be executed when the server's response has been received and parsed
// In theory, you won't need the typeOfRequest to be passed to the block, but you can use it as well
typedef void(^SuccessBlock)(NSArray *arrayObjects, kRequest typeOfRequest);

// Block that will be executed when we receive the server's response
typedef void(^ParsingBlock)(NSData *serverResponse);

// Block that will be executed if something goes wrong (Request, or Parsing)
typedef void(^ErrorBlock)(NSError *errorObject);

// Block that will be executed if something goes wrong (Request, or Parsing)
typedef void(^RequestBlock)(NSError *errorObject, kRequest typeOfRequest);

This is the base of our code. Instead of using a protocol and pass references between different objects, we will pass blocks. You should add this code to a file called Constants.h. On your prefix.pch file, you should import it. This way, you have access to the blocks and the typedef enum in any part of your application.

Tagged , , , , , , , , ,

If you want to perform a selector on every object of an NSArray just:

[myArray makeObjectsPerformSelector:@selector(mySelector)];

Selectors on Steroids

Tagged , , , ,