everburning » Programming

Stage left: Enter Goliath

dj2 — Tue, 08 Mar 2011 19:27:59 +0000

Over at PostRank Labs we’ve released the current version of our API server framework to the wild. Allow me to introduce Goliath. Goliath is built on the back of the work at PostRank, Thin, Sinatra, http-parser.rb and various other projects.

We’ve been using a version of Goliath internally for over a year serving a sustained 500 requests/sec and shuttling around gigabytes of data.

How did we get here you’re asking? Our API servers from the beginning have been built on the awesome EventMachine library. The last several iterations have used a threaded model. A request comes in, a thread is grabbed from the pool, request is processed, thread goes back to the pool. This was cool and worked quite well for us for several years. The problem we ran into, we were getting spaghetti code. A lot of our APIs call other APIs internally. Handling the callbacks, error backs and various other delayed operations was getting difficult to maintain.

Then along wandered Ruby 1.9 with these cool little things called Fibers. Fibers allow us to build synchronous looking code backed by asynchronous calls. To achieve this we’re using the EM-Synchrony library. Tying this back into Goliath, as each request comes in, a new Fiber is created, the request is processed within that Fiber and, when completed, the Fiber goes away.

Once we had the foundation in place we went a step further and built a few extra little goodies into Goliath including streaming requests and responses. This lets us do some cool things like hook AMQP exchanges up to a Goliath API to pipe content through a streaming response.

Using http-parser.rb allows us to open up the option of alternate Ruby VMs. At the time of writing, Goliath has been tested with MRI, JRuby and Rubinius. MRI is currently the fastest VM for Goliath but there is lots of work going on in the alternate VMs to make them faster.

Ok, ok, enough of the hype, lets see some code already.

Well, first we need to get Goliath installed. In general this is pretty simple, you can use your system Ruby, RVM or some other system and all you need to do is:

gem install goliath

What we’re going to build here is an HTTP proxy that stores information about each request/response into MongoDB. (The full code listing can be found in this gist.)

Before we dig into the code, a little on how Goliath works. By default, Goliath will execute your API when you run the API file. In order to do this, the API file has to have a snake cased name based on the class name. So, our HttpLog API will live in a file called http_log.rb. When you need to add configuration to your API you’ll do this by creating a config directory in the same directory as your file. You then create a file in the config directory with the same name as your API. In our case, we’ll create a config/http_log.rb file to hold our configuration.

Goliath has been built to be Rack-aware. This means we can make use of Rack middlewares, as long as they’re async safe or have been wrapped by async-rack.

We’re going to build some specs along with our API. Create spec/http_log_spec.rb and we can get this party started.

require ‘rubygems’
require ‘goliath/test_helper’
require File.expand_path(File.join(File.dirname(__FILE__), ‘..’, ‘http_log’))

describe HttpLog do
include Goliath::TestHelper

let(:err) { Proc.new { |c| fail "HTTP Request failed #{c.response}" } }

it ‘responds to requests’ do
with_api(HttpLog) do
get_request({}, err) do |c|
c.response_header.status.should == 200
end
end
end
end

With Goliath we’ve provided a simple goliath/test_helper file that makes the testing of APIs a little easier. Once you’ve required the library, you just need to include Goliath::TestHelper and you can start using the helper methods. These include the with_api and get_request methods that are being used above. The with_api call will start an instance of our API running on port 9000 and anything done within its block will executing inside an EM reactor. This method will not return until stop is executed.

We’re, essentially, creating an integration test suite for our API. Everything except for the API launching will be tested by the test suite. The configuration files will be parsed, all the middlewares will be loaded and executed. Everything that your normal application would do except for the launching.

Calling get_request will send a GET to our API. The first parameter is any query parameters to send to the API. In our case, we send nothing. The second is an error handler to add. This is fired if we are unable to communicate with the API. For this example, we’re just using the RSpec fail method to fail the spec in the error handler.

The block passed to get_request will be executed and provided the request object when the request is complete. This allows us to look at the response headers and response body. In this case, we’re just verifying that server responds with a 200 code. When you’re using get_request or post_request a default error and callback handler will be installed that calls stop for you.

With that, running the spec should fail. Let’s create a simple API to make it pass. The following code in http_log.rb will give us a passing spec.

#!/usr/bin/env ruby

require ‘rubygems’
require ‘goliath’

class HttpLog < Goliath::API
def response(env)
[200, {}, "Hello"]
end
end

You can execute the API with ./http_log.rb -sv which will launch the API on a default port of 9000.

The -sv flags tell the API to log to STDOUT (s) and use verbose logging (v). You can run ./http_log.rb -h to see a list of all the default options provided by Goliath. You can add your own options as well if you need special argument handling for your API.

With the API running we can query the API using curl.

dj2@titania ~ $ curl localhost:9000
Hello

Running the spec test again our test case should also pass at this point.

To make our lives easier, we’re going to use the Rack::Reloader middleware to handle reloading our Rack middleware on each request.

This is done by adding use ::Rack::Reloader, 0 into our API. Since we only want reloading when we’re doing development we’re going to make the use statement conditional on the Goliath environment. By default Goliath executes in a development environment. We can confirm this by calling Goliath.dev? which will return true if the current environment is development.

class HttpLog < Goliath::API
use ::Rack::Reloader, 0 if Goliath.dev?

def response(env)
[200, {}, "Hello"]
end
end

You’ll notice that we didn’t create another file to place the middleware. With Goliath, the middleware is built into the API class itself. We’ve found this is a lot easier to deal with when you keep everything together in the same file. (You can also add plugins in the same fashion by using the plugin keyword.)

The next step is to start forwarding to our backend server. To do this, we’ll specify in our configuration file the forwarder URL. Create config/http_log.rb and add the following:

config[‘forwarder’] = ‘http://localhost:8080′

The config hash allows us to store configuration data that will become available through the env parameter to the response method. In this case, we’ve specified we want our forwarder to send requests to http://localhost:8080.

In order to test this, I’m going to create a Goliath API server inside our spec files. I’ll run the server on port 8080 and check for our server response in the response from our API. Add the following to the top of the spec file.

class Responder < Goliath::API
def response(env)
[200, {"Special" => "Header"}, "Hello World"]
end
end

And the following spec:

it ‘forwards to our API server’ do
with_api(HttpLog) do
server(Responder, 8080)

get_request({}, err) do |c|
c.response_header.status.should == 200
c.response_header[‘Special’].should == ‘Header’
c.response.should == ‘Hello from Responder’
end
end

This is similar to our previous spec except I’ve added a server(Responder, 8080) call to launch an instance of our Responder API on port 8080. Running this test should fail since we aren’t sending or receiving any data to the proxied API.

As a first pass, we’ll send the request and proxy the responses back.

def response(env)
req = EM::HttpRequest.new("#{env.forwarder}").get

[req.response_header.status, req.response_header, req.response]
end

So, that’s cool. (Make sure you add the server(Responder, 8080) to the first example after doing this or it will end up failing.) There is one, non-apparent problem. It turns out the headers get transformed by EM-HTTP-Request. When we go to log this stuff we’ll want the non-transformed headers so we need to transform them back into the normal HTTP header format. Let’s start with a couple tests:

context ‘HTTP header handling’ do
it ‘transforms back properly’ do
hl = HttpLog.new
hl.to_http_header("SPECIAL").should == ‘Special’
hl.to_http_header("CONTENT_TYPE").should == ‘Content-Type’
end
end

Simple enough, we need to fix the casing and change _ into -. Let’s add that to our HttpLog class.

def to_http_header(k)
k.downcase.split(‘_’).collect { |e| e.capitalize }.join(‘-’)
end

That should make our transform tests pass and we can build the change into the response method by changing it to look like:

def response(env)
req = EM::HttpRequest.new("#{env.forwarder}").get

response_headers = {}
req.response_header.each_pair do |k, v|
response_headers[to_http_header(k)] = v
end

[req.response_header.status, response_headers, req.response]
end

Cool, so now we’re forwarding all requests to the proxied server. There is a bit of missing information that we need, that being the headers, query parameters, request path and different types of requests from just GET.

Lets start with the query parameters. To test this I’m going to augment our Responder class to return the request parameters as part of the headers.

class Responder < Goliath::API
use Goliath::Rack::Params

def response(env)
query_params = env.params.collect { |param| param.join(": ") }
headers = {"Special" => "Header",
"Params" => query_params.join("|")}
[200, headers, "Hello from Responder"]
end
end

We’re using another middleware here, Goliath::Rack::Params, which will parse the query and body parameters and put them into the params hash of the environment. Using that we can send the parameters back as a header in the response.

The test for query parameters is pretty simple, pass them in, make sure they come back:

context ‘query parameters’ do
it ‘forwards the query parameters’ do
with_api(HttpLog) do
server(Responder, 8080)

get_request({:query => {:first => :foo, :second => :bar, :third => :baz}}, err) do |c|
c.response_header.status.should == 200
c.response_header["PARAMS"].should == "first: foo|second: bar|third: baz"
end
end
end
end

To make this pass, we just need to use Goliath::Rack::Params and change the EM::HttpRequest#get request to provide the params. This is done by using: req = EM::HttpRequest.new("#{env.forwarder}").get({:query => env.params}).

Next up, let’s handle the request path. We’ll start with the spec.

context ‘request path’ do
it ‘forwards the request path’ do
with_api(HttpLog) do
server(Responder, 8080)

get_request({:path => ‘/my/request/path’}, err) do |c|
c.response_header.status.should == 200
c.response_header[‘PATH’].should == ‘/my/request/path’
end
end
end
end

Our Responder needs to return the path in the headers. This is done by adding "Path" => env[Goliath::Request::REQUEST_PATH] into the headers return hash. Making this spec pass is as simple as using the same env[Goliath::Request::REQUEST_PATH] data in our forwarder request.

req = EM::HttpRequest.new("#{env.forwarder}#{env[Goliath::Request::REQUEST_PATH]}").get(params)

With the request path out of the way, let’s look into the headers. Goliath has built in facilities to do streaming requests. As part of that, we can hook into the on_headers method to receive a callback with the headers when they’re available. We can then store them into the environment and return them in a similar fashion to the query parameters.

We’re going to use the same on_headers callback in the Responder class to give us access to the headers. Then, the same as with query params, we’ll return them in a header for the response.

class Responder < Goliath::API
use Goliath::Rack::Params

def on_headers(env, headers)
env[‘client-headers’] = headers
end

def response(env)
query_params = env.params.collect { |param| param.join(": ") }
query_headers = env[‘client-headers’].collect { |param| param.join(": ") }

headers = {"Special" => "Header",
"Params" => query_params.join("|"),
"Path" => env[Goliath::Request::REQUEST_PATH],
"Headers" => query_headers.join("|")}
[200, headers, "Hello from Responder"]
end
end

With a spec test similar to the query example as well.

context ‘headers’ do
it ‘forwards the headers’ do
with_api(HttpLog) do
server(Responder, 8080)

get_request({:head => {:first => :foo, :second => :bar}}, err) do |c|
c.response_header.status.should == 200
c.response_header["HEADERS"].should =~ /First: foo\|Second: bar/
end
end
end
end

Let’s make the tests pass:

def on_headers(env, headers)
env.logger.info ‘proxying new request: ‘ + headers.inspect
env[‘client-headers’] = headers
end

You’ll notice I added a call to env.logger.info. Goliath comes with built in logging capabilities. The logger is based on Log4r and is accessed through the environment. The Goliath environment is a subclass of Hash and can be accessed as such to store and retrieve information.

Once we’ve got the headers stored, adding them to our request is a simple process.

params = {:head => env[‘client-headers’], :query => env.params}
req = EM::HttpRequest.new("#{env.forwarder}#{env[Goliath::Request::REQUEST_PATH]}").get(params)

One step left and our proxy is complete. Let’s send the right request method through to the proxied server (we’re just going to do GET and POST in this example). First step, add "Method" => env[Goliath::Request::REQUEST_METHOD] to the headers returned from our Responder API.

We can then add the specs:

context ‘request method’ do
it ‘forwards GET requests’ do
with_api(HttpLog) do
server(Responder, 8080)

get_request({}, err) do |c|
c.response_header.status.should == 200
c.response_header["METHOD"].should == "GET"
end
end
end

it ‘forwards POST requests’ do
with_api(HttpLog) do
server(Responder, 8080)

post_request({}, err) do |c|
c.response_header.status.should == 200
c.response_header["METHOD"].should == "POST"
end
end
end
end

To make this pass we’ll use the Goliath::Request::REQUEST_METHOD to determine the right type of request to make. You’ll notice I’m putting the response into a resp variable, so the references to req in the rest of the method need to be update as well.

req = EM::HttpRequest.new("#{forwarder}#{env[Goliath::Request::REQUEST_PATH]}")
resp = case(env[Goliath::Request::REQUEST_METHOD])
when ‘GET’ then req.get(params)
when ‘POST’ then req.post(params.merge(:body => env[Goliath::Request::RACK_INPUT].read))
else p "UNKNOWN METHOD #{env[Goliath::Request::REQUEST_METHOD]}"
end

The only significant change from the previous version, in the POST request, we need to send the body data through to the forwarded server. The body is stored in a StringIO object which we can read. The object is stored in the environment under the Goliath::Request::RACK_INPUT key.

With that done, we should now have a functioning HTTP proxy.

Let’s take a look at how we can hook this up to MongoDB to give us the Log part of our the API name.

In order to talk to MongoDB we’re going to use the em-mongo gem. Since we’re working in an asynchronous environment we may have several requests being processed at the same time, so we’re going to wrap our MongoDB connection into a connection pool. There is connection pool logic built into em-synchrony for us to utilize.

I’m also, for the sake of this tutorial, going to say we don’t want to create a connection to a real Mongo instance when we’re running our spec tests. So, I’m going to restrict the connection creation to only happen in development mode.

Make sense? Ok, add the following to your config/http_log.rb file.

environment(:development) do
config[‘mongo’] = EventMachine::Synchrony::ConnectionPool.new(size: 20) do
conn = EM::Mongo::Connection.new(‘localhost’, 27017, 1, {:reconnect_in => 1})
conn.db(‘http_log’).collection(‘aggregators’)
end
end

The environment(:development) will cause this code block to only execute if we’re in development mode. We could have also passed :test or :production depending on which mode we want. Along with a single option, you can also provide an array. So, we could have said environment([:test, :development]) to execute in both test and development mode but not in production mode.

I’m going to leave it as an exercise to you, my reader, to figure out the synchrony and mongo code we’re using in the connection. Let’s just leave it at, we will now have access to a MongoDB collection object in config['mongo'] which we can use in our application.

Just before we return the status, headers and body we’re going to record the request into Mongo. We’ll do that by adding:

record(process_time, resp, env[‘client-headers’], response_headers)

The implementation of record uses the various environment variables we’ve seen above to do it’s work:

def record(resp, client_headers, response_headers)
e = env
EM.next_tick do
doc = {
request: {
http_method: e[Goliath::Request::REQUEST_METHOD],
path: e[Goliath::Request::REQUEST_PATH],
headers: client_headers,
params: e.params
},
response: {
status: resp.response_header.status,
length: resp.response.length,
headers: response_headers,
body: resp.response
},
date: Time.now.to_i
}

if e[Goliath::Request::RACK_INPUT]
doc[:request][:body] = e[Goliath::Request::RACK_INPUT].read
end

e.mongo.insert(doc)
end
end

There are a couple of things to note, first, I’m doing this work in an EM.next_tick block so that I don’t block the response from returning to the client. Because I’m doing this in the next tick I’m going to lose access to the env so I tuck it away into a e variable which gets bound up with the next_tick block.

Finally, the last thing we do is call e.mongo.insert(doc) which will access the config['mongo'] object we created earlier and call the insert method.

With that code added, all of our tests fail. We’re going to need to create a mongo key in the environment that the tests can use.

To do that, I’ve created a mock_mongo method:

def mock_mongo
@api_server.config[‘mongo’] = mock(‘mongo’).as_null_object
end

Which I call inside the with_api(HttpLog) block. I’ll leave it as an exercise to the reader to create some specs around the record method.

The default API server created inside with_api will be made available to the user through the @api_server variable.

With that, you should have a working proxy logger API. If you run webserver on port 8080 and execute the our http logger you can then make requests to port 9000 and see the results logged into mongo. Looking in mongo you should see something similar to:

connecting to: test
> use http_log
switched to db http_log
> db.aggregators.find();
{ "_id" : ObjectId("4d6efbbad3547d28f3000001"),
  "request" : {
                "http_method" : "GET",
                "path" : "/",
                "headers" : {
                              "User-Agent" : "curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3",
                              "Host" : "localhost:9000",
                              "Accept" : "*/*",
                              "Version" : "1.1" },
                "params" : { "echo" : "test" },
                "body" : "" },
   "response" : {
                "status" : 200,
                "length" : 19,
                "headers" : {
                              "Content-Type" : "application/json; charset=utf-8",
                              "Server" : "PostRank Goliath API Server",
                              "Vary" : "Accept",
                              "Content-Length" : "19",
                              "Date" : "Thu, 03 Mar 2011 02:23:54 GMT" },
                "body" : "{\"response\":\"test\"}" },
   "process_time" : 0.007593870162963867,
   "date" : 1299119034 }

With that, have fun playing with Goliath. We’re hoping people find some interesting uses for the framework.

Ramblings on programming Cocoa with Ruby

dj2 — Thu, 17 Jun 2010 04:51:46 +0000

This post started with a point. It didn’t end with one. So, I’m going to start it again and just get to the point. What makes a good Ruby Cocoa development environment. I’ll get into my rambling thoughts below, but quickly; straight up XCode/Interface Builder, HotCocoa, Interface Builder and command line building, some combination of all three or something else.

If you were going to do it, how, or what would you do?

I’ve been playing with the above three options as I’ve trying to figure this out myself. I’ve done a few straight HotCocoa applications (SilverLining, Rife and Postie) and, while they worked out well, I found the need to do all the layout by hand tedious and boring. I really like Interface Builder for ease of UI creation.

Taking that, I tried the XCode/Interface Builder solution and went to the bundled MacRuby XCode templates. When programming Objective-C I really enjoy XCode, it makes things easy when doing purely native Mac applications. That said, XCode irks me when doing Ruby development. Maybe it’s muscle memory, not sure, but I like using TextMate to do my Ruby work.

The approach I’ve been using in my latest fiddlings (Touchstone) started with the XCode templates but I broke out, stole some of the rake tasks from HotCocoa, and switched to TextMate and the command line.

The biggest issue I’ve run into is the Interface Builder integration kinda sucks. It does work, but you have to reload the class files manually all the time. A bit frustrating.

On the flip side, I can organize my code however I want. The tendency for Objective-C programs to have all their code in the root directory drives me up the wall. Sure, XCode hides this, you can change it, but, by default, everything ends up in the root folder. Maddening.

With Touchstone, I’ve put all the application code, similar to Rails, under App/Controllers, App/Models, App/Helpers and App/Views. The same structure is copied into the .app file when it’s generated. Everything feels much cleaning. The .xib and .xcdatamodel files get compiled and moved as needed.

I know I could have used the XCode build stuff but having to launch XCode and getting the debugging output in an XCode window didn’t feel right for me. I wanted something a bit more contained.

Coming back to the original question, I think what I want to see, is something similar to Touchstone but with the convenience of HotCocoa. The HotCocoa mappings make a lot of things feel more Rubyish, feel more natural. Those bindings, combined with Interface Builder, I think, would make a kick-ass Cocoa programming environment.

Again, how would you do it?

Introducing QueryStringParser

dj2 — Thu, 17 Jun 2010 01:18:40 +0000

Over at PostRank we serve a lot of data through our API servers. All of those servers parse query strings. Along with, obviously, the query string, we also encode the post data in query string format. This means we’re doing a lot of parsing of query strings. Millions of query strings a day.

Parsing time for those query strings starts to add up. We started with the query string parser from Camping and that served us well for over a year. Eventually, parsing the query data was over 80% of the processing time and something needed to be done. From there we briefly dabbled with the Rack::Utils query string parser. While faster, this still wasn’t fast enough.

From Rack, in a fit of desperation, we wrote our own. With the new version, written in C using Inline Ruby, we were finally fast enough. The parser has served us well but was starting to show some age with the Inline Ruby. We’ve started using Ruby 1.9 for our new API servers while the old servers were on 1.8. RVM doesn’t deal with Ruby Inline very well and we’d end up having to erase the Inline cache when switching between server versions. To that end, we converted the Inline Ruby version into a Ruby extension and, to help deal with Bundler, decided to push it out the door as a gem.

You can check it out on Github or install the gem from gemcutter. At this point, the gem does what we need it too. It doesn’t handle every case, but you should be able to update it, if needed, to handle what you need.

require 'query_string_parser'
p QueryStringParser.qs_parse("my=query&string=parser")
=> {"my"=>"query", "string"=>"parser"}

include QueryStringParser
qs_parse("does[]=array&does[]=data&does[3]=values&does=more")
=> {"does"=>["array", "data", "values", "more"]}

As you can see from the example above individual params will be set their values. If a parameter exists multiple times it will be turned into an array of values. You can set a number into the brackets but it will be ignored by the parser.

If you’re parsing a lot of query strings give the parser a try. Let us know what you think.

Download and XML parsing with HotCocoa

dj2 — Mon, 08 Feb 2010 05:47:16 +0000

I’ve been working on Rife, a Google Reader client, over the last few days and have been digging my way through some more HotCocoa mappings. I figured the best way to remember some of this stuff is to write it down so, the following will look at synchronous and asynchronous downloads and writing a XML parser in HotCocoa/MacRuby.

So, what are we creating you ask? Well, as I said, I’ve been playing with Google Reader APIs and we’re going to do a synchronous request to Google for an identifier token. Once we’ve successfully authenticated we’re going to make an asynchronous request for our unread items. We’ll then parse the resulting XML document and spit the titles out to the console.

As with any HotCocoa application the easiest way to get started is to have system setup the shell of our application. We’ll use the hotcocoa command to create our application which I’m calling titles.

titania:example dj2$ hotcocoa titles

In order to authenticate to Google we’re going to need your username and password. Since I’m going to do the output to the console for demonstration purposes I’ll use the main application window to show the fields for username and password and a save button.

require ‘rubygems’
require ‘hotcocoa’

class Application
include HotCocoa

def start
application(:name => "Titles") do |app|
app.delegate = self

window(:frame => [100, 100, 200, 200], :title => "Titles") do |win|
win.center
win.will_close { exit }

win << label(:text => "Username", :layout => {:start => false})
win << @username_field = text_field(:layout => {:start => false, :expand => [:width]})

win << label(:text => "Password", :layout => {:start => false})
win << @password_field = secure_text_field(:layout => {:start => false, :expand => [:width]})

win << save = button(:title => "save", :layout => {:start => true}) do |button|
button.on_action { authenticate }
end

@username_field.setNextKeyView(@password_field)
@password_field.setNextKeyView(save)
save.setNextKeyView(@username_field)
end
end
end

def authenticate
puts "DO AUTH #{@username_field.to_s} #{@password_field.to_s}"
end
end

Application.new.start

If you run the application by executing macrake in the titles directory you should see the main application window. Typing something into the username and password fields and pressing save you should see something similar to the following in your terminal.

DO AUTH test test

With our framework setup let’s get to the interesting stuff. First up, authenticating so we can retrieve our identifier from Google. We’re going to make a synchronous request to retrieve the identifier and, if successful, call a method to start retrieving our reading list.

def authenticate
username = @username_field.stringValue
password = @password_field.stringValue

query = "https://www.google.com/accounts/ClientLogin?" +
"Email=#{CGI.escape(username)}&Passwd=#{CGI.escape(password.to_s)}" +
"&source=HotCocoaExample&service=reader"

url = NSURL.URLWithString(query)
request = NSMutableURLRequest.requestWithURL(url)
request.addValue("HotCocoaExample", forHTTPHeaderField:"source")
request.addValue("2", forHTTPHeaderField:"GData-Version")

response = Pointer.new("@")
data = NSURLConnection.sendSynchronousRequest(request, returningResponse:response, error:nil)
data = NSString.alloc.initWithData(data, encoding:NSUTF8StringEncoding)

if data =~ /^SID=(.*)\n/
@sid = $1

retrieve_reading_list
else
raise Exception.new("Authentication failed with: #{data}")
end
end

def retrieve_reading_list
puts @sid
end

If you add the above to your application, and add require 'cgi', you should be able to run the program, put in your username and password and get a long line of characters spit out on the terminal. Those characters are your Google SID.

Let’s look a bit closer at what we’re doing in the authenticate method. We start by grabbing the stringValue for the username and password fields. Then, using these values, we build the query string needed for authentication. This query string is used to build a URL object by calling NSURL.URLWithString(query). With the URL in hand we can start building our request object. This is done by calling NSMutableURLRequest.requestWithURL(url). I’m using the mutable version of the request as I want to add a few extra header values. These are both added with addValue(value, forHTTPHeaderField:field).

When we execute our request the system is going to want to put our response object somewhere. In the Cocoa version the method accepts a NSURLResponse **response parameter. In order to handle the response we need to create a Pointer object which is a MacRuby object for handling these pointers to objects. We want our pointer to point to an object so we use Pointer.new("@").

With the response setup we call NSURLConnection.sendSynchronousRequest and provide our request and response objects. I don’t care about the error, but if you do, you’d want to pass in something similar to our response pointer. The request will return a NSData object which we convert to a string using the initWithData initialization method of NSString.

With the string in hand we try to extract our SID and, if successful, execute the retrieve_reading_list method which just spits out the SID.

OK, cool, we’ve now got our authentication token and are ready to move onto the asynchronous request to get our reading list.

def retrieve_reading_list
query = "https://www.google.com/reader/atom/user/-/state/com.google/reading-list?" +
"xt=user/-/state/com.google/read&ck=#{Time.now.to_i * 1000}&n=2"

NSURLConnection.connectionWithRequest(request, delegate:self)
end

def connectionDidFinishLoading(conn)
puts NSString.alloc.initWithData(@receivedData, encoding:NSUTF8StringEncoding)
end

def connection(conn, didReceiveResponse:response)
if response.statusCode != 200
puts "BAD STATUS: #{response.statusCode}"
p response.allHeaderFields
end
end

def connection(conn, didReceiveData:data)
@receivedData ||= NSMutableData.new
@receivedData.appendData(data)
end

Similar to the synchronous method we start by building our query string, NSURL and NSMutableURLRequest. We’ve added a cookie to our request object to hold the SID retrieved earlier from Google.

We fire the request by calling NSURLConnection.connectionWithRequest(request, delegate:self). We specific ourselves as the delegate for the connection. There are a few delegate methods we can implement to receive data and get notified of request states. These are:

connectionDidFinishLoading(connection)
connection(connection, didReceiveResponse:response)
connection(connection, didReceiveData:data)

We’ll look at our implementation of each of these callbacks in turn. First, in connectionDidFinishLoading(conn) we’re just printing out the data retrieved. We need to convert the data, similar to what we did in the synchronous request, from a NSData object to a NSString object.

In connection(conn, didReceiveResponse:response) we’re just checking to see if we got a 200 response code from the server. In all other cases we print an error.

The main work is done in connection(conn, didReceiveData:data) where we create a NSMutableData object if needed and append any data received into the mutable data object.

Running the code at this point should dump the first two items in your reading list to the console. The data will be a big mess of XML but we’ll look at parsing that in the next step.

def connectionDidFinishLoading(conn)
xml = HotCocoa.xml_parser(:data => @receivedData)
@receivedData = nil

xml.on_start_document { puts "Starting Parse" }
xml.on_end_document do
HotCocoa.notification(:post => true, :name => "all_entries_loaded", :object => nil, :info => nil)
end
xml.on_parse_error { |err| puts "Parse error #{err.inspect}" }

xml.on_cdata { |cdata| @elem_text += cdata.to_s }
xml.on_characters { |chars| @elem_text += chars.to_s }

xml.on_start_element do |element, namespace, qualified_name, attributes|
@elem_text = ”
end

xml.on_end_element do |element, namespace, qualified_name|
puts @elem_text if element == ‘title’
end

xml.parse
end

We’re finally getting into some HotCocoa specific code with our XML parser. HotCocoa defines a mapping wrapper around NSXMLParser and provides a set of delegate methods. These delegates mean we don’t have to set our class as the delegate and create a bunch of methods. They mean we can attach our code as blocks on our XML object. All the better if you want to define a few parsers in one class.

We start off by creating a HotCocoa.xml_parser. The parser accepts NSData objects so we don’t need to convert our response data to a string. We then setup eight callbacks. There are actually a bunch more callbacks that can be hooked up and you should look at the xml_parser mapping code to see if you need any of them. For our purposes, we only really care about eight.

The on_start_document, on_end_document and on_parse_error callbacks, as you can probably guess, get called when we start parsing, when we finish parsing and when we receive a parse error, respectively. We don’t really care about start in this example, but I put it in anyway. When we’ve completed parsing we send a notification and other application code can then listen for this notification and do anything it needs. If we wanted we could store the entries as they’re parsed and provide them to the :object key. This would make those entries available to anyone that receives the notification.

If we receive either CDATA, with on_cdata, or text, with on_characters, we append the content to our current elements text. When we receive the open tag of a new element, on_start_element, we dump our current element text as we’ve started a new element. We can also take a look at the elements name, attributes, namespace and qualified name, if desired.

Finally, in on_end_element we print out the current element text if the element we’re finishing has a name of title.

With all the callbacks configured we use xml.parse to start the parser. You should, if you run this example, see the titles and authors of the first two posts in your reading list. (The author name is also called title and I’m not bothering to check that the parent element is entry before spitting it out.)

That’s it. You can now make synchronous and asynchronous requests for content and parse any resulting XML.

One last thing before you go. Both of the requests we did above were GET requests. You can do other types of requests using the same methods as above you just need a slightly different setup for the request. You can see a POST request below.

request = NSMutableURLRequest.requestWithURL(url)
request.addValue(SOURCE, forHTTPHeaderField:"source")
request.addValue("2", forHTTPHeaderField:"GData-Version")
request.addValue("SID=#{@sid}", forHTTPHeaderField:"Cookie")

body="first=1&second=2&third=3"

request.setHTTPMethod(‘POST’)
request.setValue(‘application/x-www-form-urlencoded’, forHTTPHeaderField:‘Content-Type’)
request.setValue(body.length.to_s, forHTTPHeaderField:‘Content-Length’)
request.setHTTPBody(body.dataUsingEncoding(NSASCIIStringEncoding))

The first few lines should look familiar from creating our asynchronous request above. Since we’re going to be posting the data we use setHTTPMethod('POST') to setup the request method. We’ve form encoded the data so we set the appropriate Content-Type and set the Content-Length. Note, we convert the length to a string before sending to setValue. Finally, we set the body of the post with setHTTPBody. You need to convert the body string into a NSData object which we do with the dataUsingEncoding method. If you don’t convert the body to NSData you’ll end up sending a nil body with your post request.

Poking Objective-C with a Testing Stick

dj2 — Mon, 26 Oct 2009 20:32:14 +0000

I’ve wandered back into Objective-C coding land recently. After spending so much time doing Ruby work I’ve gotten used to writing unit tests and using mock objects. To that end, I spent a bit of time figuring out OCUnit (built into XCode) and OCMock. I figured I’d write some of this down so I don’t forget for the next time I try to set this all up.

We’re going to work with a simple Cocoa Application that connects to an external web resource, in this case, Google Reader authentication. We’ll setup the testing bundle to run when our main application is built and create a mock object so we don’t hit the external resource on every test run. I’m going to be using XCode version 3.2 and create a Cocoa Application called UnitTesting. If you build and run this application you should see an empty window on screen. If you bring up the Build Results window (Build -> Build Results) you’ll see some information about the current build.

With our app setup, we’ll start integrating the unit tests. Click on the Targets item in the project folder. Select Add -> New Target. Select Unit Test Bundle and press Next (Note, make sure you’re in the Cocoa and not the Cocoa Touch section when selecting Unit Test Bundle). I named my target Unit Tests and hit Finish.

At this point if you right click on the UnitTesting target and select Build “UnitTesting” everything should work correctly. If you right click on Unit Tests and select Build “Unit Tests” you should receive a build failure.

Let’s add some tests. The first step is to create a new group to hold our test files. Right click on the UnitTesting item in the project draw and select Add -> New Group. Name the new group Tests. Now, right click on the Tests group and select Add -> New File…. You’ll want to add an Objective-C test case class (Note, make sure you’re in the Cocoa Class section of the new dialog and not the Cocoa Touch Class section or you’ll get an iPhone test class). Name the test GReaderTest.m and de-select the Also create “GReaderTest.h” option. The reason for this is that the headers are usually empty so there is no point in creating the extra file. You’ll also want to make sure you have the Unit Tests target selected.

When working with OCUnit you need to name each of your test classes SomethingTest. The trailing Test is required. In a similar vein, each of the tests themselves needs to start with test. So, something like testAuthentication.

Since we didn’t create a header file we’ll need to setup the interface for the test in the .m file.

#import

@interface GReaderTest : SenTestCase
@end

@implementation GReaderTest
@end

You should be able to build the Unit Tests target now and have the build succeed. If the build doesn’t succeed, and you see a message about UIKit then you selected the Cocoa Touch unit test bundle instead of the Cocoa unit test bundle.

With the unit tests building we can add them into our main build as a dependency. Right click on the UnitTesting target in the project drawer and select Get Info. In the General section add a new Direct Dependency for the Unit Tests target.

Now, when you press apple-B to build the project you should see your unit tests executed before the main build phase.

Ok, with everything setup we can start testing. First step, each test in this set will be using our GReader object. So, we’ll add setUp and tearDown methods that will be executed before and after each test, respectively.

#import
#import "GReader.h"

@interface GReaderTest : SenTestCase {
GReader *gr;
}
@end

@implementation GReaderTest
- (void)setUp {
gr = [[GReader alloc] init];
}

- (void)tearDown {
[gr release];
}
@end

This, of course, won’t execute as we haven’t created our GReader object yet. Let’s do that now.

Right click on the Classes group and select Add -> New File…. Add a new Objective-C class which is a subclass of NSObject. Call this new class GReader. The new class should be attached to both our main target and the Unit Tests target.

Now, for our little app, the first thing we’ll need to do is authenticate with Google Reader. There is a really good document on the Reader API from the pyrfeed project. We’ll need to post some specific data to a given end point and parse the response.

For our unit tests, we don’t actually want to hit the Google endpoint. There is too much time involved and we want our unit tests to be fast. So, we’ll need to do some mocking in order to verify the call is happening, but not actually make the call itself.

For this we’ll use OCMock. I’m going to add the test first and then we’ll add the OCMock.framework into the project. First, we need to import OCMock. This is done by adding #import to the beginning of the GReaderTest.m file.

The test is defined as follows.

- (void)testAuthentication {
id mock = [OCMockObject partialMockForObject:gr];
[[[mock stub] andCall:@selector(fakeAuthenticationPost:)
onObject:self] post:[OCMArg any]];

[gr authenticateWithUsername:@"dan" password:@"password"];
}

- (NSString *)fakeAuthenticationPost:(NSString *)request {
NSArray *d = [request componentsSeparatedByString:@"&"];

STAssertTrue([d containsObject:@"Email=dan"], @"Username not set correclty into request");
STAssertTrue([d containsObject:@"Passwd=password"], @"Password not set correctly in request");

return @"SID=mysid\nLSID=mylsid\nAuth=myauth";
}

As you can probably tell, we’ve added two methods. There is only one test, testAuthentication but we needed a helper function to deal with the mock post call. Let’s take a look at what’s going on in these methods. We know that the GReader object will be making a call that we want to mock. So, we need to create a partial mock object that sits around our GReader object. This is done as: id mock = [OCMockObject partialMockForObject:gr];. With the mock created, we can stub out specific methods of the GReader object, this is called Method Swizzling in Objective-C land.

In order to swizzle the method we have [[[mock stub] andCall:@selector(fakeAuthenticationPost:) onObject:self] post:[OCMArg any]];. So, we create a new stub on our mock object. We then tell the stub to call the fakeAuthenticationPost defined in the current object whenever the post method is called on the GReader object. Our post method takes one parameter so we specify [OCMArg any] to allow any argument through.

Finally, we call the authenticateWithUsername:password: on the GReader object to kick off the authentication.

The second method we defined, fakeAuthenticationPost, will be called instead of the post method in the GReader object. To that end, it will receive the same parameter, the NSString that is pass to post. To be on the safe side, I’m verifying that we’re properly passing the required email and password fields in the string. I then fake some return data that is similar to a successful response from Google.

If we try to build the project at this point we’re going to get a lot of errors. First, since we haven’t added the OCMock framework and second, we haven’t created the authenticate or post methods for our GReader object.

First things first, let’s get the OCMock framework setup. To do that, you’ll need to download OCMock. You can grab the .dmg file off the OCMock pages. When you extract the archive you’ll see the OCMock.framework and the source directories. In order to keep everything in Git, I created a Framework directory in my UnitTesting directory. I then copied the OCMock.framework directory into this new Framework directory.

You could also install OCMock in the /Library/Frameworks directory but I like having it in Git as not all the developers may have OCMock installed.

Back in XCode, we need to add the framework to our project. Right click on the Frameworks group in the project directory. Select Add -> New Group. Name the new group Testing Frameworks. Note, this isn’t required, I just like the separation it provides. Finally, right click on Testing Frameworks and select Add -> Existing Frameworks... then press the Add Other… button. Navigate to the OCMock.framework directory you just copied into Frameworks directory and press Add. Make sure the new framework is hooked up to the Unit Tests target. Right click on the framework and hit Get Info in the general tab you can verify the targets.

Building the project at this point will get some warnings about missing functions and a crash executing the unit tests. In order to fix the crash we need to setup the build to copy the OCMock framework into our build directory. I’m not entirely sure why this is needed, something about one of the paths set in the framework, but it does get things working.

Right click on the Unit Tests target and select Add -> New Build Phase -> New Copy Files Build Phase.

You need to set the Destination to Absolute Path and the Full Path to $(BUILT_PRODUCTS_DIR). Once the Copy Files phase is created drag the OCMock.framework from the Test Frameworks group into the copy phase. The copy phase needs to be placed between Compile Sources and Link Binary With Library phases.

At this point, we should be able to execute our build again and we’ll get a failure [NSProxy doesNotRecognizeSelector:post]. This is good. This means our mock is setup correctly and is trying to hook into our non-existant post method.

Let’s go create a couple methods so things compile correctly. First we update the GReader.h file as follows.

@interface GReader : NSObject
- (void)authenticateWithUsername:(NSString *)username password:(NSString *)password;
- (NSString *)post:(NSString *)request;
@end

And the implementation.

#import "GReader.h"
@implementation GReader
- (void)authenticateWithUsername:(NSString *)username password:(NSString *)password {
[self post:[NSString stringWithFormat:@"Email=%@&Passwd=%@", username, password]];
}

- (NSString *)post:(NSString *)request {
return @"My post data";
}
@end

With that in place our build should succeed. You can make sure that things are working correctly by modifying [gr authenticateWithUsername:@"dan" password:@"password"]; to something similar to [gr authenticateWithUsername:@"stan" password:@"password"]; and you should see a build failure.

That’s it. We have the build system setup and the mock objects hooked up. We can now continue down our TDD path. You can see an example project that I’ve uploaded to GitHub.

What’s your moniker

dj2 — Fri, 09 Oct 2009 02:49:15 +0000

We were playing with some ideas over at PostRank and realized we needed a way to give out some unique codes. We didn’t want some random string of letters and numbers as that isn’t very memorable. We wanted real words. We wanted something entertaining.

I spent a bit of time looking around. The closest thing I found to what we wanted was Webster. While Webster would work, I wasn’t a big fan of the words we were getting out of the system in some quick tests. After some more fruitless searching, in a fit of not invented here syndrome, I created my own.

Enter, Moniker. Moniker will take a list of descriptive words and a set of animals and give you a string. There are, currently, just over 42 thousand combinations. Enough for what we needed. The system is pretty simplistic and it’s up to you to make sure you aren’t getting duplicates.

titania:~ dj2$ irb
>> require ‘rubygems’
>> require ‘moniker’
=> true
>> Moniker.name
=> "octagon-zebra"
>> Moniker.name
=> "shallow-lion"
>> Moniker.name
=> "concave-parrot"

The code is all up on GitHub so take a look and feel free to play. Let me know if you’ve got any ideas for improvements

Flicking the iPhone

dj2 — Thu, 13 Aug 2009 14:18:24 +0000

I’ve been playing with my iPhone a bit lately. Trying to work out an application that I think will be useful (more on that some other time). In the mean time, I wanted to let the user of the application flick between views to see different detailed view screens. Each flick should take the user either forward or back in the list. The transitions should push the new item into view and have a little bounce on the end.

Turns out, this wasn’t trivial. I’m not sure now why I thought it would be trivial. Maybe because I’ve seen it in a few apps.

Anyway, what follows is how I did it. Maybe there is an easier way, if so, let me know, but this appears to work.

I’m going to create a simple Core Data backed, Navigation-based iPhone application. There will be two screens, the main list screen and a detailed view. The user will be able to flick between detailed views. Note, there is no real error checking, and possibly memory leaks in this code. You’ll need to fix up as appropriate for your application.

Firing up XCode, create a new project. Under the iPhone OS Applications template section, you’ll want to select Navigation-based Application. Make sure you’ve got Use Core Data for storage selected as well. In my case I’m naming the application Flick.

With the application created you should be able to execute it in the simulator and add a series of timestamps to the main view.

Before we start adding screens, let’s create a class to hold our model entity. Double click on the Flick.xcdatamodel file to open the data modeler. Click on the Event entity and press command-n. Select, in the Mac OS X Cocoa section, Managed Object Class. Click through to finish the creation as the rest of the defaults will suffice. You should now have Event.h and Event.m files created in your project.

With the base application in place we still need to create a screen to allow viewing of our events. I’m backing this screen with a UITableViewController because that’s how my application does it. You could probably use a plain UIViewController if you don’t need to extra functionality of the table view controller.

Add a new file to the project and, under iPhone OS Cocoa Touch Class, select Objective-C class and set a Subclass of UITableViewController. Name the file EventViewController.m and have the .h file auto generated.

Opening up RootViewController.m we need to hookup the code to create our new view when one of the rows is selected.

First, lets mark the rows as having another view. Add cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator; into the tableView:cellForRowAtIndexPath: method right after the UITableViewCell is created.

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
Event *event = (Event *)[fetchedResultsController objectAtIndexPath:indexPath];

EventViewController *controller = [[EventViewController alloc] initWithStyle:UITableViewStyleGrouped];
controller.event = event;

[self.navigationController pushViewController:controller animated:YES];
[controller release];
}

Using the tableView:didSelectRowAtIndexPath: delegate method we retrieve the selected event from our fetchedResultsController. We then create a new EventViewController with a table style of UITableViewStyleGrouped. There are two styles to tables Grouped and Plain.

UITableViewStylePlain: A plain table view. Any section headers or footers are displayed as inline separators and float when the table view is scrolled.
UITableViewStyleGrouped: A table view whose sections present distinct groups of rows. The section headers and footers do not float.

With the controller created we assign the selected event to the controller. Finally, we push the new view controller into the navigation stack using [self.navigationController pushViewController:controller animated:YES]. This will set our new view as the view to be displayed. Oh, and don’t forget to import EventViewController.h and Event.h.

We want our new view controller to have a back button. If you don’t set the name in the MainWindow.xib file the back button will be available, but invisible. Double click the MainWindow.xib file to open it in Interface Builder. Click on the navigation bar in the view and press shift-command-i to open the inspector. Press command-1 to switch to the attributes panel. In the Back Button field enter Events. You can now save and exit Interface Builder. Thanks to Owen, setting self.navigationItem.title = @"Events" in the viewDidLoad method of RootViewController will set the correct text into the back button.

Continuing on, we can fill in the EventViewController files, starting with the header.

#import "Event.h"

@interface EventViewController : UITableViewController {
Event *event;
}
@property (nonatomic, retain) Event *event;
@end

The view controller has one attribute, the event that was selected. We setup a property for the event to handle the getters and setters for us.

#import "EventViewController.h"

@implementation EventViewController

@synthesize event;

- (void)viewDidLoad {
self.navigationItem.title = @"Event Info";
}

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return 1;
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return 1;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
static NSString *LocationCellIdentifier = @"Timestamp";

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:LocationCellIdentifier];
if (cell == nil) {
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle
reuseIdentifier:LocationCellIdentifier] autorelease];
cell.accessoryType = UITableViewCellAccessoryNone;
}

NSDateFormatter *dateFormat = [[[NSDateFormatter alloc] init] autorelease];
[dateFormat setDateStyle:NSDateFormatterLongStyle];
[dateFormat setTimeStyle:NSDateFormatterLongStyle];

cell.textLabel.text = [dateFormat stringFromDate:event.timeStamp];

return cell;
}

- (void)dealloc {
[super dealloc];
}
@end

Next up is the implementation file. When the view finishes loading we want to set the title to display Event Info. This is done in viewDidLoad by calling self.navigationItem.title = @"Event Info".

We’re only going to show one thing in our table, the timestamp, so we setup the table to have a single section and a single row. We then create a cell to display the time stamp.

You should be able to build and run the application at this point. You can click on the events to move to the subview. From there you can navigate back to the main list.

With that, we’re ready to add some flicking to our application.

There is no flick event built into the iPhone APIs that I could find. The way to achieve a flick is to listen for the touchesEnded:withEvent: delegate method and determine if a flicked happened. The one catch, this delegate is available on UIView objects. We don’t, currently, have a UIView object we can attach the delegate method too.

So, we’re going to subclass UIView deal with the flicking, then let our parent EventViewController know when the flick happened so we can switch views. Sound good? Ok, let’s go.

Add a new class to the project. Under iPhone OS Cocoa Touch Class select Object-C class. Make sure UIView is selected in the drop down. Name the new file EventView.m.

@protocol EventViewDelegate;

@interface EventView : UITableView {
id delegate;
}
@property (nonatomic, assign) id delegate;
@end

@protocol EventViewDelegate
- (void)eventView:(EventView *)view flickDirection:(int)dir;
@end

There are a couple things going on here. First, I switched the inherited class to UITableView as that’s what we’re actually dealing with.

We add one attribute to the EventView class. We need to be able to assign the controller as a delegate for our view so we can notify the controller of the flick. In order for the table to continue working, we also need to make sure we maintain the UITableViewDelegate protocol already attached to the delegate object in the super class.

Our protocol is pretty simple, we need one method implemented, eventView:flickDirection:. This will be called when the view is flicked and set the flickDirection to -1 for a left flick and 1 for a right flick.

#import "EventView.h"

#define MIN_FLICK_DISTANCE 10.0

@implementation EventView
@synthesize delegate;

- (int)flicked:(UITouch *)touch {
CGPoint start = [touch previousLocationInView:self];
CGPoint end = [touch locationInView:self];

double x = end.x – start.x;
double y = end.y – start.y;
double dist = sqrt((x * x) + (y * y));

if (dist > MIN_FLICK_DISTANCE) {
if (end.x < start.x) return 1;
else return -1;
}
return 0;
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
UITouch *touch = [touches anyObject];
int dir = [self flicked:touch];

if (dir != 0) [self.delegate eventView:self flickDirection:dir];

[super touchesEnded:touches withEvent:event];
}

- (void)dealloc {
[super dealloc];
}
@end

With the header out of the way we can implement the class. The touchesEnded:withEvent: method will be executed when the touch is complete. We can access the touch event, using [touches anyObject] and look at the [touch previousLocationInView:self] and [touch locationInView:self] methods to access the two touch points.

If these points are more then MAX_FLICK_DISTANCE apart then we have a flick. As long as we have a flick we notify our delegate by calling the eventView:flickDirection: method we defined in our protocol.

With the view created, we can hook it up to our EventViewController. Open up EventViewController.h. We need to add an import for the EventView.h file and then add the EventViewDelegate protocol to the view controller.

@interface EventViewController : UITableViewController

Moving over to EventViewController.h we need to add an import for the RootViewController.h. We'll be accessing it's fetched results in order to get the new view information.

We need to load our new EventView as the view to use for the controller. We do this by overriding loadView

- (void)loadView
{
EventView *eventView = [[[EventView alloc] initWithFrame:CGRectZero
style:UITableViewStyleGrouped] autorelease];
[eventView setDelegate:self];
[eventView setDataSource:self];

self.view = eventView;
self.tableView = eventView;
}

Nothing too special here, we create our EventView and tell it that the current controller is the delegate and data source for the view. Finally, we assign the new view to the controllers view and tableView methods. You need to assign both of these for things to work properly.

The last step is to implement the eventView:flickDirection: method.

- (void)eventView:(EventView *)view flickDirection:(int)dir
{
NSFetchedResultsController *frc = [[[self.navigationController viewControllers] objectAtIndex:0] fetchedResultsController];

NSIndexPath *path = [frc indexPathForObject:[self event]];
NSInteger row = [path row];

if ((dir == -1) && (row > 0)) row --;
else if ((dir == 1) && (row < ([[frc fetchedObjects] count] - 1))) row ++;

if (row == [path row]) return;

NSIndexPath *newPath = [NSIndexPath indexPathForRow:row inSection:[path section]];
[self setEvent:[frc objectAtIndexPath:newPath]];

[self.tableView reloadData];
}

The idea here is simple, grab the fetched results from the root view using [[[self.navigationController viewControllers] objectAtIndex:0] fetchedResultsController]. The root view is always at the bottom of the view stack. The fetched results controller can then be used to find the index for the event that we're currently viewing. We can then get the next view, either left or right based on flick direction, to be displayed. We set that event into the view and reload the table data.

Building and running you should be able to flick between views. Although, there is an issue, the visuals really suck. Let's do something about that.

In order to make things look good we should push the new views into place and, if we're on the end view, bounce a little to show the user they can't go any further.

For this, we're going to dip into a little but of Core Animation. To that end, we need to import into the EventViewController.h file and add the QuartzCore.framework into our project.

We'll start with a little helper method.

- (void)addAnimation:(NSString *)name subtype:(NSString *)subtype duration:(float)duration
start:(float)start end:(float)end delegate:(id)animDelegate {
CATransition *anim = [CATransition animation];

[anim setDuration:duration];
[anim setType:kCATransitionPush];
[anim setSubtype:subtype];
[anim setStartProgress:start];
[anim setEndProgress:end];
[anim setDelegate:animDelegate];
[anim setTimingFunction:[CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseOut]];

[[[self.view superview] layer] addAnimation:anim forKey:name];
}

addAnimation:subtype:duration:start:end:delegate: adds a new animation to the system. We're always using push animations and always using the same ease timing function. Otherwise, we can set things up as we need.

To start, add the following to the end of eventView:flickDirection:

[self addAnimation:@"SwitchView"
subtype:(dir == -1 ? kCATransitionFromLeft : kCATransitionFromRight)
duration:0.5
start:0.0
end:1.0
delegate:nil];

If you run this, you should be able to flick between views with a nice push animation. You can change the duration to make the transition slower or faster as desired.

Now, let's add the bounce when we're at the end of our data. Inside eventView:flickDirection: change if (row == [path row]) return; to the following.

if (row == [path row]) {
[self addAnimation:@"PushHalfOut"
subtype:(dir == -1 ? kCATransitionFromLeft : kCATransitionFromRight)
duration:0.25
start:0.0
end:0.25
delegate:self];
return;
}

You'll notice we set the delegate in this instance to ourselves. This will cause animationDidStop:finished: to be called when the animation is finished. We're going to add that callback next.

- (void)animationDidStop:(CAAnimation *)animation finished:(BOOL)flag {
[self addAnimation:@"PushHalfIn"
subtype:[(CATransition *)animation subtype]
duration:0.25
start:0.25
end:0.0
delegate:nil];
}

With the first animation we're shifting the view off screen by a quarter of the screen. Then, when that animation is finished, we trigger a second animation to shift the view back on screen again. Giving the appearance of a slight bounce.

With that, we have our views flicking and bouncing. You can grab the full source to this tutorial at http://github.com/dj2/Flick.

Toolbars with HotCocoa

dj2 — Tue, 21 Jul 2009 20:28:09 +0000

I had the opportunity to add a toolbar to my Silver Lining app the other day and though I’d write down how I did it. This would, probably, have been easier if I had an understanding of the Cocoa Toolbar.

The main thing that kept tripping me up is that you don’t add toolbar items directly to the toolbar. Each item you want to add to the toolbar is given an identifier (HotCocoa will generate one from the label if needed). Then, when you create your toolbar, you specify which toolbar items are in the toolbar by default and which items are available to be put in the bar.

Once the toolbar is created we don’t just append it to the window with the normal << operator. We need to use toolbar= to assign the toolbar to the window.

The toolbar we’re going to create is fairly simple. We want a button, with image, on the left for reloading and a search field on the right. We’ll put a flexible spacer in the middle to put them on opposite sides of the screen. (Note, there is currently a bug in HotCocoa where our specified items will be to the right and the spacer to the left. Things may not look correct until fixed.)

reload_item = toolbar_item(:label => "Reload",
:image => image(:named => "reload"))
reload_item.on_action { reload_instances }

The first toolbar item we create is the reload button. We set the image on the button to a file in the resources folder called reload.png. When the button is clicked, we want to execute the reload_instances method.

search_item = toolbar_item(:identifier => "Search") do |si|
search = search_field(:frame => [0, 0, 250, 30],
:layout => {:align => :right, :start => false})
search.on_action { |sender| filter_instances(search) }

si.view = search
end

The second item is the search box. You’ll notice we’re setting the :identifier instead of the :label as we did for the reload button. The difference being, the label will appear below the button and we don’t want Search appearing below the search box. The reload button will have an identifier of Reload created for it by HotCocoa.

With the search toolbar item in hand we create a search_field. The search field is then assigned as the view in the search toolbar item using si.view=.

@toolbar = toolbar(:default => [reload_item, :flexible_space, search_item]) do |tb|
win.toolbar = tb
end

Finally, we create our toolbar. This is done with the toolbar method. We want our default set of items to be the reload_item, :flexible_space and search_item. We then assign the toolbar to our window with win.toolbar = tb.

There are a few default toolbar items you can use, similar to :flexible_space. They are:

:separator
:space
:flexible_space
:show_colors
:show_fonts
:customize
:print

That’s all folks. Have fun.

EventMachine Screencast — EM-HTTP-Request

dj2 — Thu, 16 Jul 2009 00:52:42 +0000

I decided to try my hand at creating a screencast the other day. I took a look at the EventMachine EM-HTTP-Request library and created a simple shell program to do single and multi requests. Take a look and let me know what you think.

EventMachine Screencast — EM-HTTP-Request

require ‘rubygems’
require ‘eventmachine’
require ‘em-http’
require ‘pp’

$stdout.sync = true

class KeyboardHandler < EM::Connection
include EM::Protocols::LineText2

def post_init
print "> "
end

def receive_line(line)
line.chomp!
line.gsub!(/^\s+/, ”)

case(line)
when /^get (.*)$/ then
site = $1.chomp
sites = site.split(‘,’)

multi = EM::MultiRequest.new
sites.each do |s|
multi.add(EM::HttpRequest.new(s).get)
end
multi.callback {
puts ""
multi.responses[:succeeded].each do |h|
pp h.response_header.status
pp h.response_header
end
multi.responses[:failed].each do |h|
puts "#{h.inspect} failed"
end
print "> "
}
print "> "

when /^exit$/ then
EM.stop

when /^help$/ then
puts "get URL[,URL]* – gets a URL"
puts "exit - exits the app"
puts "help - this help"
print "> "
end
end
end

EM::run {
EM.open_keyboard(KeyboardHandler)
}
puts "Finished"

Google Analytics, OAuth and Ruby. Oh, my.

dj2 — Wed, 08 Jul 2009 03:28:25 +0000

I recently had the opportunity to take a peek at accessing Google Analytics data using their OAuth endpoint. We did this in Ruby using the Ruby OAuth gem. There were a few snags along the way so I figured I’d put up some notes for other people to take a peek.

First, you’re going to need a newer version of the OAuth gem (0.3.5 seems to work). Google uses some features from the 1.0a version of the OAuth spec, the oauth_verifier specifically, that aren’t available in older versions of the OAuth gem. That took a while to track down.

The second thing you’re going to need is a consumer token and secret from google. You can retrieve this from your domain management page (here as it’s a bit difficult to find.)

require ‘oauth’
con = OAuth::Consumer.new(CONSUMER_TOKEN, CONSUMER_SECRET,
{:site => ‘https://www.google.com’,
:request_token_path => ‘/accounts/OAuthGetRequestToken’,
:access_token_path => ‘/accounts/OAuthGetAccessToken’,
:authorize_path => ‘/accounts/OAuthAuthorizeToken’})

To start we create our OAuth connection. You’ll need to substitute your token and secret for the consumer constants above. We need to specify all of the OAuth paths to match the endpoints provided by Google.

rt = con.get_request_token({}, {:scope => ‘https://www.google.com/analytics/feeds’})

We use the connection to create a request token. get_request_token takes two parameters. The token parameters and other parameters. Above, I’m not specifying any request parameters but, if you want Google to redirect the user to a site of your choice you would provide {:oauth_callback => URL} as the token parameter. After authenticating the user would be redirected to the provided URL and the parameters oauth_token=TOKEN and oauth_verifier=VERIFIER will be passed to the URL. You’ll need to use those parameters when creating the access token.

The second parameter when creating the request token is used by Google to restrict the users access to specific portions of Google. In our case we’re requesting access to the Analytics data. A list of available scopes is here. You can specify multiple scope values by putting a space between them. e.g. "http://www.google.com/calendar/feeds/%20http://docs.google.com/feeds/".

rt.authorize_url => "https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=4%2F-1o2aZgHxJmjhaExv9htRsGWLlwy"

With our request token in hand we can use it to generate the authorization URL. You’ll need to redirect the user to this URL to do the authentication.

Since we aren’t providing a callback URL our users will just get redirected to a standard Google page and you’ll need to copy their verifier code into the application.

at = rt.get_access_token(:oauth_verifier => ‘vQH9bpXateNpsISpEDZax’)

When the user has authorized we either get them to paste the verifier code or we can retrieve it from the parameters passed to our oauth_callback. We use the verifier code to create an access token. This is the token we’ll be using to access the Google resources. We can save the at.token and at.secret values into our database to create new access tokens next time the user needs data from Google. We don’t need to authenticate each time.

at = OAuth::AccessToken.new(con, USER_TOKEN, USER_SECRET)

We can also, if we’re using the oauth_callback store some of our request token information to the session. If we store rt.token and rt.secret we can re-build our request token in a simlar fashion to the access token.

rt = OAuth::RequestToken.new(con, REQUEST_TOKEN, REQUEST_SECRET)

With the authentication out of the way we can get on with accessing the analytics data.

puts at.get("https://www.google.com/analytics/feeds/accounts/default?prettyprint=true").body

We grab our profile data first. You’ll need the dxp:tableId value in order to make calls to get profile specific analytic data. (The prettyprint=true is a handy little flag to get Google to nicely indent the XML returned. Makes for easier reading/debugging.)

< ?xml version=’1.0′ encoding=‘UTF-8′?>
xmlns=‘http://www.w3.org/2005/Atom’ xmlns:openSearch=‘http://a9.com/-/spec/opensearchrss/1.0/’ xmlns:dxp=‘http://schemas.google.com/analytics/2009′>
>http://www.google.com/analytics/feeds/accounts/dan.sinclair@gmail.com>
>2009-07-06T11:00:09.000-07:00>
type=‘text’>Profile list for dan.sinclair@gmail.com>
rel=‘self’ type=‘application/atom+xml’ href=‘http://www.google.com/analytics/feeds/accounts/default’/>
>
>Google Analytics>
>
version=’1.0′>Google Analytics>
:totalResults>1>
:startIndex>1>
:itemsPerPage>1>
>
>http://www.google.com/analytics/feeds/accounts/ga:123xxxx>
>2009-07-06T11:00:09.000-07:00>
type=‘text’>everburning>
rel=‘alternate’ type=‘text/html’ href=‘http://www.google.com/analytics’/>
:tableId>ga:123xxxx>
:property name=‘ga:accountId’ value=’73xxxx’/>
:property name=‘ga:accountName’ value=‘everburning’/>
:property name=‘ga:profileId’ value=’123xxxx’/>
:property name=‘ga:webPropertyId’ value=‘UA-73xxxx-1′/>
:property name=‘ga:currency’ value=‘USD’/>
:property name=‘ga:timezone’ value=‘America/Toronto’/>
>
>

puts at.get("https://www.google.com/analytics/feeds/data?ids=ga:123xxxx&start-date=2009-06-05&end-date=2009-06-06&dimensions=ga:pagePath&metrics=ga:pageviews,ga:uniquePageviews&prettyprint=true").body

The data I want from Google Analytics is the number of ga:pageviews and ga:uniquePageviews for each ga:pagePath between June 5th and 6th.

< ?xml version=’1.0′ encoding=‘UTF-8′?>
xmlns=‘http://www.w3.org/2005/Atom’ xmlns:openSearch=‘http://a9.com/-/spec/opensearchrss/1.0/’ xmlns:dxp=‘http://schemas.google.com/analytics/2009′>
>http://www.google.com/analytics/feeds/data?ids=ga:123xxxx&dimensions=ga:pagePath&metrics=ga:pageviews,ga:uniquePageviews&start-date=2009-06-05&end-date=2009-06-06>
>2009-06-06T16:59:59.999-07:00>
type=‘text’>Google Analytics Data for Profile 123xxxx>
rel=‘self’ type=‘application/atom+xml’ href=‘http://www.google.com/analytics/feeds/data?end-date=2009-06-06&start-date=2009-06-05&metrics=ga%3Apageviews%2Cga%3AuniquePageviews&ids=ga%3A123xxxx&dimensions=ga%3ApagePath’/>
>
>Google Analytics>
>
version=’1.0′>Google Analytics>
:totalResults>52>
:startIndex>1>
:itemsPerPage>52>
:startDate>2009-06-05>
:endDate>2009-06-06>
:aggregates>
:metric confidenceInterval=’0.0′ name=‘ga:pageviews’ type=‘integer’ value=’162′/>
:metric confidenceInterval=’0.0′ name=‘ga:uniquePageviews’ type=‘integer’ value=’152′/>
>
:dataSource>
> :tableId>ga:1239xxxx>
:tableName>everburning>
:property name=‘ga:profileId’ value=’123xxxx5′/>
:property name=‘ga:webPropertyId’ value=‘UA-73xxxx-1′/>
:property name=‘ga:accountName’ value=‘everburning’/>

>
>http://www.google.com/analytics/feeds/data?ids=ga:123xxxx&ga:pagePath=/&start-date=2009-06-05&end-date=2009-06-06>
>2009-06-05T17:00:00.001-07:00>
type=‘text’>ga:pagePath=/>
rel=‘alternate’ type=‘text/html’ href=‘http://www.google.com/analytics’/>
:dimension name=‘ga:pagePath’ value=‘/’/>
:metric confidenceInterval=’0.0′ name=‘ga:pageviews’ type=‘integer’ value=’9′/>
:metric confidenceInterval=’0.0′ name=‘ga:uniquePageviews’ type=‘integer’ value=’8′/>
>
>
>http://www.google.com/analytics/feeds/data?ids=ga:123xxxx&ga:pagePath=/quotes/&start-date=2009-06-05&end-date=2009-06-06>
>2009-06-05T17:00:00.001-07:00>
type=‘text’>ga:pagePath=/quotes/>
rel=‘alternate’ type=‘text/html’ href=‘http://www.google.com/analytics’/>
:dimension name=‘ga:pagePath’ value=‘/quotes/’/>
:metric confidenceInterval=’0.0′ name=‘ga:pageviews’ type=‘integer’ value=’6′/>
:metric confidenceInterval=’0.0′ name=‘ga:uniquePageviews’ type=‘integer’ value=’6′/>
>
>

You may notice that all of the paths returned are relative to some base URL. I haven’t been able to figure out how to get Google Analytics to tell me what that base URL happens to be. If you figure it out, please leave a comment so I can update my code.

That’s it. You can take a deeper look at the Google Analytics API documentation to learn about the different dimensions and metrics that can be queried.

If you’re doing this in Ruby you may also want to take a look at the Happy Mapper gem to make your XML using life easier.

Have fun.

HotCocoa and Core Data

dj2 — Sat, 13 Jun 2009 06:10:44 +0000

I’ve been playing around a bit with Core Data and HotCocoa the last few days and thought I’d share what I’ve got so far. When you install MacRuby you’re provided with an XCode template to start working with Core Data. I didn’t want to use XCode so I skipped the template. Some of this code is probably pretty similar to the template as I ported the Obj-C Core Data template to Ruby.

Note, this code is lightly tested, prototype, probably wrong and has already assassinated an unknown number of kitties. At this point, I’m still not sure if the approach taken is actually sane. Time will tell, but I thought it was interesting enough to share.

I stuffed all of the default Core Data stuff into a CoreData module that I’m including into my main application (mostly so I don’t have to look at the functions when working on my main code). The separation isn’t great at the moment as the should_terminate? method is currently in the module instead of the main application. I’ll be coming back to this setup once I’ve figured out how all the pieces work.

Along with the Core Data base methods I’ve also created a ManagedObject class. Each of the entities in my model I’ve created as a model class. Those model classes inherit from ManagedObject. (I just realized, the objects returned from self.create in ManagedObject aren’t of my model types. They’ll be straight up NSManagedObjects. Oops. Will need to look at that as well. Can you tell this stuff is still pretty rough?) ManagedObject contains the common create method for all of the sub-classes. When create is called the entity will be retrieved from the Core Data model and have it’s attributes and relationships added as methods on the returned object.

What this means is that, in the end, I can do the following:

p = Post.create
p.title = "HotData"
p.pub_date = NSDate.date
p.content = "Playing with Core Data from HotCocoa"

p.author = Author.create(:name => ‘dj2′)
p.tags.addObject(Tag.create(:name => "Core Data"))
p.tags.addObject(Tag.create(:name => "HotCocoa"))

p.published = true if !p.published?

One thing to note, when you’re working with Core Data you’ll be working with a .xcdatamodel file. In order to use that from code this data model needs to be compiled to a mom file and put into your application bundle. I’ve created a patch, attached to ticket 278 that builds this into the HotCocoa application builder. All you need is a build.yml similar to the following:

name: Blog
load: lib/application.rb
version: "1.0"
icon: resources/HotCocoa.icns
resources:
– resources/**/*.*
data_models:
– data/**/*.xcdatamodel
sources:
– lib/**/*.rb

Note the addition of the data_models key. This will take each of the models found, compile it, and place it in your bundles resource folder ready for use.

With that out of the way, what are we modeling? I figured I’d go simple and model a blog. I didn’t bother to write any real UI in front of it for the example as I just wanted to focus on the Core Data aspects.

The first step is to create the project: hotcocoa Blog will create the basis for us. I then updated the build.yml file to what’s seen above.

The next step was to create my data model which I saved to data/Blog.xcdatamodel. This needs to be done through XCode. Open up a new data model and create the following:

Post

content – string (not optional)
pub_date – date (not optional)
published – boolean (default NO)
title – string (not optional, default “- untitled -”)
author – relationship to Author table (not optional)
tags – relationship to the Tags table (optional, to-many)

Author

name – string (not optional)
posts – relationship to the Posts table (optional, to-many)

Tag

name – string (not optional)
posts – relationship to the Posts table (optional, to-many)

With the model in place we need to copy in our supporting code. This is the CoreData module and the ManagedObject class.

require ‘fileutils’
framework ‘CoreData’

module CoreData
def application_support_folder
return @application_support_folder if @application_support_folder

paths = NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, true)
path = (paths.count > 0) ? paths[0] : NSTemporaryDirectory
@application_support_folder = File.join(path, NSApp.name.downcase)
FileUtils.mkdir_p(@application_support_folder) unless File.exists?(@application_support_folder)
@application_support_folder
end

def managed_object_model
@managed_object_model ||= NSManagedObjectModel.mergedModelFromBundles(nil)
end

def persistent_store_coordinator
return @persistent_store_coordinator if @persistent_store_coordinator

@persistent_store_coordinator = NSPersistentStoreCoordinator.alloc.initWithManagedObjectModel(managed_object_model)

error = Pointer.new_with_type(‘@’)
url = NSURL.fileURLWithPath(File.join(application_support_folder, "#{NSApp.name}.xml"))
unless @persistent_store_coordinator.addPersistentStoreWithType(NSXMLStoreType, configuration:nil,
URL:url, options:nil, error:error)
NSApplication.sharedApplication.presentError(error[0])
end
@persistent_store_coordinator
end

def managed_object_context
return @managed_object_context if @managed_object_context

if persistent_store_coordinator
@managed_object_context = NSManagedObjectContext.alloc.init
@managed_object_context.setPersistentStoreCoordinator(persistent_store_coordinator)
end
@managed_object_context
end

def returning_undo_manager
managed_object_context.undoManager
end

def save
error = Pointer.new_with_type(‘@’)
unless managed_object_context.save(error)
NSApplication.sharedApplication.presentError(error[0])
end
end

def should_terminate?
reply = NSTerminateNow
if managed_object_context
if (managed_object_context.commitEditing)
error = Pointer.new_with_type(‘@’)
if (managed_object_context.hasChanges and !managed_object_context.save(error))
if NSApplication.sharedApplication.presentError(error[0])
reply = NSTerminateCancel
else
alertReturn = NSRunAlertPanel(nil, "Could not save changes while quitting. Quit anyway?",
"Quit anyway", "Cancel", nil)
if (alertReturn == NSAlertAlternateReturn)
reply = NSTerminateCancel
end
end
end
else
reply = NSTerminateCancel
end
end
reply
end
end

There isn’t anything special here. This is, basically, the Obj-C Core Data template ported to Ruby.

require ‘hotcocoa’

class ManagedObject
def self.create(vals={})
name = self.to_s.gsub(/^.*::/, ”)
obj = NSEntityDescription.insertNewObjectForEntityForName(name,
inManagedObjectContext:NSApp.delegate.managed_object_context)

entity = NSEntityDescription.entityForName(name,
inManagedObjectContext:NSApp.delegate.managed_object_context)

map_attributes(obj, entity.attributesByName)
map_relationships(obj, entity.relationshipsByName)

vals.each_pair do |key, value|
obj.send("#{key}=", value)
end
obj
end

def self.map_attributes(obj, attributes_by_name)
attributes_by_name.each_pair do |attribute, value|
obj.instance_eval %[
def #{attribute}=(val)
setValue(val, forKey:"#{attribute}")
end

def #{attribute}
valueForKey("#{attribute}")
end
]
if value.attributeType == NSBooleanAttributeType
obj.instance_eval %[
def #{attribute}?
send("#{attribute}".to_sym).boolValue
end
]
end

obj.send("#{attribute}=".to_sym, value.defaultValue)
end
end

def self.map_relationships(obj, relationships_by_name)
relationships_by_name.each_pair do |relationship, value|
if value.isToMany
obj.instance_eval %[
def #{relationship}
willAccessValueForKey("#{relationship}")
v = primitiveValueForKey("#{relationship}")
didAccessValueForKey("#{relationship}")
v
end
]
else
obj.instance_eval %[
def #{relationship}
valueForKey("#{relationship}")
end

def #{relationship}=(val)
setValue(val, forKey:"#{relationship}")
end
]
end
end
end
end

ManagedObject is a little more interesting. I didn’t want to have to use setValue:forKey:, valueForKey: and other NSManagedObject methods to work with my model. What ManagedObject does is create a new entity with NSEntityDescription.insertNewObjectForEntityForName:inManagedObjectContext: and then attach methods for the relationships and attributes of that entity.

We use NSEntityDescription.entityForName:inManagedObjectContext: to get the information on the entity. This allows us to call entity.attributesByName and entity.relationshipsByName. The last thing self.create does is take any provided options and send them to the appropriate keys. This allows us to do Author.create(:name => "dj2") instead of needing multiple lines.

The methods are created in self.map_attributes and self.map_relationships. For each attribute we attach an attribute= and attribute method. If the attribute is a boolean we also create an attribute? method. If the attribute assigns a default value we’ll send the default after the methods are added.

self.map_relationships works in a similar fashion if the relation ship isn’t to-many. If it is to-many we only create an attribute method. Currently you’ll need to use the NSSet methods to access the values in the to-many set.

The relationship code needs a bit more work as it won’t try to lookup a relationship, just blindly create a new row. I need to decide if I want to build that into create or add a find method to lookup the entities.

I’ve been storing my models in a lib/models directory. For this all we create three, almost identical, models. author.rb, post.rb and tag.rb

class Author < ManagedObject
end

class Post < ManagedObject
end

class Tag < ManagedObject
end

The last changes are to application.rb. We need to require lib/core_data, lib/managed_object and our models.

Dir.glob("lib/models/*.rb").each do |file|
require file
end

Then, inside the application class we include CoreData and we're good to go. You can then do something similar to:

p = Post.create
p.title = "HotData"
p.pub_date = NSDate.date
p.content = "Playing with Core Data from HotCocoa"

p.author = Author.create(:name => 'dj2')
p.tags.addObject(Tag.create(:name => "Core Data"))
p.tags.addObject(Tag.create(:name => "HotCocoa"))

p.published = true if !p.published?

save

Which will create a ~/Library/Application Support/blog/Blog.xml file with your new post inside.

I've uploaded a copy of my source if you want to take a look.

Questions? Comments? Let'em rip.

MacRuby and NSError

dj2 — Fri, 12 Jun 2009 02:54:05 +0000

Just a note for other people that might be cracking their heads trying to meld MacRuby and NSError ** parameters. The answer was already sitting on my computer, I just never through to look at the MacRuby Core Data XCode templates, but that’s beside the point. For those of you searching, you just need to do the following.

error = Pointer.new_with_type(‘@’)
unless managed_object_context.save(error)
NSLog error[0].inspect
NSApplication.sharedApplication.presentError(error[0])
end

The NSLog error[0].inspect will output #. Exactly what we want.

Heating up with HotCocoa on GitHub

dj2 — Tue, 26 May 2009 17:57:55 +0000

I’ve imported Postie to GitHub to make it easier to follow along from home. If you’re new here, you can see the development of Postie in the Heating up with HotCocoa articles (part I, part II and part III).

The code on GitHub is based off of the code from part III with a minor addition to the button action.

b.on_action do
load_feed

@timer.invalidate unless @timer.nil?
@timer = NSTimer.scheduledTimerWithTimeInterval(30, target:self,
selector:"refresh".to_sym, userInfo:nil,
repeats:true)
end

I wanted to have the application reload my metrics data automatically to feed my obsessive nature. I added a NSTimer that will execute a refresh method every 30 seconds. The refresh method just calls load_feed to reload everything. Not perfect, but works as a quick hack to be cleaned up later.

Heating up with HotCocoa Part III

dj2 — Mon, 25 May 2009 21:26:23 +0000

In the words of Homer Simpsons, “forward not backwards, upwards not forwards and always twirling, twirling, twirling towards freedom”. With that, we’re back for part III of my HotCocoa tutorial. For those of you just joining the party, you’ll probably want to take a look at part I and part II.

If you’d like to grab a copy of the code, it’s getting a bit big to post all of it in one go, you can grab the tar ball here. The file contains all of the HotCocoa files along with the sprite image that I’ve shamelessly niced from PostRank.

When we last left off we’d created the basic layout for our application with our button and table views setup. With this installment, we’re going to go a step further and get a fully working application. We’re going to use the feed entered into the text field to query PostRank to get the current posts in the feed along with there PostRank and metric information. I’m going to be skipping over sections of code that haven’t changed from part I or part II for the sake of brevity.

Note, we’re going to be using JSON when working with the PostRank APIs. There is a bug in MacRuby, as of revision 1594, where JSON.parse would crash MacRuby. You’ll need to apply the patch attached to ticket 257 in order run this application.

OK, let’s go.

POSTRANK_URL_BASE = "http://api.postrank.com/v2"
APPKEY = "appkey=Postie"

All of our calls to PostRank will use the same URL prefix and we’ll need to provide our appkey. I’ve placed both of these into constants.

vert << scroll_view(:layout => {:expand => [:width, :height]}) do |scroll|
scroll.setAutohidesScrollers(true)

pr_column = column(:id => :postrank, :title => ”)
pr_column.setDataCell(PostRankCell.new)
pr_column.setMaxWidth(34)
pr_column.setMinWidth(34)

info_column = column(:id => :data, :title => ”)
info_column.setDataCell(PostCell.new)

scroll << @table = table_view(:columns => [pr_column, info_column],
:data => []) do |table|
table.setRowHeight(PostCell::ROW_HEIGHT)
table.setUsesAlternatingRowBackgroundColors(true)
table.setGridStyleMask(NSTableViewSolidHorizontalGridLineMask)
table.setDelegate(self)
table.setDoubleAction(:table_clicked)
end
end

I’ve made one layout modification which was to add an extra column to our table to display the PostRank for each post. The PostRank column and post data columns use custom cell formatters so we can get the layout we want. I also wanted to constrain the PostRank column to a set size, 34 pixels seemed to look good. In order to use my custom formatters I use setDataCell on the column objects. The parameter to setDataCell is an instantiated instance of our formatter class. I have two classes, PostRankCell and PostCell for the PostRank and post columns respectively.

Along with the column changes we’re also setting a default height on the table rows as defined in the PostCell class. We set the Postie instance as the delegate for the table so we can receive the tableView(table, heightOfRow:row) callback (thanks @macruby for the pointer). The last addition to the table is to hookup the double click action with @table.setDoubleAction(:table_clicked). The parameter is the name of the method that will be called, as a symbol.

def table_clicked
url = NSURL.URLWithString(@table.dataSource.data[@table.clickedRow][:data][:link])
NSWorkspace.sharedWorkspace.openURL(url)
end

When a table row is double clicked we want to open the corresponding posts page in the users brower. We’ll be storing the link in the data attached to our table. We can get the clicked row with @table.clickedRow and access the link with @table.dataSource.data[@table.clickedRow][:data][:link]. We then create a NSURL with this string. The created URL object is passed to NSWorkspace.sharedWorkspace.openURL(url) causing the page to open in the browser.

def tableView(table, heightOfRow:row)
metrics = @table.dataSource.data[row][:data][:metrics].keys.length

num_rows = (metrics / PostCell::NUM_METRICS_PER_ROW) + 1
num_rows -= 1 if metrics > 0 && (metrics % PostCell::NUM_METRICS_PER_ROW) == 0
num_rows = 0 if metrics == 0

num_rows * PostCell::ROW_HEIGHT + PostCell::ROW_HEIGHT # 2nd row height for the title
end

The tableView(table, heightOfRow:row) callback is triggered each time the table is rendered out to determine the height for a given row. In the case of Postie we’re going to display the post title on the first line and the metrics on subsequent lines. I’ve constrained the metrics to allow a maximum of 6 metrics on each line. All of the metrics are stored in a :metrics key of the data attached to our table. Both the number of metrics and a row and the row height are constants stored in the PostCell class.

def load_feed
@table.data = []

str = @feed_field.stringValue
unless str.nil? || str =~ /^s*$/
fetch_feed(str)
end
end

load_feed has been updated to empty our tables data by assigning a new array and, assuming we’ve received a valid feed, call fetch_feed to start retrieving the feed data.

There are a few different ways we could go about querying the data from the PostRank APIs. We could use Net::HTTP, Curb, NSXMLDocument or, as I’ve done, NSURLConnection. The reason I used NSURLConnection is so that I can have the requests run asynchronously. As well, the UI won’t block as we’re off fetching the data. A handy feature when you want things to remain responsive.

Let’s take a quick look at the wrapper class I’ve put around NSURLConnection before looking at fetch_feed. The reason I created a wrapper is that NSURLConnection, because it’s asynchronous, works through callbacks. I’m going to need to query three different PostRank APIs and take different actions for each query. Instead of trying to do some magic in the callbacks, I’ve created a wrapper class that accepts a block. The block is called when the data has been successfully retrieved. (The wrapper just spits out an error if something goes wrong, the block is never called.) For example, to download the Google.ca homepage we could do:

DataRequest.new("http://google.ca") do |data|
NSLog "Data: #{data}"
end

class DataRequest
def get(url, &blk)
@buf = NSMutableData.new
@blk = blk
req = NSURLRequest.requestWithURL(NSURL.URLWithString(url))
NSURLConnection.alloc.initWithRequest(req, delegate:self)
end

def connection(conn, didReceiveResponse:resp)
@buf.setLength(0)
end

def connection(conn, didReceiveData:data)
@buf.appendData(data)
end

def connection(conn, didFailWithError:err)
NSLog "Request failed"
end

def connectionDidFinishLoading(conn)
@blk.call(NSString.alloc.initWithData @buf, encoding:NSUTF8StringEncoding)
end
end

As NSURLConnection executes it returns data to the application. We’re storing this data in a NSMutableData object called @buf. The callbacks we’re interested in are:

connection(conn, didReceiveResponse:resp): Called when we receive a response from the server. This can be called multiple times if there are any server redirects in place. We reset the length of our data buffer each time this callback is called.
connection(conn, didReceiveData:data): Called each time data is received from the server. This can be called multiple times and we just append the data to our buffer each time.
connection(conn, didFailWithError:err): Called if there is an error retrieving the data. We, basically, just ignore the error. You’d probably want to do something sane in your application.
connectionDidFinishLoading(conn): Called when all of the data has been retrieved from the remote server. Since we’re not working with binary data I convert the NSMutableData to an NSString using the initWithData:encoding method. Note the use of alloc on the NSString. If you try to use new you’ll, like me, spend the next 30 minutes trying to figure out why your application is crashing.

def fetch_feed(url)
DataRequest.new.get("#{POSTRANK_URL_BASE}/feed/info?id=#{url}&#{APPKEY}") do |data|
feed_info = JSON.parse(data)
unless feed_info.has_key?(‘error’)
DataRequest.new.get("#{POSTRANK_URL_BASE}/feed/#{feed_info['id']}?#{APPKEY}") do |data|
feed = JSON.parse(data)
feed[‘items’].each do |item|
post_data = {:title => item[‘title’], :link => item[‘original_link’], :metrics => {}}
@table.dataSource.data << {:data => post_data,
:postrank => {:value => item[‘postrank’],
:color => item[‘postrank_color’]}}
DataRequest.new.get("#{POSTRANK_URL_BASE}/entry/#{item['id']}/metrics?#{APPKEY}") do |data|
metrics = JSON.parse(data)
metrics[item[‘id’]].each_pair do |key, value|
next if key == ‘friendfeed_comm’ || key == ‘friendfeed_like’
post_data[:metrics][key.to_sym] = value
end
@table.reloadData
end
end
end
end
end
end

Most of the code in fetch_feed should probably be refactored into Feed, Post and Metrics classes, but, for the tutorial, I’m not going to bother.

You can see we’re doing three successive data requests. The first is to the Feed Info API. From this call we can retrieve the feed_hash which allows us to uniquely identify our feed in the PostRank system. By default all the PostRank API calls will return the data in JSON format. We could, and I did this initially use format=xml and NSXMLDocument.initWithContentsOfURL to pullback and parse all the data (the problem being, metrics only responds in JSON).

Now, as long as the query to Feed Info didn’t return an error we use the id to access the Feed API. The Feed API will return the posts in the given feed. The default is to return 10 posts which works for our purposes. We could, if we wished, add a button to retrieve the next set of posts from the API using the start and num parameters.

With the feed in hand we’re interested in the items attribute. This is an array of the posts in the feed. Using these items we can start to create our table data. For each item we’re going to create two hashes of data, one for each column of our table. The PostRank column will contain the :postrank and :postrank_color and the post column will contain the :title, :link and :metrics.

Finally, we query the metrics API for each post to retrieve the metrics data. The metrics API will provide us with a hash with a single key based on our post’s ID. Under this key we receive a hash containing the metric source names and the values. We’re skipping friendfeed_comm and friendfeed_like as they’ve been renamed to ff_comments and ff_links and only remain as legacy.

Once we’ve got all the metrics source information packed into our post_data hash we call @table.reloadData so everything gets rendered properly.

Since the calls to DataRequest are asynchronous, we have to call reload inside the metrics block. This guarantees the table will be reloaded after we’ve received our data.

With that out of the way, we’re onto our formatting cells. In order to get our custom table display we need to subclass NSCell and override the drawInteriorWithFrame(frame, inView:view) where we can layout our cell as desired.

class PostRankCell < NSCell
def drawInteriorWithFrame(frame, inView:view)
m = objectValue[:color].match(/#(..)(..)(..)/)
NSColor.colorWithCalibratedRed(m[1].hex/ 255.0, green:m[2].hex/255.0, blue:m[3].hex/255.0, alpha:100).set
NSRectFill(frame)

rank_frame = NSMakeRect(frame.origin.x + (frame.size.width / 2) – 12,
frame.origin.y + (frame.size.height / 2) – 8, frame.size.width, 17)

objectValue[:value].to_s.drawInRect(rank_frame, withAttributes:nil)
end
end

The PostRankCell is pretty simple. We parse the provided PostRank colour, which comes as #ffffff into separate red, green and blue values. These values are passed to NSColor.colorWithCalibratedRed(red, green:green, blue:blue, alpha:alpha) in order to create a NSColor object representing our PostRank colour. We need to divided each value by 255 as colorWithCalibratedRed:green:blue:alpha: expects a value between 0.0 and 1.0. Once we’ve got our colour we call set to make that colour active and, using NSRectFill we fill then entire frame with the provided postrank_color.

I’m, kinda, sorta, centering the PostRank values in the column so we need to create a NSRect to specify the box where we want to draw the numbers. This is done by calling NSMakeRect and providing the x, y, width and height values for the rectange. Once we’ve got our NSRect in hand we call drawInRect(rank_frame, withAttributes:nil) on the PostRank value. This will draw the string in the rectangle specified. We could set extra attributes on the string but, I don’t need any, so I just leave it nil.

You’ll notice I’m using objectValue in a few places. objectValue is a NSCell method that will return the value assigned to this cell as retrieved based on the column key from our table data source.

class PostCell < NSCell
ROW_HEIGHT = 20
NUM_METRICS_PER_ROW = 6
SPRITE_SIZE = 16

@@sprites = {:default => 0, :blogines => 16, :reddit => 32, :reddit_votes => 32,
:technorati => 48, :magnolia => 64, :digg => 80, :twitter => 96, :comments => 112,
:icerocket => 128, :delicious => 144, :google => 160, :pownce => 176, :views => 192,
:bookmarks => 208, :clicks => 224, :jaiku => 240, :digg_comments => 256,
:diigo => 272, :feecle => 288, :brightkite => 304, :furl => 320, :twitarmy => 336,
:identica => 352, :ff_likes => 368, :blip => 384, :tumblr => 400,
:reddit_comments => 416, :ff_comments => 432}
@@sprite = nil

def drawInteriorWithFrame(frame, inView:view)
unless @@sprite
bundle = NSBundle.mainBundle
@@sprite = NSImage.alloc.initWithContentsOfFile(bundle.pathForResource("sprites", ofType:"png"))
@@sprite.setFlipped(true)
end

title_rect = NSMakeRect(frame.origin.x, frame.origin.y + 1, frame.size.width, 17)
metrics_rect = NSMakeRect(frame.origin.x, frame.origin.y + ROW_HEIGHT, frame.size.width, 17)

title_str = "#{objectValue[:title]}"
title_str.drawInRect(title_rect, withAttributes:nil)

count = 0
orig_x_orign = metrics_rect.origin.x

objectValue[:metrics].each_pair do |key, value|
s = metrics_rect.size.width
metrics_rect.size.width = SPRITE_SIZE

y = if @@sprites.has_key?(key)
@@sprites[key.to_sym]
else
0
end
r = NSMakeRect(0, y, SPRITE_SIZE, SPRITE_SIZE)
@@sprite.drawInRect(metrics_rect, fromRect:r,
operation:NSCompositeSourceOver, fraction:1.0)
metrics_rect.origin.x += 21
metrics_rect.size.width = s - 21

"#{value}".drawInRect(metrics_rect, withAttributes:nil)
s = "#{value}".sizeWithAttributes(nil)
metrics_rect.origin.x += s.width + 15

count += 1
if count == NUM_METRICS_PER_ROW
metrics_rect.origin.y += ROW_HEIGHT
metrics_rect.origin.x = orig_x_orign
count = 0
end
end
end
end

PostRankCell is similar to PostCell in that we're basically creating bounding rectangles and drawing into them. The extra little bit we're doing here is loading up a NSImage which is our sprite set and using that to pull out all of the individual service icons. NSImage makes it easy to work with our sprite image by providing drawInRect(rect, fromRect:from_rect, operation:op, fraction:val). drawInRect:fromRect:operation:fraction: draws into the rectangle defined by rect retrieving the pixels in your NSImage that are inside the from_rect. I'm using NSCompositeSourceOver because some of my images are semi-transparent. The fraction parameter is a the alpha setting for the image.

With that, well, you'll probably need to download the source code to see it all in one file, you should have a working application that will query PostRank for a feed and display the posts and metrics for the feed.

As for the next installment. I've got a few things I still want to do, including: tabbing between widgets, submitting the text field on return, a progress indicator as the feed information is being retrieved and adding a tabbed interface to allow showing feed, post and top post information. I'm not sure which of these things I'll tackle next. There are a few helper methods I want to try to add to HotCocoa from this article that I'll probably do first. So, until next time.

Heating up with HotCocoa Part II

dj2 — Sun, 24 May 2009 02:49:57 +0000

Welcome back. In part I we created a basic HotCocoa application and took a look at the created files and some of their workings. In part II we’re going get our UI laid out and hooked up.

We’ll be creating a text field, button, scroll view and a table. When the button is pressed, for now, the content of the text field will be appended to the table view.

A good thing to keep in mind when hacking around with MacRuby and HotCocoa is that the methods available in the OS X frameworks you’re using are available in Ruby. This means, if you don’t know how to do something, the Apple documentation is awesome at trying to figure out the right methods use.

HotCocoa doesn’t have wrappers for all of the methods we need so, sometimes, we’ll drop down and call the Cocoa methods directly. Hopefully as HotCocoa matures more of these methods will have wrappers in Ruby land. I’ve created few patches, here, here, here and here for some of the wrappings I thought would be handy as I worked on this portion of our tale.

I’m going to start off with the complete listing of the code. Don’t worry if this doesn’t make any sense at the moment as we’re going to go through all of the relevant portions. Some of this should look familiar from the basic HotCocoa generated code seen in part I.

require ‘hotcocoa’

class Postie
include HotCocoa

def start
application(:name => "Postie") do |app|
app.delegate = self
window(:size => [640, 480], :center => true, :title => "Postie", :view => :nolayout) do |win|
win.will_close { exit }

win.view = layout_view(:layout => {:expand => [:width, :height],
:padding => 0, :margin => 0}) do |vert|
vert << layout_view(:frame => [0, 0, 0, 40], :mode => :horizontal,
:layout => {:padding => 0, :margin => 0,
:start => false, :expand => [:width]}) do |horiz|
horiz << label(:text => "Feed", :layout => {:align => :center})
horiz << @feed_field = text_field(:layout => {:expand => [:width]})
horiz << button(:title => ‘go’, :layout => {:align => :center}) do |b|
b.on_action { load_feed }
end
end

vert << scroll_view(:layout => {:expand => [:width, :height]}) do |scroll|
scroll.setAutohidesScrollers(true)
scroll << @table = table_view(:columns => [column(:id => :data, :title => ”)],
:data => []) do |table|
table.setUsesAlternatingRowBackgroundColors(true)
table.setGridStyleMask(NSTableViewSolidHorizontalGridLineMask)
end
end
end
end
end
end

def load_feed
str = @feed_field.stringValue
unless str.nil? || str =~ /^\s*$/
@table.dataSource.data << {:data => str}
@table.reloadData
end
end
end

Postie.new.start

I’m going to skip the parts that we saw in part I and just mention the changes and new additions in part II.

window(:size => [640, 480], :center => true, :title => "Postie", :view => :nolayout)

Instead of using the :frame => [100, 100, 500, 500] as seen in part I, I prefer to use :size => [640, 480] and :center => true to set the window with a starting size of 640×480 position in the center of the screen.

You’ll also notice the addition of :view => :nolayout tacked on the end of the window method. This isn’t strictly necessary but saves the creation of an object we’re just going to destroy anyway. By default when a window is created a LayoutView will be created and appended to the window. I’m going to be creating my own layout and overriding the created one so I’m just telling the window to skip the creation of the default view.

Before we dig into the next chunk of code lets take a little diversion to look at layout_view. The layout_view is one of the basic building blocks for organizing your application layout. The layout_view method will create a LayoutView object which is a subclass of NSView. Any Cocoa methods available for an NSView can be called on a LayoutView.

When working with layout_view there are a few parameters we’re interested in. The first, similar to window is :frame. As with window the :frame parameter allows us to set the frame position and size for the view. Note, if you don’t set a :frame then, it appears, that the view may have 0 size. This can be changed by the children placed in the view but not always. I spent a while trying to figure out why removing the :frame => [0, 0, 0, 40] from the code above caused my label, text field and button to disappear.

A handy little trick when working with layout_view is to run your application in the $DEBUG mode of Ruby. When $DEBUG is active each layout will have a red border.

To execute your application in $DEBUG you can do:

titania:Postie dj2$ macruby -d lib/application.rb

Other parameters we’re using for the layout_view calls are :mode, :margin, :spacing and :layout.

:mode: Lets us specify if this view has a :vertical or :horizontal layout. The default layout is :vertical.
:margin: Allows us to specify a margin size for the layout. The provided value is a single integer which will be applied to top, bottom, left and right margins of the view.
:spacing: Allows us to set the spacing for items placed into the view. The value is a single integer.

The last option we’re going to look at is :layout. The layout option isn’t restricted to just layout_view calls and is available on all of the other widgets I’ve created so far.

The :layout hash will be turned into a LayoutOptions object. The available keys are: :start, :expand, :padding, :[left | right | bottom | top]_padding and :align.

:start: Signifies if the view is packed at the start or end of the packing view. I’ll admit, I don’t really know what that means. I’m stealing it from the LayoutOption docs. It appears, in my limited fiddling, that setting it to false causes your subviews to end up at the top of the layout. The default value is true.
:expand: Specifies how the view will grow when the window is resized. The available options are: :height, :width, [:height, :width] and nil. The default setting is nil.
:*padding: Allows you to set the padding around the view. The padding values are specified as a float with a default of 0.0.
:align: Allows us to specify the alignment of the view as long as it isn’t set to :expand in the other direction. The available options are: :left, :center, :right, :top and :bottom.

With that out of the way, back to our code. As you can see by the layout image, our layout isn’t overly complicated. All of the layout is handled by two layout views and a scroll view.

win.view = layout_view(:layout => {:expand => [:width, :height], :padding => 0}) do |vert|

We start by creating the main window view. If you remember, we created the window with :view => :nolayout so there is currently no view in our window. We assign the new layout_view to the win.view instead of using << to pack it into the view. We remove the padding on the view and set the expand to [:width, :height] so the view will fill the entire window and resize correctly.

Since we didn’t specify a :mode the main window will layout its packed widgets in a vertical fashion.

As each layout view is created you can attach a block to the layout_view call. The block will be called with the LayoutView object that was just created. This makes it easy to pack subviews into the views as they’re created.

vert << layout_view(:frame => [0, 0, 0, 40], :mode => :horizontal,
:layout => {:padding => 0, :start => false, :expand => [:width]}) do |horiz|

Next we pack a horizontal view (:mode => :horizontal) to hold the label, text field and button. We set the view to :expand => [:width] so we’ll only get horizontal expansion and maintain the height specified in our :frame parameter. You’ll notice we’re setting a :frame on this layout_view. If we don’t have this parameter it appears that the view will be drawn with 0 height. Effectively making the view invisible.

horiz << label(:text => "Feed", :layout => {:align => :center})
horiz << @feed_field = text_field(:layout => {:expand => [:width]})
horiz << button(:title => ‘go’, :layout => {:align => :center}) do |b|
b.on_action { load_feed }
end

Into the horizontal layout we pack our label, text_field and button. For both the label and button we’re specifying an :align => :center to line them up with the center of the text field. The only item we’re setting an expand on is the text_field. The other two widgets will maintain their positions and sizes when the window is resized.

When we create the button we attach a block for the on_action callback. This will be triggered when the button is pressed. In our case we’re just calling the load_feed method.

vert << scroll_view(:layout => {:expand => [:width, :height]}) do |scroll|
scroll.setAutohidesScrollers(true)

With the horizontal view out of the way we create a scroll_view and pack it into our main vertical view. We want the scroll view to :expand => [:width, :height] so it fills the entire window on resize. There is currently no exposed HotCocoa sugar for auto hiding the scrollbars so we drop down and call setAutohidesScrollers to set the scrollbars to auto hide.

scroll << @table = table_view(:columns => [column(:id => :data, :title => ”)],
:data => []) do |table|
table.setUsesAlternatingRowBackgroundColors(true)
table.setGridStyleMask(NSTableViewSolidHorizontalGridLineMask)
end

The last view we pack is a table_view. We’re again dropping down to Cocoa for the setUsesAlternatingRowBackgroundColors and setGridStyleMask.

Now, the table_view itself. The table view is more complicated then the other widgets we’ve looked at in that it requires column and data source information.

The column information is provided by the :columns => [column(:id => :data, :title => '')] parameter. You provide an array of column objects which define the table columns. The :title will be displayed at the top of a column. If you don’t provide a :title the default is Column. We also providing an :id parameter to our column method. This parameter will be passed when we’re accessing our data source, and, if you’re using the default data source, used to access the specific column information. We’ll dig into columns and their relations to data sources in a moment.

There are two ways to provide data source information. You can either pass an array, which is what we’re doing here or provide your own data source object.

If you decide to define your own data source then it must respond to numberOfRowsInTable(tableView) => integer and tableView(view, objectValueForTableColumn:column, row:i) => string.

If you opt to use the default data source then you provide an array of hashes. The keys into the hash are the :id values set when we created our columns.

Hopefully an example will make this a bit clearer. Lets say we want to create a table with three columns, name, age and sex. We would define our table as:

@table = table_view(:columns => [column(:id => :name, :title => ‘Name’),
column(:id => :age, :title => ‘Age’),
column(:id => :sex, :title => ‘Sex’)],
:data => [{ :name => ‘Betty Sue’, :age => 29, :sex => ‘F’ },
{ :name => ‘Brandon Oberon’, :age => 0.005, :sex => ‘M’ },
{ :name => ‘Sally Joe’, :age => 48, :sex => ‘F’}])

With the table view finished all that’s left is to define the load_feed method. For this first iteration we’re just going to take the content of the feed text field and load it into our table view.

def load_feed
str = @feed_field.stringValue
unless str.nil? || str =~ /^\s*$/
@table.dataSource.data << {:data => str}
@table.reloadData
end
end

We use the Cocoa stringValue method to retrieve the value set into the text field. As long as it isn’t blank we append a new hash (with our :data key as defined in our column setup) into the @table.dataSource.data. We then call @table.reloadData to get the table to re-display its content.

That’s it. You should be able to run the application, enter some text in the text field, hit go and see the text appear in the table view. As you add more table rows, scrollbars should appear and you can scroll in the table as needed.

The third part of this series will be, hopefully, pulling real data back from PostRank and displaying it in a custom cell in our table.

Update: Part III is now available.