everburning

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

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.

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

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.

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

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

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.

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

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.

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.

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.

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

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

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.

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.