MKBlog

iOS5 Programming: Pushing the limits book updates

2012-02-15T20:40:24-08:00

Rob and myself created a new website, iosptl.com where we will be posting minor updates to the book and other relevant information that might be of use to iOS developers.

iOS is a cutting edge technology. Like everything on the cutting edge, it’s constantly growing and changing. A book captures a moment in time, and iOS:PTL captured the state of the art during the iOS 5 beta in 2011. Most things about iOS development don’t change from month to month, and we expect most of the book to be accurate long into the future. But some things do change, and this website will capture those updates so that the reader can have the most accurate information today.

Checkout the website and subscribe to the feed or follow us on twitter for up to date information on the book.
@mugunthkumar
@cocoaphony
–
Mugunth

Follow me on Twitter

Introducing my book: iOS 5 Programming Pushing the Limits iOS 5 Programming Pushing the Limits Developing Extraordinary Mobile Apps...

Some thoughts on iOS and your privacy (Address Book)

2012-02-07T23:00:17-08:00

The recent furore behind the fact that, Path, one of the most beautiful iOS app out there, uploads your entire address book to their servers when you create an account, is probably targeted at the wrong guys. Why do I say this? Read on.

Who else is doing it?

It’s not just Path. Hipster is doing it. Whatsapp is doing it. Foursquare is doing it. Instagram is doing it. Viber is doing it. “Insert your new hot social networking app here” is doing it. This tweet summarizes this.

for those who just realized that Path uploads your entire address book:you’re such a cute innocent person.Guess what they do with ur fb

— Amudi Sebastian (@amudi) February 8, 2012

Some companies explicitly ask for users’ permission (Whatsapp and Viber)

Whatsapp asking for user's permission to upload address book

Viber asking for user's permission to upload address book

Some companies do it when the user explicitly ask them to do. For example, foursquare and Instagram both have an option called “Find friends from Contacts”.

Instagram uploads when you ask it to find your friends from Contacts.

Instagram uploads your contacts when you tap on "From my contact list"

Foursquare uploads “proactively” when you open the “Invite Friends” view. This is again as bad as Path.

Foursquare uploads in the background when you open this view

To a techie like you and me, we know that this option would upload the entire address book. To any other iOS user, it’s not really clear. May be they should have added an additional prompt like Whatsapp. But then, that would _alert_ the user and he will probably opt out.

Some companies bury it deep inside their privacy policy (that no one reads). While there are many bad examples, Viber really stands out as a good example. Their privacy policy explicitly states what all they do with the contacts they read from your device.

But most company’s privacy policy is written in legal lingo, mostly incomprehensible to the common man.

I’m not arguing that two wrongs make a right. The point I want to put forth is that, this is not a problem with the third party app maker. It’s a platform issue. When a Android app steals your private information, why do you blame Google instead of the third party app developer? If Google allowed API access to your sensitive information using a opt-in dialog like iOS rather than a manifest file, would there be so many trojans on Android marketplace?

The whole problem in this recent furore roots down to the security layer of iOS. iOS allows any programmer to access all of your address book with just two lines of code.

ABAddressBookRef addressBookRef = ABAddressBookCreate();
CFArrayRef allContacts = ABAddressBookCopyArrayOfAllPeople(addressBookRef);
// upload this to server and do something really nasty
CFRelease(addressBookRef);
CFRelease(allContacts);

There is no prompt whatsoever shown by the system.

What should Apple do?

Show an access control dialog when an application makes a request to access address book. Probably from the version first iteration of iOS, you get a prompt when any app (including Apple’s own apps) requests for your location or for your unique device token for sending you notifications. Apple should extend this feature to programatic access of your contacts and calendar as well (EventKit.framework).

Personally, I’m least bothered about apps stealing my contacts. I’ll be more bothered if an app steals my events. Let me give you an example.

Imagine that I have a meeting with a client ABC from 10 AM to 11 AM on Feb 10th at their office, One Marina Boulevard, Singapore. Just imagine what all can be done when a company knows this information. They can stalk me. They can rob my home when I’m not there. They can sell this information to a “order a pizza” guy who could cold-call me during lunch time to up-sell his pizza. Well, most of these don’t really happen. But they _can_ technically happen.

Reading your calendar to know your upcoming events is also few lines of code

EKEventStore *store = [[EKEventStore alloc] init];
NSPredicate *eventPredicate = [store predicateForEventsWithStartDate:startDate endDate:endDate calendars:nil];
NSArray *matchingEvents = [store eventsMatchingPredicate:eventPredicate];
// upload this to server and do something really nasty

How can you help?

If you are a iOS developer, open bugreport.apple.com and file a bug report like this radar 10824178. Duplicate this. The more a bug gets duplicated, the more faster it reaches Apple.

If you are an iDevice user, remember that there is no free lunch. When a company makes a product free, YOU are their product. Be cautious when a app requests for any additional information like your location or push notifications. There are plenty of apps that I know, that use push notifications purely for marketing. Marketing emails in Web 2.0 era is slowly being transformed to push notifications in this mobile dominated decade. Sad part is that, there is no way to unsubscribe from those annoying push notifications apart from deleting the app.

Let’s all hope that Apple addresses this issue at the earliest before something really _bad_ happens.

–
Mugunth

Follow me on Twitter

No related posts.

iOS Tutorial: Image Cache and Loading Thumbnails using MKNetworkKit

2012-01-21T20:30:29-08:00

If you have been following me on Twitter or reading MKBlog, you would already be knowing about MKNetworkKit.

I wrote a introductory post on MKNetworkKit couple of months ago and later explained in a more detailed post on how to use it in other sophisticated scenarios.

Step 1: Create a Flickr Engine
Step 2: Create a custom cache directory for storing the cached Flickr thumbanils
Step 3: Write a method to list flickr images for a specified tag
Step 4: Create a custom table view cell for loading flickr images
Step 5: Clear previously loaded images if the cell will be reused
Step 6: Fade in thumbnails like the Apple trailers app

Source Code

From feedback so far, Image Caching was one aspect of MKNetworkKit that developers didn’t understand pretty well. In this post, I’ll try to explain how to use MKNetworkKit for image caching and loading thumbnails.
Thumbnails are often used in iOS apps to load friend’s avatar pictures from a Facebook feed or flickr thumbnails for a given tag and in many similar cases.

MKNetworkEngine makes it a breeze to add this feature into your app. What not? With MKNetworkKit, you will even know if the response image is from cache or loaded for the first time. Using this information, you can “fade in” your thumbnails when you load the images for the first time (like in Apple’s iTunes Movie Trailers app).

The completed example looks like this.

Screenshot showing images loaded asynchronously using MKNetworkKit

Having said that, lets get our hands dirty with some real code. In this example, I’ll show you how to load images from Flickr on a table view controller asynchronously.

Step 1: Create a Flickr Engine

Easy peasy. Create a subclass of MKNetworkEngine and let’s name it as “FlickrEngine”. Initialize your flickr engine with api.flickr.com as hostname in your application delegate.

Step 2: Create a custom cache directory for storing the cached Flickr thumbanils

Override cacheDirectoryName and return a custom directory for storing the cached thumbnails.

-(NSString*) cacheDirectoryName {
 
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths objectAtIndex:0];
    NSString *cacheDirectoryName = [documentsDirectory stringByAppendingPathComponent:@"FlickrImages"];
    return cacheDirectoryName;
}

This step is optional. But, since thumbnails can easily occupy precious disk space, you might want to clear them at periodic intervals. MKNetworkEngine provides a handy method (emptyCache) to empty the cache directory for a specific engine. The default implementation of this method removes all files within the cache directory of that engine. If you don’t override cacheDirectoryName and provide a distinct cache directory for your engine, you will end up emptying the shared cache directory, when you call emptyCache.

Step 3: Write a method to list flickr images for a specified tag

By now, you already know that creating a network request using MKNetworkKit is a no-brainer. The following shows how to create a request for loading images for a given tag.

-(void) imagesForTag:(NSString*) tag onCompletion:(FlickrImagesResponseBlock) imageURLBlock onError:(MKNKErrorBlock) errorBlock {
 
    MKNetworkOperation *op = [self operationWithPath:FLICKR_IMAGE_URL([tag urlEncodedString])];
 
    [op onCompletion:^(MKNetworkOperation *completedOperation) {
 
        NSDictionary *response = [completedOperation responseJSON];
        imageURLBlock([[response objectForKey:@"photos"] objectForKey:@"photo"]);
 
    } onError:^(NSError *error) {
 
        errorBlock(error);
    }];
 
    [self enqueueOperation:op];
}

The FLICKR_IMAGE_URL macro is defined as

#define FLICKR_IMAGE_URL(__TAG__) [NSString stringWithFormat:@"services/rest/?method=flickr.photos.search&amp;api_key=%@&amp;tags=%@&amp;per_page=200&amp;format=json&amp;nojsoncallback=1", FLICKR_KEY, __TAG__]

Note that, the host name api.flickr.com gets prefixed automatically when you create operations on this engine.

You should generate a new flickr api key and replace it in the FLICKR_KEY macro. You can create one for free here. (For running the example, you can use my key)

Step 4: Create a custom table view cell for loading flickr images

In this custom cell, write a method setFlickrData: that updates the cell from the dictionary you receive by invoking the flickr REST API

-(void) setFlickrData:(NSDictionary*) thisFlickrImage {
 
    self.titleLabel.text = [thisFlickrImage objectForKey:@"title"];
	self.authorNameLabel.text = [thisFlickrImage objectForKey:@"owner"];
    self.loadingImageURLString =
    [NSString stringWithFormat:@"http://farm%@.static.flickr.com/%@/%@_%@_s.jpg",
     [thisFlickrImage objectForKey:@"farm"], [thisFlickrImage objectForKey:@"server"],
     [thisFlickrImage objectForKey:@"id"], [thisFlickrImage objectForKey:@"secret"]];
 
    self.imageLoadingOperation = [ApplicationDelegate.flickrEngine imageAtURL:[NSURL URLWithString:self.loadingImageURLString]
                                    onCompletion:^(UIImage *fetchedImage, NSURL *url, BOOL isInCache) {
 
                                        if([self.loadingImageURLString isEqualToString:[url absoluteString]]) {
                                                self.thumbnailImage.image = fetchedImage;
                                    }];
}

Tip: Avoid setting the individual labels of a table view cell in the cellForRowAtIndexPath: method. It makes the cell less portable across your other view controllers.

Carefully note the use of the variable self.loadingImageURLString. If you don’t save the loading image’s URL in an ivar, your images will continue to be updated when the previous operation completes. To circumvent this, either cancel the operation when a cell is reused, or check if the returned URL is the original URL that was loaded for this cell (by storing it in ivar).

As on this commit, MKNetworkEngine’s imageAtURL method will return you the actual operation created. You should retain this and cancel it when not necessary.

Step 5: Clear previously loaded images if the cell will be reused

You should clear previously loaded images by overriding prepareForReuse method. It’s a one-liner.

-(void) prepareForReuse {
 
    self.thumbnailImage.image = nil;
    [self.imageLoadingOperation cancel];
}

If you don’t write this, you will see old images on the cell while the new image is being loaded.
Instead of “nil” you can also show a default placeholder image here.

You should also consider canceling the old imageLoadingOperation so as to load the latest visible cells faster. If you don’t cancel the operation, when the user scrolls fast to the bottom of the list, the engine loads all the images from the first cell (including images for cells that are now hidden and reused) and there by slowing down the image load operation for the currently visible cell. You can test this from the code by commenting it out and checking the performance.

Step 6: Fade in thumbnails like the Apple trailers app

MKNetworkEngine’s imageAtURL method returns the image in a block method. The block method, onCompletion looks like this.

^(UIImage *fetchedImage, NSURL *url, BOOL isInCache) {
 
                                        if([self.loadingImageURLString isEqualToString:[url absoluteString]]) {
                                                self.thumbnailImage.image = fetchedImage;
                                    }];
}

If the variable isInCache is false, you can “fade in” the image so as to add a nice UI touch to your app. The following code block illustrates this.

^(UIImage *fetchedImage, NSURL *url, BOOL isInCache) {
 
                                        if([self.loadingImageURLString isEqualToString:[url absoluteString]]) {
 
                                            if (isInCache) {
                                                self.thumbnailImage.image = fetchedImage;
                                            } else {
                                                UIImageView *loadedImageView = [[UIImageView alloc] initWithImage:fetchedImage];
                                                loadedImageView.frame = self.thumbnailImage.frame;
                                                loadedImageView.alpha = 0;
                                                [self.contentView addSubview:loadedImageView];
 
                                                [UIView animateWithDuration:0.4
                                                                 animations:^
                                                 {
                                                     loadedImageView.alpha = 1;
                                                     self.thumbnailImage.alpha = 0;
                                                 }
                                                                 completion:^(BOOL finished)
                                                 {
                                                     self.thumbnailImage.image = fetchedImage;
                                                     self.thumbnailImage.alpha = 1;
                                                     [loadedImageView removeFromSuperview];
                                                 }];
                                            }
                                        }
                                    }

Source Code

The complete source code is available as a demo on MKNetworkKit’s Github repository.
–
Mugunth

Follow me on Twitter

iOS Tutorial: Advanced Networking with MKNetworkKit Couple of weeks ago, I wrote a clean, fast networking...

Migrating your code to Objective-C ARC

2011-12-23T15:00:08-08:00

Recently, Apple introduced several new developer stuff including Xcode 4, ARC, LLVM Compiler 3.0 and iOS 5. From some of the questions on Stack overflow, I could understand that, most of the ARC related confusions arise due to the fact that, developers don’t know if “ABC” is a feature/restriction of LLVM 3.0 or iOS 5 or ARC.

Retain cycles, auto-release pools, @autorelease blocks, oh man! So many new things? What am I going to do? You are right. ARC, or Objective-C Automatic Reference Counting is almost as magical as the iPad. No really.

In this post, I’ve made an attempt to demystify the air around this. Before starting, I’ll have to warn you that, this is a fairly long post. If you are too bored, Instapaper this article and read it later. But, hopefully, at the end of this, I believe, you will have a better understanding on how ARC works and be able to work around the innumerable errors it spits out when you convert your project.

Having said that, let’s get started.

What is ARC
How does ARC work internally?
- ARC front end
- ARC optimizer
The actual Migration using Xcode 4.2
Common ARC migration errors
That last question
- When should you migrate?
Where to go from here?

What is ARC

ARC is a feature of the new LLVM 3.0 compiler that helps you to write code without worrying much about memory management. Memory management can be broadly classified into two, garbage collected and reference counted models. Before going to the details, let’s briefly discuss these two models and understand why ARC is even needed.

Problems with the current model.

The current memory model we use in Objective-C is manual reference counting on iOS and Garbage collection on Mac.

There are certain problems with both these memory models which probably was the reason why ARC was developed.

Garbage collection

Garbage collection is a higher level language feature probably introduced in Java (or technically, Java Virtual Machine) and implemented in a variety of other programming platforms including Microsoft’s Common Language Runtime. While Garbage collection worked well for higher level languages, Objective-C, which is still C under the hood, didn’t really fly high. Pointers (or rather references) in other languages like Java were actually objects that managed retain count and automatically releases itself when the count reaches zero. One of the design goals of C was to be optimized for performance and not “easy of use”. While pointer objects (read smart pointers) are great object oriented abstractions, they have an adverse effect on the performance of the code and since Objective-C was intended primarily for native programming where developers are used to use pointers, pointers within a structure, pointer to a pointer (for dereferencing a out parameter), it was just too difficult to introduce something like a smart pointer that would require a lot of mindset change from the developers who prefer a deterministic memory management model (Reference counting) over a non-deterministic memory management model (Garbage collection). Nevertheless, GC (Generational GC) was introduced in Objective-C 2.0 for Mac. While Generational GC doesn’t suffer from “Stop the world” issues like the mark and sweep alogrithm, they don’t collect every released variable and an occasional mark and sweep collection is still needed.

Reference Counting

The memory management model used in iOS is called as reference counting model, or more precisely, manual reference counting.
In manual reference counting model, you as a developer, have to deallocate every object you allocated. When you don’t do this, you either leak memory or over release it, causing a crash. While that counting sounds easy, Most of the memory leaks happen when you transfer ownership of objects across scope boundaries. That’s a creator method that allocates an object for you and expects the caller to deallocate it. To circumvent this problem, Objective-C introduced a concept called autorelease. auto-released variables are added to the auto-release pool and are released at the end of the runloop. While this sounds too good, auto-release pools do incur an additional overhead.

For example, comparing the two code blocks,

{
    NSDictionary *dict = [[NSDictionary alloc] init];
    // do something with the dictionary here
    // I'm done with the dictionary, I don't need it anymore
    [dict release];
    // more code
}

and

{
    NSDictionary *dict = [NSDictionary dictionary]; // auto-released object
    // do something with the dictionary here
    // I'm done with the dictionary, I don't need it anymore
 
    // more code
}

the first block is an example of optimized use of memory where as the second depends on auto-release pools. While this block of code doesn’t really incur significant memory overhead, code like these slowly adds together and makes your reference counted model heavily dependent on auto-release pools. That is, objects that you know could be deallocated, will still linger around in the auto-release pool for a little longer.

Automatic Reference Counting

Say hello to ARC. ARC is a compiler feature that auto inserts retain and release for you. So in the first code block of the above example, you no longer have to write the release method and ARC auto-inserts for you before compilation.

{
    NSDictionary *dict = [[NSDictionary alloc] init];
    // do something with the dictionary here
    // I'm done with the dictionary, I don't need it anymore
    [dict release]; // ARC inserts this code for you.
    // more code
}

When you create an autoreleased object, like in the second block of code, ARC compiler is clever enough not to add a release call. Sound great, so how should I go about doing this ARC thing? Just delete all release/retain codes and pray? Unfortunately, it isn’t that easy. ARC is not just some auto insert or macro expander kind of tool. It forces you to think in terms of object graphs instead of memory allocation, retain or release. Let’s delve a little deeper into ARC.

Compiler level feature

ARC is a compiler level feature. I repeat. ARC IS A COMPILER LEVEL FEATURE. This means, when you use ARC, you don’t have to worry about upgrading your deployment target and so on. However, only the latest LLVM 3.0 compiler supports ARC. If you are still stuck with GCC, you are out of luck. (Meh!) Some more points that you should know about ARC are,

ARC is backward compatible with libraries and framework compiled with under non-ARC.
ARC can be used within your project on a file-by-file basis. So you can mix and match ARC code with non-ARC code.
You can also integrate ARC compiled libraries into your project that doesn’t use ARC and vice-versa.
You use a compiler switch to turn ARC on and off.
(The keyword here is compiler switch)
You can also set the complete target to build with ARC by default (and use non-ARC compiler only when instructed so.) This is shown in the illustration below.

The two main compiler switches that you would often use are when you build your application with a third party library that is not ARC compliant and vice versa, are

-fno-objc-arc
-fobjc-arc

-f is the switch and no-objc-arc and objc-arc are the options that you are turning on. As evident from the names, the first one turns off ARC and the second turns on.

For example, if your application is ARC enabled but a third party library is not, you use the first switch -fno-objc-arc to exclude the third party library. Conversely, if your application is not yet ARC enabled (gasp!) but the third party library you are integrating is, you use the second switch -fobjc-arc You add these flags to the project from the Build phases tab as shown below.

Also a run time feature

Wait! You just told me (and repeated) that ARC is a compiler level feature? Now what? Sorry, I hear you, but, unfortunately, things aren’t that easy and it doesn’t just stop here. ARC also backs up on a runtime feature called zero-ing weak references. Oh, damn, another keyword! I should have introduced this before. But that’s ok. We will revisit about the run-time dependency of ARC, a little later in this post.

ARC Ownership qualifiers

As I showed you earlier, ARC automatically inserts releases and retains in your code in a pre-compilation step. But for ARC to know when to release your objects and when to retain them, you need to somehow tell the life of your variables. You use ownership qualifiers for that. A strong understanding of ownerships is vital to understand and use ARC properly. Once you understand this concept, you will be thinking in terms of object graphs instead of retain/release. Secondly, when you use ARC, all variables local or ivars are initialized to nil automatically for you. This means, there is little chance of having a dangling reference in your application.

__strong
__weak
__unsafe_unretained
__autoreleasing

The first qualifier, __strong, is the default and you might not even be using this explicitly. It is use to tell the ARC compiler that, the declared variable “owns” the reference. The opposite of this is __weak, which tells the ARC compiler that the declared variable doesn’t own the reference.

The __weak is synonymous to the “assign” modifier. You normally use assign modifier for IBOutlets and delegates. Under ARC, this is replaced with __weak. However, there is a caveat. __weak requires you to deploy the app on a runtime that supports zero-ing weak references. This includes, iOS 5 and Lion. Snow Leopard and older operating systems or iOS 4 and older operating systems don’t support zero-ing weak references. This obviously means you cannot use __weak ownership modifiers if you plan to deploy to older operating systems. Fret not. ARC includes another ownership qualifier, __unsafe_unretained that is synonymous to __weak, except that when the pointer is de-referenced, it is not set to nil, but remains dangling. A while ago, I told something about zero-ing weak references? When the runtime supports zero-ing weak references, your __weak variables are automatically set to nil when they are released. This is the only feature that requires a higher deployment target (iOS 5/Lion). Otherwise, you are good to deploy on iOS 4/Snow Leopard.

A couple other important things to know about __weak vs __unsafe_unretained is that, the compiler doesn’t allow you to use __weak when your deployment target is set to a operating system that doesn’t support zero-ing weak references. The Convert to Objective-C ARC wizard uses __weak only when your deployment target supports zero-ing weak references. So if your deployment target is iOS 4, the Objective-C convert ion wizard will replace assign modifiers with __unsafe_unretained instead of __weak.

The last ownership qualifier, __auto_releasing is used mostly when passing a reference to a function for writing out. You would use this in places where you normally use pointer indirection like returning a NSError object via an out parameter.

Properties in your header file can also have the above ownership qualifiers except the __auto_releasing. When applied to properties, ARC automatically generates the correct code in dealloc to release them when the object dies.

Lastly, and more importantly, all of ARC managed objects are initialized to nil when they are created. So, again, no more dangling pointers because you forgot a initialize statement. However, do note that this initialization doesn’t initialize primitive data types. So a declaration like,

int a;

might contain a garbage value for a.

Whew! That’s pretty taxing. Take a break. We just started.

ARC knows more Objective-C than you

ARC also taps into a the Objective-C language naming conventions and infers the ownership of the returned object.

In Objective-C, a method that stats with any one of the following prefix,

alloc,
copy,
mutableCopy and
new

are considered to be transferring ownership of the returned object to the caller.
This means, in your application, when you create a method, ARC automatically infers whether to return a autoreleased object or a +1 retained object from your method name. In fact, in most cases, instead of returning auto-release objects, ARC just inserts a manual release in the calling code, automatically for you. However, there is a small caveat. Let’s assume that you have a method that starts with “copy”, as in

-(NSString*) copyRightString;

ARC assumes that it would transfer the ownership of the returned string to the caller and inserts a release automatically. Everything works well, if both the called method and the calling method are compiled using ARC.

But if your “copyRightString” method is in a third party library that isn’t compiled with ARC, you will over-release the returned string. This is because, on the calling code, ARC compiler inserts a release to balance out the retain count bumped up by the “copy” method. Conversely, if the third party library is compiled with ARC and your method isn’t, you will have a memory leak. You can however override this behavior by adding one of the following attribute to your methods.

NS_RETURNS_NON_RETAINED
NS_RETURNS_RETAINED

So your method will now look like this.

-(NSString*) copyRightString NS_RETURNS_NON_RETAINED;

You can also rename the method name to copyrightString (note the case) or getCopyRightString instead of adding an attribute. However, I wouldn’t recommend the former method as it breaks the cocoa naming conventions (prefixing a method with “get” or “set” is Java-ish)

You will see methods having the NS_RETURNS_* prefixes throughout the header files in Apple’s own UIKit.framework or the foundation classes. Now that you know what happens behind the scenes and how compiler treats these decorations, you can solve crazy memory issues, like a crash when you call a copyRightString in your method in a third party library.

With that, let’s get ready for climbing the next peak.

Toll-free bridging

ARC doesn’t manage Core Foundation objects. They say, there is no free lunch. ARC, takes it one step further. There is no free-casting between Core Foundation objects and equivalent Objective-C objects (NS* objects). Yes, that’s right. You cannot cast a Core Foundation object to an equivalent Objective-C object (NS* object) without telling ARC how to manage ownerships.

Let’s now see how to specify ownership transfers when you cast a Core Foundation object.
The following ownership transfer modifiers should be provided when you cast a Objective-C object to a Core Foundation object.

__bridge
__bridge_retained
__bridge_transfer

When you migrate a project to ARC, you would have seen error messages like the one below.

ARC Error because of a missing bridge attribute in a Toll-free bridging code

You might also have proceeded by accepting the suggestions provided by the LLVM compiler. But now, let’s dig deeper and understand the “why” behind it.

The modifier, __bridge tells the ARC compiler that, it’s a plain simple, bridging cast. That means, you ask the ARC compiler to do nothing extra when the transfer is made. You might think, if that is the case, Apple could have made this the default choice. But it was not made probably because, it’s to preposterous to make such an assumption. Making such a bold assumption means, you would easily leak memory as there isn’t a easier way to tell when you are actually releasing a Core Foundation object unlike a Objective-C object.

The second modifier, __bridge_retained is used to tell the ARC compiler that the Objective-C object should be transferred to Core Foundation by bumping the retain count by 1 and it should be treated as if it is a newly created object (as opposed to a auto-released object). You use this modifier if the method was probably named like a creation method (starting with init, copy, mutableCopy etc.,) or if you are going to release the Objective-C object inside of Core Foundation using methods like CFRelease.

The last modifier, __bridge_transfer is used to tell the ARC compiler that the Core Foundation object is to be transferred to ARC with a retain count of 1. This is used if you created a Core Foundation object using one of the CF***Create methods and want the ARC compiler to handle the memory management for you. That’s you are transferring a Core Foundation object to ARC with a retain count of 1.

As a side note on this, avoid using __bridge_retained and __bridge_transfer to trick the compiler to add retain and releases for you. Use it to improve your code readability and minimizing the number of manual memory management calls. (Move on if you don’t understand this line. You will start understanding this automatically when you start using this in your own code)

How does ARC work internally?

ARC ain’t magic, if you know how it works. But a little knowledge is a dangerous thing. Knowing how the ARC compiler works will help you more in understanding the error messages and compiler warnings spat out by it.

The ARC compiler has two main parts, a front end compiler and an optimizer.

ARC front end

The ARC front end compiler checks for every “owned” Objective-C object and inserts release appropriately. By owned object, I mean, an object whose ownership qualifier has been set. For example, if the “owned” object is a local variable, ARC front end compiler inserts a release at the end of the scope. This is because, by default all local variables are “strong” ly owned. If the object is a instance variable, the ARC front end compiler inserts a release statement in the dealloc method, if the ownership type is strong. For unsafe_unretained or weak ownership ARC doesn’t do anything. It also takes care of calling the [super dealloc] for you and intact ARC compiler doesn’t allow you to explicitly call dealloc.

The ARC front end compiler also takes care of generating errors when it encounters a variable (local or instance) whose ownership qualifier is not set or when you explicitly calling dealloc.

ARC optimizer

The function of the ARC optimizer is to optimize the retain and release statements by removing them if they are inserted multiple times by the ARC front end compiler. It is this optimizer that ensures that performance is not affected by calling retain and release multiple times.

The actual Migration using Xcode 4.2

Xcode 4.2 has a wizard to automatically migrate your code for use with the ARC compiler. This means, the wizard rewrites some of your code, removes calls to retain/release and removes dealloc methods and calls to [super dealloc] for you.

The first step is to open your project, select Edit -> Refactor -> Convert to Objective-C ARC from the menu.

Migrating to Objective-C ARC using Xcode 4.2

When you select this option, you will be asked to select a target. If you have only one target, it’s fine. If you have multiple targets in your application, you have to perform the ARC migration on every target. After you select a target, the wizard by default selects all source code files that belong to that project for ARC migration. If you are using third party libraries that are not yet ARC ready, you can uncheck those files in this step. This is illustrated in the screenshot below.

Selecting your files for ARC exclusion

In the above project, since I know that ASIHttpRequest is not yet ARC compatible, I’m selecting them and command-clicking them to show the option to uncheck all of them. When you do this, the wizard automatically adds a -fno-objc-arc compiler flag for all these files.

The next step is to start the pre-checking process. The pre-checking process compiles the project and analyzes for potential problems before performing the actual migration. You might almost and always get a error message like this.

The dreaded error message!

Of course, 58 errors in this screenshot is actually quite low. You should expect anywhere in the range of 300+ for a mid sized project. But fret not, they aren’t complicated at all to fix.

Common ARC migration errors

The number of errors that might prevent you from converting your project to ARC is usually high if your code is “old” or if it doesn’t adhere to Objective-C design patterns. For example, accessing a iVar. While it’s technically ok, you should almost and always use properties to access them outside of init and dealloc methods. If you have been using properties, ARC migration would be painless. If you were old skool, you have to feel the pain now. In this last section, I’ll show you the most commonly occurring errors when you migrate your project.

Cast of Objective-C pointer to C Pointer type

This error is generated because ARC doesn’t do toll-free bridging for you. As I explained before in the section, Toll-free bridging, requires the developer to explicitly specify ownership transfer qualifiers.
Use the various ownership transfer qualifiers I showed you before to fix this problem.

performSelector may cause a leak because its selector is unknown

We now know that Objective-C ARC compiler knows more Objective-C than you. This error message is because of that. The ARC compiler tries to identify the method family and determine whether to add a retain or release to the returned value from the caller code. This means, if your method starts with init, alloc, copy, mutableCopy or new, the ARC compiler will add a release to the calling code after the variable scope ends. Since are using a selector to call a method dynamically at runtime, ARC doesn’t really know if the method called returns a +1 retained object or a auto-released object. As such, ARC cannot reliably insert a retain or release to the returned object after its scope ends. This warning is shown to warn you of potential memory leaks.

If you are sure that your code works fine without memory leaks, you can ignore this warning. To suppress this warning, you can turn off the compiler flag -Warc-performSelector-leaks warning on a line by line basis like this.

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    [self performSelector:self.mySel];
 #pragma clang diagnostic pop

Unfortunately, you cannot annotate a dynamic selector using __attribute__ ((objc_method_family(*))).

Receiver type “” doesn’t declare the method with selector “”

ARC mandates that every method you call should be declared properly. With GCC, this was a warning. But LLVM makes this step mandatory since ARC needs to accurately identify and that is why you see an error like this.

Error that you see when you don't declare a receiver type

This error is also because of the fact that ARC needs to identify the method family to determine if it has to add a retain or release to the returned object. For example, in the above code, the method, returnMyGreatObject might return a NS_RETURNS_RETAINED. In this case, the ARC compiler has to insert a release after the returned object goes out of scope. The ARC compiler can know this only when you declare it formally. This is why, under ARC method declarations are mandatory. If you have been declaring methods formally under GCC, even when the compiler didn’t enforce (so that the code was aesthetically beautiful) you wouldn’t see this error at all. As I said before, the number of ARC migration errors is directly proportional to the quality of code you write. Fixing this error is fairly simple and all you have to do is to declare every method formally in the header file or on a private category extension.

Common workarounds that you use in ARC on code that otherwise looks normal

In some cases, while using ARC, you might end up writing code that looks as if it’s written to “please” the ARC compiler rather than writing natural code. Unfortunately, nothing can be done to this and we all have to live with this. The next two sections explain when you might need to write unnecessary code like this to please the compiler.

Capturing “*” strongly is likely to lead to a retain cycle

ARC and retain cycles

The last category of warning message is shown when a retain cycle is detected in your code. An example is shown below.

This code was probably leaking the request object before ARC and increasing your memory footprint. But, thanks to ARC. You now know that code like these cause retain cycles that cannot be released automatically. Circumventing a retain cycle issue almost and always ends up breaking the cycle with a weak reference.

Fixing this error is fairly simple and in this case, you can get a weak reference to the request object and copy it to the block. Within the block, convert it again to a strong reference. This is illustrated below.

Workaround for ARC and retain cycle issue

In the above code block, you can also replace references to __unsafe_unretained with __weak if you are deploying to a runtime that supports zero-ing weak references.

Avoiding retain cycles using __block

Sometimes, you need an object to live till as long as the completion handler on it can live. For example, a Block based UIAlertView can call a completion handler after the user presses a button on the UIAlertView.
For example,

UIAlertView *alertView = [UIAlertView alertViewWithTitle:@"Test" buttons:[NSArray arrayWithObjects:@"Ok", @"Cancel", nil] completionHandler:^(int tappedButtonIndex)  {
 
	// do something based on the button tapped on alertView
}];
[alertView show];

In the above case, the alertView gets deallocated by ARC as soon as it’s shown and the call to completionHandler never gets executed (or even crashes).
To prevent this, you can use the __block decoration on UIAlertView declaration and copy it inside the block like

__block UIAlertView *alertView = [UIAlertView alertViewWithTitle:@"Test" buttons:[NSArray arrayWithObjects:@"Ok", @"Cancel", nil] completionHandler:^(int tappedButtonIndex)  {
 
	// do something based on the button tapped on alertView
	alertView = nil;
}];
[alertView show];

ARC takes care of releasing it when you nil it inside the completionHandler. You will find this pattern used a lot when you work with completionHandlers in TwTweetComposeViewController or even UIViewController presentViewController:animated:completion: methods.

That last question

When should you migrate?

NOW

The performance benefits you get by using ARC is remarkable. Apple claims that the @autoreleasepool is over 6 times faster than NSAutoReleasePool objects used in your non-ARC code. This is because, @autoreleasepools don’t allocate objects and all it does is must bump up the pointer retain counts. Similarly, NSObjects’ retain and release are optimized that you can expect a performance boost of anywhere around 2.5x. The third important performance benefit you will see is in methods that return autoreleased object. Under ARC, this variable is no longer transferred using the auto-release pool and what instead happens is a ownership transfer. Again this is upto 20x faster.

Hence, don’t wait till your dependent third party frameworks are migrated to ARC. You can always exclude them and go ahead and convert your code to ARC now.

Where to go from here?

WWDC 2011 – Session 322 Introduction to Automatic Reference Counting
WWDC 2011 – Session 322 Objective-C Advancements in depth
Stop: You are warned. This link is only for hard code geeks. http://clang.llvm.org/docs/AutomaticReferenceCounting.html
WWDC 2011 – Session 308 – Blocks and Grand Central Dispatch in Practice

One last word, treat this post as a living document. I’ll be updating the last few sections on new workarounds as and when I find a fix for them.

–
Mugunth

Follow me on Twitter

MKStoreKit 4.0 – Supporting Auto Renewable Subscriptions MKStoreKit started off in a pet project a couple of...

iOS Tutorial: Advanced Networking with MKNetworkKit

2011-12-19T03:00:13-08:00

Couple of weeks ago, I wrote a clean, fast networking toolkit for iOS and Mac written for the LLVM Compiler 3.0 with ARC.
Reception was very good that it was the “most-watched” repository on Github last week. Early adopters have sent me innumerable emails on how fast their network operations are, and how responsive their app is after integrating MKNetworkKit.

Caching your responses, the wrong way
Say hello to MKNetworkKit
- Behind the scenes
Freezing Operations
Advanced Tips
Source Code

MKNetworkKit is faster (and it makes your app feel smoother and faster with seamless transparent caching) in reality. There are two things that makes MKNetworkKit faster.
First, it’s ARC based and the awesome LLVM 3.0 compiler brings in a ton of performance benefits. Using the @autoreleasepool block instead of NSAutoReleasePool in MKNetworkOperation alone should improve the performance by a huge factor (Apple claims it to be 6 times faster). If you still haven’t migrated to ARC because you want to support those iOS 3.x users, read this post by Matt Gemmell first.

Second important performance benefit is seamless and transparent caching. By transparent caching, I mean, caching that involves zero overhead from the developer (That’s you).

Let me, in this post, brief you about how this seamless caching might help you. First, an example. You are refreshing a twitter stream. A GET request for that looks similar to

GET http://twitter.com/mugunthkumar/statuses

Caching your responses, the wrong way

Some developers cache responses using Core Data. STOP IT

Using Core Data for caching is like using the military to kill bedbugs in your bedroom. DON’T DO IT.

The problem when you implement Core Data is, you should program your view controllers to work with two kinds of data structures. One, JSON/XML from server and the other, Core Data NSManagedObjects. Some “clever” developers “take it to the next level” by just programming their view controllers to work with only Core Data. The design goes like this. The network layer talks to the server and updates Core Data Store. Once the store is updated, send a NSNotification to “refresh” view controllers.
This may sound clever to many. But it’s completely WRONG. I REPEAT. COMPLETELY WRONG. Core Data (or even structured SQL storage) is not meant for that. Core Data is a structured storage for persisting/serializing Object graphs in your application. Don’t use it for storing objects that have a low life time. Thumbnail images, list of tweets etc., just don’t belong there. Secondly, this would require you to read and write to flash memory on the iDevice which have a limited read/write cycle. Finally, reading and writing to disk (in this case, Core Data) is a very ugly way to transfer data from one class to another (in this case, from your Network Layer to View Controllers)

Say hello to MKNetworkKit

MKNetworkKit calls the SAME completion handler with cached data if you are making the call for the second time. When the network connectivity is proper, MKNetworkKit calls your completion handler twice. First with the cached data and again after fetching the latest data from server. As such, you can design your view controllers to work with just ONE kind of data, data from server. If you have an app that doesn’t cache and doesn’t work offline, just replace your networking library with MKNetworkKit and you get caching for free. Not even a single line of code change is required on your view controllers. Caching is transparent. Your view controllers needs to work with the same data structure, no matter whether the data is from cache or server.

Behind the scenes

MKNetworkKit caching is super light-weight and it caches your responses in a NSMutableDictionary. Doesn’t that lead to high memory usage? Yes. of-course, but MKNetworkKit is clever. It observes the UIApplicationDidReceiveMemoryWarningNotification and flushes the dictionary to disk. The next time you make a request to the cached URL, the cached data is brought back to memory. So in-effect, it has a in-memory cache and disk cache and uses a least recently used algorithm to flush items to disk. The MKNetworkEngine class has methods that can be over-ridden to control the cache cost.

Just override the method

-(int) cacheMemoryCost;

and return a higher/lower value based on your application’s requirements.

MKNetworkKit caching works like a intermediate proxy server by intercepting the response headers. So, when a second GET request to the same URL is made, MKNetworkKit behaves the following way.

1) For GET requests that sent a ETag in the header previously (for example, requests to Amazon S3 servers), MKNetworkKit sends a second request as a HEAD request (even if you specify as GET) with IF-NONE-MATCHheader. Most servers that send ETag (like Amazon S3) responds to IF-NONE-MATCH by sending the real data only when it has been changed. Otherwise, they return a 304 Not Modified which MKNetworkKit safely ignores. So data transfer is really not huge. Even this request is honored only after 1 day. So, repeated requests to the same thumbnail image doesn’t even hit the server.

2) For any GET request that contained a Cache-Control:max-age=in the header, MKNetworkKit honors that and makes the second request only after the expiry date. For dynamically generated requests, you should set Cache-Control on server. This not only helps MKNetworkKit, but most proxy servers along the way.

3) For requests that contained a Last-Modified field in the header, MKNetworkKit sends a “IF-MODIFIED-SINCE” HEAD request. This again works like the IF-NONE-MATCH. The server, either sends the complete data or a 304 Not Modified.

4) For servers that implement Cache-Control: no-cache, MKNetworkKit goes one step ahead and makes a second request only after a minute (60 sec). So repeated refreshes to often refreshed page will not exactly hit the server. For example, refreshing foursquare check-ins. It’s rare for these information to change within the next 60 sec.

5) For performance reasons, when the response type is an image, and the response headers doesn’t have any cache control information, MKNetworkKit assumes an expiry date of 7 days.

The last two are not an RFC standard. But these optimizations make network operations fast on a mobile devices even if the server isn’t implemented in an optimized way. All POST, PUT, HEAD and DELETE requests are ignored and not cached.

And, of course, you can customize all these behaviors by editing the values in MKNetworkKit.h

Freezing Operations

Another very important feature of MKNetworkKit is operation freezing. Imagine that, your customer take an awesome photo with your own “Instagram-killer” app, but since he is at a remote exotic place, 3G connectivity is poor and uploading the photo fails. Without MKNetworkKit, you should remember the photo related meta data, store the photo’s NSData in a file and upload the operation the next time the app is launched. Painful!
With MKNetworkKit, you mark the photo upload operation is “freezable”. This means, in the event of network failure, your operations are automatically serialized (frozen beneath snow) and restored the next time the app launches, all for free.

MKNetworkOperation *op = [myEngine operationWithPath:@"/imageUpload" params:paramsDict httpMethod:@"POST"];
[op setFreezable:YES]; // ONE EXTRA LINE
[myEngine enqueOperation:op];

You can mark any POST/PUT/DELETE operation as freezable. GET operations are not freezable and MKNetworkKit ignores your call to setFreezable: if your operation is a “GET” operation.

Advanced Tips

Friction-free authentication

MKNetworkOperation *op = [myEngine operationWithPath:@"/letmein"];
[op setUserName:@"mugunth" password:@"mYsEkReTpAsSwOrD"]; // ONE EXTRA LINE
[op setUserName:@"mugunth" password:@"mYsEkReTpAsSwOrD" basicAuth:YES]; // OR THIS LINE
[myEngine enqueOperation:op];

When your server uses HTTP Basic auth or Digest auth or even Windows NTLM authentication, all you need to do is to set your username and password and MKNetworkKit auto-magically authenticates your request!. For NTLM authentication, just ensure your username is “domain\username”. There is no separate method setDomain: or something.

You can also set basicAuth:YES to send the credentials even before receiving the authentication challenge. However, this works only if your server uses HTTP Basic Authentication.

Custom Authentication

If your server uses HTML Form authentication, you can override the authHandler block and provide custom auth mechanisms.

MKNetworkOperation *op = [myEngine operationWithPath:@"/letmein"];
op.authHandler = ^(NSURLAuthenticationChallenge *cred) { 
// show a web view controller or do whatever you want and finally, when you have a credentials ready, just call 
[challenge.sender useCredential:credential forAuthenticationChallenge:challenge];
};
[myEngine enqueOperation:op];

Overriding MKNetworkEngine

Tweaking the URL building methods with MKNetworkEngine is easy. Let me start by giving you an example. Imagine that you have a server which authenticates a logged in user and after authentication, it expects a Authorization header to be set with an access token.
You need to have a factory method that creates URLs customized to your web service. This could include adding a authorization header in our case. You can do this by overriding the method,

-(void) enqueueOperation:(MKNetworkOperation*) operation;

For example, in the above case, you can check your engine subclass for an access token and add it to the operation’s header in this method (if you have one).

Overriding MKNetworkOperation

Sometimes, you might do custom error handling based on the response from your server. For example, your server might send a valid HTTP response (status code 200) which could be an internal error, like “Invalid User”. Business logic errors are better handled with your own application level error codes. You overriding MKNetworkOperation to customize the success/failure reporting. I would highly recommend doing this along with designing your server to send error codes for error conditions.

The following methods are to be overridden for customizing error handling.

-(void) operationSucceeded;
-(void) operationFailedWithError:(NSError*) error;

For example, in the previous case, you can override operationSucceeded, inspect the response and if the response was indeed a business logic error (“Invalid User”), you can call the [super operationFailedWithError:[Your custom error class for "Invalid User"]];
Otherwise, call [super operationSucceeded].

You can also override operationFailedWithError to introspect the actual cause of the error, if your server sends any error related information in the dictionary.

The reason for overriding at this level is to minimize error handling at view controller layer. So your presentation layer, UIViewController subclasses will be cleaner to read.

If you have subclassed the MKNetworkOperation and want the factory method in your engine subclass, operationWithURLString:params:httpMethod to prepare an operation of your subclass. To register your operation subclass with the engine, you can call the registerOperationSubclass: method.

-(void) registerOperationSubclass:(Class) aClass;

Your code fragment might look like,

[self.myEngine registerOperationSubclass:[MyAppNetworkOperation class]];

Image Cache with MKNetworkEngine

MKNetworkEngine has a handy method to load images from a server. It’s built-in cache mechanism ensures, your images are cached without using any third-party image cache libraries. That means your code base is even leaner.
You can use the following method of MKNetworkEngine to load images.

-(void) imageAtURL:(NSURL *)url onCompletion:(MKNKImageBlock) imageFetchedBlock;

MKNKImageBlock is defined like this.

typedef void (^MKNKImageBlock) (UIImage* fetchedImage, NSURL* url, BOOL isInCache);

So your calling code will look like,

    [ApplicationDelegate.myAppEngine imageAtURL:[NSURL URLWithString:@"http://example.com/image.png"] onCompletion:^(UIImage *fetchedImage, NSURL *fetchedURL, BOOL isInCache) {
        self.imageView.image = fetchedImage;
    }];

If you are loading images onto a imageView inside a tableview cell, you can check if the completed URL is same as the passed URL

    [ApplicationDelegate.myAppEngine imageAtURL:[NSURL URLWithString:@"http://example.com/image.png"] onCompletion:^(UIImage *fetchedImage, NSURL *fetchedURL, BOOL isInCache) {
	if(originalURL == fetchedURL)
        cell.imageView.image = fetchedImage;
    }];

This check is necessary as tableview cells might be recycled and a cell might end up getting images from multiple network operations.

You might also want to read my other elaborate post on Image Caching with MKNetworkKit

Lastly, if you are fading in your images like those fancy apps, add your fade-in logic if the image is loaded from server and not from cache.

Source Code

MKNetworkKit on Github

MKNetworkKit might look simple, but it’s incredibly powerful. Use it in your apps and tell me how it scores. My next blog post would be on how to write a better RESTful server that serves a mobile device. Watch this space, subscribe to my feed or follow me on twitter.

Interested in learning in-depth features of Objective-C and iOS? You should get my book.

Amazon - http://mk.sg/ios5book

iBooks - http://mk.sg/ibook

Wiley – http://mk.sg/book

Book Depository – http://mk.sg/bdbook
–
Mugunth

Follow me on Twitter

iOS Tutorial: Image Cache and Loading Thumbnails using MKNetworkKit If you have been following me on Twitter or reading...
iOS Framework: Introducing MKNetworkKit How awesome would it be if a networking framework automatically...

iOS Framework: Introducing MKNetworkKit

2011-11-29T03:22:49-08:00

How awesome would it be if a networking framework automatically takes care of caching responses for you?

How awesome would it be if a networking framework automatically remembers your operations when your client is offline?

You favorite a tweet or mark a feed as read when you are offline and the Networking Framework performs all these operations when the device comes back online, all with no extra coding effort from you. Introducing MKNetworkKit.

What is MKNetworkKit?
Features
How to use
Documentation
Source Code
Feature requests
Licensing

What is MKNetworkKit?

MKNetworkKit is a networking framework written in Objective-C that is seamless, block based, ARC ready and easy to use.
MKNetworkKit is inspired by the other two popular networking frameworks, ASIHTTPRequest and AFNetworking. Marrying the feature set from both, MKNetworkKit throws in a bunch of new features. In addition to this, MKNetworkKit mandates you to write slightly more code than the other frameworks at the expense of code clarity. With MKNetworkKit, it’s hard to write ugly networking code.

Features

Super light-weight

The complete kit is just 2 major classes and some category methods. This means, adopting MKNetworkKit should be super easy.

Single Shared Queue for your entire application.

Apps that depend heavily on Internet connectivity should optimize the number of concurrent network operations. Unfortunately, there is no networking framework that does this correctly. Let me give you an example of what can go wrong if you don’t optimize/control the number of concurrent network operations in your app.

Let’s assume that you are uploading a bunch of photos (think Color or Batch) to your server. Most mobile networks (3G) don’t allow more than two concurrent HTTP connections from a given IP address. That is, from your device, you cannot open more than two concurrent HTTP connections on a 3G network. Edge is even worse. You can’t, in most cases, open more than one connection. This limit is considerably high (six) on a traditional home broadband (Wifi). However, since your iDevice is not always connected to Wifi, you should be prepared for throttled/restricted network connectivity. On any normal case, the iDevice is mostly connected to a 3G network, which means, you are restricted to upload only two photos in parallel. Now, it is not the slow upload speed that hurts. The real problem arises when you open a view that loads thumbnails of photos (say on a different view) while this uploading operations are running in the background. When you don’t properly control the queue size across the app, your thumbnail loading operations will just timeout which is not really the right way to do it. The right way to do this is to prioritize your thumbnail loading operation or wait till the upload is complete and the load thumbnails. This requires you to have a single queue across the entire app. MKNetworkKit ensures this automatically by using a single shared queue for every instance of it. While MKNetworkKit is not a singleton by itself, the shared queue is.

Showing the Network Activity Indicator correctly

While there are many third party classes that uses “incrementing” and “decrementing” the number of network calls and using that to show the network activity indicator, MKNetworkKit backs on the single shared queue principle and shows the activity indicator automatically when there is an operation running in the shared queue by observing (KVO) the operationCount property. As a developer, you normally don’t have to worry about setting the network activity indicator manually, ever again.

    if (object == _sharedNetworkQueue &amp;&amp; [keyPath isEqualToString:@"operationCount"]) {
 
        [UIApplication sharedApplication].networkActivityIndicatorVisible =
        ([_sharedNetworkQueue.operations count] &gt; 0);
    }

Auto queue sizing

Continuing the previous discussion, I told that most mobile networks don’t allow more than two concurrent connections. So your queue size should be set to two, when the current network connectivity is 3G. MKNetworkKit automatically handles this for you. When the network drops to 3G/EDGE/GPRS, it changes the number of concurrent operations that can be performed to 2. This is automatically changed back to 6 when the device connects back to a Wifi network. With this technique in place, you will see a huge performance benefit when you are loading thumbnails (or multiple similar small requests) for a photo library from a remote server over 3G.

Auto caching

MKNetworkKit can automatically cache all your “GET” requests. When you make the same request again, MKNetworkKit calls your completion handler with the cached version of the response (if it’s available) almost immediately. It also makes a call to the remote server again. After the server data is fetched, your completion handler is called again with the new response data. This means, you don’t have to handle caching manually on your side. All you need to do is call one method,

[[MKNetworkEngine sharedEngine] useCache];

Optionally, you can override methods in your MKNetworkEngine subclass to customize your cache directory and in-memory cache cost.

Operation freezing

With MKNetworkKit, you have the ability to freeze your network operations. When you freeze an operation, in case of network connectivity losses, they will be serialized automatically and performed once the device comes back online. Think of “drafts” in your twitter client.

When you post a tweet, mark that network call as freezable and MKNetworkKit automatically takes care of freezing and restoring these requests for you! So the tweets get sent later without you writing a single line of additional code. You can use this for other operations like favoring a tweet or sharing a post from your Google reader client, adding a link to Instapaper and similar operations.

Performs exactly one operation for similar requests

When you load thumbnails (for a twitter stream), you might end up creating a new request for every avatar image. But in reality, you only need as many requests as there are unique URLs. With MKNetworkKit, every GET request you queue gets executed exactly once. MKNetworkKit is intelligent enough not to cache “POST” http requests.

Image Caching

MKNetworkKit can be seamlessly used for caching thumbnail images. By overriding a few methods, you can set how many images should be held in the in-memory cache and where in the Caches directory it should be saved. Overriding these methods are completely optional.

Performance

One word. SPEED. MKNetworkKit caching is seamless. It works like NSCache, except that, when there is a memory warning, the in-memory cache is written to the Caches directory.

Full support for Objective-C ARC

You normally choose a new networking framework for new projects. MKNetworkKit is not meant for replacing your existing framework (though you can, it’s quite a tedious job). On new projects, you will almost and always want to enable ARC and as on date of writing this, MKNetworkKit is probably the only networking framework that is fully ARC ready. ARC based memory management is usually an order of magnitude faster than non-ARC based memory management code.

How to use

Ok, Enough self-praises. Let us now see how to use the framework.

Adding the MKNetworkKit

Drag the MKNetworkKit directory to your project.
Add the CFNetwork.Framework, SystemConfiguration.framework and Security.framework.
Include MKNetworkKit.h to your PCH file
Delete NSAlert+MKNetworkKitAdditions.h file if you are building for iOS.
Delete UIAlertView+MKNetworkKitAdditions.h file if you are building for Mac.

You are done. Just 5 core files and there you go. A powerful networking kit.

Classes in MKNetworkKit

MKNetworkOperation
MKNetworkEngine
Miscellaneous helper classes (Apple’s Reachability) and categories

I believe in simplicity. Apple has done the heavy lifting of writing the actual networking code. What a third-party networking framework should provide is an elegant queue based networking with optional caching. I believe that, any third party framework should have under 10 classes (whether it’s networking or UIKit replacement or whatever). More than that is a bloat. Three 20 library is an example of bloat and so is ShareKit. May be it’s good. But it still huge and bloated. ASIHttpRequest or AFNetworking are lean and lightweight, unlike RESTKit. JSONKit is lightweight unlike TouchJSON (or any of the TouchCode libraries). May be it’s just me, but I just can’t take it when more than a third of source code lines in my app comes from a third party library.

The problem with a huge framework is the difficulty in understanding the internal working and the ability to customize it to suit your needs (in case you need to). My frameworks (MKStoreKit for adding In App Purchases to your app) have always been super easy to use and I believe MKNetworkKit would also be the same. For using MKNetworkKit, all you need to know are the methods exposed by the two classes MKNetworkOperation and MKNetworkEngine. MKNetworkOperation is similar to the ASIHttpRequest class. It is a subclass of NSOperation and it wraps your request and response classes. You create a MKNetworkOperation for every network operation you need in your application.

MKNetworkEngine is a pseudo-singleton class that manages the network queue in your application. It’s a pseudo-singleton, in the sense, for simple requests, you should use MKNetworkEngine methods directly. For more powerful customization, you should subclass it. Every MKNetworkEngine subclass has its own Reachability object that notifies it of server reachability notifications. You should consider creating a subclass of MKNetworkEngine for every unique REST server you use. It’s pseudo-singleton in the sense, every single request in any of it’s subclass goes through one and only one single queue.

You can retain instances of your MKNetworkEngine in your application delegate just like CoreData managedObjectContext class. When you use MKNetworkKit, you create an MKNetworkEngine sub class to logically group your network calls. That is, all Yahoo related methods go under one single class and all Facebook related methods into another class. We will now look at three different examples of using this framework.

Example 1:

Let’s now create a “YahooEngine” that pulls currency exchange rates from Yahoo finance.

Step 1: Create a YahooEngine class as a subclass of MKNetworkEngine. MKNetworkEngine init method takes hostname and custom headers (if any). The custom headers is optional and can be nil. If you are writing your own REST server (unlike this case), you might consider adding client app version and other misc data like client identifier.

    NSMutableDictionary *headerFields = [NSMutableDictionary dictionary];
    [headerFields setValue:@"iOS" forKey:@"x-client-identifier"];
 
    self.engine = [[YahooEngine alloc] initWithHostName:@"download.finance.yahoo.com"
                       customHeaderFields:headerFields];

Note that, while yahoo doesn’t mandate you to send x-client-identifier in the header, the sample code shown above sends this just to illustrate this feature.

Since the complete code is ARC, it’s up to you as a developer to own (strong reference) the Engine instance.

When you create a MKNetworkEngine subclass, Reachability implementation is done automatically for you. That’s when your server goes down or due to some unforeseen circumstances, the hostname is not reachable, your requests will automatically be queued/frozen. For more information about freezing your operations, read the section Freezing Operations later in the page.

Step 2: Designing the Engine class (Separation of concerns)

Let’s now start write the methods in Yahoo Engine to fetch exchange rates. The engine methods will be called from your view controller. A good design practice is to ensure that your engine class doesn’t expose URL/HTTPHeaders to the calling class. Your view should not “know” about URL endpoints or the parameters needed. This means, parameters to methods in your Yahoo Engine should be the currencies and the number of currency units. The return value of this method could be a double value that is the exchange rate factor and may be the timestamp of the time it was fetched. Since operations are not performed synchronously, you should return these values on blocks. An example of this would be,

-(MKNetworkOperation*) currencyRateFor:(NSString*) sourceCurrency
                   	    inCurrency:(NSString*) targetCurrency
			  onCompletion:(CurrencyResponseBlock) completion
        	               onError:(ErrorBlock) error;

MKNetworkEngine, the parent class defines three types of block methods as below.

typedef void (^ProgressBlock)(double progress);
typedef void (^ResponseBlock)(MKNetworkOperation* operation);
typedef void (^ErrorBlock)(NSError* error);

In our YahooEngine, we are using a new kind of block, CurrencyResponseBlock that returns the exchange rate. The definition looks like this.

typedef void (^CurrencyResponseBlock)(double rate);

In any normal application, you should be defining your own block methods similar to this CurrencyResponseBlock for sending data back to the view controllers.

Step 3: Processing the data
Data processing, that is converting the data you fetch from your server, whether it’s JSON or XML or binary plists, should be done in your Engine. Again, relieve your controllers of doing this task. Your engine should send back data only in proper model objects or arrays of model objects (in case of lists). Convert your JSON/XML to models in the engine. Again, to ensure proper separation of concerns, your view controller should not “know” about the “keys” for accessing individual elements in your JSON.

That concludes the design of your Engine. Most networking framework doesn’t force you to follow this separation of concerns. We do, because we care for you

Step 4: Method implementation
We will now discuss the implementation details of the method that calculates your currency exchange.

Getting currency information from Yahoo, is as simple as making a GET request.
I wrote a macro to format this URL for a given currency pair.

#define YAHOO_URL(__C1__, __C2__) [NSString stringWithFormat:@"d/quotes.csv?e=.csv&amp;f=sl1d1t1&amp;s=%@%@=X", __C1__, __C2__]

Methods you write in your engine class should do the following in order.

Prepare your URL from the parameters.
Create a MKNetworkOperation object for the request.
Set your method parameters.
Add completion and error handlers to the operation (The completion handler is the place to process your responses and convert them to Models.)
Optionally, add progress handlers to the operation. (Or do this on the view controller)
If your operation is file download, set a download stream (normally a file) to it. This is again optional.
When the operation completes, process the result and invoke the block method to return this data to the calling method.

This is illustrated in the following code

        MKNetworkOperation *op = [self operationWithPath:YAHOO_URL(sourceCurrency, targetCurrency)
                                                  params:nil
                                             httpMethod:@"GET"];
 
    [op onCompletion:^(MKNetworkOperation *completedOperation)
     {
         DLog(@"%@", [completedOperation responseString]);
 
		 // do your processing here
         completionBlock(5.0f);
 
     }onError:^(NSError* error) {
 
         errorBlock(error);
     }];
 
    [self enqueueOperation:op];
 
    return op;

The above code formats the URL and creates a MKNetworkOperation. After setting the completion and error handlers it queues the operation by calling the super class’s enqueueOperation method and returns a reference to it. Your view controller should own this operation and cancel it when the view is popped out of the view controller hierarchy. So if you call the engine method in, say viewDidAppear, cancel the operation in viewWillDisappear. Canceling the operation will free up the queue for performing other operations in the subsequent view (Remember, only two operations can be performed in parallel on a mobile network. Canceling your operations when they are no longer needed goes a long way in ensuring performance and speed of your app).

You view controller can also (optionally) add progress handlers and update the user interface. This is illustrated below.

    [self.uploadOperation onUploadProgressChanged:^(double progress) {
 
        DLog(@"%.2f", progress*100.0);
        self.uploadProgessBar.progress = progress;
    }];

MKNetworkEngine also has convenience methods to create a operation with just a URL. So the first line of code can also be written as

        MKNetworkOperation *op = [self operationWithPath:YAHOO_URL(sourceCurrency, targetCurrency)];

Do note here that request URLs are automatically prefixed with the hostname you provided while initializing your engine class.

Creating a POST, DELETE or PUT method is as easy as changing the httpMethod parameter. MKNetworkEngine has more convenience methods like this. Read the header file for more.

Example 2:

Uploading an image to a server (TwitPic for instance).
Now let us go through an example of how to upload an image to a server. Uploading an image obviously requires the operation to be encoded as a multi-part form data. MKNetworkKit follows a pattern similar to ASIHttpRequest.
You call a method addFile:forKey: in MKNetworkOperation to “attach” a file as a multi-part form data to your request. It’s that easy.
MKNetworkOperation also has a convenience method to add a image from a NSData pointer. That’s you can call addData:forKey: method to upload a image to your server directly from NSData pointer. (Think of uploading a picture from camera directly).

Example 3:

Downloading files to a local directory (Caching)
Downloading a file from a remote server and saving it to a location on users’ iPhone is super easy with MKNetworkKit.
Just set the outputStream of MKNetworkOperation and you are set.

[operation setDownloadStream:[NSOutputStream
	outputStreamToFileAtPath:@"/Users/mugunth/Desktop/DownloadedFile.pdf"
			  append:YES]];

You can set multiple output streams to a single operation to save the same file to multiple locations (Say one to your cache directory and one to your working directory)

Example 4:

Image Thumbnail caching
For downloading images, you might probably need to provide an absolute URL rather than a path. MKNetworkEngine has a convenience method for this. Just call operationWithURLString:params:httpMethod: to create a network operation with an absolute URL.
MKNetworkEngine is intelligent. It coalesces multiple GET calls to the same URL into one and notifies all the blocks when that one operation completes. This drastically improves the speed of fetching your image URLs for populating thumbnails.

Subclass MKNetworkEngine and override image cache directory and cache cost. If you don’t want to customize these two, you can directly call MKNetworkEngine methods to download images for you. I would actually recommend you to do that.

Caching operations

MKNetworkKit caches all requests by default. All you need to do is to turn on caching for your Engine. When a GET request is performed, if the response was previously cached, your completion handler is called with the cached response almost immediately. To know whether the response is cached, use the isCachedResponse method. This is illustrated below.

    [op onCompletion:^(MKNetworkOperation *completedOperation)
     {
         if([completedOperation isCachedResponse]) {
             DLog(@"Data from cache");
         }
         else {
             DLog(@"Data from server");
         }
 
         DLog(@"%@", [completedOperation responseString]);
     }onError:^(NSError* error) {
 
         errorBlock(error);
     }];

Freezing operations

Arguably, the most interesting feature of MKNetworkKit is built in ability to freeze operations. All you need to do is set your operation as freezable. Almost zero effort!

[op setFreezable:YES];

Freezable operations are automatically serialized when the network goes down and executed when connectivity is restored. Think of having the ability to favorite a tweet while you are offline and the operation is performed when you are online later.
Frozen operations are also persisted to disk when the app enters background. They will be automatically performed when the app is resumes later.

Convenience methods in MKNetworkOperation

MKNetworkOperation exposes convenience methods like the following to get the format your response data.

responseData
responseString
responseJSON (Only on iOS 5)
responseImage
responseXML
error

They come handy when accessing the response after your network operation completes. When the format is wrong, these methods return nil. For example, trying to access responseImage when the actual response is a HTML response will return nil. The only method that is guaranteed to return the correct, expected response is responseData. Use the other methods if you are sure of the response type.

Convenience macros

The macros, DLog and ALog were stolen unabashedly from Stackoverflow and I couldn’t again find the source. If you wrote that, let me know.

A note on GCD

I purposefully didn’t use GCD because, network operations need to be stopped and prioritized at will. GCD, while more efficient than NSOperationQueue, cannot do this. I would recommend not to use GCD based queues for your network operations.

Documentation

The header files are commented and I’m trying out headerdoc from Apple. Meanwhile, you can use/play around (read: Fork) with the code.

Source Code

The source code for MKNetworkKit along with a demo application is available on Github.
MKNetworkKit on Github

Feature requests

Please don’t email me feature requests. The best way is to create an issue on Github.

Licensing

MKNetworkKit is licensed under MIT License

All of my source code can be used free of charge in your app, provided you add the copyright notices to your app. A little mention on one of your most obscure “about” page will do.

Attribution free licensing available upon request. Contact me at mknetworkkit@mk.sg

–
Mugunth

Follow me on Twitter

iOS Tutorial: Advanced Networking with MKNetworkKit Couple of weeks ago, I wrote a clean, fast networking...
Introducing my book: iOS 5 Programming Pushing the Limits iOS 5 Programming Pushing the Limits Developing Extraordinary Mobile Apps...

Software philosophy: Release early, release often vs polished releases

2011-11-28T04:00:36-08:00

Release early, release often is a philosophy where you release the product as soon as possible and rapidly iterate it to perfection by listening to your customers. A polished release, on the other hand is where your product, in its initial version is solid, lacks obvious bugs and has just enough features to satisfy a majority of your consumers. Most software companies adopt either one of this and that choice is not superficial. In fact, it roots down to the heart of the company’s ideologies.
Before you launch your next big product, website, app, read this and decide which side you are on.

Philosophy followed by them

Release early, release often, has always been the mantra of Linux kernel, software from Microsoft and plenty other open source software. Microsoft (and Microsoft developers) followed this philosophy since its inception. The Windows Operating System, in the initial version (1.0) did not support overlapping windows which was a breakthrough feature on the then contemporary Macintosh. Despite that, a few years later, Microsoft was able to catch up with the competition by following the release early, release often philosophy. In 1995, the same race happened between Microsoft and Netscape with browsers. IE 1.0 was no where near Netscape, but a couple of years later, the fourth iteration of the browser, IE 4 nailed it.

In late 90s, when the web became popular, updating your software (web application) became even easier and web application developers, continued to follow the same mantra.

The workflow of a web developer used to be like this.

Make a shitty website
Improve your website
check your visitor count
…
Improve your website
check your visitor count
…
…
Once your reach a satisfactory level, mark your release as final (remove that beta/gamma tag).

Later in 2004, when Google introduced their Gmail, it was known for the perpetual beta in the logo.
Flickr moved from alpha to beta to gamma(!) in 2006!

Philosophy followed by Apple

Apple on the other hand polish their products to perfection. May be it’s their “Think different” culture or may be it’s the ingrained attitude of the late founder, Steve Jobs, to make “insanely great” products relegating profits or business strategies.

The first version of iOS (then called as iPhone OS), did not even have MMS, included in even the dumbest phones out there. Yet, every feature that was available, worked really really well. The first iPod, despite being available only for Mac users, was a runaway success.

Consumer mindset outside of Software

Let’s for a moment think outside of Software. Let’s take movies for example. Every single release of a movie, whether it is The Jurassic Park and its sequels or The Matrix and its sequels or Steve Jobs’s own Toy Story and its sequels never had “versions”.
The movies were great right from the first release and the producers and directors never “planned” to make their movie incrementally better. Of course there were sequels, but they were not “bug fixes” or incremental updates to the original movie. The same holds good for physical commodities like cars or cameras. Remember, the world had cars, cameras and movies, much before Software. So, how and why did people got accustomed to this way of life, when it comes to Software? Will you accept if your new car, in its “version 1.0″ doesn’t speed up beyond 60? Will you accept if the car manufacturer promises a free “engine update” in the “near future”?

The reason was partly because, at least in the past, software was considered “Magical”. The first spreadsheet program (Lotus 1-2-3) can “sort” the marks of student in ascending order and made the process of calculating the rank among students in a class, super easy, fast and reliable. What usually took days, was accomplished within seconds using Software. Other commodities did not provide this level of satisfaction.

When something performs well on one area, human beings tend to be lenient in evaluating its performance else where. That “something” can be anything. A beautiful blonde girl who is “not so smart” or a restaurant that serves tasty food, but looks shoddy (or the other way round). This is precisely what happened to user’s perception of Software decades ago and unfortunately, has been continuing till now. A software that does one thing (sorting in this case) properly, but crashes often was still acceptable.

How Apple changed your consumers

Apple, on the other hand, tend to think differently. They never use the “beta” tag. (And when they do, it is still better than the competition). Look at the iterative changes that happens to any of their product. It, mostly remains same. The first iPod, still looks closely similar to the latest generation iPod classic and the first iPhone looks closely similar to the latest iPhone, the iPhone 4S and Mac OS X 10.0, looks closely similar to Mac OS X Lion. Leave software, even the light bulb invented by Edison a century ago, looks very similar in shape and size compared to the tungsten filament light bulb today. Contrarily, compare that to the control panel on Windows 95 to Windows 7 and the upcoming Windows 8 beta. It’s clear that, Microsoft didn’t nail it and they still haven’t nailed it.

With iPod, iPhone, iPad and several other products, Apple has proved that, Software can be done right, right from the initial version and has re-wired users’ brain to expect quality products even when it is Software. This can be seen on the ratings of same apps from the same companies on Apple App Store and Android Market Place. Ratings on Market Place is usually higher than on App Store even if the Android version is buggier. Apple users expect quality. They don’t tolerate sh*t.

These two philosophical differences might have stemmed from the thought process of Steve Jobs and Bill Gates who shaped the early software industry. Steve was a perfectionist. Anything less than the ultimate is a shitty product. Bill on the other hand was different. He was more focussed on the monetary aspects of things (that doesn’t automatically mean it’s bad) at the expense of quality.

What should you do?

The release early, release often mantra has created a notion that Software is unreliable and often buggy. Since most software are like that, consumers, more than not, aren’t willing to pay for Software just as easy as they would for anything else. When we learn this, we complain that, their attitude is wrong. We even go as far as comparing the cost of a Starbucks coffee to an app and say people don’t pay for software that costs a fraction of the price of a coffee. It’s not that people don’t want to pay. It’s more like, people are not interested in paying for something that they are afraid, might not work as advertised. To consumers, buying a software is more like taking a risk than buying a coffee. With Windows, the risk was viruses. With online, cloud only, web applications, it was privacy. With App Store, Apple has shown them, what trustworthy computing is mitigating a huge risk considerably. With App Store, the risk a customer takes is paying for a software that doesn’t work as advertised (or doesn’t meet the quality expectations).

While Apple was not doing well in late 90s, the industry thrived well on release early, release often mantra. It often worked since, funding the software product was easy when it was iteratively developed. But, it’s 2011 now. If you are making a iOS app, remember that your target audience are iPhone/iPad users. They don’t tolerate sh*t. The App Store is filled with high quality apps and if your app doesn’t meet that quality expectations, don’t expect a run away success. Make a polished product from day 1. If you are running low on budget/funding, don’t write software in the first place. If you were a movie producer, you can’t make a movie with half the money, release it and build upon that. Neither movies, nor cars or any other commodities are made like that. Don’t make a 0.8b release and expect users to tolerate it. Don’t promise *big* features on upcoming release. Some companies that I admire are Tapbots, Panic Software (they make the awesome FTP client, Transmit), AgileBits (the guys behind 1password). All of their products are “insanely great” right from day 1. Just because, something can be changed easily, doesn’t mean you should be changed frequently (iterated) even after release. Movies too had iterations, and cars had prototypes, but they existed only within the studio or the factory and never made it to the customers. You and me, the common man, doesn’t even know of their existence. Why can’t we build software like that? Why should you ship a product that’s not complete?

Let’s kill the notion that software can be made great only by rapid iteration. Make your next product an example of that.

–
Mugunth

Follow me on Twitter

No related posts.

iOS Code: MKiCloudSync – Sync your NSUserDefaults to iCloud with a single line of code

2011-11-19T21:33:32-08:00

Just wrote this class, MKiCloudSync (100 lines of code) that auto syncs your NSUserDefaults to iCloud.

How to use?

All you need to do is to enable iCloud key value store entitlements, copy the files and forget about the rest.

Step 1:

Enable iCloud entitlements for your app. This is easily done in Xcode 4.2.1 by opening your target settings and checking “Enable Entitlements” from the summary tab.

This is illustrated below.

Enabling iCloud Entitlements in Xcode 4.2.1

Tip:
If you are sharing settings with other apps, ensure that your iCloud Key-Value Store is the same across all those apps.
Step 2:
Drag the two files

MKiCloudSync.h
MKiCloudSync.m

into your project. You can find these files in the Source Code section of this post.
Step 3:
In your applicationDidFinishLaunchingWithOptions: method,
start the sync by calling,

[MKiCloudSync start];

You also have to #include the header file.
This is probably the only line of code you have to write!
Step 4:
Sleep… Kidding.

There is no step 4. Continue using NSUserDefaults to save your settings. The MKiCloudSync class automatically syncs your settings to iCloud and restores them back to your NSUserDefaults when they are changed on other devices.

To top them all, it also posts a notification,

kMKiCloudSyncNotification

to let you know that a sync has been performed. You can listen to this notification and update your user interface from NSUserDefaults.

Advantages

Upgrading your existing iOS 4 apps to sync settings to iCloud is now super easy.
With this class, you no longer have to add calls to NSUbiquitousKeyValueStore throughout your app. You can continue your existing method of saving them to NSUserDefaults. Everything is automatic. If your settings might change often, you can observe the notification kMKiCloudSyncNotification and update your user interface.

Source Code

MKiCloudSync on Github

Licensing

Royalty free for commercial or non-commercial use, though attribution will please me to write more such code

–
Mugunth

Follow me on Twitter

Using MKStoreKit in your apps MKStoreKit, as you probably know is a framework for implementing...

Easy Debugging with NSMutableURLRequest

2011-11-07T03:30:36-08:00

This post is a sequel to one of my previous post, Easy Debugging with ASIHTTPRequest.
I previously showed you a code snippet for logging ASIHTTPRequest as curl commands on command line.
I’ve updated that code for NSMutableURLRequest, which means, you can use it for almost any third party networking kits, including the recently famous AFNetworking.

The Drive

The main necessity for this was, I always used to miss some of the parameters I should use for calling a said API. The only way to debug these issues is to simulate the call on a third party REST client, check if everything works and then start coding. But that was a bit too overkill for me. I wrote this snippet so that, you can straight away NSLog a NSMutableURLRequest and see the curl syntax on the console. You can copy and paste this to your Terminal and check if you are calling the API correctly.

Usage

Drag the attached files into your project.

<code>NSMutableURLRequest+CurlDescription.h
NSMutableURLRequest+CurlDescription.m</code>

Add a line to your PCH file or any global header file to include this file.

That’s it!. You are done.
Now, whenever you need to print your request as a curl command, just add a NSLog it.

If you are using AFNetworking, I would recommend overriding the method,

- (void)enqueueHTTPRequestOperationWithRequest:(NSURLRequest *)urlRequest 
                                       success:(void (^)(id object))success 
                                       failure:(void (^)(NSHTTPURLResponse *response, NSError *error))failure;

in your own APIClient class.
You can now NSLog the request and call the super class implementation.

Example

-(void) enqueueHTTPRequestOperationWithRequest:(NSURLRequest *)request success:(void (^)(id))success failure:(void (^)(NSHTTPURLResponse *, NSError *))failure {
 
    NSLog(request);
    [super enqueueHTTPRequestOperationWithRequest:request success:success failure:failure];
}

This would log every single API call you make in your app on the console as a curl command.
A second advantage of this is, it reduces cognitive overload. When you see the request printed on console, you don’t have to think what it is doing. Just copy and paste it to Terminal and start debugging right away!

Source Code

NSMutableURLRequest+Curl.zip

Licensing

Do whatever you want with the code without removing the source code attribution.

–
Mugunth

Follow me on Twitter

Easy Debugging with ASIHTTPRequest Just wrote this quick and dirty method that dumps a...

iOS5: Migrating your code to NSJSONSerialization using the Adapter Design Pattern

2011-10-24T20:20:59-07:00

In iOS 5, Apple introduced NSJSONSerialization, for parsing JSON strings.

But, as on date, you might have already developed your app using a third party component like JSONKit or json-framework or TouchJSON and you might not want to migrate your complete code base to NSJSONSerialization. In fact removing or replacing an existing framework is not really an easy thing especially if you have a lot of dependencies. However, moving towards Apple’s implementation is always safer to use since you have the guarantee that it will be maintained kept up to date.

The Adapter Design Pattern

This is where the Adapter design pattern comes to rescue.
Adapters are classes that helps in migrating your code base with as low side-effects as possible. If you were depending on the class categories in your third party framework, which is probably the case, you can use my “adapter” classes to route those messages to Apple’s framework. That way, all you need to do is to copy couple of files from my framework, and ditch your third party json parsing frameworks. It should all start working automatically.

Let’s see how that works.

The adapter classes I wrote “adapts” your code to use Apple’s NSJSONSerialization instead of your third party framework. Did I say that the whole adapter classes run under a hundred lines of code?
For example, if you call JSONValue of json-framework in your code like this,

NSString *jsonString = [NSString stringWithContentsOfURL:@http://example.com/test.json"];
[jsonString JSONValue];

my adapter routes the “JSONValue” extension method to Apple’s implementation. The adapter classes have similar implementations for every similar category method in the framework.

Source Code

The source code is pretty elementary right now and supports only json-framework. and I’m maintaining them on Github here.

https://github.com/MugunthKumar/third-party-json-adapters

Expecting volunteers to write equivalent adapters for other frameworks (especially for frameworks that are slower than Apple’s)

–

Mugunth

Follow me on Twitter

In App Purchases: Troubleshooting Code=0 “Cannot connect to iTunes Store” (SKErrorUnknown) When using MKStoreKit or any other equivalent framework or regular...

MKBlog

iOS5 Programming: Pushing the limits book updates

Some thoughts on iOS and your privacy (Address Book)

Who else is doing it?

What should Apple do?

How can you help?

iOS Tutorial: Image Cache and Loading Thumbnails using MKNetworkKit

Contents

Step 1: Create a Flickr Engine

Step 2: Create a custom cache directory for storing the cached Flickr thumbanils

Step 3: Write a method to list flickr images for a specified tag

Step 4: Create a custom table view cell for loading flickr images

Step 5: Clear previously loaded images if the cell will be reused

Step 6: Fade in thumbnails like the Apple trailers app

Source Code

Migrating your code to Objective-C ARC

Contents

What is ARC

Problems with the current model.

Garbage collection

Reference Counting

Automatic Reference Counting

Compiler level feature

Also a run time feature

ARC Ownership qualifiers

ARC knows more Objective-C than you

Toll-free bridging

How does ARC work internally?

ARC front end

ARC optimizer

The actual Migration using Xcode 4.2

Common ARC migration errors

Cast of Objective-C pointer to C Pointer type

performSelector may cause a leak because its selector is unknown

Receiver type “*” doesn’t declare the method with selector “*”

Common workarounds that you use in ARC on code that otherwise looks normal

Capturing “*” strongly is likely to lead to a retain cycle

Avoiding retain cycles using __block

That last question

When should you migrate?

Where to go from here?

iOS Tutorial: Advanced Networking with MKNetworkKit

Contents

Caching your responses, the wrong way

Say hello to MKNetworkKit

Behind the scenes

Freezing Operations

Advanced Tips

Friction-free authentication

Custom Authentication

Overriding MKNetworkEngine

Overriding MKNetworkOperation

Image Cache with MKNetworkEngine

Source Code

iOS Framework: Introducing MKNetworkKit

Contents

What is MKNetworkKit?

Features

Super light-weight

Single Shared Queue for your entire application.

Showing the Network Activity Indicator correctly

Auto queue sizing

Auto caching

Operation freezing

Performs exactly one operation for similar requests

Image Caching

Performance

Full support for Objective-C ARC

How to use

Adding the MKNetworkKit

Classes in MKNetworkKit

Example 1:

Example 2:

Example 3:

Example 4:

Caching operations

Freezing operations

Convenience methods in MKNetworkOperation

Convenience macros

A note on GCD

Receiver type “” doesn’t declare the method with selector “”