everburning

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:

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:

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.

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

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

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

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

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.

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.

The NSLog error[0].inspect will output #<NSError:0x80057a640>. Exactly what we want.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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:

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.

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.