TwitterAuth Integration Testing

Michael Bleigh’s TwitterAuth gem is truly full of awesome. It’s a complete OAuth authentication and API access solution for building Twitter apps with Rails. It uses familiar conventions borrowed from the Restful Authentication plugin, too. If you’re building a Rails-based app and you want to allow your users to Sign in with Twitter there’s just no better way to go.

For this particular app, I’m using the dynamic duo of Cucumber and Webrat to whip up integration tests. Since I initially stumbled a little bit when thinking about how to test integrated authentication against an external source like Twitter, I thought I’d doc the solution here in case other people were having the same issue.

Ready? Let’s do it.

Setup

First, install the TwitterAuth gem and use the provided generator to whip up the appropriate facilities. You’ll need to register your Twitter application accounts too. Or you know what? Screw it. If you want to make this super easy on yourself, Mike wrote a really great Twitter app Rails template that does all the setup for you, including walking you through getting the dev accounts. It’s nice, try it out. You’ll be up and writing Twitter apps in no time.

For the rest of this I’m going to assume that you have all of that working, and have installed Cucumber too. Don’t have Cucumber? Install it using RubyGems and then just run script/generate cucumber inside your Rails app.

Authentication Feature

So let’s write a Cucumber feature to test authentication in our boilerplate Twitter template application. Put the following in features/authentication.feature:

Feature: Authentication
In order to create and edit games
As a user
I want to sign in with Twitter

  Scenario: Login via Twitter
    When I go to "the homepage"
    And I follow "Login via Twitter"
    And Twitter authorizes me
    Then I should see "Logged in as"

  Scenario: Checking login status
    Given I am signed in
    When I go to "the homepage"
    Then I should see "Logged in as"

  Scenario: Log out
    Given I am signed in
    When I go to "the homepage"
    And I follow "Log out"
    Then I should see "Login via Twitter"

Step Definitions

Next, you’ll need to write step definitions to satisfy the missing steps. Do that by creating a file called features/step_definitions/auth_steps.rb. The content of the file should define the following two steps:

Given /^I am signed in$/ do  
  visit login_path
  visit oauth_callback_path
end  

When /^Twitter authorizes me$/ do
  visit oauth_callback_path
end

Fake Style

The secret sauce here is FakeWeb. We’ll use it to fake out responses from the Twitter auth service so that your integration tests stay local (and reliable). Make sure to gem install fakeweb, and add the following to tests/environments/cucumber.rb:

config.gem "fakeweb", :version => ">= 1.2.5"

Now edit Cucumber’s features/support/env.rb file:

FakeWeb.allow_net_connect = false
FakeWeb.register_uri(:post, 'http://twitter.com/oauth/request_token', :body => 'oauth_token=fake&oauth_token_secret=fake')
FakeWeb.register_uri(:post, 'http://twitter.com/oauth/access_token', :body => 'oauth_token=fake&oauth_token_secret=fake')
FakeWeb.register_uri(:get, 'http://twitter.com/account/verify_credentials.json', :response => File.join(RAILS_ROOT, 'features', 'fixtures', 'verify_credentials.json'))

Here we’re stubbing out the interaction with Twitter auth, and responding to all outbound authorization attempts with canned data. Note that this references a fixture file, containing a sample verify_credentials API response from Twitter. You can obtain a copy using curl from the comfort of your terminal prompt (substitute your own username and password):

curl -i -u user:pass "http://twitter.com/account/verify_credentials.json" > verify_credentials.json

The last thing you’ll want to do is to check your twitter_auth.yml file and make sure there’s a cucumber environment defined in it. If not, you may need to add it.

And We’re Done

Alright that should do it. Go ahead and run rake features. Everything should be green. And green is good. If you need to write other features that are dependent on a login requirement, you can reuse the same “Given I am signed in” step that we created earlier.

Thanks to b.kocik, whose original post on using FakeWeb to stub Twitter auth was 80% of the solution I needed here.

My Apprenticeship - Monday, July 12, 2004

Introducing HTTPRiot - Easily Consume REST Resources on the iPhone and OS X

If you’ve ever tried to do networking with Foundation you know that wrestling with NSURLConnection and NSURLRequest can be painful. Thankfully, we’ve seen a few third party tools step up to alleviate some of this pain. I want to introduce you to a couple of those tools and show you what I’ve been working on as well.

UPDATED: Fixed the permission issue on the download link

The current crop of tools

There are some excellent HTTP libraries available for the iPhone and OS X. So why do we need another one? Balance. There are two particularly popular libraries that I’m going to talk about: ASIHTTPRequest and ObjectiveResource. I’ll explain the benefits and tradeoffs of each and also explain where HTTPRiot fits in to this equation.

ASIHTTPRequest

ASIHTTPRequest is a highly flexible lower level tool (relative to HTTPRiot & ObjectiveResource). It can do a lot of things and do them well. Besides the basic GET, POST, PUT and DELETE you can also upload files, post form encoded data, handle basic authentication and a host of other really nice things. Not to mention it can handle synchronous and asynchronous requests–something HTTPRiot and ObjectiveResource can’t do. This library is all about flexibility and this flexibility doesn’t take away from how easy it is to use. This code should definitely have in your bag of tricks when you’re looking for an all purpose HTTP library.

The tradeoff for ASIHTTPRequest is that it can’t automatically convert XML and JSON. There is also no mechanism for setting default configuration options which results in you having to configure things like delegates and selectors for every asynchronous request. To be fair, ASIHTTPRequest was never meant to be used this way, thus I would take these tradeoffs with a grain of salt.

ObjectiveResource

If you’ve ever used ActiveResource with Rails you’ll probably be familiar with ObjectiveResource’s style. ObjectiveResources is a high-level library that does a lot of behind the scenes work. It’s built specifically to consume REST resources. It can convert to and from JSON and XML (ASIHTTPRequest can’t) and it will automatically initialize models and do all sorts of other work for you. This makes it a great fit for working in conjunction with a Rails app.

The tradeoff of ObjectiveResource is that it doesn’t handle XML and JSON that’s not produced by Rails well. I’m not sure what kind of results you’d get if you fed it something like Govtrack’s bill data. ObjectiveResource is also a big library with a lot of moving parts. In addition to the networking code, the library also includes ObjectiveSupport, a nice library in itself that’s loosely based on ActiveSupport.

One final thought about ObjectiveResource—there are a lot of methods added to NSObject. Apple doesn’t explicitly say not to do this, but they do warn you of the consequences:

“You can define categories that add methods to the root class, NSObject. Such methods are available to all instances and class objects that are linked into your code. Informal protocols—the basis for the Cocoa delegation mechanism—are declared as categories on NSObject. This wide exposure, however, has its dangers as well as its uses. The behavior you add to every object through a category on NSObject could have consequences that you might not be able to anticipate, leading to crashes, data corruption, or worse.”

With all that being said, ObjectiveResource is definitely worth checking out. I know a few people who are using it and love it.

HTTPRiot

Like ObjectiveResource, HTTPRiot was inspired by its Ruby counterpart: John Nunemaker’s httparty. Hence the name. HTTPRiot serves as a balance between ASIHTTPRequest and ObjectiveResource. You get a certain amount of flexibility and a higher level api. Like ASIHTTPRequest, you can send GET, POST, PUT, and DELETE requests, also like ObjectiveResource the XML or JSON response will automatically be converted to an Objective-C type (NSArray or NSDictionary).

The tradeoff with HTTPRiot is that it makes no attempt to convert the data further or automatically compose instances of other objects for you. It gives you the data and lets you do what you want with it. This means that you must be aware of the data you receive because it’s up to you to decide what to do with it after it’s been converted to a native type. For instance, if two request originate from the same model they will both use the same delegate methods to handle the response. It’s up to you to decide what’s what.

Some examples

Some quick examples to give you an idea of how you use HTTPRiot.

GET Request: Reads JSON from the server.

[Person getPath:@"/people" withOptions:nil object:nil];

POST Request: POSTs the body set in options to the server.

NSDictionary *options = [NSDictionary dictionaryWithObject:[foo JSONRepresentation] forKey:@"body"];
[HTTPRiotRestModel postPath:@"/person" withOptions:options error:nil];

Setting default options: You can subclass HRRestModel and set default options like basic auth, headers, params, etc. Every request you make from MyModel will use these default options.

@implementation MyModel
+(void) initialize {
    [self setBasicAuthWithUsername:@"justin" password:@"pass"];
    [self setDefaultHeaders:[NSDictionary dictionaryWithObject:@"Some Header Value" forKey:@"My-Header"]];
}
@end

Implementing the delegate methods

You’ll need to implement a few delegate methods to deal with the responses. I’ll explain why I settled on this approach in another post, but for now here is sample of what you’ll have:

- (void)restConnection:(NSURLConnection *)connection didReturnResource:(id)resource object:(id)object {
    //resource contains the NSDictionary or NSArray version of the XML or JSON you requested
    for(id item in resource) {
        //Do something with your data
    }
}

- (void)restConnection:(NSURLConnection *)connection didReceiveError:(NSError *)error response:(NSHTTPURLResponse *)response object:(id)object {
    //Recieved a bad status code 404, 500, etc.
}

Summing up

All three libraries have a job they are well suited for. Hopefully I’ve given you an idea of what to expect with each one. On a final note regarding HTTPRiot, it is a young library so there will <strike>likely</strike> be bugs along the way. If you spot one, cease development and report it to the proper authorities.

• HTTPRiot Website
• Online Documentation
• Source Code
• Report Bugs & Get Help

FutureRuby talk: Living With 1000 Open Source Projects

The FutureRuby conference has been (and still is, as of 11:43am on Sunday) wonderful. I just finished my talk on “Living With 1000 Open Source Projects” which was great fun, good for a bunch of laughs, and more importantly allowed me to share some thoughts on Zero Maintenance, Managing community expectations, self-sustaining communities, and the difficulty of scaling pet children.

Below are the slides and all the nice things people said about the talk, which has made me feel very good for sharing, and for the 60hr return flight from Brisbane to Toronto.

If you want to hear the jokes, and an Australian “mistaking” Canada for a state of America, perhaps wait for InfoQ to publish the video.

The slides

Nice things people said

Thanks to…

Elle Meredith who helped me design and theme the slides so they looked spot-on-awesome.

My two children for not being old enough to be disturbed by some of the things I said about them during the talk.

Python Decorators in Ruby

This past week, I had a pretty long discussion on StackOverflow about Ruby and Python, that was touched off by question about whether there was anything special about Ruby that made it more amenable for Rails.

My initial response covered blocks (as a self-hosting way to improve the language) and the ability to define new “class keywords” because of the fact that class bodies are just normal executable code. The strongest argument against this was that Python decorators are as powerful as Ruby’s executable class bodies, and therefore can be used to achieve anything that Ruby can achieve.

Python decorators do in fact provide a certain amount of additional power and elegance over the Python before decorators. However, this power is simply a subset of the available Ruby functionality. This is because Ruby has always had the ability to add features like decorators to the language without needing language changes.

In other words, while Python has added a new hardcoded feature in order to achieve some of the power of Ruby, adding such a feature to Ruby would be unnecessary because of the underlying structure of the Ruby language.

To show this clearly, I have implemented a port of Python function decorators in under 70 lines of Ruby. I wrote the code test-first, porting the necessary functionality from two Python Decorator tutorials written by Bruce Eckel in October 2008.

The list of features supported:

• Decorate any object that responds to call via: decorate SomeKlass or decorate some_lambda
• A simpler syntax for class names that can be used as decorators: SomeKlass(arg)
• The ability to give the decorator a name that could be used instead of the class name, if desired

Some examples:

class MyDecorator
  def initialize(klass, method)
    @method = method
  end
 
  def call(this, *args)
    puts "Before MyDecorator with #{args.inspect}"
    @method.bind(this).call(*args)
    puts "After MyDecorator with #{args.inspect}"
  end
end
 
class WithDecorator
  # we could trivially add these to all classes, but we'll keep it isolated
  extend MethodDecorators
 
  MyDecorator() # equivalent to decorate MyDecorator
  def my_function(*args)
    puts "Inside my_function with #{args.inspect}"
  end
end
 
WithDecorator.new.my_function(1)

When MyDecorator() is called inside the WithDecorator class, it registers a decorator for the next method that is defined. This is roughly equivalent to Python’s function decoration. Some other examples:

class MyDecorator < Decorator
  decorator_name :surround
 
  def initialize(klass, method, *args)
    @method, @args = method, args
  end
 
  def call(this, *args)
    puts "Before MyDecorator(#{@args.inspect}) with #{args.inspect}"
    @method.bind(this).call(*args)
    puts "After MyDecorator(#{@args.inspect}) with #{args.inspect}"
  end
end
 
class Class
  include MethodDecorators
end
 
class WithDecorator
  surround(1, 2)
  def function(*args)
    p args
  end
end
 
WithDecorator.new.function(1)

In this case, I’ve inherited from the Decorator class, which allows me to add a decorator name, which can then be used in a class with MethodDecorators mixed in. In this example, I’ve mixed MethodDecorators into Class, which makes decorators available for all classes. Again, I could have made this the default, but I like to try to make new behaviors global if I can avoid it.

This is of course a first pass and I’m sure there are subtle inconsistencies between Python’s decorator implementation and what I have here. My point is just that the feature that was added to Python to add flexibility is merely a subset of the functionality available to Ruby, because Rubyists can implement new declarative features without needing help from the language implementors, and have always been able to.

Python Decorators in Ruby

This past week, I had a pretty long discussion on StackOverflow about Ruby and Python, that was touched off by question about whether there was anything special about Ruby that made it more amenable for Rails.

My initial response covered blocks (as a self-hosting way to improve the language) and the ability to define new “class keywords” because of the fact that class bodies are just normal executable code. The strongest argument against this was that Python decorators are as powerful as Ruby’s executable class bodies, and therefore can be used to achieve anything that Ruby can achieve.

Python decorators do in fact provide a certain amount of additional power and elegance over the Python before decorators. However, this power is simply a subset of the available Ruby functionality. This is because Ruby has always had the ability to add features like decorators to the language without needing language changes.

In other words, while Python has added a new hardcoded feature in order to achieve some of the power of Ruby, adding such a feature to Ruby would be unnecessary because of the underlying structure of the Ruby language.

To show this clearly, I have implemented a port of Python function decorators in under 70 lines of Ruby. I wrote the code test-first, porting the necessary functionality from two Python Decorator tutorials written by Bruce Eckel in October 2008.

The list of features supported:

• Decorate any object that responds to call via: decorate SomeKlass or decorate some_lambda
• A simpler syntax for class names that can be used as decorators: SomeKlass(arg)
• The ability to give the decorator a name that could be used instead of the class name, if desired

Some examples:

class MyDecorator
  def initialize(klass, method)
    @method = method
  end
 
  def call(this, *args)
    puts "Before MyDecorator with #{args.inspect}"
    @method.bind(this).call(*args)
    puts "After MyDecorator with #{args.inspect}"
  end
end
 
class WithDecorator
  # we could trivially add these to all classes, but we'll keep it isolated
  extend MethodDecorators
 
  MyDecorator() # equivalent to decorate MyDecorator
  def my_function(*args)
    puts "Inside my_function with #{args.inspect}"
  end
end
 
WithDecorator.new.my_function(1)

When MyDecorator() is called inside the WithDecorator class, it registers a decorator for the next method that is defined. This is roughly equivalent to Python’s function decoration. Some other examples:

class MyDecorator < Decorator
  decorator_name :surround
 
  def initialize(klass, method, *args)
    @method, @args = method, args
  end
 
  def call(this, *args)
    puts "Before MyDecorator(#{@args.inspect}) with #{args.inspect}"
    @method.bind(this).call(*args)
    puts "After MyDecorator(#{@args.inspect}) with #{args.inspect}"
  end
end
 
class Class
  include MethodDecorators
end
 
class WithDecorator
  surround(1, 2)
  def function(*args)
    p args
  end
end
 
WithDecorator.new.function(1)

In this case, I’ve inherited from the Decorator class, which allows me to add a decorator name, which can then be used in a class with MethodDecorators mixed in. In this example, I’ve mixed MethodDecorators into Class, which makes decorators available for all classes. Again, I could have made this the default, but I like to try to make new behaviors global if I can avoid it.

This is of course a first pass and I’m sure there are subtle inconsistencies between Python’s decorator implementation and what I have here. My point is just that the feature that was added to Python to add flexibility is merely a subset of the functionality available to Ruby, because Rubyists can implement new declarative features without needing help from the language implementors, and have always been able to.

Introducing HTTPRiot - Easily Consume REST Resources on the iPhone and OS X

If you’ve ever tried to do networking with Foundation you know that wrestling with NSURLConnection and NSURLRequest can be painful. Thankfully, we’ve seen a few third party tools step up to alleviate some of this pain. I want to introduce you to a couple of those tools and show you what I’ve been working on as well.

UPDATED: Fixed the permission issue on the download link

The current crop of tools

There are some excellent HTTP libraries available for the iPhone and OS X. So why do we need another one? Balance. There are two particularly popular libraries that I’m going to talk about: ASIHTTPRequest and ObjectiveResource. I’ll explain the benefits and tradeoffs of each and also explain where HTTPRiot fits in to this equation.

ASIHTTPRequest

ASIHTTPRequest is a highly flexible lower level tool (relative to HTTPRiot & ObjectiveResource). It can do a lot of things and do them well. Besides the basic GET, POST, PUT and DELETE you can also upload files, post form encoded data, handle basic authentication and a host of other really nice things. Not to mention it can handle synchronous and asynchronous requests–something HTTPRiot and ObjectiveResource can’t do. This library is all about flexibility and this flexibility doesn’t take away from how easy it is to use. This code should definitely have in your bag of tricks when you’re looking for an all purpose HTTP library.

The tradeoff for ASIHTTPRequest is that it can’t automatically convert XML and JSON. There is also no mechanism for setting default configuration options which results in you having to configure things like delegates and selectors for every asynchronous request. To be fair, ASIHTTPRequest was never meant to be used this way, thus I would take these tradeoffs with a grain of salt.

ObjectiveResource

If you’ve ever used ActiveResource with Rails you’ll probably be familiar with ObjectiveResource’s style. ObjectiveResources is a high-level library that does a lot of behind the scenes work. It’s built specifically to consume REST resources. It can convert to and from JSON and XML (ASIHTTPRequest can’t) and it will automatically initialize models and do all sorts of other work for you. This makes it a great fit for working in conjunction with a Rails app.

The tradeoff of ObjectiveResource is that it doesn’t handle XML and JSON that’s not produced by Rails well. I’m not sure what kind of results you’d get if you fed it something like Govtrack’s bill data. ObjectiveResource is also a big library with a lot of moving parts. In addition to the networking code, the library also includes ObjectiveSupport, a nice library in itself that’s loosely based on ActiveSupport.

One final thought about ObjectiveResource—there are a lot of methods added to NSObject. Apple doesn’t explicitly say not to do this, but they do warn you of the consequences:

“You can define categories that add methods to the root class, NSObject. Such methods are available to all instances and class objects that are linked into your code. Informal protocols—the basis for the Cocoa delegation mechanism—are declared as categories on NSObject. This wide exposure, however, has its dangers as well as its uses. The behavior you add to every object through a category on NSObject could have consequences that you might not be able to anticipate, leading to crashes, data corruption, or worse.”

With all that being said, ObjectiveResource is definitely worth checking out. I know a few people who are using it and love it.

HTTPRiot

Like ObjectiveResource, HTTPRiot was inspired by its Ruby counterpart: John Nunemaker’s httparty. Hence the name. HTTPRiot serves as a balance between ASIHTTPRequest and ObjectiveResource. You get a certain amount of flexibility and a higher level api. Like ASIHTTPRequest, you can send GET, POST, PUT, and DELETE requests, also like ObjectiveResource the XML or JSON response will automatically be converted to an Objective-C type (NSArray or NSDictionary).

The tradeoff with HTTPRiot is that it makes no attempt to convert the data further or automatically compose instances of other objects for you. It gives you the data and lets you do what you want with it. This means that you must be aware of the data you receive because it’s up to you to decide what to do with it after it’s been converted to a native type. For instance, if two request originate from the same model they will both use the same delegate methods to handle the response. It’s up to you to decide what’s what.

Some examples

Some quick examples to give you an idea of how you use HTTPRiot.

GET Request: Reads JSON from the server.

[Person getPath:@"/people" withOptions:nil object:nil];

POST Request: POSTs the body set in options to the server.

NSDictionary *options = [NSDictionary dictionaryWithObject:[foo JSONRepresentation] forKey:@"body"];
[HTTPRiotRestModel postPath:@"/person" withOptions:options error:nil];

Setting default options: You can subclass HRRestModel and set default options like basic auth, headers, params, etc. Every request you make from MyModel will use these default options.

@implementation MyModel
+(void) initialize {
    [self setBasicAuthWithUsername:@"justin" password:@"pass"];
    [self setDefaultHeaders:[NSDictionary dictionaryWithObject:@"Some Header Value" forKey:@"My-Header"]];
}
@end

Implementing the delegate methods

You’ll need to implement a few delegate methods to deal with the responses. I’ll explain why I settled on this approach in another post, but for now here is sample of what you’ll have:

- (void)restConnection:(NSURLConnection *)connection didReturnResource:(id)resource object:(id)object {
    //resource contains the NSDictionary or NSArray version of the XML or JSON you requested
    for(id item in resource) {
        //Do something with your data
    }
}

- (void)restConnection:(NSURLConnection *)connection didReceiveError:(NSError *)error response:(NSHTTPURLResponse *)response object:(id)object {
    //Recieved a bad status code 404, 500, etc.
}

Summing up

All three libraries have a job they are well suited for. Hopefully I’ve given you an idea of what to expect with each one. On a final note regarding HTTPRiot, it is a young library so there will <strike>likely</strike> be bugs along the way. If you spot one, cease development and report it to the proper authorities.

• HTTPRiot Website
• Online Documentation
• Source Code
• Report Bugs & Get Help

Judging at the The ONYAs

I’m proud to be a judge at the first ONYA awards, which celebrate all things web in New Zealand. Having been twice at Webstock, the awesomest web conference ever, I’m really honoured by this and are looking forward for your entries! So, if you’re in New Zealand and have a really cool website, web application [...]

Introducing HTTPRiot - Easily Consume REST Resources on the iPhone and OS X

If you’ve ever tried to do networking with Foundation you know that wrestling with NSURLConnection and NSURLRequest can be painful. Thankfully, we’ve seen a few third party tools step up to alleviate some of this pain. I want to introduce you to a couple of those tools and show you what I’ve been working on as well.

UPDATED: Fixed the permission issue on the download link

The current crop of tools

There are some excellent HTTP libraries available for the iPhone and OS X. So why do we need another one? Balance. There are two particularly popular libraries that I’m going to talk about: ASIHTTPRequest and ObjectiveResource. I’ll explain the benefits and tradeoffs of each and also explain where HTTPRiot fits in to this equation.

ASIHTTPRequest

ASIHTTPRequest is a highly flexible lower level tool (relative to HTTPRiot & ObjectiveResource). It can do a lot of things and do them well. Besides the basic GET, POST, PUT and DELETE you can also upload files, post form encoded data, handle basic authentication and a host of other really nice things. Not to mention it can handle synchronous and asynchronous requests–something HTTPRiot and ObjectiveResource can’t do. This library is all about flexibility and this flexibility doesn’t take away from how easy it is to use. This is code you should definitely have in your bag of tricks when you’re in need of an all purpose HTTP library.

The tradeoff for ASIHTTPRequest is that it can’t automatically convert XML and JSON. There is also no mechanism for setting default configuration options which results in you having to configure things like delegates and selectors for every asynchronous request. To be fair, ASIHTTPRequest was never meant to be used this way, thus I would take these tradeoffs with a grain of salt.

ObjectiveResource

If you’ve ever used ActiveResource with Rails you’ll probably be familiar with ObjectiveResource’s style. ObjectiveResources is a high-level library that does a lot of behind the scenes work. It’s built specifically to consume REST resources. It can convert to and from JSON and XML (ASIHTTPRequest can’t) and it will automatically initialize models and do all sorts of other work for you. This makes it a great fit for working in conjunction with a Rails app.

The tradeoff of ObjectiveResource is that it doesn’t handle XML and JSON that’s not produced by Rails well. I’m not sure what kind of results you’d get if you fed it something like Govtrack’s bill data. ObjectiveResource is also a big library with a lot of moving parts. In addition to the networking code, the library also includes ObjectiveSupport, a nice library in itself that’s loosely based on ActiveSupport.

One final thought about ObjectiveResource—there are a lot of methods added to NSObject. Apple doesn’t explicitly say not to do this, but they do warn you of the consequences:

“You can define categories that add methods to the root class, NSObject. Such methods are available to all instances and class objects that are linked into your code. Informal protocols—the basis for the Cocoa delegation mechanism—are declared as categories on NSObject. This wide exposure, however, has its dangers as well as its uses. The behavior you add to every object through a category on NSObject could have consequences that you might not be able to anticipate, leading to crashes, data corruption, or worse.”

With all that being said, ObjectiveResource is definitely worth checking out. I know a few people who are using it and love it.

HTTPRiot

Like ObjectiveResource, HTTPRiot was inspired by its Ruby counterpart: John Nunemaker’s httparty. Hence the name. HTTPRiot serves as a balance between ASIHTTPRequest and ObjectiveResource. You get a certain amount of flexibility and a higher level api. Like ASIHTTPRequest, you can send GET, POST, PUT, and DELETE requests, also like ObjectiveResource the XML or JSON response will automatically be converted to an Objective-C type (NSArray or NSDictionary).

The tradeoff with HTTPRiot is that it makes no attempt to convert the data further or automatically compose instances of other objects for you. It gives you the data and lets you do what you want with it. This means that you must be aware of the data you receive because it’s up to you to decide what to do with it after it’s been converted to a native type. For instance, if two request originate from the same model they will both use the same delegate methods to handle the response. It’s up to you to decide what’s what.

Some examples

Some quick examples to give you an idea of how you use HTTPRiot.

GET Request: Reads JSON from the server.

[Person getPath:@"/people" withOptions:nil object:nil];

POST Request: POSTs the body set in options to the server.

NSDictionary *options = [NSDictionary dictionaryWithObject:[foo JSONRepresentation] forKey:@"body"];
[HTTPRiotRestModel postPath:@"/person" withOptions:options error:nil];

Setting default options: You can subclass HRRestModel and set default options like basic auth, headers, params, etc. Every request you make from MyModel will use these default options.

@implementation MyModel
+(void) initialize {
    [self setBasicAuthWithUsername:@"justin" password:@"pass"];
    [self setDefaultHeaders:[NSDictionary dictionaryWithObject:@"Some Header Value" forKey:@"My-Header"]];
}
@end

Implementing the delegate methods

You’ll need to implement a few delegate methods to deal with the responses. I’ll explain why I settled on this approach in another post, but for now here is sample of what you’ll have:

- (void)restConnection:(NSURLConnection *)connection didReturnResource:(id)resource object:(id)object {
    //resource contains the NSDictionary or NSArray version of the XML or JSON you requested
    for(id item in resource) {
        //Do something with your data
    }
}

- (void)restConnection:(NSURLConnection *)connection didReceiveError:(NSError *)error response:(NSHTTPURLResponse *)response object:(id)object {
    //Recieved a bad status code 404, 500, etc.
}

Summing up

All three libraries have a job they are well suited for. Hopefully I’ve given you an idea of what to expect with each one. On a final note regarding HTTPRiot, it is a young library so there will likely be bugs along the way. If you spot one, cease development and report it to the proper authorities.

• HTTPRiot Website
• Online Documentation
• Source Code
• Report Bugs & Get Help

rc-rest 3.0.0

• documentation
• project page

Robot Co-op REST web services base class. This library makes it easy to implement REST-like web services APIs.

Changes

• Upgrade to Nokogiri from REXML. This is incompatible with 2.x and older. Thanks Aaron Patterson!

How to make really nice buttons

Introduction

Creating buttons is something every web designer deals with, usually on a very regular basis. It can be one of those tasks that becomes tedious and repetitive but with a few tricks you can make pleasing looking buttons that also give the visitor useful feedback and navigational consistency. In this article I’ll be talking about buttons with 3 states – normal, hover, and pressed – and I will be using the sprite based method which places all 3 states in the same image file.

Shapes ‘n Shapes

Achieving the right graphical look is important so that you are able to present your design in the manner you desire – be it rational UI or crazy mystery meat navigation. It’s important to have your choices look deliberate and not haphazardly chosen – it will help you when presenting to the client and in the final UI users will interact with.

Photoshop’s shape tool is a quirky thing with a couple important options to understand before you start working. First there is the choice between creating a vector-based “Shape Layer” or a pixel based “Fill pixels” option. In a nutshell the vector option is versatile but clunky and the pixel option is less flexible (especially when you want to modify the shape later) but it acts predictably in the pixel world. I use pixels simply because the vector tool can be a pain.

Of equal importance is the “snap to pixels” option which is accessible from the hidden menu at the end of the shape option bar (see fig. 2, step 1) when you are using the rounded corner shape. This will prevent your shapes from displaying unpredictable antialiasing which becomes very important as you duplicate shapes and specify heights and widths in CSS. Also make certain if you’re created a rounded corner shape to turn anti-aliaising on (fig. 2, step 3).

(fig. 2)

Now you can create shapes! Choose a radius for your rounded corners and you’re ready to go.

Button Styles

Button styles have been evolving as long as the web has and there are an infinite number of styles you could use but I am going to demonstrate a sensible approach that is universal and not heavy on character. The following are tips on using Photoshop’s Layer Styles to create a button like the ones used in the examples.

• Inner Shadow — Pick a bright color, choose the Color Dodge blending mode, bring choke to 100% with a size of 0 and an angle of 90%. This gives a great top edge highlight (tip shout out to Andrew Wilkinson of Metalab Design).

• Inner Glow — Mirror Inner Shadow’s settings and play with the opacity

• Gradient Overlay — Choose colors not too far apart on the color wheel, the gradient should be subtle

• Stroke — A 1px stroke works best. The object is to pick a slightly darker version of your darkest gradient color to “hold things together”.

These are your basic settings for the “normal” state. For the hover state alter the gradient overlay and lighten both colors. The “pressed” state requires a few new styles and a couple adjustments to get that indented look.

• Inner Shadow
  • Color: black
  • Blend mode: multiply
  • Opacity 75%
  • Distance 4px
  • Choke 4%
  • Size: 13px

• Bevel and Emboss
  • Style: Outer Bevel
  • Depth: 100%
  • Size: 1px
  • Angle: -90°
  • Highlight Mode: Screen
  • Highlight Opacity: 40%
  • Shadow Opacity: 0%

The CSS behind the buttons

The 3 states of the button are contained in one image so you will use the background-position CSS attribute to control which states are shown for normal, hover and active states. This method is known as sprites and there are many great resources on it. The primary benefit is since all 3 states of the image are loaded in the same file there is no additional loading on hover and active states. The CSS for changing the background image would look something like this:

1
2
3
4
5
6
7
8

#bee_button a {
display: block;
text-indent: -5000px;
width: 136px;
height: 41px;
background-image: url(/images/bee_button.png);
background-repeat: no-repeat;
}

1
2
3

#bee_button a {background-position: 0 0;}
#bee_button a:hover {background-position: 0 -41px;}
#bee button a:active {background-position: 0 -82px;}

Conclusion

You can see buttons like these in action on the Widgetfinger home page and inside both Hoptoad and Thunder Thimble. They provide a tactile experience for the user and an extra bit of visual feedback when a button has been clicked.