properties

Everybody uses iVars. You need them, that's no question. In order not to violate encapsulation either you have to provide accessors or you can declare properties. If you declare your variables as properties, you have to possibility to get your accessors generated by defined rules and set some other handy stuff.

Declaration

@interface someClass : NSObject {
    NSObject * someObject;
}
@property (nonatomic, retain, readwrite, getter = getMyAwesomeObject, setter = setNewAwesomeObject) NSObject * someObject;
@end

The result of this property declaration is something like this in the interface:

- (NSObject *) getMyAwesomeObject;
- (void) setNewAwesomeObject;

You can declare properties using the @property directive. Between the parentheses (which is an optional part) you can define attributes. These attributes will define how the accessors will work or how they should work if you implement them by yourselves.

Attributes

Accessor names
By using the getter and the setter attributes, you can define your accessors instead of the automatically generated accessors name (default in this case: getter=someObject, setter=setSomeObject).

Writability
By using readwrite, you have to have both accessors in your implementation and by using readonly you should have only a getter for your propert. The default writability is readwrite.

Setter mechanism

• strong: specifies a "strong" relationship with the destination object. It kind of guarantees that your object won't be deallocated until you have a reference to it
• weak: you won't have ownership over the value, if the object gets deallocated, your property's value will become nill
• retain: upon setting a property like this, the setter should release the previous value and retain the new
• assign: single assignment, no ownership
• copy: previous value should be released, new should be copied

Synchronization
By using the atomic attribute you ensure that your property would be safely accessible in a multi thread environment during multiple accessing. The default attribute is atomic and you can use nonatomic to prevent this mechanism (you should avoid using atomic if you can, because it has robust mechanism).

IBOutlet
IBOutlet is an identifier for properties. It's purpose is to mark the property so that in the interface builder you can assign it to certain elements.

synthesize

This is the best part. Using @synthesize you don't have to create accessors it will be provided to you by the compiler. More than that if you have a property and you didn't declared your variable the compiler will do that as well. These accessors - generated by the compiler upon using @synthesize - will follow the policy given by the property declaration. For example if you set the attribute retain, your generated setter will release the previous entry than retain the new value, or if you used readonly, only a getter will be provided to you.

You can use the property=ivar formula to specify that a particular instance variable should have been used for the property.

@synthesize firstProperty, secondProperty, thirdProperty=someIvar;

Without using synthesize you must implement the accessors for the property and you should do the implementation so that it fits the property attributes.

Private & Public

By default all of your declared properties are public, so they are accessible from outside of your object. If you want to use properties but limit it's access, you have declare your private properties in the @private section of your interface.

@interface someClass : NSObject
@property (strong, nonatomic) NSObject * someObject;
@private
@property (strong, nonatomic) NSString * somePrivateProperty;
@end

That's all i have for now, hope it will help understand the basics.

Blocks and Grand Central Dispatch

What are those so called blocks?

Blocks are chunks of codes which can be used for future execution. All right, blocks are more than that, but that's the basic idea. The good thing about blocks is that they can be used as method parameters, method return values you can pass them through objects and so on.

How does blocks look like?

Let's start with an example:

^(int number){return number > 100 ? YES : NO;};

Weird right? That's what I thought when I first saw it too. But it's not that hard. Let me explain. The little caret's (^) function is to declare that from that point we're dealing with a block. After it we have an optional part, the parameter(s). In our case an int named number. And within the curly brackets we have the code that will be executed.


That's pretty easy. If we want to assign it to a variable, that can be done this way:

BOOL(^isBiggerThanAHundred)(int) = (BOOL)^(int number){return number > 100 ? YES : NO;};

After this little declaration we can use it easily:

BOOL result = isBiggerThanAHundred(22);

As I said before the return value and the parameters are optional, so let's see an example for that case as well:

void(^spamLog)(void) = ^{NSLog(@"spam");}

The usage is the same as before:

spamLog();

Blocks are closures

Blocks are smart! Blocks can take a snapshot of their surroundings and encapsulate that state within themselves. This means that if you have a local variable defined before the block and you use it within the block, the block will be able to access it even if it's execution is delayed. More to that the value of the local variable within the block won't change.

NSData * date = [NSDate date];
void(^dateBlock)(void) = ^{
    NSLog(@"Date is %@", date);
}

The interesting part is that if you call the dateBlock(); method it will give you the current date in this example. But if you call it again a little later, you'll see exactly the same value because the block is not using the actual date variable we created there. It will use the snapshot it created in the specific time when it was created.

Why to use them?

First of all, you have to. More and more objects have methods that are working with blocks. For example UIView animations.

[UIView animateWithDuration:1.0f
                     animations:^{
                       someView.alpha = 1.0f;
                     }
                     completion:^(BOOL finished) {
                         if (finished) {
                           someOtherView.alpha = 0.0f;
                         }
                     }];

But there's more than that. You'll be able to pass through callback code chunks, you'll be able to give an executable code to another object with a snapshots of the block's scope and so on. And at least but not last it's worth using because of GCD.

Grand Central Dispatch

GCD is what makes blocks really awesome. It makes multithreading easy. With GCD you can use/create queues where you can submit blocks to be executed. There are three types of queues we can use:

• Main
  Tasks will be executed serially on the app's main thread.
• Concurrent
  Tasks will be fired in a FIFO order concurrently, and the submitted tasks can finish in any order.
• Serial
  Execution in a FIFO order but only one task can run at a time.

The main queue is always there. It's the main thread you're application is running on. You can access it by calling dispatch_main.

You can use concurrent queues to execute blocks concurrently. Concurrent queues are global to your application. You can request global queues by calling dispatch_get_global_queue. Concurrent queues are created by the GCD itself and they are only different by their priority level. e.g.

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0)

By default there are no serial queues provided by GCD, you have to create/manage them yourself.

dispatch_queue_t backgroundQueue = dispatch_queue_create("com.victo.someapplication.bgqueue", NULL);

Putting things together

At this point, probably we can create blocks, we can use queues given by GCD. So let's put these things together.

- (void)startAsync {
    dispatch_async(backgroundQueue, ^(void) {
        [self doSomethingAsync];
    });
}

- (void)doSomethingAsync {
    // run some code here (http request, file operation, etc...)
    dispatch_async(dispatch_get_main_queue(), ^(void) {
        [self refreshUI];
    });
}

What did we do above? when calling the startAsync method, it's using the backgroundQueue (declared before) to run our code asynchronously. After the doSomething method did what it wanted it will run another block of code on the main thread to refresh the UI.

By using blocks and GCD, you can forget NSOperation and NSInvocationOperation, in most cases you won't need to use NSThread any more. Isn't it fun? I think it's cool.

That's all for now. You can find more information at developer.apple.com about GCD and blocks if you need more.

Playing a bit with NSURLConnection

First of all, I just have to define what I'm going to do. I found an open API to work with. I'm a WOW player and since there's an API by Blizzard to access some WOW related information, I'm going to use that to get specific WOW character data.

Here's the API doc, if you're interested:
http://blizzard.github.com/api-wow-docs/

Since I want to use "new" stuff (by new I mean thing I never used before) I will use ARC, GCD with blocks, native JSON parsing, I'm going to use storyboard and I want to put as most IOS version >= 4.0 features as I can.

First we need a HTTP client to work with. I choose NSURLConnection because the delegate callbacks are close to what I want to have.

Interface

So, what are the requirements?
To keep things simple I want to have a delegate to implement just the necessary things

@protocol HTTPRequestServiceResponseDelegate <NSObject> 
@required
- (void)HTTPConnectionFinishedWithData:(NSData*)data;
- (void)HTTPConnectionFailedWithError:(NSError*)error;
@optional
- (void)HTTPStatusCodeFetched:(int)statusCode;
- (void)HTTPConnectionCancalled;
@end

Fairly simple right? The HTTPConnectionFinishedWithData method will send the downloaded data to the delegate, while the HTTPConnectionFailedWithError method will notify the delegate on errors. The optional methods are just to have additional informations if you want to have those.
Let's start implementing stuff. My HTTP client will encapsulate the NSURLConnection and it's related vars and will give back feedback and data to it's delegate. My plan was to initialize with a host and with two optional parameters, HTTP method and variables in a dictionary.

The initialization looks like this.

- (id)initWithHost:(NSString*)host;
- (id)initWithHost:(NSString*)host withParameters:(NSDictionary*)parameters;
- (id)initWithHost:(NSString*)host withParameters:(NSDictionary*)parameters withHTTPMethod:(NSString*)method;

I wanted to keep the number of ivars as less as possible. The most important is the responseData where the callback will gather the connection's data. The other ivars are to keep track of the connection and store some specific data if it's required later on. Plus we have the connection delegate, where we can send back our data/feedback.

@interface HTTPRequestService : NSObject <NSURLConnectionDelegate>  {
    NSURL * requestURL;
    NSURLConnection * connection;
    NSString * HTTPMethod;
    NSMutableData * responseData;
    BOOL running;
    BOOL cancalled;
}

@property (weak) id<HTTPRequestServiceResponseDelegate> delegate;

@property (nonatomic, strong) NSURL * requestURL;
@property (nonatomic, strong) NSURLConnection * connection;
@property (nonatomic) BOOL running;
@property (nonatomic) BOOL cancalled;

@property (nonatomic, strong) NSString * HTTPMethod;
@property (atomic, strong) NSMutableData * responseData;

I added a few other methods to my implementation. These are:

- (BOOL)validateURL;
- (BOOL)startRequest;
- (void)cancelRequest;

The validateURL method is self explanatory as well as the startRequest method. The cancelRequest will cancel an ongoing request and it will notify the delegate.
You can see there there that I was using ARC, so I used strong/weak references. The only thing worth mentioning here is that you always use only weak on delegates.

Implementation

- (id)initWithHost:(NSString*)host withParameters:(NSDictionary*)parameters withHTTPMethod:(NSString*)method {
    self = [super init];
    if (self) {
        self.HTTPMethod = method;
        
        if ([host length]) { // Only doing anything if have at least a host to do a request with
            NSString * HTTPParameters = nil;
            if ([parameters count]) {
                HTTPParameters = [URLUtil createQueryStringFromDictionary:parameters];
            }
            NSMutableString * urlString = [NSMutableString stringWithString:host];
            if ([HTTPParameters length]) {
                [urlString appendString:HTTPParameters];
            }
            NSLog(@"URL to call: %@", urlString);
            self.requestURL = [NSURL URLWithString:urlString];
        }
    }
    return self;
}

This is the point where we got all the required info to do the actual initialization. We're doing some validation on the parameters, and using the URLUtil we put together the parameters string from the dictionary. Note here that the request has not been fired here, we're just dealing with the url.

A bit about the URLUtil. This little class is to convert our dictionary into a parameter string. Pretty easy stuff, I'm not going to explain it in details, you can just check the code. It will iterate through the dictionary, escape it and it will return a string ready to use for NSURL.

@implementation URLUtil

+(NSString*)urlEscapeString:(NSString *)unencodedString 
{
    CFStringRef originalStringRef = (__bridge_retained CFStringRef)unencodedString;
    NSString *s = (__bridge_transfer NSString *)CFURLCreateStringByAddingPercentEscapes(NULL,originalStringRef, NULL, NULL,kCFStringEncodingUTF8);
    CFRelease(originalStringRef);
    return s;
}

+ (NSString*)createQueryStringFromDictionary:(NSDictionary *)dictionary
{
    NSMutableString *urlWithQuerystring = [NSMutableString string];
    
    for (id key in dictionary) {
        NSString *keyString = [key description];
        NSString *valueString = [[dictionary objectForKey:key] description];
        
        if ([urlWithQuerystring rangeOfString:@"?"].location == NSNotFound) {
            [urlWithQuerystring appendFormat:@"?%@=%@", [self urlEscapeString:keyString], [self urlEscapeString:valueString]];
        } else {
            [urlWithQuerystring appendFormat:@"&%@=%@", [self urlEscapeString:keyString], [self urlEscapeString:valueString]];
        }
    }
    return [urlWithQuerystring stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
}

@end

After our initialization is done, we can validate the URL with the validateURL method and you can fire the request using the startRequest method which will give you back NO if there was any error during the creation of the connection.

- (BOOL)validateURL {
    if (self.requestURL != nil) {
        return YES;
    }
    return NO;
}

- (void)cancelRequest {
    if (self.running) {
        [self.connection cancel];
        self.running = NO;
        self.cancalled = YES;
        if ([delegate respondsToSelector:@selector(HTTPConnectionCancalled)]) {
            [delegate HTTPConnectionCancalled];
        }
    }
}

- (BOOL)startRequest {
    if (self.requestURL) {
        NSMutableURLRequest * request = [NSMutableURLRequest requestWithURL:requestURL];
        [request setHTTPMethod:self.HTTPMethod];
        self.connection = [NSURLConnection connectionWithRequest:request delegate:self];
        responseData = [NSMutableData data];
        self.running = YES;
        [connection start];
        return YES;
    }
    else {
        NSLog(@"Cannot create NSURL from urlString");
    }
    return NO;
}

Data handling

At this point if we did everything right, we have an open HTTP connection. We have to accept the data coming through and we have to pass the relevant information to our delegate.

- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSHTTPURLResponse *)response {
    NSHTTPURLResponse * HTTPResponse = (NSHTTPURLResponse *)response;
    int statusCode = [HTTPResponse statusCode];
    if ([delegate respondsToSelector:@selector(HTTPStatusCodeFetched:)]) {
        [delegate HTTPStatusCodeFetched:statusCode];
    }
}

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
    [responseData appendData:data];
}

- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
    if (delegate) {
        [delegate HTTPConnectionFinishedWithData:responseData];
    }
    self.running = NO;
}

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error {
    [delegate HTTPConnectionFailedWithError:error];
}

The first method (didReceiveResponse) will be responsible for giving back an HTTP status code. The didReceiveData is again self explanatory as well as the didFailWithError method. After the connection is closed we'll pass back the data using the HTTPConnectionFinishedWithData method.

That's all for now, feel free to add any constructive comment. You can download the source code here.

Introduction

First of all I wanted to do some introduction. I started iPhone development late in 2009 in a small company. It was a rough change for me, because before that mainly I did web development. We did middle size projects but after a while I got a better opportunity in a huge, multinational company.
That's when the game really started for me. It was all about code quality, design patterns, unit testing and more stuff I wasn't even aware of. Since then I'm working there doing application for market leading companies both in IOS and Android.
I'm not an Android lover, nor a hater, but this blog (at least for now) is just about IOS. The reason I'm doing this is because in this year and in the last year I was only involved in Android development and I started feeling that my knowledge has faded a bit which I'm not really happy about.
I hope you guys will find some interesting/helpful stuff here.