Category: Cocoa

In this post, I’d like to outline what MacLemon and I worked on for the metalab Hackathon 8. The project stems from a problem with one of the most basic rules of software development:

Let software developers develop software, don’t hog them with repeated configuration/administration stuff.

This rule is violated with large-scale Cocoa development for the iPhone that also has beta testers: If you want to allow them, you need something like HockeyApp (or TestFlight, but we didn’t use that one). Further, somebody might break the build without realizing it (that’s not specific in any way to Cocoa development). Different versions of Xcode use different compilers, which might not accept the same source code.

Apple sketched a solution for some of these problems in WWDC 2012, session 404: You can integrate Xcode into Jenkins CI, a continuous integration platform written in Java. We chose to improve on this solution, to let it do much more.

What you need:

  • A build server that runs Mac OS X, accessible by all developers and itself able to access the HockeyApp website.
  • A server runnig git. This might be the same server as the above, but doesn’t have to be. Our instructions are for the case where it’s on the same server, as this is easier to do (only “localhost” as hostname).
  • Development must happen using git & Xcode (we tested version 4.3, 4.4DP4 and 4.5DP2)
  • A very solid knowledge of the command line, since just about everything will be done there.

What this solution provides:

  • On every push, the app is checked for build errors (and the test suites can be run, if you happen to have some).
  • Working versions are automatically tagged, so you can easily correlate build logs to the git history.
  • Pushing a release to HockeyApp only requires adding a tag to a revision before pushing it to the server.

Some ideas in what way this solution can be extended very easily:

  • Push working git revisions to a different git server.
  • Email a build breaker to communicate this fact.

View full article »

Mac OS X Range Selection Behavior

Sorry for the long silence, I’m really busy with work!

This is only a quick note about the list view range selection behavior (shift-click) I’m observing in Mac OS X Lion’s Finder. There’s quite more to it than you might think!

  • First off, when there’s nothing selected and you shift-click on an item, all items from the top up to the clicked one (including itself) are selected.
  • When there is an existing selection, the result depends on the previous non-range selection action:
    • Regular selection: The range between that item and the clicked one is selected (including both items).
    • Deselection (cmd-click on a previously selected item): The range between the clicked item and the next selected one below it is selected. If there is none, the range between the previous selected item and the clicked one is selected.
  • In the previous step, if the previously selected item is part of a contiguous range, all other items of that range are deselected.

Did I miss anything? Please tell me via Twitter (@anlumo) or comment below!

UPDATE: @5minpause pointed me to an article, describing the same behavior in a much more elaborate way: Legendary Selections, Dude

UPDATE 2: Alright, discovered another peculiarity in the Finder selection behavior: When clicking onto the file name or file icon without any modifiers, the selection is changed on mouseUp: (the previous selection is also not changed in mouseDown: yet). When either any modifier is held down or the row is clicked somewhere else, the selection is changed in mouseDown:. I guess this is implemented so that you can drag a file without changing the selection.

Cocoa Blocks Pitfall

Just because it bit me again for a millionth time:

int a = 0;
void(^block)(void) = ^{ printf("%d", a); };
a = 1;

outputs 0, because the value of a is copied to the block when it is declared.

View full article »