MKBlog

Panacea for slow Xcode

2012-04-02T20:24:44-07:00

Wrote a quick and dirty script for clearing “nonsense” files with a click.

Copy the contents of this script to a file on your Mac.
Save it to a file named, say, cleanup.sh, preferably in your home directory (or the directory where your terminal opens up by default)
Set execute permissions to it by typing,
chmod +x cleanup.sh

You are done.

Whenever Xcode “misbehaves”, just execute this script. It cleans up your Simulator and derived data directory for you.
Updates welcome.

–
Mugunth

Follow me on Twitter

No related posts.

RESTful API Server – Doing it the right way (Part 2)

2012-04-02T04:30:05-07:00

In the part 1 of the post, I introduced the RESTful principle and explained how to architecture your server code so as to ensure easier versioning and deprecation of your API. In this part, I’m going to talk briefly about HATEOAS and hypermedia and then show you the role it plays in a native mobile client development. But the crux of this post is going to be centered around how to implement caching (or rather server side support for caching). Target audience include, server developers and to some extent, iOS or any mobile platform developers.

HTTP APIs, REST and HATEOAS
HATEOAS - Hypermedia as the Engine of Application State
HATEOAS for your next API?
Caching
Recommended Reading

HTTP APIs, REST and HATEOAS

In today’s world, HTTP APIs can be classified into

Web Services
RPC URI Tunnelling
HTTP-based Type 1
HTTP-based Type 2
REST

Here is a very good explanation by Jon Algermissen. Unfortunately, every API provider calls their service as “RESTful” despite otherwise.

So what really is a RESTful server? Any API server that is hypertext/hypermedia driven is RESTful. That means, the developer/client application should be able to discover “other available resources” from the API’s root URL. This, is in fact the most important constraint for implementing RESTful APIs. Additionally, a pure RESTful server is one that adheres to HATEOAS constraint.

HATEOAS – Hypermedia as the Engine of Application State

The two main constraints that you should follow for implementing HATEOAS are,

1. Serve only hypermedia resources.

A hypermedia resource is one that contains content and controls (hyperlinks) to other hypermedia resources. JSON (application/json) is NOT a hypermedia resource. (Again, there are a lot of RESTful, HATEOAS servers that serve JSONs) However, you can add additional keys to the JSON making it behave like a hypermedia resource. (For ex: a href key for linking the resource to an associated thumbnail image)

2. Single point of entry for the client application.

From the home page of the API, subsequent “GET” endpoints are embedded as URLs (or links) and subsequent “POST”, “PUT” or “DELETE” endpoints are embedded as forms.

The main advantage of adhering to these two HATEOAS constraint is easier documentation.

HATEOAS for your next API?

A big NO
Why do I say this? In the past, APIs were predominantly written for consumption in a web based application. These servers normally serves XHTML and applications run on a web browser. A web browser is a “client”, much similar to your mobile (iOS/Android/Windows Phone) client that can parse hypermedia resources and understand HTML forms and “knows” how to present a form to the user. For mobile client implementations, when your RESTful server’s resource has a form that you could submit, you can’t (at least easily) convert it to a native control available on the platform. None of the platform vendors, Apple/Google or Microsoft has built in support for converting a XHTML form to a UIViewController (on iOS) or a Intent(on Android) or a Silverlight Page(on Windows Phone).

My recommendation is to go with resource representation for all “GET” entries and expose controller endpoints (instead of forms) for all POST/PUT and DELETE entries. (Example: /friends/add or /venue/checkin) The controller endpoints can (should) be embedded in other responses (so that the client or the client developer can discover it). Of course, that breaks REST, but it’s ok. It’s better to make products that work, than adhering to standards that offer zero benefits. (This will probably make our API a HTTP-based Type 2 API).

Caching

Let’s talk about caching. Caching, as you might think, is predominantly a client side (or intermediate proxy) thing. But do you know that a little bit of support from the server side, you can ensure that your API server adheres to conventions expected by a intermediate caching proxies? This in turn means, you will be benefited from free load balancing provided by them. In fact, caching is described in section 13 of the HTTP spec. Here is a link to it.

Art Taylor, tweeted this couple of months ago.

I have two new rules.1) If your application is slow, add caching.2) If your application is buggy, remove caching.#Why_is_caching_so_hard

— art taylor (@reeses) January 12, 2012

But believe me, caching can be done just right without getting into trouble like this. Two important principles I would recommend that you adhere to are,

1. Don’t rollout custom caching schemes on your client.

2. Understand the basic caching principles explained in HTTP 1.1 RFC specification. The RFC explains two kinds of caching models. Expiration model and Validation model.

In any client/server application, the server is the authoritative source of information. When you download a resource (a page or a response) from a API server, the server sends some “hints” to the client on how to cache them. The server authoritatively dictates if (and when) the client should expire the cache. These “hints” can be sent either programmatically or by a server side configuration. Expiration model is usually a configuration on the server (nginx.conf or equivalent) where as validation model requires some programming effort from the server developer. The server developer should determine when to use validation and when to use expiration based on the kind of resource. Expiration model is normally used when the server can make a reliable guess on how long will a given resource be valid. Validation model is used for everything else. Later, I’ll show you how to code your server for both these models. Once you understand the two models, I’ll explain when to you use which model.

Expiration model

Let’s first look at a very common cache control configuration. If you have configured nginx, you would have added something like this to your nginx.conf. (The Apache equivalent is written into the .htaccess file.)

location ~ \.(jpg|gif|png|ico|jpeg|css|swf)$ {
                expires 7d;
        }

nginx translates this config to an equivalent HTTP cache header. In this case, the server sends a “Expires” or “Cache-Control: max-age=n” header for all images (amongst others) and expects the client to cache them for 7 days. This means, you normally don’t have to re-request the same content again within the next 7 days. Every major web browser (and intermediate proxies) respects this header and works as expected. Unfortunately, a vast majority of the open source image caching frameworks for iOS, including the popular SDWebImage, uses a built in cache control mechanism, that deletes images after n days. The problem here is, these frameworks don’t cater to validation model and your mobile client application that uses these frameworks must resort to hacks.

Let me show you an example where this could go wrong. Lets’ go back to our “next Facebook” app. When your user uploads an avatar image, he expects to see the changes propagated on all the views. Some clever developers empty the cache after the call to update-profile-image succeeds. (This means, every view controller now have to load the content from the server again). Everything goes well and you have successfully cheated your project manager and every view controller now shows the latest profile picture. However, it doesn’t eliminate the problem completely. The user’s new profile picture is visible to his friends only after 7 days. Clearly unacceptable. So how do you solve this? As I already told, you have to accept the fact that the server is the only authoritative source for the latest data. Don’t use dirty tricks on the client to expire the cache.

Validation model

Both Facebook and Twitter solve the problem of expiring profile images (after a new image is uploaded) using validation model. In a validation model, the server sends an identifier unique to the requested resource and the client caches both the identifier and the response. In HTTP parlance, this unique identifier is called as an ETag. When you make a second request to the same resource, you should send this ETag. The server uses this identifier to check if the resource you requested has changed (remember, the server is the authoritative source). If the resource has indeed changed, it sends you the latest copy. Otherwise, it sends a 304 Not Modified. Validation model requires programming effort on both client and server. I’ll walk you through both in the next section.

Client side coding

As a matter of fact, on iOS, if you use MKNetworkKit, it does all these automatically for you. But for the sake of Android and Windows Phone developers, I’ll explain how this should be implemented.

The validation model uses ETag and Last-Modified HTTP Headers. Client side support for validation model is easier than server side implementation. If you received a ETag with a resource, when you make a second request to the same resource, send the ETag in “IF-NONE-MATCH” header. Alternatively, if you received a “Last-Modified” with a resource, send it in “IF-MODIFIED-SINCE” header on subsequent requests. Again, the server determines when to use “ETags” and when to use “Last-Modified”

Implementing expiration model is easy. Just calculate the expiry date based on the headers, “Expires” or “Cache-Control:max-age-n” and delete the cache after this day.

Server side coding

ETag based caching

ETags are usually calculated on the server using object hashing algorithms. (Most high level server side languages like Java/C#/Scala has methods to hash an object). Before serializing the responses, the server should compute the object hash and add this value to the header as ETag. Now, If the client has indeed sent a IF-NONE-MATCH in the request and that ETag matches with what you have computed, send a 304 Not Modified. Otherwise, serialize your response and send the new ETag.

Last-Modified based caching

Last-Modified implementation is slightly tricky. Let’s assume that you have an endpoint that points to thelist of friends resource.

http://api.mynextfacebook.com/friends/

When using ETags, you computed the hash of the array of friends. If you are using Last-Modified, you should send the Last-Modified date of this resource. Because this resource is a list; this date could actually mean the date when the user last accepted a new friend. It requires the server developer to store the last modified date for every user in the database. Slightly tricky than ETags, but there is a huge performance advantage.
When the client requests this resource for the first time, you send the complete list of friends. Subsequent requests from client will now have a “IF-MODIFIED-SINCE” header. Your server should be programmed to send only the list of friends that are added after this date. The database fetching pseudo code that was previously something like this,

select * from friends

becomes,

select * from friends where friendedDate > IF-MODIFIED-SINCE

If the database select returns zero results, send a 304 Not Modified. So if the user has 300 friends but only two of them are new friends, serialize and send only those two records back to the client. Your database fetching time and the resource payload is reduced by a huge margin.

Of course, this is a super simplified pseudo code. Server developer will probably have a headache when you support unfriending (deletion) or blocking friends. The server should be able to send hints using which the client should be able to tell which all friends were newly added and which all were deleted. This technique in fact requires additional effort on the server side.

Choosing a caching model for your resource

Whew! That was some heavy stuff. I’m now going to establish some ground rules on when to use what type of caching mechanism.

1) All static images should be served using a expiration model.

2) All dynamically changeable data should be served using a validation model.

3) If your dynamic data is a list, you should use Last-Modified based validation model. (For example: /friends).
Other wise, you should use ETag based validation model (For example: /friends/firstname.lastname

4) Images or any resource that might be updated by the user (like profile image) should again use the ETag based validation model. Though they are images, they are not static in your application (like your company logo). Moreover, you cannot reliably calculate the expiry date for such a resource. The other (slightly easier to implement but a bit hackish) way is to use a URL fault. URL fault works like this.
When you send a avatar URL embedded in a resource, make sure that, some part of the URL is dynamic. That is instead of representing an avatar URL as

http://images.mynextfacebook.com/person/firstname.lastname/avatar

represent it like this

http://images.mynextfacebook.com/person/firstname.lastname/avatar/<randomhash>

Ensure that the random hash changes when the user updates the image. The API that sends the list of friends resource will now have a different URL for friends who updated their image. Changes to profile images happen almost instantly!

If both server and client adheres to already established caching standards, your iOS app and your product can “fly”. What I did in this post is a mere explanation of those standards which aren’t followed by a vast majority of developers.

That ends this part of the post. In the last and final part, we will discuss about how to communicate errors and do error handling properly and support internationalization for your application.

Adding Twitter support (iOS 5 with oAuth fallback) to your iOS App with RSOAuthEngine

2012-03-14T07:05:15-07:00

Till today, the two most commonly used ways (without writing tediously long code) to integrate Twitter connect to your app is

Ben Gottlieb’s Twitter OAuth library
By using ShareKit

The only problem I have with both these libraries is that, they are bloated. You end up adding at least 20 classes (more than 50 files in the first case and even more if you go with ShareKit).

Call me a person with Not Invented Here syndrome, but I hate adding third party code unless it offers considerable number of features that is critical to the app’s functionality. Today, when working on a code base, I deleted over 52 files that adds a functionality that allows a user to tweet “achievements” from within the app.

Deleting Twitter Sharing Code means getting rid of 52 files in your app

To me, this is a bloat. Same goes with ShareKit. You will use every single ShareKit supported social network only if you are writing a Google Reader (or any RSS reader) app or a Instapaper competitor. In most apps, Facebook and Twitter sharing is all that you need. 52 files for that, is a BLOAT.

Introducing RSOAuthEngine

RSOAuthEngine, in the words of the original author (Rodrigo Sieiro), is a ARC based OAuth engine for MKNetworkKit.

He originally posted his RSOAuthEngine on Github about a month ago. It is possibly the leanest implementation of Twitter oAuth I’ve ever seen. His sample code also contained a demo on how to use RSOAuthEngine with Twitter and with Instapaper.

The fork

Today, I forked his code and added a neat and important feature, iOS 5 Twitter Accounts support. I added a category class and a config file to his code and this is how it looks now.

RSOAuthEngine based Twitter Connect ~ 10 files

Just 10 files (3 classes and a category addition) that enables your app users to send tweets from the app.
Since MKNetworkKit provides operation freezing by default, users can send tweets even when they are offline. Those tweets are queued, frozen and sent when the connectivity is back again.

Using RSOAuthEngine

Step 1:
Clone the RSOAuthEngine fork from github. Add the RSOauthEngine code by dragging the directories RSOAuthEngine, Twitter and UIActionSheet+MKAdditions. If you are not using MKNetworkKit, you might have to add that too.

Step 2: Add the Twitter.framework and Account.Framework and weak link it. Weak linking ensures that your app doesn’t crash on devices running iOS 4 and below. If you are adding MKNetworkKit for the first time, you might want to add the related frameworks as well. See this blog post for details.

Step 3: Open RSTwitterConfigs.h and set the oAuth consumer key and consumer secret from twitter.
Fill in your callback URL. All these information should match exactly to the app you created on twitter’s website

Step 4: Initialize the RSTwitterEngine in your app delegate like this.

 self.twitterEngine = [[RSTwitterEngine alloc] initWithStatusChangedHandler:^(NSString *newStatus) {
 
    DLog(@"%@", newStatus);
  }];

Logging is purely optional.

Step 5: To send a tweet, set the presenting view controller of the twitter engine to the current view controller (where the “tweet/share button” is present) and call the sendTweet method.

ApplicationDelegate.twitterEngine.presentingViewController = self;
 
  [ApplicationDelegate.twitterEngine sendTweet:@"Hi there" withCompletionBlock:^(NSError *error) {
 
   }];

The magic behind the scenes

The fork I wrote automatically authenticates the user the first time you call the sendTweet:withCompletionBlock method. It presents a UIViewController with a UIWebView that shows the Twitter oAuth login page, extracts the credentials and saves it. The true magic is, on iOS 5+ devices, if the user has configured his twitter account on the Settings app, it shows the Twitter account authorization request and uses the built-in twitter account.

Accessing iOS Twitter Accounts

If the user has configured multiple twitter accounts, he sees

The code automatically shows this dialog when multiple iOS Twitter Accounts are available

If there is exactly 1 account, that account is automatically used without further prompts.

The fallback

If there are no accounts configured or if the user is running iOS 4.3 or lower, the code falls back to traditional oAuth and shows a web view based authentication form.

Once the authentication workflow is done, the tweet is sent. Authentication information is saved and reused in subsequent calls to sendTweet:withCompletionBlock:.

The complete twitter sharing integration is done with just 3 classes. This, to me, is arguably the most leanest twitter sharing code in the Interwebs.

Fork it share it and do whatever you want. The code (both mine and Rodrigo’s) is licensed under MIT license.

On similar lines, I just finished a Facebook Sharing library

–
Mugunth

Follow me on Twitter

No related posts.

ARC retain cycles and blocks

2012-03-05T07:33:08-08:00

I wrote a method to add blocks based completion handler support to AVAudioPlayer. The calling code looks like this.

__block MKAudioPlayer *player = [[MKAudioPlayer alloc] initWithResourceName:@"Test.mp3"];
[player playWithCompletionHandler:^{
	player = nil;
}];

The playWithCompletionHandler method naively copies the block into a property like this.

-(void) playWithCompletionHandler:(VoidBlock) block {
 
    self.audioCompletedBlock = block;
    [self.thePlayer play];
}

Smell something? No? Not yet?

Let’s consider the other case where the block is a property and you set the completion handler like this

__block MKAudioPlayer *player = [[MKAudioPlayer alloc] initWithResourceName:@"Test.mp3"];
player.completionHandler = ^{
	player = nil;
};
[player play];

In this case, LLVM compiler is clever enough to warn you. However, in the previous case, you end up with a retain cycle when the block copies the MKAudioPlayer reference within the playWithCompletionHandler method.

Neither the LLVM compiler nor the static analyzer warn you about this. And that doesn’t mean everything is fine. The first block of code leaks memory because of a retain cycle created when you copy the block.

BEWARE OF RETAIN CYCLES! With ARC, It just got a little more difficult to debug problems related to memory leaks.

I noted this problem a while ago when brianensorapps tweeted me a problem with my sample code and wrote this post after reading this tweet.

Retain cycles caused by blocks have become one of the hardest problems in Cocoa programming in my opinion.

— Ole Begemann (@olebegemann) March 5, 2012

I seriously wish Apple improves the LLVM static analyzer to avoid true negatives and catch, if possible, all retain cycles.

–
Mugunth

Follow me on Twitter

No related posts.

A note on MKInfoPanelDemo

2012-03-01T17:52:24-08:00

MKInfoPanel is a open source class written by me (that was available on Github) that attempts to mimic the non modal alerts used in Tweetbot.

Yesterday, Tapbots tweeted that MKInfoPanelDemo, the open source iOS project, is infringing their copyrights and they weren’t happy about the project on Github. A DMCA notice was sent to Github (so far no one from Github contacted me on that) to remove the project, but I removed it before hand just to be on the safer side.

What you should know

If you are using that on your projects or your client projects, please be assured that all the assets and colors used were recreated by me and not just a copy of what is shipped with Tapbot’s application. Sure, it looks similar to Tweetbot’s implementation because it was an imitation of their work, much like Quad Curve Menu, or Clear app’s open source implementation or the infamous pull-to-refresh implementation by enormego.

All assets inside any IPA file are byte swapped because PNG optimization is enabled by default. This means, you cannot lift a PNG file and re-use in your project at least easily (at least without reswapping those bits). It’s far more easier to recreate them from scratch (come on, it’s just an exclamation mark inside a triangle)

I’m not a lawyer, but the allegation that the project infringes their rights is completely baseless and wrong. Since the guys behind Tweetbot are not cool like Loren Brichter or Realmac Software, I’ve decided to remove the code from Github.

You can always get the code for educational purposes from here.

Source Code
MKInfoPanelDemo

Thanks for those innumerable DMs that you guys sent on how people would have mis-understood me for pulling the project.

Update:
The code is available again on Github following this tweet.

@mugunthkumar @Cocoanetics again you’re welcome to re-submit the code, AFAIK the DCMA is no more.

— Paul Haddad (@tapbot_paul) March 2, 2012

Huge thanks to @cocoanetics for making this happen.
–
Mugunth

Follow me on Twitter

No related posts.

RESTful API Server – Doing it the right way (Part 1)

2012-03-01T07:01:25-08:00

In 2007, Steve Jobs announced the iPhone that revolutionized the technology industry and changed the way we work and do business. It is 2012 now and increasingly, more and more websites are offering native iOS and Android clients as front ends to their service. Not all startups have the funding to develop apps in addition to their core product. To increase the adoption rate of their product, these companies, release a public API that developers can use to build apps on top. Twitter was probably the first company to be “API first” and now increasingly more number of companies are following this strategy as it is really a great way to build an ecosystem around your product.

Startup life is full of pivots. If you code base cannot support the pivoting decisions you make, you lose. A server code that is nimble enough to adapt to business needs, decides the make or break of a startup. Successful startups are not those that come up with great ideas, but those that are good at executing them. Success of a startup depends on the success of their product, whether it’s their iOS app or their service or their API. In my past 3 years, I’ve worked on a variety of iOS apps (mostly for startups) consuming web services and in this blog, I’ve tried to consolidate my knowledge and show you the best practices that you should adopt when developing a RESTful API. A good RESTful API is one that is not resistive to changes.

Target Audience
Structure and Organization
RESTful constraints
API documentation
- Documentation
  - Documenting Request Parameters
  - Documenting Response Parameters
Reasons to version and deprecate your API
- Versioning
  - Versioned URL paradigm
  - Versioned model paradigm
- Deprecation
Caching
Error handling & Internationalization of your API

Target Audience

This blog post is targeted for readers who have intermediate to advanced knowledge in developing RESTful APIs and some basic knowledge of any object oriented (or functional) server side programming language like Java/Ruby/Scala. (Note: I intentionally ignored PHP or Programmable Hyperlinked Pasta)

Structure and Organization

The post is quite detailed and the first part explains basics of REST and the second part explains documenting and versioning your API. The first part is for beginners. The second part is for pros. I know, you are a pro. So, here is a link to jump ahead to API documentation section right away! This is probably where you should start if you think this post is a tl;dr.

RESTful constraints

A RESTful server is one that conforms to the REST constraints. Here is a Wikipedia article on REST. When you develop a API that would predominantly be consumed by a mobile device, following and understanding the three most important constraints would be helpful, not just in developing the API, but in maintaining it and making changes moving forward. Let me explain.

Statelessness

The first constraint is statelessness. Put in simple words, a RESTful server should not contain contextual information about the client. A client, on the other hand, can maintain context of the server’s state though. In other words, you shouldn’t make your server remember the state of a mobile device using an API.

Let’s imagine that your startup is the “next Facebook”. A good example of where a developer would potentially make such mistakes is to expose an API that allows a mobile device to set the last read item on a stream (say a Facebook feed). API endpoint that normally returns the feed (say /feed) will now return items that are new after this last read item. Sounds clever right? You “optimize” the data transfer between the client and server right? Wrong.

What could possibly go wrong in this case is when the user accesses your service from two or three devices and one device sets the last read status and the other device doesn’t have a way to download items that was already read on other devices.

Stateless means, the data returned for a specific API call should not be dependent on calls that are made before it.

The right way to optimize this call, is to pass the timestamp of the last read feed item to the server along with the API call that returns the feed (/feed?lastFeed=20120228). There are other, more standard way of doing this using HTTP Modified Since header. But we will leave that for now. I’ll discuss this in part 2 of this post.

The client, however can (should) remember access tokens generated on the server and send it other APIs that require them.

Cacheable and a Layered architecture

The second constraint is to provide a certainty to the client that a response can be cached and reused for a set period of time without making round trips to server. This client can be the real mobile client or any intermediate proxy server. I will explain more about caching later in part 2 of this post.

Client-server separation of concerns and a uniform interface

A RESTful server should abstract and hide away as much implementation details as possible from the client. That is, the client shouldn’t bother (or know) about what database the server uses or how many load balancers are currently active and other such stuff. Maintaining a good separation of concerns helps in scaling when your product becomes “viral”.

That’s probably the three most important constraints you should have in mind while developing a RESTful server. There are three other minor constraints, but they all overlap with what we discussed here.

REST Requests and the four HTTP methods

GET
POST
PUT
DELETE

Cacheable constraint and GET requests

Key takeaway from this is, GET method doesn’t alter the server state. This inherently means your requests could be cached by any intermediate proxies (think: reduced load). So as a server developer, you shouldn’t expose a “GET” method that updates data in your database. It breaks RESTful philosophy specifically the second constraint I talked about earlier. Your “GET” methods should not even update a access log or insert a record that maintains the “last logged in” time. If you are updating your database, it should be always be a POST/PUT method.

That POST vs PUT debate

The HTTP 1.1 specification says, PUT is idempotent. This means, the client can make multiple PUT requests to the same URI and yet doesn’t create/update duplicate records.

Assignment operations are a good example of idempotent operation.

String userId = this.request["USER_ID"];

Even if this operation is executed twice or three times, there is no harm (other than lost CPU cycles).

POST on the other hand is not idempotent. It’s like an increment operator. You should use POST or PUT based on whether or not the action performed is idempotent. In programmer’s parlance, if the client “knows” the URL of the object that would be created, you should use PUT. If the client knows the URL of the creator/factory, use POST.

PUT www.example.com/post/1234

Use PUT if the client knows the URI that would be created as a result of the call. Even if the client calls this PUT method multiple times, there is no harm or no duplicate records created.

POST www.example.com/createpost

Use POST if the server creates the unique key and sends results back to the client. Duplicate records will be created when the call is repeated later on with the same parameters.

Read this answer on Stackoverflow for more.

DELETE method

DELETE is straight forward. It’s again idempotent like PUT, and should be used to delete a record if it is present.

REST Responses

Responses from your RESTful server can either use XML or JSON. Personally, I would prefer JSON over XML as JSON is less verbose and data transferred is usually less compared to the same response in XML format. The difference might be in the order of a few hundred kilobytes, but given the speed of 3G networks and intermittent mobile data connectivity, these few hundred kilobyte changes can have a huge impact when downloading the response data.

Authentication

Authentication should be done over https and the client should send the password encrypted using some cryptographic algorithm. Getting a sha1 hash of a NSString in Objective-C is fairly straight forward and the following code illustrates this.

- (NSString *) sha1
{
	const char *cstr = [self cStringUsingEncoding:NSUTF8StringEncoding];
	NSData *data = [NSData dataWithBytes:cstr length:self.length];
 
	uint8_t digest[CC_SHA1_DIGEST_LENGTH];
 
	CC_SHA1(data.bytes, data.length, digest);
 
	NSMutableString* output = [NSMutableString stringWithCapacity:CC_SHA1_DIGEST_LENGTH * 2];
 
	for(int i = 0; i <; CC_SHA1_DIGEST_LENGTH; i++)
		[output appendFormat:@"%02x", digest[i]];
 
	return output;
}

The server should match the encrypted password with the encrypted password stored previously on the server. In any case, you should never transfer passwords in plain text from the client to the server. There is NO EXCEPTION to this rule. The day your users come to know that you are storing passwords as plain text will probably be the day your startup dies. Trust that is once lost can never be gotten back.

RFC 2617 specifies two ways to authenticate with a HTTP server. The first is Basic Access Authentication and the second is Digest Authentication. For internal mobile client use, Basic or Digest authentication is sufficient and most server side (and client side) languages have built in mechanism for implementing this authentication scheme.
If you are planning to make your API public, you should consider using oAuth or better oAuth 2.0. oAuth allows your end users to share the content created within your application with other third party vendors without handling over the keys (username/password). oAuth also allows user to be in full control over what is shared and what is rights do the requesting third party application has.

Facebook Graph API is, by and large, the biggest implementation of oAuth to date. By using oAuth, a Facebook user can share photos with a third party application without sharing other personal information and his access details (username/password). A user can also revoke access to a “rogue” third party application without changing his password.

So far, I talked about the basics of REST. Now lets dive into the meat of the post. In the subsequent sections I’ll talk about best practices that you should follow when documenting, versioning and deprecating your API.

API documentation

The worst documentation that a server developer could write is the one that contains a laundry list of API endpoints, the parameters that are required and the corresponding response from the server. The problem with this is, it’s too difficult to make incremental changes to the server and changing response data as the product evolves becomes a nightmare. I’m proposing some suggestions on how to document your API so that a client developer would understand you better. In the course of time, that will also help you in becoming a better server developer!

Documentation

The first step, I would recommend, is to start thinking about your top level model objects before you start the documentation. Then think about actions that can be done on these objects. The foursquare API documentation is a good example to start with. They have a set of top level objects like venues, users and so on. They also have a set of actions that can be performed on these objects. Once you know the top level objects and actions in your product, designing the endpoints becomes easier and clearer. For example, to “add” a new venue, you would probably have to call a method similar to /venues/add

Document every member of the top level objects in your documentation. Next, document your request and responses using these top level objects rather than raw primitive data types. Instead of writing, this API would return three strings, the first being the id, second name and third description, write that this API would return a venue model.

Documenting Request Parameters

Let’s assume that you have a API that allows the user to login with a Facebook token. Let’s call that api as /login.

Request

/login

Headers

Authorization: Token XXXXX
User-Agent: MyGreatApp/1.0
Accept: application/json
Accept-Encoding: compress, gzip

Parameters

Encoding type – application/x-www-form-urlencoded

token – “Facebook Auth Token” (mandatory)

profileInfo = “json string containing public profile information from Facebook” (optional)

This profileInfo is a top-level object. Since you have already documented this object’s internal structure, mentioning this alone would suffice.

If your server uses the same Accept, Accept-Encoding and parameter encoding, you can document it separately instead of repeating them everywhere.

Documenting Response Parameters

Responses from API should be documented based on the top level model objects. Quoting from the same foursquare example, the /venue/#venueid# method returns a complete venue model.

In case your model is big and you want to reduce the payload, consider creating a compact model. You should use this for APIs that return a list of model objects. Foursquare’s API does this as well. Their search API returns an array of compact venue

Exchanging ideas, documenting or letting other developers know what you will return has just gotten easier when you document your API using model objects. The most important takeaway from this section is to treat this document as a contract between you, the server developer and client developers (iOS/Android/Windows Phone/Whatever)

Reasons to version and deprecate your API

Prior to mobile applications, in the era of Web 2.0 applications, API versioning was never a problem. Both the client (Javascript/AJAX front-end) and the server was deployed at the same time. Consumers (your customers) always use the latest front-end client to access your system. Since you are the company that writes both the client and server, you have full control over how to use your API and changes to the API can always be implemented immediately on the front-end. Unfortunately, with native clients this is not possible. You might deploy API version 2 assuming everything will go well, but will blow up on older versions of your iOS apps because there would be still users using the older version of iPhone app even after you pushed an update through App Store. Some companies resort to using push notification to pester users to update their app. This will only end up in losing that customer. I have seen many many iPhones that have more than a 100 app updates pending. There is a pretty good chance that your app might be one of them. You should always be prepared for versioning the API and deprecate them as and when it’s proper to do so. But do support your APIs for at least three months.

Versioning

Deploying your server code on a different directory and using a different URL endpoint doesn’t automatically mean you have effectively migrated your server code.
That’s
http://example.com/api/v1 will be used by version 1.0 of the app and your latest and greatest version 2.0 of the app will use http://example.com/api/v2

When you make an update, you almost and always make changes to internal data structures, and model objects within your server. That includes changes to the database (adding or removing columns). To make things clear, let’s assume that your “next Facebook” app has a API called /feed that returns “Feed” objects.
Today, as of version 1, your Feed object contains a URL to a person’s picture (avatarURL), the person name (personName) the feed entry text (feedEntryText) and the timestamp (timeStamp) of the news entry.
Later on, in your version 2, you introduce a feature where you allow advertisers to market their products in the feed. Now, your feed object contains, let’s say, a new field called “sourceName” that super cedes person name on the UI. That’s, the app should display “sourceName”, instead of “personName”. Since the UI no longer need to display personName when “sourceName” is present, you decide not to send “personName” when “sourceName” is present. This all sounds good till the older version, version 1 of your application hits your newly deployed server. It starts displaying your advertised entries without a title since “personName” is missing. A “clever” way of handling this, is to send both “personName” and “sourceName”. But, my friend, life isn’t always that easy. As a developer, you can’t keep track of every single change that has ever been made for every single model object in your class. It’s just not an efficient way of doing it and 6 months later, you will almost forget why something was added to your code.

Thinking back, in web 2.0, this wasn’t a problem at all. The Javascript front-end would have been immediately updated to cater to the API changes. However iOS apps are disconnected unlike a web application. It’s the user’s prerogative to update it.

I have a very elegant solution to propose for this kind of tricky situation.

Versioned URL paradigm

First is to differentiate multiple versions using the URL.
http://api.example.com/v1/feeds will be consumed by version 1 of the iOS app and
http://api.example.com/v2/feeds will be consumed by version 2 of the iOS app.

While this method sounds good, you can’t go on creating duplicate copies of your deployed code base for every single change you make to the output format. I recommend this only when you make a huge breaking release/change. For minor changes, consider versioning your models.

Versioned model paradigm

I showed you how to document your models a while ago. Consider this document as a contractual agreement between the server and client developer. You should never make a change to this model without changing the version. This means, in our previous case, there would be two models, Feed1 and Feed2.
Feed2 has sourceName and outputs sourceName and removes personName when sourceName is present.
Feed1 behavior remains same like how it was agreed upon when documented.

The request controller code flow will look closely similar to this.

RESTful controller pseudo-code flow chart

You should consider moving the instantiation code into the class as a factory method. The controller pseudo-code should look similar to this

Feed myFeedObject = Feed.createFeedObject("1.0");
myFeedObject.populateWithDBObject(FeedDao* feedDaoObject);

Whether it is 1.0 or 2.0 is decided by the controller from the UserAgent string.

Update:
Rather than depending on version numbers in UserAgent string, the client should send the version number in Accept header.
So instead of sending

Accept: application/json

you should send

Accept: application/myservice.1.0+json

This way, you have the ability to request a different version of response object for every REST resource you request.
Thanks for hacker news readers who sent this to me.

The controller asks the Feed factory method to create the correct feed object based on the incoming request (all requests have UserAgent that looks like AppName/1.0) and based on the version of the client. When you implement your server like this, *any* change is easy. Making a change to your server without breaking existing contracts will be a breeze. Just create new models, make change to the factory method to instantiate this new model for newer versions and you are set to go!

With this architecture in place, your version 1 and version 2 of the app can still talk to the same server. Your controller will render the version 1 object to the older client and version 2 object to the newer client.

Deprecation

With the versioned model paradigm I proposed, deprecating your API gets a lot more easier. This is very important when you make your API public at a later stage.
When you make a major version update, cleanup all the factory methods in your models based on your business decisions.
If you decide not to support version 1 of the iOS app with the release of version 3 of the API, remove the associated models, remove the lines that instantiate version 1 of the model (in your factory method) and you are good to go.

Versioning and deprecation goes a long way in ensuring the longevity of your company and the product by ensuring that you will always be nimble enough for most of the pivoting decisions made by the business owner. Businesses die when they cannot pivot. Usually resistance to pivoting comes internally from the technical team. This technique should solve that problem.

Caching

The next important performance improvement that you should focus on when you build an API is to support caching. If you are like most other and think caching is a client side thing, think again. Part 2 of this blog post explains how to support caching based on HTTP 1.1 standards.

Error handling & Internationalization of your API

Notifying your client of the kind of errors that happened on server is as important as sending the correct data. I’ll explain about error handling and Internationalization of your API in part 3 of this post. Not making any promises, but this will surely take some time.

–
Mugunth

Follow me on Twitter

RESTful API Server – Doing it the right way (Part 2) In the part 1 of the post, I introduced the...

Ownership of presented view controllers with and without ARC

2012-02-25T19:58:42-08:00

Yesterday, I tweeted a classical design issue on who should own a view controller.

The controller that presents a modal controller should dismiss it. Don’t do [self dismissModalViewControllerAnimated:NO] in the child.

— Mugunth Kumar () (@mugunthkumar) February 25, 2012

Calling [self dismissModalViewControllerAnimated:NO] on child is like committing seppuku. A child shouldn’t kill itself.

— Mugunth Kumar () (@mugunthkumar) February 25, 2012

The negative replies I received to the tweet were phenomenal that I had to write this post explaining the “why” behind the tweet.

Memory management with pushed view controllers

Things are straight forward when you “push” a view controller to the navigation stack. The UINavigationController retains/takes ownership of your view controller and you can forget about it. viewDidAppear/viewDidDisappear methods are called notifying the controllers to prepare itself.

Memory management with presented view controllers

However, this is not the case when you present a view controller modally.

Memory Management pre ARC

Lets see how memory management worked in the pre-ARC era (read: last year). Before ARC, there are two ways to retain the child view controller. The first (and slightly cumbersome) method is to have a retain property for every child controller, on the parent controller.

Method 1

@interface MasterViewController
@property(nonatomic, retain) ChildViewController *child;
@end

Presenting the view modally requires you to allocate it and then present it.

self.child = [[ChildViewController alloc] initWith…];
self.child.delegate = self;
[self.navigationController presentModalViewController:self.child animated:YES]
…
…

Implement the delegates

-(void) childViewController:(UIViewController*) childController didFinishWithResult {
 
  [self.child dismissModalViewControllerAnimated:YES];
  self.child.delegate = nil;
  self.child = nil;
}

Method 2

The second method is like the classical email sheet, where the didFinishWithResult delegate sends a pointer to self.

-(void) childViewController:(UIViewController*) childController didFinishWithResult {
 
[childController dismissModalViewControllerAnimated:YES];
[childController release];
}

The only advantage of this method is, you don’t need to retain a pointer to the child in the parent view controller.
You allocate the child view controller when you show it and release it when the method returns. However, this method isn’t going to work with ARC. You cannot allocate a pointer in one method and release it in another without the parent specifying a ownership qualifier on that pointer. That means we have only one option, retain a strong reference to the child.

Memory Management with ARC

Memory management with ARC is going to be exactly similar to method 1 that I showed you earlier, except that instead of a retain, you specify a strong ownership qualifier.

@interface MasterViewController
@property(nonatomic, strong) ChildViewController *child;
@end

The presenting and delegate handling remains the same. It gets tricky when you try to implement method 2 with ARC. The problem is, ARC compiler doesn’t allow a pointer to linger around. So your child controller gets deallocated after it’s presented unless you need to “own” the pointer explicitly.

The other easier way is to use blocks. With completion delegates implemented as blocks, this becomes easier. This, I would say, is synonymous to the method 2 which I described before.

ChildViewController *child = [[ChildViewController alloc] initWith…];
 
  __weak __block ChildViewController *weakChild = child; 
 
  child.completionHandler = ^(BOOL result) {
 
	[self dismissModalViewControllerAnimated:YES];
	weakChild = nil;
};
 
[self.navigationController presentModalViewController:child animated:YES]

Back to square one

In both methods, with or without ARC, we dismiss the child controller on the callback method in the parent. Coming back to our original problem, if you dismiss a child controller by calling

[self dismissModalViewControllerAnimated:YES];

The parent has no way to know that the child controller has completed it task and has been dismissed.
Using viewDidAppear on parent to release a child view controller and use boolean logic is, well, BOOL sh!t.

ARC manages memory in the following ways depending on your design.
1. If you captured the child within a completion handler, the memory allocated to the child leaks
2. If your child controller is a local stack variable and there is no completion handler block, the memory allocated to the child gets released prematurely (as soon as the view is presented and results in a crash)
3. If your child controller is owned by the parent with a strong reference, it lingers around till the parent view gets deallocated (if you set it to nil in viewDidUnload of the master).

All these three methods are probably not the right way to do. The only right way is to invoke a completion handler and let the parent dismiss your child safely. This is the reason why I tweeted,

Calling [self dismissModalViewControllerAnimated:NO] on child is like committing seppuku. A child shouldn’t kill itself.

— Mugunth Kumar () (@mugunthkumar) February 25, 2012

Apple follows this pattern throughout their sample code and within their framework. So, I repeat, don’t ever dismiss a child view controller within a child.

Update 1: Method 2 works fine with ARC in this case since presentModalViewController bumps up the retain count. (Thanks Hollance and Johan Kool for pointing this out) However, do note that, there are some methods very similar to this, that are likely to be affected. CLLocationManager’s startUpdatingLocation will not call the delegate if there is no owner for the CLLocationManager object. Same happens to MKReverseGeocoder.

Update 2:When you call dismissModalViewController on a child, the UIKit framework automatically takes care of forwarding the message to the parent view controller.
–
Mugunth

Follow me on Twitter

No related posts.

iOS5 Programming: Pushing the limits book updates

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

iOS5 Programming: Pushing the limits

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...

MKBlog

Panacea for slow Xcode

RESTful API Server – Doing it the right way (Part 2)

Contents

HTTP APIs, REST and HATEOAS

HATEOAS – Hypermedia as the Engine of Application State

HATEOAS for your next API?

Caching

Expiration model

Validation model

Client side coding

Server side coding

Choosing a caching model for your resource

Recommended Reading

Adding Twitter support (iOS 5 with oAuth fallback) to your iOS App with RSOAuthEngine

Introducing RSOAuthEngine

The fork

Using RSOAuthEngine

The magic behind the scenes

The fallback

ARC retain cycles and blocks

A note on MKInfoPanelDemo

What you should know

RESTful API Server – Doing it the right way (Part 1)

Contents

Target Audience

Structure and Organization

RESTful constraints

Statelessness

Cacheable and a Layered architecture

Client-server separation of concerns and a uniform interface

REST Requests and the four HTTP methods

Cacheable constraint and GET requests

That POST vs PUT debate

DELETE method

REST Responses

Authentication

API documentation

Documentation

Documenting Request Parameters

Documenting Response Parameters

Reasons to version and deprecate your API

Versioning

Versioned URL paradigm

Versioned model paradigm

Deprecation

Caching

Error handling & Internationalization of your API

Ownership of presented view controllers with and without ARC

Memory management with pushed view controllers

Memory management with presented view controllers

Memory Management pre ARC

Method 1

Method 2

Memory Management with ARC

Back to square one

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