I was tinkering with our build system at work, and I realized that builds were failing on r5b and below. After a bit of debugging (and reading the NDK changelog), I realized that LOCAL_WHOLE_STATIC_LIBRARIES was broken in r5b and missing in r4 and before. To prevent other engineers from running into this, I wanted to make our project depend on r5c or above.

There doesn’t seem to be a facility in place to do this, so I created a shellscript you can invoke from your Makefile to assert that the right version of the NDK is present. You can find the shellscript as a gist on GitHub

EDIT: This script depends on the environment variable ANDROID_NDK_ROOT to point to the base of your NDK. The script has been updated to test that this is the case (thanks to David R. for pointing this out).

The only caveat is that it does not support asserting versions below r5 - this is because only r5 and above have a version identifier in the NDK tree. It will correctly identify r4 and below as not being good enough for your build, but you can’t say “I need r3 or above”.

Put the script into jni/assert_ndk_version.sh, and put the following at the top of your jni/Android.mk, and voilà! Builds should now fail with a more understandable message if someone’s using the wrong NDK version. :-)

1
2
3

ifneq ($(shell $(LOCAL_PATH)/assert_ndk_version.sh "r5c"),true)
  $(error NDK version r5c or greater required)
endif

With the launch of Lion, Apple added a new security feature to the operating system: The Application Sandbox. It encourages application authors to specify what subset of system functionality their app needs to function correctly, in order to reduce the impact of a malicious or compromised app. See the Mac OS X Developer Library or the ars technica Lion review for more info on this.

As a part of this, Apple added a set of entitlements labeled “temporary exceptions” (here’s a complete list), most likely to simplify and speed up adoption of this new technology. Your app can claim to need one of these “temporary” entitlements to do certain things that otherwise wouldn’t be allowed by the Sandbox. For GrabBox I need to have read-only access the users desktop – which falls under this category.

I’ve been spending some time today trying to figure out how to get the com.apple.security.temporary-exception.files.home-relative-path.read-only entitlement working. The documentation is sparse, and there’re no samples as far as I can tell. After many attempts, I finally figured out the key piece of information keeping me from getting this working: The path you specify in the entitlement needs to start with a slash. For example, instead of specifying Desktop, you specify /Desktop.

Here’s an example of a valid entitlement plist:

1
2
3
4
5
6
7
8
9
10
11
12
13

<pre><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>com.apple.security.app-sandbox</key>
        <true/>
        <key>com.apple.security.temporary-exception.files.home-relative-path.read-only</key>
        <array>
                <string>/Desktop</string>
                <string>/Dropbox</string>
        </array>
</dict>
</plist>

I assume this applies to the com.apple.security.temporary-exception.files.home-relative-path.read-write entitlement as well.

I hope this saves other people trying to get this working a little bit of time. :-)

Yesterday I needed to whip together a simple little app to “vet” photos - a tool to quickly let me go through each photo in a directory and choose between “thumbs up” or “boo”, then give me a list of the ones I said “boo” to.

Ideally, I’d write this app in Ruby, but I have had only bad experiences trying to get a useful, good GUI written in either Ruby or Python. Years ago I looked into GTK, QT and WxWidgets, but none of them convinced me they were capable. So I googled around for “simple GUI ruby”, and “Shoes” caught my eye. I tried it out, and it was indeed simple, but sadly too simple. It was hellbent on not letting me do anything complex, even when it’s “intuitive behavior” was wrong.

I’ve been writing Objective-C since last summer (GrabBox is written in it), so I gave up on my Ruby track and tried putting something together using Interface Builder and Cocoa. To my amazement, writing the whole app took me much less time than researching “simple” GUI frameworks for Ruby: ~1 hour from scratch to working app:

Is this really the state of GUI frameworks for Ruby and the likes (say, Python and Perl) - or have things improved significantly since I last looked at GTK, WxWidgets and QT? Is there nothing that can even remotely compete with Interface Builder and Cocoa? I’m by no means a fanboy, and I’d love to be able to do this as efficiently in Ruby or Python! Please post a comment if you have any tips or thoughts on this. :)

If you wonder what was wrong with Shoes: Things like the image class only letting you load data by providing a path or an URL, and having some caching behavior that rendered the app very slow after changing the ~4MB displayed image tens of times.