IOS openGL rotating Earth using NinevehGL from Erick Bennett on Vimeo.

In this tutorial I am going to show you how to easily, and effectively add an openGL ES 2.0 3D view into your project, and display a fully rendered, rotating 3D earth. The model assets are available here, and include the object and texture. These assets are also available in the project ZIP file, available thru the link at the end of this tutorial.

Download and install the NinevehGL framework.

Since we want to add this view into an existing project and understand how the engine functions, lets create a new single-view project to start. Although NinevehGL can just as easily be setup thru interface builder, we will be adding this view programmatically. For this exercise, it does not matter if you select storyboard or XIB for the new project.

To begin with there are a few frameworks we will need to add. Do this by first selecting your projects main file in the project navigator pane. Make sure your projects target is selected, and under Build Phases click ‘Link Binaries with Libraries’. Use the + at the bottom of this display and add the QuartsCore  and OpenGLES frameworks.

Next, using the ‘Add Other’ button, navigate to your downloaded NinevehGL folder and import the NinevehGL.framework.

Now onto the code…….import NinevehGL into your header (.h) file,

#import <NinevehGL/NinevehGL.h>

add the delegate to your @interface, if this is missing your drawview method will never get called.

@interface ViewController : UIViewController <NGLViewDelegate>;

In order to see what is being rendered we will need an ivar for an NGLCamera, and for our single object, an NGLMesh. The complete code for all of this should look as follows.

#import <UIKit/UIKit.h>
#import <NinevehGL/NinevehGL.h> 

@interface ViewController : UIViewController <NGLViewDelegate> 
{ 
    NGLCamera *_camera; 
    NGLMesh *_mesh; 
}

In your source (.m) file you must initialize your NGLView, set its delgate to self, define a dictionary with a few basic settings, and initialize the mesh and camera. I am doing this in my viewDidLoad method but depending on your needs, this could be done elsewhere.

    
- (void)viewDidLoad
{
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.

    // Setup our NGLView.
    NGLView *theView = [[NGLView alloc] initWithFrame:CGRectMake(40, 40, 240, 360)];

    // Set its delegate to self so the drawview method is used.
    theView.delegate = self;

    // Add the new view on top of our existing view. 
    [self.view addSubview:theView];

    // The content scale factor is used to increase the resolution to take advantage 

 of retina displays and values range from 1.0 to 2.0. This sets the contentscalefactor 

 to the max screen scale of the device.
    theView.contentScaleFactor = [[UIScreen mainScreen] scale];

    // Setup some initial environment states to be applied to our mesh.
    NSDictionary *settings = [NSDictionary dictionaryWithObjectsAndKeys:
	kNGLMeshCentralizeYes, kNGLMeshKeyCentralize,
	@"0.3", kNGLMeshKeyNormalize, nil];

    // Initialize the mesh which includes the model file to import (.obj or .dae).
    _mesh = [[NGLMesh alloc] initWithFile:@"earth.obj" settings:settings delegate:nil];

    // Initialize the camera used to render the scene.
    _camera = [[NGLCamera alloc] initWithMeshes:_mesh, nil];

    // If a trasparent background of the NGLView is needed
    //theView.backgroundColor = [UIColor clearColor];
    //nglGlobalColorFormat(NGLColorFormatRGBA);
    //nglGlobalFlush();

    // The following command displays a 3d view status monitor that will show your current frame rate and number of polygons being rendered in the view.
    [[NGLDebug debugMonitor] startWithView:(NGLView *)self.view];
}

You will need to add at least one method to your source (.m) file, this is the drawView loop. This drawView loop is used to generate each frame being displayed (up to 60 per second). This drawloop is where you would affect the mesh to animate movement or create the effects your a looking to display. The  [_camera drawCamera] is needed to commit the changes and render the frame. The method usually ends with this command.

-(void)drawView
{
    // Rotate on Y axis
    _mesh.rotateY += .5;

    // Draw to our camera to display on our view
    [_camera drawCamera];
}

In the above example, the _mesh.rotateY += .5 is used to rotate the mesh .5 degrees each time the frame is rendered.

Now build and run the project and you should see a slowly spinning planet Earth. The NGLView was purposely drawn smaller than the background view in order to show how you could overlay this NGLView over any other normal view to add 3D content. If you want the background of the NGLView to be transparent, set the background color of the view to clear and add the following additional commands. There is also a status monitor that can be run to display frame rates and the number of polygons being rendered for optimization.

// If a trasparent background of the NGLView is needed
 theView.backgroundColor = [UIColor clearColor];
 nglGlobalColorFormat(NGLColorFormatRGBA);
 nglGlobalFlush();

// The following command displays a 3d view status monitor that will show your current frame rate and number of polygons being rendered in the view.
 [[NGLDebug debugMonitor] startWithView:(NGLView *)self.view];

There are many commands you can use to affect your object, it’s movement and how it interacts in it’s 3D environment, here are just a few basic ones. Advanced animation, movement techniques, object hit testing, custom shaders, etc. would be worthy of a separate tutorial. Enjoy.

// rotation
 _mesh.rotateX, rotateY, rotateZ

// scaling
 _mesh.scaleX, scaleY, scaleZ 

// placement
 _mesh.x,y,z 

// offset center of objects rotation
 _mesh.pivot = nglVec3Make(x, y, z)

Assets

Project file

In this blog post I will demonstrate how to mock HTTP requests using an Objective-C runtime dynamic method replacement technique known as method swizzling. I will show how this can be used in tandem with some unit test technologies to help with development of iOS web-service client side code.

In this example, the actual work of the HTTP request is embodied in my AsyncURLConnection class. It uses NSURLConnection to perform an NSURLRequest in an asynchronous manner, using completion handler blocks to return the response to the caller. I could have chosen to mock the native APIs but mocking at the AsyncURLConnection level provides the desired effect more easily.

Method Swizzling Helper Class

This is a generic helper class for method swizzling (swapping). This gets used in tests as seen below. The

swizzleClassMethod:selector:swizzleClass:

method takes a class and a method selector along with a class with an alternative implementation of the method given by the selector. The class swaps the implementation of the existing class method with the corresponding method in the swizzleClass.

#import <Foundation/Foundation.h>
#import <objc/runtime.h>
 
@interface Swizzler : NSObject
 
- (void)swizzleClassMethod:(Class)target_class selector:(SEL)selector swizzleClass:(Class)swizzleClass;
- (void)deswizzle;
 
@end
 
#import "Swizzler.h"
 
@implementation Swizzler
 
Method originalMethod = nil;
Method swizzleMethod = nil;
 
/**
Swaps the implementation of an existing class method with the corresponding method in the swizzleClass.
 */
- (void)swizzleClassMethod:(Class)targetClass selector:(SEL)selector swizzleClass:(Class)swizzleClass
{
	originalMethod = class_getClassMethod(targetClass, selector); // save the oringinal implementation so it can be restored
	swizzleMethod = class_getClassMethod(swizzleClass, selector); // save the replacement method
	method_exchangeImplementations(originalMethod, swizzleMethod); // perform the swap, replacing the original with the swizzle method implementation.
}
 
/**
 Restores the implementation of an existing class method with its original implementation.
 */
- (void)deswizzle
{
	method_exchangeImplementations(swizzleMethod, originalMethod); // perform the swap, replacing the previously swizzled method with the original implementation.
	swizzleMethod = nil;
	originalMethod = nil;
}
 
@end

Class to be mocked

This is the interface of a class that connects and loads a URL. I will be replacing the implementation so its details are left out of here for brevity.

#import <Foundation/Foundation.h>
 
typedef void (^completeBlock_t)(NSData *data);
typedef void (^errorBlock_t)(NSError *error);
 
@interface AsyncURLConnection : NSObject
{
    NSMutableData *data;
    completeBlock_t completeBlock;
    errorBlock_t errorBlock;
}
 
/**
 Asynchronously performs an HTTP GET - invokes one of the blocks depending on the response to the request 
*/
+ (id)request:(NSString *)requestUrl completeBlock:(completeBlock_t)aCompleteBlock errorBlock:(errorBlock_t)anErrorBlock;
 
/**
 Initializes and asynchronously performs an HTTP GET - invokes one of the blocks depending on the response to the request
 */
- (id)initWithRequest:(NSString *)requestUrl completeBlock:(completeBlock_t)aCompleteBlock errorBlock:(errorBlock_t)anErrorBlock;
 
// If both HTTP Basic authentication optional parameters are non-empty strings, request will encode the URL with them.
@property (nonatomic, copy) NSString *authUserName; // HTTP Basic authentication optional parameter
@property (nonatomic, copy) NSString *authPassword; // HTTP Basic authentication optional parameter
 
@property (nonatomic, copy) NSString *accept; // Optional parameter to set the response type accepted (default is @"application/json")
 
@end

Example of Usage in a Test

In this test I am testing that I am correctly processing the JSON data returned from the web service. However, I want to isolate the actual web service from the test. I want a test to validate the creation of the NSDictionary response object from the JSON.
As an aside, by removing the Swizzler code, this test could be run against the actual web service; but that is not the intent here.
Here is what the JSON response looks like –

{
    "coaches" :
	[
     {
     "id" : 1,
     "name" : "Jeff Tucker",
     "thumbnail_url" : "http://img.breakingmuscle.com/sites/default/files/imagecache/full_portrait/images/author/64337_10150578149548471_1189630488_n.jpg"
     },
     {
     "id" : 2,
     "name" : "Traver H. Boehm",
     "thumbnail_url" : "http://img.breakingmuscle.com/sites/default/files/imagecache/full_portrait/images/author/traver.jpg"
     },
     {
     "id" :3,
     "name" : "Jeff Tucker",
     "thumbnail_url" : "http://img.breakingmuscle.com/sites/default/files/imagecache/full_portrait/images/author/64337_10150578149548471_1189630488_n.jpg"
     },
     {
     "id" : 4,
     "name" : "Traver H. Boehm",
     "thumbnail_url" : "http://img.breakingmuscle.com/sites/default/files/imagecache/full_portrait/images/author/traver.jpg"
     },
     {
     "id" : 5,
     "name" : "Jeff Tucker",
     "thumbnail_url" : "http://img.breakingmuscle.com/sites/default/files/imagecache/full_portrait/images/author/64337_10150578149548471_1189630488_n.jpg"
     },
     {
     "id" : 6,
     "name" : "Traver H. Boehm",
     "thumbnail_url" : "http://img.breakingmuscle.com/sites/default/files/imagecache/full_portrait/images/author/traver.jpg"
     }
     ],
    "per_page": 6,
    "page": 1,
    "total" : 11,
    "total_pages": 2
}

The method under test here is:-

- (void)loadCollectionFromEndpoint:(NSString *)endpoint successBlock:(JSONLoaderLoadSuccessBlock)successBlock failBlock:(JSONLoaderLoadFailBlock)failBlock

This method calls the AsyncURLConnection class method

+ (id)request:(NSString *)requestUrl completeBlock:(completeBlock_t)completeBlock errorBlock:(errorBlock_t)errorBlock;

I will replace the existing implementation of that method with one that does not actually make an HTTP request, but instead gets JSON from a local file.

The unit test uses OCHamcrest matchers and XCode’s built in OCUnit.

- (void)test_loadPopularCoaches_success
{
    // Test set-up
    Swizzler *swizzler = [Swizzler new];
    // Replace the actual AsyncURLConnection method with our own test one.
    [swizzler swizzleClassMethod:[AsyncURLConnection class] selector:@selector(request:completeBlock:errorBlock:) swizzleClass:[RequestPopularCoachesPassMock class]];
    __block BOOL hasCalledBack = NO;
 
    // Test
    NSString *endpoint = [NSString stringWithFormat:@"%@?per_page=6&page=1&popular=true", kCoachesEndpoint];
    [[JSONLoader sharedJSONLoader] loadCollectionFromEndpoint:endpoint successBlock:^(NSDictionary *collection) {
        NSArray *coaches = [collection valueForKey:@"coaches"];
        assertThat(coaches, hasCountOf(6)); 
        int i = 0;
        for (NSDictionary *coach in coaches) {
            STAssertTrue([coach isKindOfClass:[NSDictionary class]], @"Incorrect class");
            assertThat(coach, equalTo([popularCoaches objectAtIndex:i])); // popularCoaches defined elsewhere with expected data
            ++i;
        }
        assertThat([collection valueForKey:@"per_page"], equalToInt(6));
        assertThat([collection valueForKey:@"page"], equalToInt(1));
        assertThat([collection valueForKey:@"total"], equalToInt(11));
        assertThat([collection valueForKey:@"total_pages"], equalToInt(2));
        hasCalledBack = YES;
    } failBlock:^(NSError *error) {
        NSLog(@"%@", [error localizedDescription]);
        STFail(@"Unexpected error returned");
        hasCalledBack = YES;
    }];
 
    // see http://drewsmitscode.posterous.com/testing-asynchronous-code-in-objective-c
    NSDate *loopUntil = [NSDate dateWithTimeIntervalSinceNow:1];
    while (hasCalledBack == NO) {
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:loopUntil];
    }
    swizzler = nil;
}

You can use any class to provide an implementation of the replacement method. This approach allows you can return various responses from your HTTP request. Here is one that returns the expected payload that is read from a file.

@interface RequestPopularCoachesPassMock : NSObject
 
+ (id)request:(NSString *)requestUrl completeBlock:(completeBlock_t)completeBlock errorBlock:(errorBlock_t)errorBlock;
 
@end
 
@implementation RequestPopularCoachesPassMock
 
// Swizzled method
+ (id)request:(NSString *)requestUrl completeBlock:(completeBlock_t)completeBlock errorBlock:(errorBlock_t)errorBlock
{
    if (completeBlock) {
        NSData *data = [FileReader dataWithContentsOfBundleFile:@"popularCoaches.json"];
        completeBlock(data);        
    }
    return self;
}
 
@end

Conclusion

In this blog post I have demonstrated how to use the Objective-C runtime dynamic method replacement technique known as *method swizzling* to assist with unit testing in a situation where there is a 3rd party web service that I want to mock. This technique can be used during development to assist with integrating of an iOS app with a web service. It helps speed up development and prototyping. It can also be applied during development in the normal running of your app if you want to mock out portions of or all of a web service.

Cloning UIImagePickerController using the Assets Library Framework
Update: ELCImagePickerController

A lot has happened in the iOS world since the creation of this code. With the advent of every new version of iOS there are always exciting new features and bug fixes. Sometimes subtle code changes sneak into classes we’ve been using for a while though. These changes might create bugs that can be hard to find. Whenever I am debugging code on a new release, especially if it’s a beta release, I try to remember to consult the docs sooner than later. When we started to get reports of ELCImagePickerController not working in iOS 5, it was time to do some homework.

The problem seemed to be that the albums were coming up as empty, even when people had plenty of pictures to display. Someone in the community found a quick work around that if you don’t release the library object, then the code starts working again! Leaking memory like this is never the right answer, but it was a great starting spot to figure out the real problem.

The problem seemed to be arising here:

Commenting out the release fixed the problem? Very odd. I floundered around the code a bit before remembering to go to the documentation for this new (beta, at the time) version of iOS. Lo and behold!

The last sentence is key, “The lifetimes of objects you get back from a library instance are tied to the life of the library instance.” If we release our library instance right there we aren’t going to have access to any of the objects we get back from it anymore! This is new behavior in iOS 5. To adapt to it I just moved the library variable out to be an instance variable of the class and didn’t release it until dealloc is called.

Not such a hard fix once I knew what to look for, just have to remember that the documentation is there for a reason! Thanks to the community for the feedback that made tracking down this bug much easier.

We’re back in action!

As I was troubleshooting this control I kept running into the problem that my simulator didn’t have any pictures in it. If only there was a utility to populate the photo album for me. Maybe it could grab images of cute little kittens from the internet or something? Hmm. Stay tuned to iCodeBlog for more on this!

This tutorial assumes that you have at least a basic understanding of using blocks and Grand Central Dispatch (GCD). If not, @cruffenach has created a more basic intro to blocks tutorial here if you need a refresher on them.

When You Might Want To Pass A Block To A Method

There are quite a few times when you might want to pass a block to a method. The most common reason is to replace the “delegate” design pattern. Basically, when you want to process some data (usually in another thread) and it needs to call back to the caller when it completes. This pattern is also useful when you want to have a method “return” multiple values. (Note: return is in quotes, because we are not actually returning multiple values but calling back using the block and passing multiple values).

Another great reason to use blocks in this way is it keeps your code flowing in a much more logical order. Rather than having this feeling of spaghetti code with callbacks jumping all over the place, all of your callback code can be written inline with everything else.

In the following example, we are going to (asynchronously) fetch a very large array of strings (in plist form) from the web and load it up into a UITableView. We will pass a simple completion block to our array fetch method which will tell our class to reload the table.

Creating Our Dictionary Downloader Class

We’ll start by creating a new class called PListDownloader. This will contain a single method called downloadPlistForURL. Declare it like this in PListDownloader.h.

- (void) downloadPlistForURL:(NSURL *) url completionBlock:(void (^)(NSArray *data, NSError *error)) block;

Let’s break this down. First, the method is void (no return). That’s because our block will handle all of the data that this method “returns”. The first parameter is simply the URL of the plist file. In our case, we will be passing in http://icodeblog.com/samples/block_test/block_test.plist . This is a ~3MB plist file that should take a couple seconds to download and process.

Finally, we pass in our block. Let’s break the block down even further.

1. “(void ” The void denotes that the block doesn’t return any value.

2. “(^))” The ^ without anything next to it denotes that it’s an anonymous block. We will go over naming our blocks in a bit.

3. (NSArray *data, NSError *error)) is what will be passed back into the block when it gets called. This would be equivalent to the “return values” in this case.

4. “block” This is simply the name of our block parameter passed in. You could have named it anything really.

It’s time for the implementation of this method. In the PListDownloader.m file add the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13

- (void) downloadPlistForURL:(NSURL *) url completionBlock:(void (^)(NSArray *data, NSError *error)) block {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0ul), ^{
        NSArray *returnArray = [NSArray arrayWithContentsOfURL:url];
        if(returnArray) {
            block(returnArray, nil);
        } else {
            NSError *error = [NSError errorWithDomain:@"plist_download_error" code:1 
                                             userInfo:[NSDictionary dictionaryWithObject:@"Can't fetch data" forKey:NSLocalizedDescriptionKey]];
            block(nil, error);
        }
 
    });
}

At first glance, one might argue that this looks “sloppier” than the delegate style. Simply because it uses nested blocks. I can assure you this is much cleaner AND simpler. For one, by using GCD you no longer have to worry about creating auto release pools.

So, there’s quite a bit going on here, let’s break it down line by line.

2. This is the Grand Central Dispatch way of firing off a code segment inside of a new thread. Basically we are executing this code on a new thread with a priority of HIGH. You can use this first parameter to prioritize the execution of multiple threads. For example say you are running 2 concurrent threads (one to download user data, the other to download the avatar). You can assign the user data thread higher priority than the avatar thread. The system will handle the rest.

**Note: Using Blocks here replaces the delgate method style of performSelectorInBackground

3. This is a very simple line to download plist data from a URL into an NSArray. There is no error checking or anything fancy. In production, you would want to use NSURLConnection or a lib built on top of it like ASIHTTPRequest.

4. Very simple error check, basically seeing if there was any data downloaded.

5. This is where the magic happens. We call this block as a simple function call passing in our returned array and nil for the error (nil since there was no error).

6-11. This segment handles our error case. If for some reason, no data was downloaded, we create our own NSError object and pass it into the exact same block as in line 5. The only difference is we pass in nil for the results and our error for the NSError object.

Before you gripe in the comments “You could have just done that async call in your main class…blah…blah…”, know that I know this. However, this is just a trivial example. Often times you might have a much larger codebase built up that does more than downloads a stupid plist. Perhaps you have a ton of preprocessing of the url or post-processing of the data. Then it starts to make less and less sense to put this code in your main implementation file.

Also, you might need to download plist files in various parts of the application and do different things with the data that was returned.

Calling A Method With A Block

So, now we have our simple class to download our plist and return the data in a block. But, how do we use it?

Let me give you a bit of context about my sample application first. I have a basic “Navigation Based” project with a NSArray property called pListData. I am displaying the contents of pListData in the UITableView. So, I want to download the plist data from the web, set it to my pListData property and reload my table.

First import the PListDownloader class and then uncomment the viewDidLoad method adding the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

- (void)viewDidLoad {
    [super viewDidLoad];
    PListDownloader *downloader = [[[PListDownloader alloc] init] autorelease];
    NSURL *url = [NSURL URLWithString:@"http://icodeblog.com/samples/block_test/block_test.plist"];
    [downloader downloadPlistForURL:url completionBlock:^(NSArray *data, NSError *error) {
        self.plistData = data;
        if(!error) {
            dispatch_sync(dispatch_get_main_queue(), ^(void) {
                [self.tableView reloadData];
            });
        } else {
            NSLog(@"error %@", error);
        }
    }];
}

Again, let’s take a look at it line by line.

3. This should be familiar, we create a new instance of PListDownloader. One thing to note here is we are able to set it to autorelease. It won’t be released until AFTER the execution finishes and the thread dies. This is a HUGE improvement over the async delegate model where you would have to keep a property laying around.

4. Simply creating an NSURL object using the string location of our test plist (it’s still there, you can test with it)

5. This is where we actually call our downloadPListForURL method. The first parameter is the easy one, just the URL you created on line 4. The second is the the block that the method will call back to when execution finishes. Luckily XCode will auto complete a nice template for us.

6. Once the method calls back and contains an array of strings, we set our property (pListData) to the returned array. This will allow use to actually do something with the data.

7. Our simple error check

8. It’s going to get crazy again. Since we used GCD to run our code in a separate thread, we need a way to come back to the main thread to update the UI. If you are reading this and don’t know that you do all UI manipulations in the main thread, then I suggest you start following my “Back To Basics” tutorial series.

9. Now that we are in the context of the main thread, we can simply reload the tableview.

Now, when you run this application, it should take quite some time to fetch that data (3MB). But, you will have complete control over the UI while it’s fetch in the background. You could even throw up a little loading message if you so choose.

For completeness, here is a look at what this application produces.

As this post has gotten a little longer than I anticipated, I’ll save the part about declaring blocks as properties until next time. If you have any questions or comments, feel free to leave them in the comments of this post (or write them to me on Twitter).

You can download the source for this tutorial here.

Happy iCoding!

In a previous post Facebook SDK – Posting to User News Feed I showed how to post various types of status’s to the logged in users news feed. These code snippets have been added to a forked version of the official Facebook for iOS SDK. A sample of how to use the new block callbacks can be found within the sample project from the last post.

For more information on blocks, you can refer to the Apple document discussing blocks in more detail.

Step 1: Modifying FBRequest Class for new callbacks
First we will modify the FBRequest class. There are a few simple modifications that we need to create. Within the FBRequest.h file add the following:

@property (copy) void (^FBRequestCallback)(FBRequest*, id, NSError*);
@property (nonatomic, assign)  BOOL usesBlockCallback;
 
+ (FBRequest*) getRequestWithParams:(NSMutableDictionary *)params
                         httpMethod:(NSString *)httpMethod
                           callback:(void(^)(FBRequest *request, id result, NSError *error)) _block
                         requestURL:(NSString *)url;

In the FBRequest.m file add the following code:

@synthesize FBRequestCallback = _FBRequestCallback;
@synthesize usesBlockCallback;
 
+ (FBRequest*) getRequestWithParams:(NSMutableDictionary *)params
                         httpMethod:(NSString *)httpMethod
                           callback:(void(^)(FBRequest *request, id result, NSError *error)) _block
                         requestURL:(NSString *)url
{
    FBRequest* request = [[[FBRequest alloc] init] autorelease];
    request.delegate = nil;
    request.url = url;
    request.httpMethod = httpMethod;
    request.params = params;
    request.connection = nil;
    request.responseText = nil;
    request.FBRequestCallback = _block;
 
    return request;
}

In the FBRequest class we are duplicating what they already have in the provided method but swapping out the delegate with a block. Out of personal preference I went with a single callback versus having an error and result callback. If there is no error we will be returning nil for the error parameter.

I also added a boolean property that will be used to determine which callback to use when processing the data when it has been returned from the Facebook servers.

Moving onto the – (void)handleResponseData:(NSData *)data; Method we need to add logic to pass the result request data onto the block callback.

- (void)handleResponseData:(NSData *)data {
  if ([_delegate respondsToSelector:
      @selector(request:didLoadRawResponse:)]) {
    [_delegate request:self didLoadRawResponse:data];
  }
 
    if (usesBlockCallback) {
        NSError* error = nil;
        id result = [self parseJsonResponse:data error:&error];
        _FBRequestCallback(self, result, error);
    }
    else if ([_delegate respondsToSelector:@selector(request:didLoad:)] ||
             [_delegate respondsToSelector:@selector(request:didFailWithError:)])
    {
        NSError* error = nil;
        id result = [self parseJsonResponse:data error:&error];
 
        if (error) {
            [self failWithError:error];
        }
        else if ([_delegate respondsToSelector:@selector(request:didLoad:)]) {
            [_delegate request:self didLoad:(result == nil ? data : result)];
        }
 
    }
}

We are using the same logic as the standard delegate methodology, except we do not need to make a separate delegate call if there is an error. Within the block we have included result and an NSError parameter. That way you can handle the error logic within the same callback.

Finally within the dealloc method we need to release the block. Since we are using the block in objective-c we can simply use [_FBRequestCallback release]; You can also use Block_release(_FBRequestCallback); but since we are using it within Objective-C we can use the standard way of releasing an object.

- (void)dealloc {
    [_FBRequestCallback release];
    [_connection cancel];
    [_connection release];
    [_responseText release];
    [_url release];
    [_httpMethod release];
    [_params release];
    [super dealloc];
}

Step 2: Adding request methods with block callbacks

We want to include two new methods to the Facebook.h class. One method is for graph API requests, and one is for the the old REST API.

In the Facebook.h add the following two methods:

- (void) requestWithGraphPath:(NSString *) _graphPath
                       params:(NSMutableDictionary*) _params
                       method:(NSString*) _method
                     callback:(void(^)(FBRequest *request, id result, NSError *error)) _block;
 
- (void) requestWithMethodName:(NSString *) _methodName
                     andParams:(NSMutableDictionary *) _params
                 andHttpMethod:(NSString *) _method
                      callback:(void(^)(FBRequest *request, id result, NSError *error)) _block;

In the Facebook.m file add the following two method implementations:

- (void) requestWithGraphPath:(NSString *) _graphPath
                       params:(NSMutableDictionary*) _params
                       method:(NSString*) _method
                     callback:(void(^)(FBRequest *request, id result, NSError *error)) _block
{
    NSString * fullURL = [kGraphBaseURL stringByAppendingString:_graphPath];
    [_params setValue:@"json" forKey:@"format"];
    [_params setValue:kSDK forKey:@"sdk"];
    [_params setValue:kSDKVersion forKey:@"sdk_version"];
    if ([self isSessionValid]) {
        [_params setValue:self.accessToken forKey:@"access_token"];
    }
 
    [_request release];
    //modify request to have block
    _request = [[FBRequest getRequestWithParams:_params
                                     httpMethod:_method
                                       callback:_block
                                     requestURL:fullURL] retain];
    [_request connect];
}
 
- (void) requestWithMethodName:(NSString *) _methodName
                     andParams:(NSMutableDictionary *) _params
                 andHttpMethod:(NSString *) _method
                      callback:(void(^)(FBRequest *request, id result, NSError *error)) _block
{
    NSString * fullURL = [kRestserverBaseURL stringByAppendingString:_methodName];
    [_params setValue:@"json" forKey:@"format"];
    [_params setValue:kSDK forKey:@"sdk"];
    [_params setValue:kSDKVersion forKey:@"sdk_version"];
    if ([self isSessionValid]) {
        [_params setValue:self.accessToken forKey:@"access_token"];
    }
 
    [_request release];
    //modify request to have block
    _request = [[FBRequest getRequestWithParams:_params
                                     httpMethod:_method
                                       callback:_block
                                     requestURL:fullURL] retain];
    [_request connect];
 
}

Once again we are duplicating the previously implemented methods by Facebook. The only difference is changing the request method. As you notice we are now using the methods we implemented in the FBRequest class.

Now that we have everything implemented that we need in the Facebook SDK we can use our awesome new block callbacks! The following snippet will return the logged in users friends!

    NSMutableDictionary *params = [[[NSMutableDictionary alloc] init] autorelease];
    [facebook requestWithGraphPath:@"me/friends"
                                    params:params
                                    method:@"GET"
                                  callback:^(FBRequest *request, id result, NSError *error)
    {
        NSLog(@"friends %@", result);
        if ([result isKindOfClass:[NSDictionary class]]) {
            friendsList = [[result objectForKey:@"data"] retain];
            [table reloadData];
        }
 
    }];

What’s a static library

Here is what wiki has to say:

In computer science, a static library or statically-linked library is a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable. This executable and the process of compiling it are both known as a static build of the program. Historically, libraries could only be static.

On the iPhone, static libraries have a .a extention and can only contain code. This means that any resources (xibs, images, etc…) must be packed either in a bundle or shipped separately than the library. We won’t go into this part today.

Why Use Static Libraries

There are a number of reasons to use static libraries, but the main two are distribution to others without revealing source code, and code reuse across projects.

1. Distribution:

Say you have a great idea for a view that given a few images, creates a beautiful photo mosaic. Now, others might want to use your awesome mosaic class as part of their fart-light (fart machine flashlight) app to make mosaic fart-lights from your photo library. You have done a ton of work to make your mosaic app and don’t want to just give away the code. $$$ you decide to sell your code. However, would-be thieves might not honor your awesome license and begin to redistribute the code as if it were their own (oh noooz). Boom static library.

Bundle up your code into a static library and package it with the header files. Now others can purchase your library, use it in their own apps to make fart mosaics without revealing the source and you can continue to sell copy after copy.

2. Code reuse:

So, you have like 30 apps in the store that do just about nothing. However they all have some common code, say a farting engine. Rather than dragging all of the source files in and having redundant code all over the place, you can just compile your fart engine once and use the library in all of your projects.

Where Can I Get Me One Of These?

Well, let’s dig in and create a sample static library. The project we are going to create is code-only (remember we are not going over resources in this tutorial) and will be a simple math library with two methods exposed. It will be able to compute fibonacci numbers given number n and compute a factorial value given number n (I know, pretty dang exciting).

Step 1: Starting a New Static Library Project

This is pretty straight forward as Apple has made it pretty simple to create a static library.

Open XCode and start a new project. Under iOS, select Library and “Cocoa Touch Static Library”. We are going to name ours ICodeMathUtils. This will create a nice new project for us that builds a .a file.

One thing to note is, NO class files get created by default. Don’t freak out, we will create some manually.

Step 2: Code your static library

First we need to add some files. Add a new NSObject subclass to your project and name it MathFunctions.m.

Add this code to the header file:

#import 
 
@interface MathFunctions : NSObject {
}
 
- (NSArray *) fibonacci:(NSInteger) n;
- (NSInteger) factorial:(NSInteger) n;
 
@end

Nothing fancy, just our method declarations. When we distribute the library file, this header file MUST be included as well.

One thing I should point out here is don’t make every iVar public! As a newer developer (or a stubborn lazy one: Im looking at you @cruffenach), you might think it’s cool to make a public property out of EVERYTHING. This is bad form and here is where it will bite you. You don’t want the external world being able to muck with things that you don’t want them to.

And Now the .m file for the implementation:

#import "MathFunctions.h"
 
@implementation MathFunctions
 
- (NSArray *) fibonacci:(NSInteger) n {
 
	NSMutableArray *fib = [NSMutableArray array];
 
	int a = 0;
	int b = 1;
	int sum;
	int i;
 
	for (i=0;i < n;i++)
	{
		[fib addObject:[NSNumber numberWithInt:a]];
		sum = a + b;
		a = b;
		b = sum;
	}
 
	return (NSArray *) fib;
}
 
- (NSInteger) factorial:(NSInteger) n {
	if ( n <= 1 )
		return 1;
	else
		return n * [self factorial:( n-1 )];
}
@end

This code should be very familiar to any CS 101 student : ). And that’s it for our static library. The best way to test this puppy out before distributing is to create a new unit test target, set up some unit tests, and check it out that way. That tutorial is for another day.

Building And Distributing Your Library

Once you are happy with your library, simply build it in XCode. Obviously, don’t do build and run as you can’t run it (again unless you have a test suite). Now, look under the Products group in XCode and you should see a file called lib(libraryName).a. In our case, it’s libICodeMathUtils.a.

Right click on that file and select “Reveal In Finder”. Drag this file into a new folder that you create where you will be bundling all of your library files. I just created a folder on my desktop named iCodeBlogsMathLibrary. Now, do the same with all of the .h files. In our case, just copy MathFunctions.h into this new directory. Your directory structure should now look like:

iCodeBlogsMathLibarby
|- libICodeMathUtils.a
|- MathFunctions.h

Now you can zip this folder and sell it to would-be iOS developers for millions!

Linking Your Library In A New Project

So now that you have built your shiny new static library, it’s time to test it out in another application. XCode has a number of ways to actually achieve this, but I will show the most simple and Mac-like… drag and drop : ).

Create a new View-Based project (or whatever it doesn’t really matter). I named mine MathTest.

Now, just drag this folder into the project and XCode will set up all of the linking automagically. When prompted to copy, I usually say yes, but you can do whatever you want depending on how you intend on using the library. Sometimes just linking and not copying is far more beneficial if you have multiple projects sharing a single library. It ensures that they all use the most up to date version.

You should now see the .a file along with the header files in the new project.

Using The Static Library Code

Now that all of the linking is set up, you just use your library like any other class. In the App Delegate class of my test project, I simple did this:

// Import at the top
#import "MathFunctions.h"

And in the applicationDidFinishLaunchingMethod…

MathFunctions *mFunctions = [[[MathFunctions alloc] init] autorelease];
NSLog(@"fibonacci for 10 = %@", [mFunctions fibonacci:10]);
NSLog(@"10! = %d",[mFunctions factorial:10]);

This of course prints out:

2011-04-07 11:48:49.528 MathTest[854:607] fibonacci for 10 = (
    0,
    1,
    1,
    2,
    3,
    5,
    8,
    13,
    21,
    34
)
2011-04-07 11:48:49.533 MathTest[854:607] 10! = 3628800

And there it is! Static library code being executed in a totally separate project.

Conclusion

Like I said earlier, static libraries can be quite helpful in your iPhone development endeavors. I feel that they are quite underused, but could really save time and money in the long run.

You can download the source code here.

As always, if you have any questions please feel free to leave them in the comments OR write me on Twitter.

Happy iCoding!

This is my first foray into the AssetsLibrary Framework which was introduced with iOS 4.0. If you’re not already familiar with the framework, I highly suggest checking out both of these posts:

Asset Libraries and Blocks in iOS 4

Cloning UIImagePickerController using the Assets Library Framework

These should give you a solid picture of how to work with ALAssetLibrary, ALAssetGroup, and ALAsset.

One of the obvious changes I’ve made to the project is a reorganization of the code. Classes are broken out for clarity as you can see here:

Old Tree:

New Tree:

On major change to the project is how you present the new ELCImagePickerController. This is mainly due to an issue we uncovered with a redundant call to [super init] which was causing a substantial memory leak. Here’s the new way of showing the image picker:

ELCAlbumPickerController *albumController = [[ELCAlbumPickerController alloc] initWithNibName:@"ELCAlbumPickerController" bundle:[NSBundle mainBundle]];ELCImagePickerController *elcPicker = [[ELCImagePickerController alloc] initWithRootViewController:albumController];
 
[albumController setParent:elcPicker];
 
[elcPicker setDelegate:self];
 
ELCImagePickerDemoAppDelegate *app = (ELCImagePickerDemoAppDelegate *)[[UIApplication sharedApplication] delegate];
 
[app.viewController presentModalViewController:elcPicker animated:YES];
 
[elcPicker release];
 
[albumController release];

One interesting optimization I was able to make was on the loading of large albums which was previously taking several seconds. Since ALAssetGroup uses a block to enumerate assets, I just fire off a reloadTable call after a short delay:

// Show partial list while full list loads
 
[self.tableView performSelector:@selector(reloadData) withObject:nil afterDelay:.5];

Then when the block is finished enumerating, it’ll call reloadTable as well. On an album with roughly 1500 photos, it was pretty tough to reach the bottom of the tableview before the block finished enumerating. So this is a pretty decent solution to the issue. Originally, I experimented with lazy loading the assets as the user scrolled through the table, but ultimately wasn’t able to get the performance I wanted out of it.

This release of ELCImagePickerController should perform faster, and with a smaller memory footprint than before. I hope you enjoy it.

You can follow me on twitter @matt_tuzzolo or get in touch with us at http://www.elctech.com

ps. for an extra bonus, check out [ELCAsset toggleSelection];

Demo of Photo Board Application for iCodeBlog.com from Collin Ruffenach on Vimeo.

GIT Hub

You can find this project now on GitHub. Please let me know any issues you may have. Happy coding!

Creating the project

Lets get a project ready that can handle all of this functionality. Open up xCode and start a View based iPad application called DemoPhotoBoard. Once the project window has come up go to the Framework group in the left bar and right click on it. Select Add -> Existing Framework… A large model view will come down listing all of the Frameworks that can be added to the project. Add in the Framework “Mobile Core Services”. Now go into DemoPhotoBoardViewController.h and add in the line

I apologies for having to use the image there, WordPress hates any line of code with < or > in it. We might as well finish filling in the rest of the header now too. Don’t worry about what these properties will be used for yet just include them in the header for the moment, they will be what we use to keep track of our scaling, movement and rotation. The add photo method will be called from a button we put in our interface in the next step.

@interface DemoPhotoBoardViewController : UIViewController  {
 
	CGFloat lastScale;
	CGFloat lastRotation;
 
	CGFloat firstX;
	CGFloat firstY;
}
 
-(IBAction)addPhoto:(id)sender;
 
@end

Filling in the XIB

The next thing we are going to do is add a tool bar and tool bar button to our XIB. Double click on DemoPhotoBoardViewController.xib. Once it has opened drag in a UIToolBar Item and then Put a UIToolBarButtonItem with a Flexible Space element to the left of it. Make the UIBarButtonItem the system button “Add”. Now if you go to the file owner below and right click on it, you should see an outlet for the method “addPhoto”. Connect this to the add button we have. As a final step, select the UIToolBar and look at its size panel in the inspector. Make sure the Autosizing settings match the settings seen below so that things don’t get screwy when the app is in other orientations.

Implementing the Photo Picker

Go ahead and open up DemoPhotoBoardViewController.m. The first thing we are going to do is implement the addPhoto method. Insert the following code into your main.

-(IBAction)addPhoto:(id)sender {
 
	UIImagePickerController *controller = [[UIImagePickerController alloc] init];
	[controller setMediaTypes:[NSArray arrayWithObject:kUTTypeImage]];
	[controller setDelegate:self];
 
	UIPopoverController *popover = [[UIPopoverController alloc] initWithContentViewController:controller];
	[popover setDelegate:self];
	[popover presentPopoverFromBarButtonItem:sender permittedArrowDirections:UIPopoverArrowDirectionUp animated:YES];
}

This method creates a UIImagePickerController and tells it to only display images. Next we create an UIPopoverController that we instantiate with our UIImagePickerController as the content view controller. We set the delegate to ourself, and present it from the bar button item sender, which refers to the add button in our interface. We know the pop over will always be below our button so we force the button direction to always be point up. With this done, we can now run the app and see a UIImagePickercController appearing in a UIPopOverController below our add button.

Setting up the Gesture Recognizers

Now we need to implement the delegate method for our UIImagePickerController and add the image to our view when it is selected. We do this with the imagePickerControler:DidFinishPickingMediaWithInfo: delegate method. This method will provide us a dictionary where the key @”UIImagePickerControllerOriginalImage” will return a UIImage object of the image the user selected. We are going to need to create an ImageView and then put this ImageView in a UIView holder. The reason we do this is because standard UIImageViews, despite being UIView subclasses, do not react to gesture recognizer added to them. I’m not exactly sure why that is but this is the solution I have found in my testing. We are going to create 4 different kinds UIGestureRecognizers and connect them to our holder view.

We will first create a UIPinchGestureRecognizer. This object doesn’t require and customization, we will simply set its target to us with the scale: selector and assign this class as its delegate. With this done we add it to the holder view we created.

Next we create a UIRotationGestureRecognizer. This object doesn’t require much customization either. We simply set it to call the rotate: method in our class and set its delegate.

Net we create the UIPanGestureRecognizer. We create the PanGestureRecognizer to make a call to the method move: upon being activated. We tell the PanGestureRecognizer that we only care when a single touch is panning by setting the maximum and minimum touches to 1. We once again add this to the holder view we created.

The final UIGestureRecognizer we create is the UITapGestureRecognizer. The UITapGestureRecognizer will be used to stop an object that has been “thrown” from going all the way to its stopping point. It essentially will be used to catch an object while it is still moving. We set the required number of taps to 1 and set the delegate. We add this final UIGestureRecognizer to our holder view and add the view to subview. You can see the code below. Please ignore the random number WordPress is weak sauce.

- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info {
 
	UIImage *image = [info objectForKey:@"UIImagePickerControllerOriginalImage"];
 
	UIView *holderView = [[UIView alloc] initWithFrame:CGRectMake(0, 0, image.size.width, image.size.height)];
	UIImageView *imageview = [[UIImageView alloc] initWithFrame:[holderView frame]];
	[imageview setImage:image];
	[holderView addSubview:imageview];
 
	UIPinchGestureRecognizer *pinchRecognizer = [[UIPinchGestureRecognizer alloc] initWithTarget:self action:@selector(scale:)];
	[pinchRecognizer setDelegate:self];
	[holderView addGestureRecognizer:pinchRecognizer];
 
	UIRotationGestureRecognizer *rotationRecognizer = [[UIRotationGestureRecognizer alloc] initWithTarget:self action:@selector(rotate:)];
	[rotationRecognizer setDelegate:self];
	[holderView addGestureRecognizer:rotationRecognizer];
 
	UIPanGestureRecognizer *panRecognizer = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(move:)];
	[panRecognizer setMinimumNumberOfTouches:1];
	[panRecognizer setMaximumNumberOfTouches:1];
	[panRecognizer setDelegate:self];
	[holderView addGestureRecognizer:panRecognizer];
 
	UITapGestureRecognizer *tapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(tapped:)];
	[tapRecognizer setNumberOfTapsRequired:1];
	[tapRecognizer setDelegate:self];
	[holderView addGestureRecognizer:tapRecognizer];
 
	[self.view addSubview:holderView];
}

Quickly lets also define each of these methods as such so we can see them all occurring as we touch an object that we add to the view. Add this code in and run the application, you can click around on the objects you add to the board and see the Log messages displaying in the terminal. In the terminal you may or may not be able to activate all of these, because of multi touch being simulated in a pretty limited way. But you can run the code and try this out.

-(void)scale:(id)sender {
	NSLog(@"See a pinch gesture");
}
 
-(void)rotate:(id)sender {
	NSLog(@"See a rotate gesture");
}
 
-(void)move:(id)sender {
	NSLog(@"See a move gesture");
}
 
-(void)tapped:(id)sender {
	NSLog(@"See a tap gesture");
}

UIGestureRecognizer Action Methods

All UIGestureRecognizers contain a state property of type UIGestureRecognizerState. This is because of UIGestureRecognizers calling their action methods throughout the entire time a gesture is being performed. When the gesture first begins the state of the calling UIGestureRecognizer is UIGestureRecognizerStateBegan, throughout its all subsequent calls have the state UIGestureRecognizerStateChanged, and the final call is of state UIGestureRecognizerStateEnded. We can use this to our advantage to do house keeping in each of our gesture action methods. Another important thing to note about the action calls from UIGestureRecognizers is that the properties it will report about a gesture, such as scale for UIPinchGestureRecognizer and rotation for UIRotationGestureRecognizer, will always be in reference to the original state of the object. So as a scale is happening the scale may be reported as; 1.1, 1.2, 1.3, 1.4 and 1.5 on subsequent calls. These scales are not cumulative but all in reference to the original state of the object the UIGestureRecognizers are attached to.

Implementing Scaling

First thing we will do is implement the scale method. The scale method will be called by an id sender, this sender will actually be a UIPinchGestureRecognizer object. If we look at the documentation for a UIPinchGestureRecognizer object we will see that it includes a scale property that is a CGFloat. This scale property will be provided by the UIPinchGestureRecognizer every time the scale: method is called. Because the scale will be cumulative and always in reference to the original state of the object. Because of this, as we make our photo grow, we must make sure that we only scale by the difference of the last scale to the current scale. For example of the first scale: call has the UIPinchGestureRecognizer scale as being 1.1 and the next call has it by 1.2, we should scale by 1.1 and then by another 1.1. To handle this we have the the class property CGFloat lastScale. This will keep track of the last scale we applied to our view so that on the next call we can only apply the difference between them.

So now that we can tell how much to scale an item upon being pinched we need to look into the mechanism that will actually scale the view. Every UIView has a CGAffineTransform property called transform. This described much of the geometry of the view that will be drawn. Using method provided by the Quartz frameworks we will figure out how to change this variable to scale as we need. Lets first take a look at out whole scaling method.

-(void)scale:(id)sender {
 
	[self.view bringSubviewToFront:[(UIPinchGestureRecognizer*)sender view]];
 
	if([(UIPinchGestureRecognizer*)sender state] == UIGestureRecognizerStateEnded) {
 
		lastScale = 1.0;
		return;
	}
 
	CGFloat scale = 1.0 - (lastScale - [(UIPinchGestureRecognizer*)sender scale]);
 
	CGAffineTransform currentTransform = [(UIPinchGestureRecognizer*)sender view].transform;
	CGAffineTransform newTransform = CGAffineTransformScale(currentTransform, scale, scale);
 
	[[(UIPinchGestureRecognizer*)sender view] setTransform:newTransform];
 
	lastScale = [(UIPinchGestureRecognizer*)sender scale];
}

The first thing we do in this method is bring the touched view to the front. We do this by accessing the view property of our sender which in this case is the UIPinchGesturereRecognizer. Next thing we do is check if this is the final touch in this pinch motion. If it is we reset out lastTouch value to 1. When the scale of one is applied a view does not change. When a pinch has ended we set the final pinch as being the new starting point for the next pinch sequence, specifically 1. Any other touch besides the last will subtract the difference from the last scale and the current scale from 1. This will be the scale change between the current touch and the last. We want to apply this to the current CGAffineTransfom matrix of the view this gesture recognizer is attached to. We now get the current transform of the view and pass it into CGAffineTransformScale() method. The first parameter is for current transform and the following two are the x and y scale to be applied to the passed in transform. The output here will be the new transform for the view. We apply this and reset the scale.

Implementing Rotation

Next thing we handle is rotation. This method has a very similar structure to the scaling method. We use another class property called lastRotation this time instead and a slightly different Quartz method, but the code overall should make sense. Check it out below.

-(void)rotate:(id)sender {
 
	[self.view bringSubviewToFront:[(UIRotationGestureRecognizer*)sender view]];
 
	if([(UIRotationGestureRecognizer*)sender state] == UIGestureRecognizerStateEnded) {
 
		lastRotation = 0.0;
		return;
	}
 
	CGFloat rotation = 0.0 - (lastRotation - [(UIRotationGestureRecognizer*)sender rotation]);
 
	CGAffineTransform currentTransform = [(UIPinchGestureRecognizer*)sender view].transform;
	CGAffineTransform newTransform = CGAffineTransformRotate(currentTransform,rotation);
 
	[[(UIRotationGestureRecognizer*)sender view] setTransform:newTransform];
 
	lastRotation = [(UIRotationGestureRecognizer*)sender rotation];
}

Implementing Movement

Now we handle movement which is a bit different that the rotation and scaling transformations. Although you could use the transform to move an object around using the transform property, we are going to continuously reset the center of each view. We utilize PanGestureRecognizers method translationInView to get the point which the view has been moved to in reference to its starting point. If this is the first touch from the gesture recognizer we set our class properties firstX and firstY. We the calculate our translated point by adding the original center points to the translated point in the view. We set the view’s center with this newly calculated view. You can see the code below.

-(void)move:(id)sender {
 
	[[[(UITapGestureRecognizer*)sender view] layer] removeAllAnimations];
 
	[self.view bringSubviewToFront:[(UIPanGestureRecognizer*)sender view]];
	CGPoint translatedPoint = [(UIPanGestureRecognizer*)sender translationInView:self.view];
 
	if([(UIPanGestureRecognizer*)sender state] == UIGestureRecognizerStateBegan) {
 
		firstX = [[sender view] center].x;
		firstY = [[sender view] center].y;
	}
 
	translatedPoint = CGPointMake(firstX+translatedPoint.x, firstY+translatedPoint.y);
 
	[[sender view] setCenter:translatedPoint];
 
	if([(UIPanGestureRecognizer*)sender state] == UIGestureRecognizerStateEnded) {
 
		CGFloat finalX = translatedPoint.x + (.35*[(UIPanGestureRecognizer*)sender velocityInView:self.view].x);
		CGFloat finalY = translatedPoint.y + (.35*[(UIPanGestureRecognizer*)sender velocityInView:self.view].y);
 
		if(UIDeviceOrientationIsPortrait([[UIDevice currentDevice] orientation])) {
 
			if(finalX < 0) { 				 				finalX = 0; 			} 			 			else if(finalX > 768) {
 
				finalX = 768;
			}
 
			if(finalY < 0) { 				 				finalY = 0; 			} 			 			else if(finalY > 1024) {
 
				finalY = 1024;
			}
		}
 
		else {
 
			if(finalX < 0) { 				 				finalX = 0; 			} 			 			else if(finalX > 1024) {
 
				finalX = 768;
			}
 
			if(finalY < 0) { 				 				finalY = 0; 			} 			 			else if(finalY > 768) {
 
				finalY = 1024;
			}
		}
 
		[UIView beginAnimations:nil context:NULL];
		[UIView setAnimationDuration:.35];
		[UIView setAnimationCurve:UIViewAnimationCurveEaseOut];
		[[sender view] setCenter:CGPointMake(finalX, finalY)];
		[UIView commitAnimations];
	}
}

Implementing Momentum

The final half of the above method is for us to calculate the momentum that the object will have after being moved. This will make the object appear as if it is being thrown across a table and slowly coming to stop. In order to do this we utilize UIPanGestureRecognizers velocityInView method which will tell us the velocity of the pan touch within a provided view. With this we can do an easy position calculation for both the x and y coordinates of our object. To do this we must provide an input for time, in this case .4 seconds. While this is not truly momentum and friction based physics it provides a nice affect for our interaction. With out final resting place calculated we ensure that where the object ends up will still be within the visible surface of the iPad by checking against the bounds of the screen depending on the current orientation. The final step is to animate the view moving to this final location over the same .4 second time period.

Implementing Taps

We have one final gesture recognizer implementation to do and that is the tap: method. This method will be used when a user taps an object that is in the midsts of sliding after being moved. We essentially want to stop the movement mid slide. In order to do that we are going to tell the CALayer layer property of our view to cancel all current animations. The short piece of code can be seen below.

-(void)tapped:(id)sender {
 
	[[[(UITapGestureRecognizer*)sender view] layer] removeAllAnimations];
}

Implementing UIGestureDelegate

If you run the code now you will be able to perform all of the gestures described within this document but you will notice that you are not able to do several at the same time. For instance you can not pinch zoom and rotate a view at the same time. This is because we still need to implement the UIGestureRecognizerDelegate method gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer. We want to make sure that any gesture recognizers can happen together except for the pan gesture recognizer. To do this we simply check that it is not a UIPanGestureRecognizerClass and return true in that case. See the short code below.

- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer {
 
	return ![gestureRecognizer isKindOfClass:[UIPanGestureRecognizer class]];
}

GIT Hub

You can find this project now on GitHub. Please let me know any issues you may have. Happy coding!

Follow me on Twitter @cruffenach

The ELCImagePickerController

The ELCImagePickerController is only possible because of the newly introduced Assets Library framework. This framework gives you raw (more or less) access to the photo and video elements of a user. We looked at UIImagePickerController and saw a lot of weaknesses with it. You can only select 1 photo at a time, and even in Apple’s photo app, where you can choose several pictures at a time, you can’t use multi touch to do your selection. To solve these problems we rolled our own solution that works very closely to UIImagePickerController.

How to use it

First I am going to explain using the picker since to many people the process of creating it won’t be very interesting. The image picker is created and displayed in a very similar manner to the UIImagePickerController. The sample application that is part of the GitHub project, where I distribute the controller, shows its use, but I will go into detail here. To display the controller you instantiate it and display it modally like so.

ELCImagePickerController *controller = [[ELCImagePickerController alloc] initImagePicker];
[controller setDelegate:self];
[self presentModalViewController:controller animated:YES];
[controller release];

The ELCImagePickerController will return the select images back to the ELCImagePickerControllerDelegate. The delegate contains to methods very similar to the UIImagePickerControllerDelegate. Instead of returning one dictionary representing a single image the controller sends back an array of similarly structured dictionaries. The two delegate methods are:]

- (void)elcImagePickerController:(ELCImagePickerController *)picker didFinishPickingMediaWithInfo:(NSArray *)info;
- (void)elcImagePickerControllerDidCancel:(ELCImagePickerController *)picker;

GIT Hub

You can find this project now on GitHub. Please let me know any issues you may have and look for future releases with feature enhancements

General Structure

The ELCImagePicker is a collection of UITableViewControllers that are placed inside a UINavigationController. While the ELCImagePickerController is actually 5 separate custom classes I have written, I have put them all within a single header and main. I chose this to make the classes that were required to be imported into a project when using this as few as possible. While usually when presenting a UINavigationController you would create one yourself in code and use the initWithRootViewController method, in this case we have created a UINavigationController subclass called ELCImagePickerController which does all this behind the scenes. In the end all a developer has to do is use the initImagePicker method and present the controller modally. This lets the class match the functionality of UIImagePickerController closer. You can see the Header and Main for the ELCImagePickerController class on the next page.

ELCImagePickerControllerDemo from Collin Ruffenach on Vimeo.

What is Oauth?

Twitter has a brief explanation of the difference between Basic Authentication and OAuth. They use the example of a letter and how it is addressed as their metaphor, and I think this gets the idea across clearly. You can see their entire explanation along with pros and cons here.

TL;DR With Basic Auth you would make every request and would include a username and password with each. This method is very insecure because it allows applications to actively hold user’s credentials and does not have any accountability for which application is performing what action on who’s account. If you imagine your Twitter account as a room, this is like having access to the room be granted based on a single key that many people have copies of. OAuth makes access to your room be granted by a key pad. And everyone that has access to the room has a different code they input into the keypad. You can see who came in and when and revoke anyone’s code at any time.

Twitter is evolving and now requiring that applications register. As a result, user’s gain more control over what services have access to their account. Additionally, Twitter can be more effective at targeting malicious applications, and developers can get more accurate feedback on the frequency of their app’s use throughout Twitter. With all this said, OAuth is tough to implement from scratch. So today we are going to go through the installation and use of a collection of classes that takes care of the dirty work for us, and let developers update the Twitter functionality of their application easily.

Required Classes

Today we are going to be building off a collection of classes that were created by several different people. The main portion of the class is the MGTwitterEngine which was created by Matt Legend Gemmell who’s website can be found here. From here, Ben Gottlieb took the classes and added his own drop in view controller to them. With all this together we have a simple view controller that will perform login and OAuth, and from there an engine that will perform any type of Twitter request we are looking to do. You can get a zip file of the root folder that contains all of these files here.

Installation

We are going to start out with a blank, view based iPhone project called iCodeOAuth. Once the project has come up, take the folder you downloaded called “Twitter+OAuth” and drag it into the “Other Sources” folder within Xcode. Make sure you check the box to copy the sources into the project folder. If we do a build now, you will get a ton of errors. That is because these classes require that libXML be a target of the project build as well. This can be accomplished by clicking the arrow next to Targets in the left column of the Xcode project. Here there will be an application called iCodeOAuth. If we right click on this and select Get Info we will see the info about our target. From here we click the build tab and search for the field “Header Search Paths”. You need to add the following into the Header Search Paths:

$(SDKROOT)/usr/include/libxml2

EDIT: I forgot to include here that you must also include a special XML library for the build to be successful. The Framework is called libxml2.dylib. You can find it at

/Macintosh HD/Developer/Platforms/iPhoneOS.platform/Developer/SDK/iPhoneOS4.1SDK/usr/lib

If you build again, you should see no errors and we can move forward with using this awesome set of classes.

Getting your Creds from Twitter

Now that we have these classes properly installed, it is time to take care of some registration requirements for OAuth. In order to use OAuth you must identify your app to Twitter. Once you do so, Twitter will provide you with an OAuthConsumerKey and an OAuthConsumerSecretKey. These are going to need to be provided to the classes we have just added into our project in order to talk with Twitter’s OAuth system. To register your application and get these creds go to http://dev.twitter.com/apps/new. I have created a application called the iCodeBlog OAuth Demo, whose credentials are included in the sample app which I have provided. For your own personal app you will need to go create your own Twitter Application and get your own keys.

Using SA_OAuthTwitter Engine

Ben Gottlieb used a great design pattern to create a very easy to use access point for the more complex MGTwitterEngine which lies underneath. In order to use these classes we will go into out view controller and add the following code to the header:

#import "SA_OAuthTwitterEngine.h"
#import "SA_OAuthTwitterController.h"
 
@interface iCodeOauthViewController : UIViewController  {
 
	IBOutlet UITableView *tableView;
	IBOutlet UITextField *textfield;
 
	SA_OAuthTwitterEngine *_engine;
	NSMutableArray *tweets;
}
 
@property (nonatomic, retain) IBOutlet UITableView *tableView;
@property (nonatomic, retain) IBOutlet UITextField *textfield;
 
-(IBAction)updateStream:(id)sender;
-(IBAction)tweet:(id)sender;
 
@end

And add the following into the Main

- (void)viewDidAppear:(BOOL)animated {
 
	if(_engine) return;
 
	_engine = [[SA_OAuthTwitterEngine alloc] initOAuthWithDelegate:self];
	_engine.consumerKey = @"PzkZj9g57ah2bcB58mD4Q";
	_engine.consumerSecret = @"OvogWpara8xybjMUDGcLklOeZSF12xnYHLE37rel2g";
 
	UIViewController *controller = [SA_OAuthTwitterController controllerToEnterCredentialsWithTwitterEngine: _engine delegate: self];
 
	if (controller)
		[self presentModalViewController: controller animated: YES];
	else {
		tweets = [[NSMutableArray alloc] init];
		[self updateStream:nil];
	}
}

This will instantiate our engine with the appropriate consumer and consumer secret keys. With this done we will create a controller. If you run the app now you will see a modal web view come up and lead to a sign in page for Twitter. This is a web view, but the great classes written by Ben are set up to programmatically handle the progression of these web views as the user signs in.

Scrolling to the bottom of this page there will be a username and password field to fill out. Don’t put in your Twitter credentials yet. We need to fill out a few delegate methods to handle the callback from SA_OAuthTwitterEngine.

Handling Login Callbacks

Insert the following into your main class.

 
-(IBAction)updateStream:(id)sender {
 
}
 
-(IBAction)tweet:(id)sender {
 
}
 
#pragma mark SA_OAuthTwitterEngineDelegate
 
- (void) storeCachedTwitterOAuthData: (NSString *) data forUsername: (NSString *) username {
 
	NSUserDefaults	*defaults = [NSUserDefaults standardUserDefaults];
 
	[defaults setObject: data forKey: @"authData"];
	[defaults synchronize];
}
 
- (NSString *) cachedTwitterOAuthDataForUsername: (NSString *) username {
 
	return [[NSUserDefaults standardUserDefaults] objectForKey: @"authData"];
}
 
#pragma mark SA_OAuthTwitterController Delegate
 
- (void) OAuthTwitterController: (SA_OAuthTwitterController *) controller authenticatedWithUsername: (NSString *) username {
 
	NSLog(@"Authenticated with user %@", username);
 
	tweets = [[NSMutableArray alloc] init];
	[self updateStream:nil];
}
 
- (void) OAuthTwitterControllerFailed: (SA_OAuthTwitterController *) controller {
 
	NSLog(@"Authentication Failure");
}
 
- (void) OAuthTwitterControllerCanceled: (SA_OAuthTwitterController *) controller {
 
	NSLog(@"Authentication Canceled");
}

We just implemented the SA_OAuthTwitterControllerDelegate and the SA_OAuthTwitterEngineDelegate. The SA_OAuthTwitterEngineDelegate methods take care of storing the OAuth data string in a plist so that when the app is launched again the user will not have to sign in. SA_OAuthTwitterControllerDelegate methods are callbacks depending on what happens upon sign in. In this case when sign in is successful another method in our class called updateTweets will fire. For now we have those methods defined but we don’t have them filled in. We will get to that in a few steps. If you run the application and login using some Twitter credentials, you should see a successful authentication message appear in your debug screen. With this done, let’s add some interface elements to our view controller XIB so that we can start interacting with Twitter. Our final product is going to look like this:

Building the Interface

To Build the interface open up the XIB for your view controller. We are going to be putting in 2 buttons, a UITextField and a UITableView. Lay the elements out like so.

Make sure to connect the delegate and data source of the table view to the file owner. Also connect the “Tweet This” button to the tweet method and the Update Tweets method to the updateStream method. Finally, make sure the IBOutlets for the UITextField and the UITableView are set. With these in place we can fill in the final methods to take advantage of our Twitter engine.

Filling in our IBActions

Put the following code in for the IBActions which we defied before.

#pragma mark IBActions
 
-(IBAction)updateStream:(id)sender {
 
	[_engine getFollowedTimelineSinceID:1 startingAtPage:1 count:100];
}
 
-(IBAction)tweet:(id)sender {
 
	[textfield resignFirstResponder];
	[_engine sendUpdate:[textfield text]];
	[self updateStream:nil];
}

The update stream method will ask our engine to get the Twitter timeline of the people you follow. It will retrieve the first page of the first 100 tweets. There is a delegate method that fires off on this request completing that we will fill out in a moment. The tweet method dismisses the keyboard and then uses our engine to send an update. Once the update is send we update the tweet view below.

Making a really simple Tweet Object

To help us with displaying tweets we are going to make a very quick Tweet object. This will be a simple NSObject subclass. Use this code for the header:

@interface Tweet : NSObject {
 
	NSDictionary *contents;
}
 
-(NSString*)tweet;
-(NSString*)author;
 
@end

And this code for the main

@implementation Tweet
 
-(id)initWithTweetDictionary:(NSDictionary*)_contents {
 
	if(self = [super init]) {
 
		contents = _contents;
		[contents retain];
	}
 
	return self;
}
 
-(NSString*)tweet {
 
	return [contents objectForKey:@"text"];
}
 
-(NSString*)author {
 
	return [[contents objectForKey:@"user"] objectForKey:@"screen_name"];
}
@end

Finally make sure to import the class within the main of your view controller class. These will simply give easy methods to get the info we want out of each tweet dictionary that the MGTwitterEngine will return to us.

Filling in our MGTwitterEngineDelegate Methods

The MGTwitterEngine is doing most of the heavy lifting here when it comes to interacting with Twitter. The methods we are using to get tweets and to send tweets are all defined within the MGTwitterEngine. There is also a defined MGTwtterEngineDelegate which defines the callback methods that fire upon these requests finishing. For the sake of completeness, I have filled out all the methods, although only a few of them will be called in the case of our application working properly. Insert the following code into your main.

#pragma mark MGTwitterEngineDelegate Methods
 
- (void)requestSucceeded:(NSString *)connectionIdentifier {
 
	NSLog(@"Request Suceeded: %@", connectionIdentifier);
}
 
- (void)statusesReceived:(NSArray *)statuses forRequest:(NSString *)connectionIdentifier {
 
	tweets = [[NSMutableArray alloc] init];
 
	for(NSDictionary *d in statuses) {
 
		NSLog(@"See dictionary: %@", d);
 
		Tweet *tweet = [[Tweet alloc] initWithTweetDictionary:d];
		[tweets addObject:tweet];
		[tweet release];
	}
 
	[self.tableView reloadData];
}
 
- (void)receivedObject:(NSDictionary *)dictionary forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"Recieved Object: %@", dictionary);
}
 
- (void)directMessagesReceived:(NSArray *)messages forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"Direct Messages Received: %@", messages);
}
 
- (void)userInfoReceived:(NSArray *)userInfo forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"User Info Received: %@", userInfo);
}
 
- (void)miscInfoReceived:(NSArray *)miscInfo forRequest:(NSString *)connectionIdentifier {
 
	NSLog(@"Misc Info Received: %@", miscInfo);
}

These methods are all very straightforward in their naming. The only one we fill out significantly is the statusesReceived:forRequest method. Here is where tweets will be returned to us, each as a separate dictionary when we request the timeline for a user. We will clear the tweets array that we have defined for our class and create a Tweet object for each of the dictionaries we have representing a tweet. From there we will ask our table view to reload. The only task we have left to perform is to fill in our table view data source methods to show all the tweets.

Table View Data Source and Delegate Methods

Now we have everything in place. We just need to create a UITableViewCell for every tweet we have. We will also do some tweaking of the size of each cell and the number of lines of each UITextField within each table view cell. These methods are very common so I wont go into much detail on them. Here are the necessary Data Source and Delegate Methods.

#pragma mark UITableViewDataSource Methods
 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
 
	return [tweets count];
}
 
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
	NSString *identifier = @"cell";
	UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
 
	if(!cell) {
 
		cell = [[UITableViewCell alloc] initWithStyle:UITableViewStyleGrouped reuseIdentifier:identifier];
		//[cell setBackgroundColor:[UIColor clearColor]];
	}
 
	[cell.textLabel setNumberOfLines:7];
	[cell.textLabel setText:[(Tweet*)[tweets objectAtIndex:indexPath.row] tweet]];
 
	return cell;
}
 
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
 
	return 150;
}

With this in place you will have an OAuth twitter client that is capable of doing any type of interaction with Twitter. You can find the source for the project here. Please post any questions you have and happy coding!

Follow me on Twitter at @cruffenach