Luminary

Running Unit Tests from the CLI via Xcode 4

First make your test target depend on the actual app, then do this:

$ xcodebuild build -target $TARGET_NAME -configuration $BUILD_CONFIGURATION -sdk iphonesimulator SYMROOT="$TEMP_DIR"

It’ll then build and run like a normal build operation. I have not yet looked into any way to configure Test Document Data / Test Location via the CLI without resorting to scripting yet.

Undocumented way to pass the buck

If you have xcconfig files, using $(inherited) in build configurations helps a lot. It means “also use anything the previous level has defined”.

• Where can (inherited) be used?
• XCode, oh how you hurt me

Using Omni frameworks in Xcode 4, redux

Xcode 4 has an awesome feature called implicit dependency finding (in the Edit Schemes sheet). That wreaks havoc, but only at some time.

To allow Omni frameworks — namely, faux iOS frameworks — to build reliably and correctly, add the uninstalled products directory to the user header search paths of your build target (not the project), and tell Xcode to always search for user headers.

Also, make sure Xcode is using a shared build directory, so it looks for built stuff in that directory. That’s enabled thru Preferences > Locations > Derived Data. It’s recommended that you set it to something along the line of /Users/Shared/evadne/Products where you use your OS X user short name. In Advanced tell Xcode to use Locations Specified by Targets.

Here’s one:

$(CONFIGURATION_BUILD_DIR)/../UninstalledProducts/include/**
$(CONFIGURATION_TEMP_DIR)/../../UninstalledProducts/include/**
$(inherited)

Remember to edit your active scheme, and add all the static libraries you’re using as target dependencies that get built before your main target. For example, if you’re using the Omni frameworks, put libraries like OmniAppKitTouch before your app, even if your app target already (implicitly) contains them.

If you run into any problem, turn Parallelize Build off. If you still can’t build, rm -rvf the entire shared Products directory.

Frameworks are Teh Suck, Err.

Using Omni Frameworks in an iOS app

Mostly the problem with framework ordering. Since Omni code assume existence of frameworks, you need to shovel all the headers into the derived data directory — which is recommended by Omni to be something along the line of /Users/Shared/somebody/Products. This way #import <OmniBase/OmniBase.h> would succeed. Inter-framework dependencies, however, is ugly on iOS without native frameworks support, and you must ensure things are built in the right order (since building them copies the headers into the derived data directory).

This is the order I use in stuff that uses Omni’s code:

• OmniBase
• OmniQuartz
• OmniAppKit
• OmniFileStore
• OmniUnZip
• OmniUI

Additionally, if you are creating a static library relying upon Omni Frameworks, but you intend to use it in another application, make sure the library weak-links against Omni code, so you can use the binaries in your app and avoid dependency encapsulation hell, where an important portion of your dependencies is encapsulated within one dependency you use.

Continuous smooth scrolling using UIScrollView

I was so dumb not to realize this earlier.

[UIView animateWithDuration:0.3f delay:0 options:(

    UIViewAnimationOptionAllowUserInteraction | 
    UIViewAnimationOptionBeginFromCurrentState | 
    UIViewAnimationOptionCurveEaseInOut

) animations: ^ {

    [self.scrollView scrollRectToVisible:visibilityEnsuredRect animated:NO];

} completion:nil];