Damien DeVille

→ Shared preferences between sandboxed applications

Damien DeVille — Wed, 05 Dec 2012 07:30:03 PST

I’ve written an article on Realmac’s blog about shared preferences between sandboxed applications.

Some fun stuff, go give it a read!
The framework and a sample application both are available on GitHub.

Hosting on GitHub Pages

Damien DeVille — Mon, 19 Nov 2012 14:06:50 PST

When I redesigned this website last year I had one main goal in mind: it had to be flexible. I didn’t want to depend on a platform such as WordPress or have my content tight to a database. Very naturally I decided to use Jekyll.

Jekyll gives you just enough power to generate a static blog from a bunch of markdown files while leaving you completely in control of the structure and layout. Back then, I was a happy customer of Linode so I was able to host the site myself. I was simply building it locally and pushed the content to my server via FTP with Transmit. While this worked quite well, it required me to have my MacBook (with Jekyll and related gems installed) just to be able to publish a post. So I then moved to have the server check out the git repository and set up a post update hook that simply built and published the site. This worked nicely but required more setup on the server that I would need to replicate when changing provider, too much hassle for a simple blog. Also, over the last months I found it harder to justify the $240 per year for a Linode VPS given that I was only hosting my blog on (and a couple of git repositories that could easily be moved to GitHub at any time).

So I made the move, from now on I will be hosting this blog on GitHub. This will make things much easier, the website only being a git repository built when pushing to the master branch. Drafts can be kept in a side branch, building locally for previewing, and merging to master to deploy. This approach has one caveat though, one cannot use a non-vanilla version of Jekyll. In other words, this means no plugins. GitHub runs a basic version of Jekyll and (slightly outdated) Liquid and plugins in the repository will be ignored. I didn’t make an extensive use of plugins but still depended on a couple of them, to classify the posts by date for example. Anyway, nothing insurmountable so I removed the yearly and monthly classification of posts in the archive page and now display them sequentially with their appropriate posting date. I have also slightly simplified the post types. Every post written on this site will be classified under Posts, that’s it! In other words, no more Bits and Starred Posts.

The last little thing was the Contact page. I was using a simple PHP script for the contact form that I obviously won’t be able to run anymore. No big deal, no one likes contact forms and there are plenty of other ways to contact me!

So, let’s just hope that this easier setup works smoothly and stimulates me writing more!

John Siracusa‘s Mac OS X reviews

Damien DeVille — Thu, 28 Jun 2012 22:34:40 PDT

With Mountain Lion soon to be released next month, I am looking forward to read John Siracusa well renowned OS X review on Ars Technica. John puts a tremendous effort in reviewing our favorite operation system and his articles are always an amazing journey through every little updates and improvements in the OS release.

I have been a full-time OS X user since Tiger (I have used Mac OS 8 for a while in elementary school but my personal switch to the Mac, like many Europeans, was only around 2005). For this reason, the only reviews I actually had a chance to read were the ones for Leopard, Snow Leopard and Lion. Feeling like I had been missing something, I decided to read the whole saga from the very first one: Developer Preview 2! It's been an amazing reading so far (I have just finished the 10.0 review) and I cannot recommend it enough to anyone even only slightly interested in OS X.

All the articles can be found on Ars Technica. Since there doesn't seem to be a global table of contents for the various reviews, I've linked to them below. Every article is split between multiple pages (some up to 25!); you can view the article on a single page if you become a subscriber though. For $5 a month, it's really a no-brainer, and the articles will save nicely in Instapaper.

Enjoy!

Mac OS X DPs and Public Beta

Releases

Specials

→ Chocolat 1.0 released today

Damien DeVille — Thu, 28 Jun 2012 22:04:40 PDT

Given the dead-not-dead status of TextMate, I've been looking for a nice text editor to replace it with. Unfortunately, TextMate is awesome and I found it quite hard to find an app that I was comfortable with. Many people seem to like BBEdit or Sublime Text but I don't seem to become accustomed to the UI of any of them.

I have been alpha testing Chocolat for the past few months, and it looks like a very promising alternative to TextMate. A couple of minutes spent with Chocolat are actually enough to realize that it has clearly been built as a direct replacement to TextMate.

The 1.0 version has been released today, it's $49 on Fileability's store.

→ Stephen Wolfram on the .data domain for the Data Web

Damien DeVille — Tue, 10 Jan 2012 00:00:00 PST

Fascinating concept.

NSURLConnection setDelegateQueue is broken on iOS

Damien DeVille — Thu, 29 Dec 2011 00:00:00 PST

On Mac OS 10.7 and iOS 5.0, a very handy method has been added to NSURLConnection: setDelegateQueue:.

Using a URL connection in an NSOperation subclass has always been quite tedious because of the fact that one has to run a runloop for as long as the delegate callbacks have to happen. As suggested by Marcus Zarra in this StackOverflow answer, this has usually been achieved by calling CFRunLoopRun() when calling the start: method on NSURLConnection and CFRunLoopStop(CFRunLoopGetCurrent()) when the connection finishes loading or fails.

However, as my colleague Keith Duncan pointed out on CocoaBuilder, this is not optimal and should be avoided.

So, by creating an NSOperationQueue in your NSOperation subclass and scheduling the delegate callbacks into this queue, we do not need to run the current runloop for the length of the operation and consume a thread. In a nutshell, this is very handy and a much cleaner way to achieve this!

Here comes the problem: even though everything works perfectly fine on Lion, when performing the very same thing on iOS, the delegate callbacks are never called. It looks like the connection has to be started (and the delegate queue set) on the main queue for the delegate callbacks to happen. This obviously defeats the point of using it within an NSOperation subclass given that since Snow Leopard (and iOS 4.0) the start method of NSOperation will likely not be called on the main thread.

For this reason, in my opinion, the setDelegateQueue: method is unusable as per iOS 5.0 and should be avoided until Apple fixes this problem.

I have filed a bug at rdar://10529053 and you should dupe it if you observe the same behavior as I do.

I have created a small sample project to demonstrate the bug that I have attached to the radar. Feel free to run it on your side and see for yourself. You can download it from here.

MIME type to UTI and back again in Cocoa

Damien DeVille — Wed, 28 Dec 2011 00:00:00 PST

Often when working with web services in Cocoa, I need to convert between MIME type and Uniform Type Identifier (UTI).

I have seen many hacky way to do this but, in my opinion, following is the correct way to achieve it.

First let's import the appropriate framework based on the platform (you might also need to add the framework to your project if not previously done).

#if TARGET_OS_IPHONE
#import <MobileCoreServices/MobileCoreServices.h>
#else
#import <CoreServices/CoreServices.h>
#endif

To get the UTI from a MIME type.

NSURLResponse *response = ... // assume a URL response from somewhere else.
NSString *responseMIMEType = [response MIMEType];
CFStringRef MIMEType = (__bridge CFStringRef)[response MIMEType];
CFStringRef UTI = UTTypeCreatePreferredIdentifierForTag(kUTTagClassMIMEType, MIMEType, NULL);
NSString *UTIString = (__bridge_transfer NSString *)UTI;

And to get the MIME type from the UTI.

NSString *filePath = ... // assume the path to a file from somewhere else.
CFStringRef fileExtension = (__bridge CFStringRef)[filePath pathExtension];
CFStringRef UTI = UTTypeCreatePreferredIdentifierForTag(kUTTagClassFilenameExtension, fileExtension, NULL);
CFStringRef MIMEType = UTTypeCopyPreferredTagWithClass(UTI, kUTTagClassMIMEType);
CFRelease(UTI);
NSString *MIMETypeString = (__bridge_transfer NSString *)MIMEType;

→ Sophiestication Apps on Sales

Damien DeVille — Thu, 22 Dec 2011 00:00:00 PST

All Sophiestication Software apps are $0.99 for the Christmas period.

I own all of them and am a big fan of Groceries and Articles for both iPhone and iPad in particular. Go check them out!

→ Updated Realmac Company Page

Damien DeVille — Tue, 20 Dec 2011 00:00:00 PST

Check out the updated company page at Realmac Software and our new avatars!

→ UCL Computer Science Short Courses

Damien DeVille — Tue, 06 Dec 2011 00:00:00 PST

The UCL Computer Science department has released a list of short courses for the summer of 2012.

The Time-Series Modelling one looks quite nice (and would remind me of the time when I used to be a student there actually!). I also like Popular Writing. Many of us can indeed very well write when targeting a technical audience but writing for the general public is definitely another story.

New Google+ for iOS icon

Damien DeVille — Tue, 06 Dec 2011 00:00:00 PST

Google+ for iOS. Keeping up with good design and inconsistencies.

→ Alfred app goes 1.0 on the Mac App Store

Damien DeVille — Tue, 06 Dec 2011 00:00:00 PST

Today, Alfred app version 1.0 has been released on the Mac App Store (it's actually been available to download from their website for a couple of days).

I love Alfred. I've never been a fan of Quicksilver or LaunchBar, always preferring the simpler Spotlight but Alfred seriously got me!

Also, if you feel like you want to give some money to the developers, make sure you check Alfred Powerpack. Plenty of awesome additions.

→ LLVM 3.0 Release Notes

Damien DeVille — Fri, 02 Dec 2011 00:00:00 PST

Check out the new goodies.

Birds vs Chickens

Damien DeVille — Thu, 01 Dec 2011 00:00:00 PST

This is getting seriously ridiculous.

Welcome to the New Way to Navigate Google

Damien DeVille — Wed, 30 Nov 2011 00:00:00 PST

Not sure I like it.

→ Analog Update on the Mac App Store

Damien DeVille — Tue, 01 Nov 2011 00:00:00 PDT

The 1.01 version of Analog has just been approved this morning and is available on the Mac App Store. Update through the Mac App Store or if you didn't purchase it yet, go get it!

→ A Sister's Eulogy for Steve Jobs

Damien DeVille — Sun, 30 Oct 2011 00:00:00 PDT

A very poignant article from Mona Simpson, Steve Jobs' sister. Such a touching story, extremely well narrated.

Recursive Blocks in Objective-C

Damien DeVille — Sat, 29 Oct 2011 00:00:00 PDT

Blocks are an awesome feature added to Objective-C with Mac OS X 10.6 and iOS 4.0.

Most of the Cocoa API now includes block-based alternatives and some new APIs (like the AssetsLibrary framework for example) are only based on blocks. So you do not have a choice anymore, you have to use blocks.

One cool feature that you might run into is recursive blocks. Even if there is in fact no reason why a block could not be recursive, there are a couple of rules to follow. An example of a recursive block would be something like the following:

void (^blocky) ();
blocky = ^ void (){
    blocky();
};
blocky();

Note that this piece of code has a couple of problems, apart from the fact that it loops forever, but explaining them being the point of this post we will discuss them later (no spoilers!).

So why would we ever want to use a block recursively? Well, think about a common pattern in Cocoa, particularly in CocoaTouch. You have a UINavigationController on which you push instances of subclasses of UITableViewController in order to display some sort of tree structure of data. This structure will most likely be fetched from Core Data and resides in a single place in your application, probably in the root view controller of your navigation controller.

Now suppose that each of these instances of (subclasses of) UITableViewController has to perform a specific action when one of its cells is clicked. It could be modifying the cell, pushing a new UITableViewController on the navigation stack or even do nothing. Since, as we have seen, the whole data structures would be owned by a single object (the root view controller), you do not really want controller down the stack to have to decide what to do with this data. You would rather have the root view controller, that actually manages the data, react to events down the chain.

You could have a simple protocol in your UITableViewController subclass that the root view controller would conform to but you would end up with your logic for cell selection handling residing in two spots: in the table view cell selection callback in your root view controller and in the table view controller subclass delegate methods in this very same root view controller.

So why not having a block that handles the cell selection in the root view controller and passing this block down the stack. Once a cell down the navigation controller is clicked, the controller subclass simply invokes that block and the root view controller will perform anything it has to do at that stage.

So let's write some (pseudo)code. First, assume that we will use the same subclass of UITableViewController for any level of navigation down the stack. At the end, it probably will display the same kind of data so why create a custom subclass for each level of navigation. We will also have a simple class representing a data object to be displayed. Think about it as the data backing up the content of your cells. These objects are probably organized in an NSArray that itself resides in the root view controller. Each data object has a children array containing other data objects further down in the data hierarchy.

First the very elementary MyDataObject class:

@interface MyDataObject : NSObject

@property (strong) NSArray children;

@end

@implementation MyDataObject

@synthesize children = _children;

@end

Next, the UITableViewController subclass used to manage the table view used to display content down the navigation stack:

typedef void (^CellSelectionHandlerBlock)(MyDataObject clickedItem);

@interface MyTableViewControllerSubclass : UITableViewController

@property (strong) MyDataObject dataObject;
@property (copy) CellSelectionHandlerBlock selectionHandlerBlock;

@end

@implementation MyTableViewControllerSubclass

@synthesize dataObject = _dataObject;
@synthesize selectionHandlerBlock = _selectionHandlerBlock;

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (_selectionHandlerBlock != NULL)
    {
        MyDataObject *clickedDataObject = [[[self dataObject] children] objectAtIndex: [indexPath row]];
        _selectionHandlerBlock(clickedDataObject);
    }
}

// some other methods, in particular UITableView dataSource and delegate

@end

And finally the root view controller, itself a subclass of UITableViewController, that manages the table view used at the first level of hierarchy. It also manages the data objects and handle the cell selection in both its own table view and down the stack:

@interface MyRootTableViewController : UITableViewController

@property (strong) NSArray *dataObjects;

@end

@implementation MyRootTableViewController

@synthesize dataObjects = _dataObjects;

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    CellSelectionHandlerBlock selectionHandlerBlock = nil;
    selectionHandlerBlock = ^ void (MyDataObject clickedItem) {
        if ([[clickedItem children] count] > 0)
        {
            MyTableViewControllerSubclass *viewController = [[MyTableViewControllerSubclass alloc] init];
            [viewController setDataObject: clickedItem];
            [viewController setSelectionHandlerBlock: selectionHandlerBlock]
            [[self navigationController] pushViewController: viewController animated: YES];
        }
        else
        {
            NSLog(@"Do some funky stuff with the cell!");
            // like presenting a modal view controller with some content.
        }
    }
    
    MyDataObject *dataObject = [[self dataObjects] objectAtIndex: [indexPath row]];
    selectionHandlerBlock(dataObject);
}

// some other methods, in particular UITableView dataSource and delegate

@end

So as you can see, we only need to write the selection handling code once. In function of the data object underlying the clicked cell, the root view controller create a new MyTableViewControllerSubclass with the appropriate data object and pass the selection handler block to it. Whenever a cell is clicked in a view controller down the stack, we first retrieve the data object corresponding to the clicked cell and invoke the block.

Also, every time a table view cell is clicked in the root view controller itself, the very same block is invoked.

However, this piece of code creating the block is wrong for two reasons that I am going to explain. As you can see, the block is recursively called inside the block itself. In order to explain the problems with the current approach, let's get back to our simpler blocky example.
In this example, a block is created and then called inside the content of the block creating infinite recursion. Leaving aside the infinite part here, this piece of code would crash on the first recursive call. To understand why, let's first discuss how a block treats its enclosing scope variables. Consider the following example:

int i = 1;
void (^block) () = ^ void () {
    NSLog(@"i = %i", i);
    i++;
};

This piece of code would correctly print i = 1 but would crash on the second line i++. The reason is that the block captures local variables in its scope and treat them as constant.
In the case of Objective-C objects, captured objects are retained (and automatically released when the block goes away).
Blocks are actually Objective-C objects themselves. When first created, a block lives on the stack. If you intend to use the block beyond the current scope, you need to copy it to the heap. Once the block has been copied to the heap, it can be retained and released as a regular object (it does not make sense to retain a stack-based block though).
In order for a block to change its enclosing scope, we can use the __block storage type. Consider the following example:

__block int i = 1;
void (^block) () = ^ void () {
    NSLog(@"i = %i", i);
    i++;
    NSLog(@"i = %i", i);
};

In this case, the program will run correctly and print i = 1 and i = 2. The block was able to modify the variable in its enclosing scope. Also note that __block captured objects are not retained.

So coming back to our blocky example, we now understands better why the crash is occurring. Since the block itself is invoked inside the block, it is const copied even before the assignment occurs. We can fix this by rewriting the program as:

__block void (^blocky) ();
blocky = ^ void (){
    blocky();
};
blocky();

Similarly, in our navigation controller example, we would have to rewrite:

__block CellSelectionHandlerBlock selectionHandlerBlock = nil;
selectionHandlerBlock = ^ void (MyDataObject clickedItem) {
    ...
}

So far so good, and to be honest, during my testing, I did not have to do anything else for this to run perfectly in Debug mode. However, the first time I ran it in Release mode, my program crashed on the block invocation. It took me a while to understand what was going on until I realized that there was a small problem here.
I was reusing my block outside the current scope and even copied it later on (when passed to another objects).
If you think about it, the first block that is assigned to the __block type variable is a stack-based block. The block that is called inside the block is this very same stack-based block.
When the block is moved to the heap, captured variable are moved to the heap too. So our block variable is moved to the heap once the block is copied so we need to make sure that the reference variable points to the copy of the block and not the original stack-based one.

The solution to this problem is to copy the block while creating it and assign this copied version to our __block variable:

__block void (^blocky) ();
blocky = [^ void (){
    blocky();
} copy];
blocky();

I have no idea why this was not crashing in Debug.

Blocks are very handy but are a tricky concept to grasp at first. However, there are a very powerful tool and I can only tell you that once you go block you never go bock (sorry, that was lame).

I definitely recommend the following articles and books to learn more:

Joachim Bengtsson - Programming with C Blocks
Bill Bumgarner - ^ Blocks Tips & Tricks
Mark Dalrymple - Advanced Mac OS X Programming chapter 3 "Blocks"

Moving to Jekyll

Damien DeVille — Fri, 28 Oct 2011 00:00:00 PDT

I haven't had much time to blog about it since I made the switch but you might have noticed the new feel and look of my site!

I have moved away from WordPress for various reasons but mainly because I really did not like the idea of having my content living in a database. Also, I wanted to code the CSS myself and did not particularly want to go through the whole WP theme stuff.

So, the story in a nutshell, I am now generating a static version of this site with Jekyll. I write all the posts and bits in Markdown that I store as plain text files. I have written all the CSS using Sass (highly recommended by the way). I store my media files on Amazon S3 that I access with Amazon Cloud Front. I use TypeKit for serving and managing the fonts and the MathJax JavaScript display engine for rendering the mathematics formulae written with LaTeX. I am also using DISQUS for the comments on the posts.

I use quite a few new goodies of HTML 5 and CSS 3 so the site will render best on WebKit and fairly alright in Firefox. I checked that the site looked ok on the latest version of IE but I have no idea how it does on former versions. But frankly, I don't even give a rat's ass!

I am very happy with the look of the site on a desktop browser and Safari on the iPad (and I guess this applies to all tablet even though I haven't tested it). However, I still will have to write a mobile stylesheet for the iPhone (and other smartphones).

The very cool stuff is that I can now version control my entire website.

Norman's Dream Device

Damien DeVille — Thu, 27 Oct 2011 00:00:00 PDT

Donald A. Norman in The Design of Everyday Things, 1988:

Would you like a pocket-size device that reminded you of each appointment and daily event? I would. I am waiting for the day when portable computers become small enough that I can keep one with me at all times. I will definitely put all my reminding burdens upon it. It has to be small. It has to be convenient to use. And it has to be relatively powerful, at least at today's standards. It has to have a full, standard typewriter keyboard and a reasonably large display. It needs good graphics, because that makes a tremendous difference in usability, and a lot of memory - a huge amount actually. And it should be easy to hook up to the telephone; I need to connect it to my home and laboratory computers. Of course, it should be relatively inexpensive.

What I ask for is not unreasonable. The technology I need is available today. It's just that the full package has never been put together, partly because the cost in today's world would be prohibitive. But it will exist in imperfect form in five years, possibly in perfect form in ten.

In my opinion, even if PDAs have existed for quite a long time, almost 30 years later, the first device that actually meets every criteria mentioned by Norman (apart from the cost maybe) is the iPhone.