Programming

There are 61 entries in this Category.

Blocks and block lists

When I first heard about blocks, I was horrified. All the un-clean code structure of huge ten-page functions, plus the loss of self-documenting function names. Why would someone want anonymous functions? And even worse, anonymous functions that can cause retain circles because they automatically retain objects you reference, because they have access to the scope of the surrounding function, like nested functions?

Then, at one NSConference, someone pointed out that they are really good for making asynchronous code look more synchronous. Who would have thought that blocks, carefully used, could actually improve readability of code?

Imagine you are using an NSURLConnection to retrieve a JSON file from a server and extract information from it. In synchronous pseudocode:

-(void) showInfo
{
    NSString* myJSON = [NSString stringWithContentsOfURL: @"http://example.com/data.json"];
    if( myJSON == nil )
    {
        [self reportError];
        return;
    }
    NSString* userText = [self prettyPrintJSON: myJSON];
    [self showPanelWithText: userText button: @"OK"];
}

Minimal code for doing this asynchronously and avoid blocking the user interface and spinning the beach ball when the connection is slow includes creating an NSURLConnection, setting yourself as its delegate then displaying any error you get from one delegate method, or when the request completes and a second is called, to actually process the request. So the above code turns into pseudocode:

-(void) showInfo
{
    self.connection = [[NSURLConnection alloc] initWithURL: @"http://example.com/data.json"];
    myConnection.delegate = self;
    [myConnection start];
}

-(void) connection: (NSURLConnection*)sender didFinishLoading: (NSString*)myJSON
{
    NSString* userText = [self prettyPrintJSON: myJSON];
    [self showPanelWithText: userText button: @"OK"];
    self.connection = nil;
}

-(void) connectionDidFailLoading: (NSURLConnection*)sender
{
    [self reportError];    
}

Notice how 5 straightforward lines have turned into a spaghetti of three methods? Now imagine you had to chain several requests. You’d have to create separate delegate objects for each request, or key off the ‘sender’ parameter and handle the OK case for all requests together in one delegate method, and the error cases together in another.

Now how does that look with blocks (still pseudocode)?

-(void) showInfo
{
    [NSURLConnection sendAsynchronousRequest: @"http://example.com/data.json" completionHandler: ^( NSURLRequest req, NSString* myJSON, NSError* error )
        {
            if( error )
            {
                [self reportError];
                return;
            }
            NSString * userText = [self prettyPrintJSON: myJSON];
            [self showPanelWithText: userText button: @"OK"];
        }];
}

Shockingly, that almost looks like our original, synchronous code. Now to be fair, if someone at Apple had added a delegate method to NSURLConnection that combined the error case and the success case like the above block does, the original example would be a tad simpler as well. But performing several requests in sequence would still split the actual requests from their replies, and group them by request or reply.

With blocks, on the other hand, two requests in sequence would look almost like the synchronous code would, with nested ifs:

-(void) showInfo
{
    [NSURLConnection sendAsynchronousRequest: @"http://example.com/data.json" completionHandler: ^( NSURLRequest* req, NSString* myJSON, NSError* error )
    {
        if( error != nil )
        {
            [self reportError];
            return;
        }

        NSString* userText = [self prettyPrintJSON: myJSON];
        [self showPanelWithText: userText button: @"OK"];

        [NSURLConnection sendAsynchronousRequest: @"http"//example.com/data2.json" completionHandler: ^( NSURLRequest* req2, NSString* myJSON2, NSError* error2 )
        {
            if( error2 != nil )
            {
                [self reportError];
                return;
            }

            NSString * userText2 = [self prettyPrintJSON: myJSON2];
            [self showPanelWithText: userText2 button: @"Done"];
        }];
    }];
}

You’re probably already seeing where our problem is, though. Since every block adds one level of brackets and depth, it becomes pretty hard to re-order requests. You’d have to cut the inner request out, then wrap it around the outer request so it only triggers the other request on success.

But here is where it comes in handy that blocks aren’t just nested functions. Blocks are actually real Objective-C objects. So, we can keep an array of blocks:

-(void) showInfo
{
    NSMutableArray * steps = [NSMutableArray array];
    [steps addObject: ^( NSMutableArray * steps )
    {
        // First request start:
        [NSURLConnection sendAsynchronousRequest: @"http://example.com/data.json" completionHandler: ^( NSURLRequest* req, NSString* myJSON, NSError* error )
        {
            if( error != nil )
            {
                [self reportError];
                return;
            }

            NSString* userText = [self prettyPrintJSON: myJSON];
            [self showPanelWithText: userText button: @"OK"];
            // First request end.

            [[steps[0] retain] autorelease]; // Make sure we don't go away.
            [steps removeObjectAtIndex: 0];
            steps[0]( steps );
        }];
    }];
    [steps addObject: ^( NSMutableArray * steps )
    {
        // Second request start:
        [NSURLConnection sendAsynchronousRequest: @"http://example.com/data2.json" completionHandler: ^( NSURLRequest* req2, NSString* myJSON2, NSError* error2 )
        {
            if( error2 != nil )
            {
                [self reportError];
                return;
            }

            NSString* userText2 = [self prettyPrintJSON: myJSON2];
            [self showPanelWithText: userText2 button: @"OK"];
            // First request end.

            [[steps[0] retain] autorelease]; // Make sure we don't go away.
            [steps removeObjectAtIndex: 0];
            steps[0]( steps );
        }];
    }];
    [steps addObject: ^( NSMutableArray * steps )
    {
        // Done.
    }];
    steps[0]( steps ); // Kick off execution
}

So, we add the blocks to an array with 3 -addObject: calls, then at the bottom run the first block in the array. When each block is done, it removes itself from the array, and runs the next block in the array (except for the last block, which is simply there so the second-to-last block has someone after it to call — we could also just check whether the array is empty before trying to call the next block). This looks a little more complicated than it should, but if wrapped in an ObjC class with a -next method is very readable.

Now, if you want to re-order two requests, you simply re-order the -addObject: calls. Since none of the blocks care which block follows them, you don’t need to wrap anything around anything else.

You can now read all requests in sequence (hence I call these things block sequences), ignoring the spots at which control is given up to the system for a while, and re-arrange them as you please. Neat, huh?

Posted on 2013-05-08 at 13:35 Leave a Comment

This post is filed under Common Cocoa Coding Patterns, Objective-C, Programming.

Why Cocoa programmers can’t have nice things

Amy Worrall pointed me at a nice post on the technical feasibility of using exceptions for more than programming errors in Cocoa by Hari Karam Singh. Even though he is misled by some Mac documentation into thinking iOS didn’t have zero-cost exceptions and then disproves that documentation by disassembly, he draws lots of valid conclusions.

However, the problem is not one of technology. The problem is one of the sheer size of Apple’s Cocoa codebase, which would have to be updated to survive having an exception thrown through it. Apple would have to add @trys in every location where they call a SEL, after all, since they don’t know which of them may be user-provided and throw.

Since they’re not doing that, a user who decides to use exceptions anyway would have to add @trys to every method that might ever be called by the framework. That means you can’t catch exceptions thrown by that method when you call it, though, because it swallows them itself. So if you want to handle errors from that method, you either split it up into okButtonClickedThrows: and okButtonClicked:, duplicating every method and working in parallel with two error handling schemes, or you give up, like Apple, and just use one non-exception error handling scheme.

I love exceptions, but I don’t think my Cocoa code will be cleaner and error handling nicer if I put a try block at the top of every action and delegate method. NSError is less dangerous, because if an object returns nil and gives an error (and you don’t look at the returned error), the method call will simply collapse (call to NIL is a no-op) so nothing much will happen. Since I can’t put up an error dialog from drawing code or table delegate callbacks like numberOfSections, there’s not much difference there. The code is actually cleaner, because with NSError and nil returns I can just ignore errors, while with exceptions in an exception-unsafe Cocoa, I must catch here or I’ll risk throwing through Cocoa.

C++ also has an advantage when working with exceptions over Objective-C because it uses “Resource Acquisition Is Initialization” (or RAII for short). Locks, allocations, even changes of a global boolean can be implemented as stack objects using RAII to set themselves up when created and clean up behind themselves in their destructor. You don’t even have a ‘finally’ block in the language. OTOH, every method you write in an exception-handling ObjC would need an @finally block, even if it doesn’t care about the errors, just to clean up behind itself.

ARC, @autoreleasepool and @synchronized can help a little with clean-up of memory and locks these days, as they’ll get triggered on an exception anyway. But as Cocoa and Apple’s frameworks currently stand, using exceptions effectively doubles your work.

The same applies to existing code. Nobody wants to have to completely rewrite their apps for 10.9 just to adopt a new error handling scheme when their code already has working error handling with NSError. Apple understands that their developers want a certain degree of backward compatibility. That’s the reason why only iOS got the new runtime on 32-bit: There was no code that relied on the old runtime there, it was a new platform. But all existing Mac applications would have been broken if the system had suddenly no longer guaranteed instance variable layouts and method lookup-tables. However, since 64-bit required changes to pointer sizes and data structures anyway, nobody complained when Apple introduced the new runtime for 64 bit on the Mac. They had to re-test and update their applications anyway.

All that said, I would love a new Objective-C framework that uses exceptions and is exception-safe for new projects to be built against. It just doesn’t seem like something Apple can retrofit at a whim.

At best, they can slowly make each framework exception-safe, and then in every spot where there can be an error, instead of returning it, look at an “app supports exception handling”-flag and throw their errors if that is set. That way, existing applications will keep working, while new applications can be written exception-safe. And once the majority of applications have moved to exceptions, Apple can switch to using exceptions themselves (see above — you don’t want 2 versions, exception-safe and unsafe, of every method), and tell the stragglers to please make their code exception-safe.

Posted on 2013-05-04 at 13:27 3 Comments

This post is filed under Language Design, Macintosh, Objective-C, Programming.

Setting up Jenkins for Github and Xcode, with Nightlies

Jenkins? What? Why?

When you work alone on a several projects that share code, it’s easy to unnoticeably break the build of one project with a change for the other, or introduce some specific dependency on a quirk of your main work Mac, or lose data by referencing a file outside the repository instead of copying it in. Since that’s annoying, I decided to set up Jenkins, a continuous integration system, on my Mac mini that serves as my EyeTV DVR, media centre and home server.

It’s not that hard, but some of the details are a bit fiddly and under-documented, so I thought I’d write down how I made it work before I forget it (and for when I next have to set it up again). My source code is in a Github repository, and while I was at it, I wanted to set it up that one of my open source projects gets nightly builds FTPed onto its web site (but only when I’ve actually changed something).

Initial Install

Jenkins is a Java application. Since Java no longer comes pre-installed on Mac OS X, if you’re not using any other Java applications, you should open a Terminal and type in java, which will make Mac OS X notice Java is not yet installed and download it. Also make sure you’ve installed Xcode on your Mac. The version from the app store is fine, but make sure you install the command line tools under Preferences > Downloads on the Components tab, so Jenkins will be able to find git.

Next, you’ll want to create a dedicated user account that Jenkins will run under. The standard installer does that for you, but it only creates a command-line account, which makes it very hard to set up all the certificates, so go to System Preferences‘s Users & Groups section, and create a new account and name it “Jenkins”. Make sure you enter “Jenkins” with a capital ‘J’ under “Account name”. Also, right-click the account in the list on the left and choose “Advanced Options…”. Replace the standard home directory “/Users/Jenkins” with “/Users/Shared/Jenkins”, which is what the standard installer will use.

Now that all is ready, go to jenkins-ci.org, and right on the front page you’ll find a Mac OS X direct download link that gives you a nice Mac installer package. Run that. Jenkins will be installed so it automatically launches at system startup, and it will run on your Mac on Port 8080. So make a note to later forward that port through your router to your Mac so it is accessible from the outside (you will need a dynDNS domain-name connected to it, or a static IP, or Github won’t be able to notify you of changes). But not yet! First you have to secure Jenkins with a password.

Open your browser and point it at http://localhost:8080 (your Mac’s Bonjour name is fine as well, as will be your external domain name or IP, when you later set up the port forward). And after a short wait you’ll get to Jenkins’ front page. There’s a breadcrumb bar at the top which pops up a little menu if you mouse over the initial Jenkins breadcrumb:

Jenkins front page

Under Manage Jenkins, click Configure Global Security and there, check Enable Security, but do not save yet! If you do, Jenkins will happily lock you out. You haven’t created a user login yet, so you’ll never be able to get back in again without editing the config.xml in the Jenkins user folder and manually deleting the three security-related lines in there.

Next, we’ll have to set up permissions for the new user login, and then actually create it. So first tell Jenkins to use Jenkins’s own user database and Allow users to sign up under Security Realm. Then check Matrix-based security and type whatever user name you want into the little User/group to add: field and click Add. Then make sure that all checkboxes are checked for this user login, all the way to the right, and all are off for “Anonymous”.

Screen Shot 2013 04 06 at 00 20 36

Now that that’s done, you can save. Then click Sign up in the upper right and sign up under the user name you just gave all the permissions to. Yay! We have a valid user! Now go and turn off the Allow users to sign up checkbox again so nobody else makes themselves an account on your server.

Git support

By default, Jenkins only does SVN. But it has a nice big list of plug-ins that you can easily install. Go to the menu, Manage Jenkins > Manage Plugins and go on the Available tab. There’s a boatload of plugins there, but we only care about one for now: Github Plugin. Find it (there are a few with similar names) and install it. Check the box to restart after the installation.

If you’re curious about a plugin, just click its name. It will show a web site with documentation and setup instructions. Installing a plugin means that its checkboxes and text boxes show up in the Configure System section and each job’s Configure section. So let’s go to Configure System.

Take note of the Home directory mentioned at the top. This is where you’ll later be installing your Github certificates so Jenkins can check out code. Also, since you want your Jenkins externally accessible, scroll down to Jenkins Location and enter your external URL or static IP as the Jenkins URL there.

Between those two is a Git category. Click the lone Git installations… button there. If you installed the Xcode command line tools as mentioned, you will not see a red error message here and it will have found git in the default location. Otherwise, set up the search paths to point wherever you have git installed.

Now go to Github Web Hook and check Let Jenkins auto-manage hook URLs and enter your username and password in the fields that show up. This is needed so Jenkins can install a script that notifies it whenever a new commit has been pushed, so it’ll start a build. Click Test Credential to make sure that works.

GithubWebHook

Setting up a job

In Jenkins, everything that is built periodically is represented as a Job. To create a new job, click New Job in the upper left on the Jenkins home page. In the page that follows, choose a name (but be sure not to use spaces, as this name will be used for the folder in which Jenkins will work, and you’ll have much less trouble with a shell-script-friendly name), and select “Build a free-style software project”.

Jenkins New Job Page

Click OK, and you’ll get to that job’s Configure page. Select Git under Source Code Management and enter the URL you see on Github under SSH for your repository twice, once in Github project at the top, and as the Repository URL under Source Code Management:

Creating a new Jenkins Job

And finally, check Build when a change is pushed to Github under Build Triggers:

Screen Shot 2013 04 06 at 13 44 07

Now you’ve set up Jenkins so it will try to check out your code whenever a change happens. Next, we will have to tell it how to actually build it. We do that in the Build section. Click Add build step and choose Execute shell. You’ll get a text field in which you can enter a shell script.

This shell script will be run in the folder into which your repository was checked out. This will be a folder named after your job in the workspace subfolder of your jenkins user’s home directory. So if your Xcode project file is at the root of the repository, you can just call xcodebuild there. If it’s in a subfolder, you can cd SubFolderName and then call xcodebuild.

Set up a Jenkins build

One problem with Xcode is that it builds into a hardly-predictable folder somewhere in Library. Jenkins requires all built files to be inside a job’s workspace folder, or it won’t let you archive them. So we need to override it to e.g. build into a build folder inside the checkout. To achieve this, we set the CONFIGURATION_BUILD_DIR environment variable when we call xcodebuild. Note the example screenshot hard-codes the path, while I now use one of Jenkins’ environment variables:

BUILD_DEST_PATH=${WORKSPACE}/build

The script above, once it is done, grabs the files from the build folder and compresses them into a single archive. This is so we can archive the built file somewhere, for future reference. The actual archiving is done under Post-build Actions where we select Archive the artifacts from the Add post-build action popup. Here again, the path is relative to your job’s workspace subfolder, so if you want to archive something added to the build folder, use a relative path like build/MySweetApp.tgz.

Note that Jenkins tries to be helpful and displays red warnings that it can’t find the file to archive right now. At this point, that’s OK. There is no checkout, and we’ve never archived anything. However, later, this can be very helpful in figuring out what’s gone wrong, if the checkout works, but building fails or so.

Done? Then save. You could also click Build Now on the left (or the little clock with the green “run” arrow on it anywhere next to your newly-created job on the home page), but it would fail. Apart from errors in your script, there would likely be two issues, which you can see in the menu that shows up when you hover the mouse over any failed build and click “Console Output” in the menu that shows up:

Github will complain that you don’t have permission/are missing certificates
Xcode will complain you haven’t accepted its license agreement.

Remember when you set up access to Github for the first time and you had to create and install certificates? You’ll have to do that for your Jenkins user, too. Or you could simply copy the hidden .ssh folder in your user directory over into the Jenkins user’s home folder. Note that this isn’t e.g. /Users/Shared/Jenkins/Home like in the standard installation, but actually one folder up, so you want your certificates in /Users/Shared/Jenkins/.ssh/.

Note you’ll have to

sudo cp -R ~/.ssh /Users/Shared/Jenkins/
sudo chown -R jenkins /Users/Shared/Jenkins/.ssh

to make the folder accessible to the Jenkins user. If you created a real GUI-user for jenkins, you can simply run Xcode once and accept the license agreement once. Alternately, as the error message from xcodebuild will tell you, you can do

sudo -u jenkins -i
xcodebuild -license
exit

To view the license. While you’re in the license screen, you can skip to the end by typing an uppercase G (you’ve already accepted the license agreement when installing the command line tools from inside Xcode, after all), then type in agree, as directed.

If you now click Build Now on Jenkins’s home page, it should work. The job should show up in the Build Queue, the ball at its left should flash for a while, and the similar ball next to the job in the list of jobs on the home page should be blue. If it is red, click the Job’s name, and in the Build History on the left mouse over it and choose Console Output to see the log and error messages.

If a build was successful, you can view the archived files (“artifacts”) by clicking a job on the home page, and then one of the individual build times listed at the bottom of its page.

Setting up nightly builds

If you want to make nightly builds and not just have them in Jenkins, but actually upload them to an FTP server somewhere, you will need the FTP Publisher Plugin. Install it, then go into Manage Jenkins > Configure System and scroll to the new FTP repository hosts section. You can create a preset for each server you have. Since Jenkins is publicly accessible, I recommend creating a separate user for Jenkins and restricting it to only a nightlies folder on the server, and no CGIs. That way, should Jenkins somehow be hacked, people at least can’t use the password and login to deface the rest of your server (even though they *can* replace the downloads).

FTP Server settings

Once you’ve added your server, create a new job (e.g. MySweetAppNightly, but this time check Copy existing Job and type in the name of your regular CI job as the template (e.g. MySweetAppCI). Then just add a new action to Post-build Actions, by choosing Publish artifacts to FTP from the Add post-build action popup. Select your server from the FTP site popup and write the relative path name of the TGZ archive you set up in Files to upload (in our example, that would have been build/MySweetApp.tgz). Leave the Destination-field empty, unless you want to upload into a subfolder of the folder you set up in System Configuration. If you are building into a subfolder (like in our example build/MySweetApp.tgz), you may also want to check Flatten files, or it will upload into a subfolder of the same name on the server.

Now, what this would do right now is upload every change to the FTP server. The server would be strained unnecessarily if your application contains large assets. We want a nightly build. How do we do this? We scroll up to Build Triggers, turn off Build when a change is pushed on Github, and check Poll SCM. Now, we could just pick Build periodically, which is almost identical, but the advantage of Poll SCM is that it won’t build and upload if nothing has changed since the last build. (It would also be the right option if you host somewhere else than Github and can’t use the plugin and don’t want to write your own post-commit hook.

Click the question mark next to the Schedule text field to see the syntax, it is pretty much like cron. I picked 4 AM at night, every day of the week. That’s a time where I’m usually not in the middle of a series of check-ins, so chances are this should build.

Jenkins Build Triggers for Nightlies

If you hardcoded the path in the Build section, be sure to rename the job in the path there, then save and click Build Now to generate and upload your first nightly build.

Getting notified

Of course, all of this would be pretty pointless if we had to check Jenkins after every commit. Luckily, Jenkins can e-mail you. You need an e-mail account somewhere (I recommend creating one dedicated to Jenkins, again for security reasons, but any old Hotmail account would work). Scroll to “E-Mail Notifications” in Configure System and click the Advanced button, check Use SMTP Authentication, then enter the same user name, password and SMTP server you would specify to use this account from Mail.app or another e-mail client. Check Use SSL if your mail hoster supports that.

Advanced E-Mail Notifications

Then check Test configuration by sending test e-mail and enter whatever e-mail addres you want to send a test e-mail to in Test e-mail recipient and click Test configuration. If you mis-configured something, you’ll get Java throwing up backtraces in red all over your window. Enjoy.

Now, all that’s left is adding a E-mail Notification Post-build action to each job. Happy continuous integration, and a happy new year.

I also installed the Twitter plugin and added that as a Post-build action to notify me whether the build is broken. It is pointed at a protected Twitter account that only I can follow. You have to run a little Java command-line app to get the API access tokens needed for Jenkins to talk to Twitter, and paste those into text fields on Jenkins’ System Configuration, but that’s as complicated as it gets.

Certificates and DeveloperID Builds

If you want to build your Mac executables for distribution outside the Mac app store, you will need to log into your Jenkins user and open Xcode, and there go into the Organizer. Click Refresh in the Provisioning Profiles section (click OK in any App Store certificates not existing error messages it may put up if you only want to go outside the MAS, or you work Mac-only and not iOS).

Next, click your team. If it says there are no private certificates across the top, go to a Mac that has all your certificates already set up for development, and in the Organizer choose Editor > Developer Profile > Export Developer Profile… to export your private keys as a password-protected .developerprofile file. Copy that file over to the Jenkins user and double-click it there, and Xcode will ask for the password and install your certificates.

Now, verify that everything works: Open the project you want to build for developer ID. Go into the project‘s build settings and set the Code Signing setting to your Developer ID Application certificate. Build the project, clicking Always allow if Xcode asks for permission to use your private key to sign the application. If the build fails with an error like “timestamps differ by 205 seconds — check your system clock Command /usr/bin/codesign failed with exit code 1″, you probably dawdled too long in the confirmation dialog. Just build again and it should work.

If codesign fails trying to sign a file that doesn’t exist, you probably have a target that doesn’t produce a file, like a target that runs a shell script to generate a header containing the build number. Since we’re overriding the code signing setting for the entire project, it will try to sign that nonexistent output file. One way to satisfy it is to add a line like touch ${CODESIGNING_FOLDER_PATH} to the end of your script, which will create an empty file for codesign to sign.

Now that we know you have code signing set up correctly, we simply modify the call to xcodebuild in the job you want to have signed for Developer ID:

security unlock-keychain -p 's3kr1tp4ssw0rd' ~/Library/Keychains/login.keychain
xcodebuild CONFIGURATION_BUILD_DIR=$BUILD_DEST_PATH  \
  CODE_SIGN_IDENTITY="Developer ID Application: Joe Shmoe" \
  -configuration Release \
  clean build

The first call to security unlock-keychain does just that: Give xcodebuild running under Jenkins access to the keychain containing the keys it needs for code signing. Here you need to specify the keychain’s password, which is not a very secure thing to do, but can’t really be avoided in this case. At some point, the server *will* need access to your keys to build.

For a tiny bit of extra peace of mind, you might want to change the password of your keychain to be different from the account’s login password using the Keychain Access application. That way, if someone somehow manages to see this script and the password to the keychain, they still can’t log into your build tester to actually use it.

Alternately, you could run the Jenkins server that is exposed to the outside and manages the job on a different Mac (or at least as a different user?) than the actual build server. Jenkins allows that, so you can e.g. have one Jenkins web interface to build Mac, Windows and Unix software.

The second call is the same as our previous xcodebuild call, with three parameters added:

The first one does in script what we did manually for testing in the GUI: It overrides the “Code Signing:” build setting with the Developer ID certificate (Insert your name here).
The second one makes sure we don’t build with whatever configuration was last set, but instead make a release build, with optimizations and such. You could also specify that for other cases, if you wanted, to make sure e.g. stuff you remove from release builds doesn’t break the debug builds or vice versa.
The third makes sure we clean before we build. This makes sure you don’t get any leftover files from a previous build (e.g. script-generated header files), but is also slower than an incremental build. You would probably also want to do this for nightly builds, but probably not for a CI build that gets triggered a lot, unless your project is very small.

Including the job number

For my nightly builds, I wanted to have a monotonically increasing version number. To add this is fairly easy: Just pass a few more settings overrides to xcodebuild:

  GCC_PREPROCESSOR_DEFINITIONS="BUILD_NUM=${BUILD_NUMBER} BUILD_MEANS=nightly" \
  INFOPLIST_PREPROCESSOR_DEFINITIONS="BUILD_NUM=${BUILD_NUMBER} BUILD_MEANS=nightly" \

The first line includes the build number that Jenkins uses for this job as a #defined constant accessible to your source files. The second does the same for projects that you have set to preprocess their Info.plist file (e.g. to include the build number in the CFBundleVersionString). You can also define other constants, separated by spaces, like BUILD_MEANS in this example, to e.g. somewhere display that this is a nightly build. You can provide default values for manual builds in a header that you include in those source files that need them, or in a prefix header for your Info.plist:

#ifndef BUILD_NUM
#define BUILD_NUM     0
#endif
#ifndef BUILD_MEANS
#define BUILD_MEANS   manual
#endif

And this should cover everything you typically need to do on your new continuous integration Mac.

Posted on 2013-04-06 at 13:23 2 Comments

This post is filed under Macintosh, Objective-C, Programming.

Universal Procedure Pointers

When Apple announced they’d be switching from PowerPC to Intel CPUs in 2005, many existing Mac developers were looking at the prospect more calmly than newer arrivals to the platform. After all, Apple had done something similar before, successfully, in the mid-nineties: The switch from the 68000 CPU to the PowerPC CPU.

One of the differences to 2005′s switch, however, was that Apple permitted mixing of PowerPC and 68000 code within the same application. To achieve that, a new “Mixed Mode Manager” was introduced, that took care of switching between executing raw PowerPC code and emulating 68000 CPU instructions. The linchpin of this manager were Universal Procedure Pointers, or UPPs, for short (sometimes also called Routine Descriptors).

Universal Procedure Pointers

A UPP was a simple data structure that described the calling conventions and location of a PowerPC function in RAM, and started with a 68000 instruction. This data structure could be handed to any system function where it expected a callback, and could be executed by 68000 code just like a function pointer.

The instruction at the start of the UPP simply contained a jump (think function call, or goto) to a function that recorded the address of the UPP and stopped/started the 68000 emulator.

This meant that Apple only had to port the very foundations of the operating system to PowerPC for the initial roll-out. Applications like the Finder, or window/control definition functions (WDEFs and CDEFs, little code modules that took care of drawing the frame around a window or custom views) could remain 68000 code, and could be ported selectively as needed.

This also meant that plug-ins written for a 68000 application could be loaded and launched by a PowerPC application. All it had to do was, instead of calling the plug-in’s main function directly (which would crash, because it contained 68000 instructions, not PowerPC instructions), it would call the CallUniversalProc function.

The CallUniversalProc function would look at the start of the function pointer given. PowerPC plug-ins effectively contained a UPP at the start. From the address of the function it jumped to, the Mixed Mode Manager could see that this was already PowerPC, and just jump over the UPP to where the PowerPC code lay, without having to load and run the 68000 emulator, which only got chosen if the function didn’t begin with a UPP.

Also, a 68000 application running in emulation on a PowerPC Mac was able to load a PowerPC plugin. It would simply try to execute the UPP, whose first bytes were the jump instruction telling the Mixed Mode Manager to switch back to PowerPC and run it directly.

Fat binaries – universal apps before universal apps

It was trivial to create an application where the same file ran both on old and new Macs: 68000 executables contained their code in ‘CODE’ resources in their resource fork. PowerPC applications had their code in the data fork of the application file, plus a ‘cfrg’ (“code fragment”) resource with some information about the code (e.g. an offset, so you could have other data in the data fork besides code, which especially games on 68000 liked to do). So a 68000 Mac would simply ignore the data fork and ‘cfrg’ resource, while an PowerMac would look for it, and only if it failed to find one start the emulator and run the 68000 code.

This meant that, in those days, compilers simply built a 68000 and a PowerPC version of the application, then copied the ‘CODE’ resources from the 68000 application into the PowerPC application. Presto! Fat binary for both architectures!

But that wasn’t all: It was also possible to create UPPs (and thus plug-ins) that were “fat”: They contained both PowerPC and 68000 code. Depending on what architecture you were running under, the Mixed Mode Manager would simply jump to the right offset in your plug-in resource, which contained both versions of your code.

Of course, all this mucking about with UPPs meant that you had to allocate/free memory for a UPP for each function you wanted to pass to a system API. And you had to keep that memory around as long as that system call needed it.

For plug-ins, this involved some additional management, as often plug-ins would be dynamically loaded and unloaded during the life of an application. For functions in your application, you usually just stashed the result of NewRoutineDescriptor in a global variable and never bothered calling DisposeRoutineDescriptor.

Why no UPPs for Intel?

So why didn’t Apple choose to do UPPs again for the Intel switch? Well, apart from political reasons (back then, many application vendors, not just Apple, dragged their feet porting their Mac applications to PowerPC, meaning Macs spent most of their cycles emulating old code instead of overtaking the competition), PowerPC and Intel differed in the way they stored numbers in memory.

The PowerPC CPU actually supported running both in big endian like the 68000 and little endian like Intel CPUs. This came in handy when switching from 68000, because the PowerPC CPU was simply told to run big endian, and both PowerPC and 68000 code now stored their data the same way.

But of course the Intel CPU didn’t have that switch. And since an emulator only knows about raw bytes, the PowerPC emulator (“Rosetta”) in Intel Macs could not transparently convert the stored bytes. So it was decided to not allow mixing of PowerPC or Intel code at all. There would only be a tiny bit of translation at the point when a PowerPC application called into the system.

If an application had plug-ins that might still be written in PowerPC code, it could not load them. You had to run a PowerPC version of the application to run your PowerPC plug-ins in, or the Intel version to run your Intel plug-ins (Of course, there were universal binaries that packaged those two versions up in the same file).

Though the QuickTime media playback library found a nice workaround for this during another switch, from 32-bit to 64-bit: It simply launches a separate, hidden background process that is 32 bit. That process can load any old legacy plug-ins, QuickTime running in a 64-bit application can pipe the data to be en-/decoded to that process, and that process sends it back when it’s done. This is not optimal, but can be surprisingly fast because it uses Unix shared memory and Mach messages.

Posted on 2013-03-31 at 10:19 2 Comments

This post is filed under Macintosh, Programming.

Common Cocoa Coding Patterns: NSError returns

Error reporting wasn’t something Cocoa did in much detail in the early days. There were nil return values instead of objects, or a BOOL that was YES on success.

C didn’t have exceptions, and by the time ObjC got “fake” exceptions based on the longjmp() mechanism, all wrapped up nicely in NSException and NS_DURING/NS_HANDLER/NS_ENDHANDLER macros, most of the framework API had already been written and it would have been too much work to make all of it work with exceptions and adapt all applications to watch for exceptions in error situations. So they were reserved mostly for Distributed Objects (where an additional error return wasn’t possible) and programming errors.

But with the release of Safari and WebKit in 2003, someone at Apple realized they needed more detailed and standardized error information, and introduced the NSError class. NSError is a simple container object for any error code you might encounter on your Apple device, plus a dictionary for any other info like an error message.

Error codes are not unique across all the libraries, frameworks and system services that are on your device, so each error code is also identified by its domain, an arbitrary string constant. For example, Mac OS X offers the NSCocoaErrorDomain, NSOSStatusErrorDomain, NSPOSIXErrorDomain and NSMachErrorDomain error domains, which let you wrap Cocoa framework error codes, Carbon/CoreServices error codes, standard Unix error codes and kernel errors unambiguously, all by wrapping them in an NSError. And you can make up your own for your application, library, and even for a single class. Whatever logical unit of encapsulation makes the most sense.

Most NSErrors are returned as a return parameter. This has the advantage that methods that already have a return value can still be implemented as they were before the arrival of NSError, and can return nil to have an entire chained expression collapse. E.g., a fictional

NSError    theErr = nil;
ULIObject  obj = [[[ULIObject allocGivingError: &theErr] initGivingError: &theErr] autoreleaseGivingError: &theErr];

can fail at any of the three calls and return nil, and none of the subsequent messages will be sent, nor will they touch theErr.

However, one thing Apple tells us is that we shouldn’t look at theErr above unless obj is nil. Why is that? Well, imagine a possible implementation of our fictional autoreleaseGivingError::

-(id) autoreleaseGivingError: (NSError**)outError
{
    ULIAutoreleasePool* currentPool = [ULIAutoreleasePool _currentPoolGivingError: outError];
    if( currentPool == nil )
        currentPool = [NSAutoreleasePool _createBottomPool];
    if( currentPool == nil )    // Still couldn't create?
    {
        // Hand on whatever error _currentPoolGivingError: had.
        return nil;
    }
    
    [currentPool addObject: self];
    return self;
}

Our fictional internal _currentPoolGivingError: method here might return nil and give us an NSError when there is no pool in place yet.

But in the most common case, we will be able to recover from this error by creating the pool ¹.

So in most cases, we’ll just create the pool and add the object to it. If callers look at theErr in such a situation, they will see the error object put there by _currentPoolGivingError:, from which we recovered. So they will see an error where none occurred.

And that, kids, is why you always check the return value, and not just the error parameter.

¹) This is nonsense in real life, because nobody would ever release this bottom pool and we’d have a quiet leak, but let’s just assume in our example’s world ULIRunLoop will release this bottom pool once it regains control, as part of a lazy-allocation-of-pools scheme.

Posted on 2013-03-24 at 14:19 Leave a Comment

This post is filed under Common Cocoa Coding Patterns, iOS, Macintosh, Objective-C, Programming.

View-based NSTableViews: Row 1 should be in the valid visible section

With Mac OS X 10.7 “Lion”, Apple added a second “content mode” to NSTableView: View-based table views. This allows you to simply create your list items as separate views that get reused and reshuffled to simulate scrolling, instead of using the classic approach of “rubber stamping” a more lightweight NSCell repeatedly into the window. If you’ve programmed for iOS before, this is essentially like UITableView works, just for the Mac.

While this works fairly well most of the time, as of this writing it has one severe bug: Occasionally, a view-based NSTableView‘s view hierarchy gets corrupted in some odd way, causing it to hit an assertion and throw an exception. The main message you see in that case is:

Row 1 should be in the valid visible section.

I don’t know what exactly happens, but it happens if you call -reloadData on your table view too early. Now “too early” may sound a little weird, as cell-based NSTableViews work just fine, but for example the view-based content mode doesn’t like getting a -reloadData from the -awakeFromNib method of the controller that loaded it with its NIB/XIB file.

Doing this early on makes sure that your table view breaks, even if it still seems fine afterwards as long as it is empty. As soon as you add items, however, it croaks. Also, sometimes you don’t need to call the method directly. Just get someone else to call it for you, e.g. by setting the automaticallyPreparesContent property on an NSArrayController.

Thanks to:
brettper, who filed a reproducible case in Apple’s bugreporter and posted it on OpenRadar.
Jacob Gorban, who made the connection to the NSArrayController issue.

Posted on 2012-03-14 at 09:11 3 Comments

This post is filed under Macintosh, Objective-C, Programming.

A proposal: Categories for C++

Categories?

One of the most useful features I’ve used in object-oriented programming languages is the “category”. A category is a way of adding methods to a class dynamically. Take, for example Objective C’s “NSAttributedString” class. As defined in the Foundation framework, it is simply a string where you can attach key-value pairs to a range of it.

Only a category in the GUI framework AppKit actually defines the methods and constants that define what key to use for “bold”, and let you draw such a string to the screen. Yet in everyday use with AppKit, these two disparate parts feel like one homogeneous part. And, more importantly, anyone who wants to write a text-processing command line tool can use NSAttributedString without having to drag in all that unneeded drawing code.

How C++ objects work

But C++ does not have this feature. So let’s come up with an implementation of this concept that a compiler vendor could implement, and that stays true to the core of C++, mainly it’s compile-time determination of as much as possible. But of course we want to be able to add a category to a system class or a class in another module, and want to define virtual methods in a category, and override them in a category on a subclass. So, of course we want to end up at something that looks like this in C++:

category BarSupport : MyObject // extend class MyObject with some methods.
{
    void doBar( MyObject baz );
};

and can be called just like any other method on MyObject, e.g.

MyObject foo, dodo;
foo.doBar( dodo );

If we didn’t have to support virtual methods, things would be trivial. A non-virtual method call like

MyObject foo;
foo.doBar(baz);

compiles to something like

MyObject_doBar( foo, baz );

Where the this pointer is simply passed in as the first parameter before the first parameter you defined. So all we’d have to do is tell the parser about these new methods, compile the functions that implement them, and call them.

But virtual methods work differently. First, there is a virtual function table, something like this:

struct MyObjectVTable
{
    void (*doFoo)( struct MyObject* this ); // defined by user as doFoo(void).
};

And whenever you define a new class, what it actually does is add a hidden instance variable at the start:

struct MyObject
{
    struct MyObjectVTable *vtable;
    int                   firstInstanceVariable;
};

And it declares a global variable containing the vtable once, for all objects created with this class, and stashes it in each new object’s vtable instance variable:

struct MyObjectVTable gMyObjectSharedVTable = { MyObject_doFoo };

...

// Equivalent code to MyObject* foo = new MyObject :
struct MyObject* foo = malloc(sizeof(struct MyObject));
foo->vtable = &gMyObjectSharedVTable;
MyObject_Constructor( foo );

Here, MyObject_doFoo() is a function just like our

MyObject_doBar()

above. But when a virtual method is called, it is done slightly differently:

foo.vtable->doFoo( &foo );

This means that a subclass that wants to override doFoo() can provide its own gMySubclassSharedVTable that is also a struct MyObjectVTable, but contains a pointer to MySubclass_doFoo instead, and thus overrides the behaviour of doFoo() for all MySubclass objects. And if it wants to define additional virtual methods in its subclass, it can simply declare a struct MySubclassVTable that starts with the same fields in the same order as struct MyObjectVTable, and contains the additional methods after that. That way, anyone who expects an object for the base class doesn’t even have an inkling that there is more stuff after the methods it knows.

Applying that to Categories

Our categories also want to add methods, but the problem is we can’t just add new fields to the struct. The system classes like std::string have already been compiled, and we can’t just change their code to add these ivars. But what we can do is declare a parallel class hierarchy for our categories. So, first we declare a struct for our category:

struct MyObject_BarSupportVTable
{
    void (*doBar)( struct MyObject* this, struct MyObject* baz );
};

Then we extend the vtable to list categories:

struct CategoryEntry
{
    MyObject_BarSupportVTable* catVTable; // Simplified, each category's vtable is really a different struct.
};

struct MyObjectVTable
{
    struct CategoryEntry *cattable;
    void (*doFoo)( struct MyObject* this ); // defined by user as doFoo(void).
};

When a class is first built, the cattable array is empty, but as soon as someone declares a category, it gets added to that list. We just add some initialization code at the start of main() that mallocs the list. But how do we look up the vtable for a category? We could store its name, but then we’d have to loop over this list on each call and compare category names until we find it. How can we make that more efficient?

Simple: When we add the category to the class, we remember the index into the array where we added this category in the list, cache it in a global variable int gMyObject_BarSupport_Index; and then we can call a virtual method in a category like:

foo.vtable->cattable[gMyObject_BarSupport_Index].catVTable->doBar( &foo, baz );

Again, a subclass-category that overrides this method can just provide its own doBar method in the struct MyObject_BarSupportVTable.

The cost of categories

Of course this means that, just like with C++ virtual methods, and a bit more so, you pay a price for calling a virtual method in a category. You also pay with a little bit of overhead at startup, when the categories are added to the base class vtable. And just like with C++ virtual methods, to override a category method in a subclass, you have to know that the category exists on the base class. And if your program uses threads and you load a dynamic library that contains a category on a system class, bad things could happen while the category lists change under your running code’s rear.

Another gotcha with this approach is that the category list has to be built from the base class to the subclasses, because once a subclass locks down an index in the table for its first category vtable, you can’t add another category to the base class (it would have the index of the subclass’s category). But even that can be fixed:

We can just give every subclass its own categories table. So it only deals with the base class table when it wants to call a method inherited from the base class. E.g.:

struct MySubclassVTable
{
    struct CategoryEntry *cattable;
    void (*doFoo)( struct MyObject* this ); // defined by user as doFoo(void).
    struct CategoryEntry2 *cattable2;
    void (*doBar)( struct MyObject* this, struct MyObject baz ); // defined by user as doBar( MyObject baz ).
};

And now, calling a method in a category specific to the subclass simply goes through the cattable2.

Thoughts, suggestions, additional runtime geekery?

Posted on 2012-03-10 at 09:37 6 Comments

This post is filed under C++, Language Design, Programming.

Building a custom NSButton

In the previous article, I illustrated how one can theme NSTableView. Another control that commonly needs to be customized in themed Mac applications is NSButton. Since NSButton is a cell-based NSControl subclass, we don’t actually need to subclass it. Rather, we need to subclass NSButtonCell.

If you are using a XIB file, you can then just select the NSButton‘s NSButtonCell by clicking the button a couple of times, or by uncollapsing the button in the outline view and selecting the cell there, and setting its class to the name of our subclass.

In most cases, it is sufficient to override - (void)drawBezelWithFrame:(NSRect)frame inView:(NSView*)controlView and draw your custom button body there. NSButtonCell will take care of drawing the title, image etc.

The biggest difficulty in that case is to find out when and how to highlight your button. There are two ways a button can be highlighted, which are most obvious in a checkbox button: The actual highlight when a button is pressed is indicated by the -(BOOL) isHighlighted property.

In addition to that, a checkbox can be selected or unselected, which is indicated by its -(NSInteger) state property being set to NSOnState, NSOffState or NSMixedState. However, while every button toggles its state when clicked, not all buttons draw differently when their state is not NSOffState To find out whether you should look at the button’s state, query the -(NSInteger) showsStateBy bit mask to check whether the NSChangeGrayCell bit is set. Your button is only supposed to reflect its state if this bit is set.

If your button shape and position differs from the standard size and shape, you will also want to override - (NSUInteger)hitTestForEvent:(NSEvent *)event inRect:(NSRect)cellFrame ofView:(NSView *)controlView to return NSCellHitContentArea | NSCellHitTrackableArea so the user doesn’t click beside your button or on its shadow to drag the window and accidentally triggers its action, or worse, click on the button to have nothing happen because the standard system button doesn’t extend as far as your custom drawing.

Usually that is all you need. You will get a custom look, but the system will provide all the correct tracking behaviour and implement accessibility actions etc. for you, swap out the title and image for the alternate title and image as needed etc.

However, sometimes you need to also adjust the title text color, e.g. because you are implementing a dark button, or because you want to reflect the button’s selected state through its text color being different from the highlighted variant. To do that, you override - (NSRect)drawTitle:(NSAttributedString*)title withFrame:(NSRect)frame inView:(NSView*)controlView. Note that the frame that is passed to this is usually already correct. Just draw your text at the origin of this rect in the font set on the cell, and you should be fine. And return the actual rectangle in which your drawing ended up.

If the standard button text positioning or image positioning doesn’t match your button’s design, there are - (NSRect)titleRectForBounds:(NSRect)theRect and - (NSRect)imageRectForBounds:(NSRect)theRect for you to override.

Finally, if you plan to create your buttons in code instead of thawing them from a XIB file, you will also have to create a subclass of NSButton and call +(void) setCellClass: (Class)inClass in its +(void) load method to tell it what cell class to instantiate.

Posted on 2011-12-11 at 12:04 Leave a Comment

This post is filed under Macintosh, Objective-C, Programming.

Creativity Finds a Way

Uli's xDraw XCMD screenshot

Great observations

There is currently a nice little discussion on HyperCard going on in the comments on Stanislav Datskovskiy’s article Why HyperCard had to Die:

The article looks at the right facts, but I think draws the wrong conclusions: Yes, HyperCard was an echo of an era where a computer was a complex machine, and its owners were tinkerers who needed to customize it before it became useful. Yes, when Steve Jobs came back, he killed a lot of projects. And the Steve Jobs biography mentions that he doesn’t like other people screwing around with his designs.

But I do not think this automatically leads to the conclusion that Apple is on a grand crusade to remove the users’ control over their computers. Nor does it mean what many of the commenters say, that Apple is trying to dumb down programs and that programmers are underestimating their users.

How people work

Every programmer knows how important a coherent whole is: If a button appears in the wrong context, it will easily (and unintentionally) trick the user into thinking it does the opposite of what it really does. You can add paragraphs over paragraphs of text telling your users the opposite and they will not read it.

This is not because users are stupid, but because users “scan”. Screens are complex, and full of data. For the user to find something without spending hours of their life on it, they tend to quickly slide their eyes across the page, looking for words that come from the same category as the thing they are trying to do next.

This is a human efficiency optimization. It is a good thing. If we didn’t have this mechanism, we’d probably all be autistic, and incapable of coping with the world. Once a word is found, the user starts reading a little bit around it to verify the impression that this is what they want, and then they click the button.

It seems trivial to engineer a program for that, but it’s easy to overlook that a computer is not a single application at a time. There are other things happening on the screen, there may be other windows open. There may be system alerts popping up. Even if they are marked with each application’s icon or name, chances are that most users are too busy getting actual work done to memorize application names and icons. They won’t be able to distinguish what is your application, what is another.

Similar with haxies. Any halfway successful programmer probably has a story of how they tried to track down a crash or oddity a user encountered in their program that was actually caused by a plug-in or haxie that injects itself into every application to modify some behaviour system-wide. And once they are installed, even I occasionally forgot I had them installed. Or didn’t expect it to have an effect; Why should a tool that watches when my cursor hits the edge of my screen and then remote-controls the cursor on another computer as if it was an attached screen cause the menu bar to just randomly not show up when switching between applications?

Software is complex. Designing reliable, usable software is complex. In a comment, Stanislav had a great analogy for this (in response to someone’s pipe dream that one would just have to use HTML, and the technical stuff was all already done, you just had to add the human touch):

All the pieces of the world’s greatest statue are sitting inside a granite mountain. Somebody just has to come and chip away all the extra granite, adding the human touch. The technical problems are all virtually solved!

Software is hard. I don’t say this because it makes me sound cooler when I say I’m a programmer, but because you’re not just building a thing. You are building behaviours. HyperCard was notorious for being the tool for the creation of a number of the ugliest, least Mac-like programs ever released on the Mac. Because even with the best camera, your movie is only as good as the camera man.

So was Steve Jobs happy to get rid of HyperCard and stop people from screwing with his design? Probably. Was he forced to let it linger instead of killing it outright because he didn’t want to lose the educational market? I can’t disprove it. But Steve Jobs was also known to be an idealist. He genuinely thought his work would improve the world. What would he gain by making everyone dumb and uncreative?

Why assume malice when Occam’s Razor is a much better explanation?

You can’t hold a good idea down

When the Mac was originally released, it was intended as a machine for everyone. To bring computers to the masses. Almost from day one, the goal of Apple Computer, Inc. has been to drop the darned “Computer” from their name. Compared to the mainframes of the time, the Apple ][ that started the home computing revolution already was a “dumbing down” of computers.

Was this the end of the world? Should we have stayed in the trees? Will people become un-creative? Look around on the net. There are people out there who have no programming skills, who dig around in the games they bought and modify them, create their own levels, use existing game engines to create a game about their favorite book or TV show. Heck, there are people out there who create a 3D game engine in Excel.

If there is one thing we can learn, it is that Creativity Finds a Way.

HyperCard was designed in the late 1980s, for hardware of the time, for what very smart people thought would be the future at the time. Being creative with a computer, at the time, meant writing code. So they gave us a better programming language. Ways to click on a “Link to…” button to create the code to change pages. Not unlike Henry Ford’s competitors would have built you a better horse, but not a car.

Yes, I am saying that the developers of HyperCard didn’t quite anticipate the future correctly. They didn’t anticipate the internet, for example. That’s not a shame. It was ’87 back then. I didn’t get what the internet would be good for in ’91. I probably wouldn’t even have managed to invent a better horse. But anyway, all I am saying is that HyperCard’s creators didn’t know some things we know now, and probably made some compromises that wouldn’t make sense now.

The world has changed: This is 2011! All our programs do so much more. You can create 3D graphs in Excel, colorful drawings and animations in Keynote, and upload it all to the web with Sandvox. So many tools are available for such low prices. Why would you bother with a low-level, rudimentary tool like HyperCard when all you want to do is a movie with some branching?

A new tool for a new world

After all that, it might surprise you that I still agree with everyone in the comments who says that we need a new HyperCard for the 2010s. However, I do not agree that any of the examples the commenters mentioned (or even HyperCard as it shipped) are this program. Yes, Xcode and the NeXT-descended dev tools, and VB and others use the Rapid Application Development drag-and-drop manipulation to lay out your UI. But guess what? So does Pages.

Yes, you can use Ruby and Python and Smalltalk to branch between different choices. Or you could just use links to move between web pages built using Sandvox.

Yes, you can build real, runnable applications from your work with Java or AppleScript. But why would anyone want to build an application? Movies can be uploaded to YouTube, web sites can be built with WordPress, and I don’t have to transfer huge files to users. I just send my friends the link, and they know what to do. There’s no installer.

Our computing world has become so much richer, so much easier, that it is more efficient and actually smarter to just create your stuff with those tools that we old HyperCarders see as dumb. They can stand on the shoulders of giants, and spend their time creating the best possible gameplay instead of coding yet another 3D renderer. That is why HyperCard 2.4 just won’t cut it, or as David Stevens commented on that very same article:

most people get on a train to go somewhere, not because they really want to lay track, which explains the shortage of track laying machines in yard sales, and the demise of HyperCard.

The new HyperCard won’t be like HyperCard. Maybe the web is enough. Maybe it will just be a good “web editor”, like it used to be included in every copy of Netscape back in the day.

Or maybe, it will just be a niche product aimed at people who find that they want to do more than their tools let them do. This will not be the typical movie-maker, podcaster or writer. Like the directors, radio hosts or journalists in the generations before them, those will specialize. They will be exceptional at directing, making a show or researching the truth. But they will not care how the camera transports the film, they won’t care how their voice is really broadcast as radio waves and re-assembled in the receiver, nor how to build a printing press.

The people a new HyperCard is aimed at will be a person like you, who saw HyperCard, and at some point stood up and said: This is not enough. I want to create more. And then maybe went out and bought CompileIt!, which let her use the system APIs from the comfort of her HyperCard stack, only needing to use the scary memory management stuff when absolutely necessary. And then went and bought MPW, or THINK C, or CodeWarrior, or Xcode.

A real programmer doesn’t program because she wants to use HyperCard. A real programmer programs because she wants to. Because she just has to. A real programmer doesn’t limit herself to that one language and IDE she learned once so she never has to learn anything else. A real programmer learns new programming languages because each language teaches her a new way of looking at or solving a problem. A real programmer has been programming since she opened PowerPoint for the first time. She will find a way.

It’s been like that back in the days of HyperCard. Why shouldn’t it be like that again?

Posted on 2011-12-02 at 09:45 Leave a Comment

This post is filed under Language Design, Macintosh, Programming, Usability.

Themeing NSTableView

Themed tstableview While most Mac applications rely on the standard controls provided by MacOS X to do their work, most application developers like to follow Apple’s lead and apply their own textures, colors and fonts. And why not? Screens today have a much higher resolution and aren’t limited to basic B/W shapes. Tinting or texturing a user interface — when done with restraint and taste — helps the user find your application’s windows on multiple-window desktops more easily, and can increase recognizability of your application for other purposes.

But how does one correctly theme user interface controls with minimal interference to Apple-provided default behaviour? After all, we want our application to still look and, more importantly, behave in recognizable and familiar ways to the user. We just want it to look like a different material, or match the application’s logo and packaging better.

Let’s start with a table view. While an NSCollectionView can be easily themed by modifying various views’ color settings in Interface Builder, the best you can do for an NSTableView or its subclass NSOutlineView is set one single solid background color.

We need to write code, then. There is enough documentation for the old NSCell-based table views out there that describe how to override - (void)drawRow:(NSInteger)row clipRect:(NSRect)clipRect to theme those. So I’ll restrict myself to themeing the view-based table view variant. Most of the cells can easily be edited, but what if you want custom alternating row colors?

Luckily, NSTableRowView has a backgroundColor property that you can change. So all you need to do is make sure that you provide a - (void)tableView:(NSTableView *)tableView didAddRowView:(NSTableRowView *)rowView forRow:(NSInteger)row method in your delegate that uses the % operator to grab the corresponding color from an array of alternating row colors and sets the appropriate one as each rowView’s backgroundColor.

However, this only fixes the cells. The area below the rows, or an empty table, will still have whatever standard alternating row colors the system uses. You will have to subclass NSTableView and override - (void)drawBackgroundInClipRect:(NSRect)clipRect to fill the area below the rows.

Call -rowViewAtRow:(NSInteger)row makeIfNecessary: YES to get the last row’s NSMaxY(), if it is inside the bounds, draw alternating rectangles with a height of -(CGFloat) rowHeight underneath it until the row rect is fully out of view (start their row number at -(NSInteger) numberOfRows).

It is unfortunate that there seems to be no public equivalent to tableView:didAddRowView:forRow: in NSTableView itself. That way, one could create one subclass that takes care of the whole appearance consistently, instead having to add code for that to each delegate.

Posted on 2011-11-19 at 00:11 1 Comment

This post is filed under Macintosh, Objective-C, Programming.