A Tasty Pixel » Interface

Compiling Image Resources into a Static Library

I’ve recently been working on a static library for distribution to other developers — [Audiobus](http://audiob.us) — and I need to include a couple of graphical resources with the distribution. The usual solution to this is to include the resources separately in a bundle, and require the user to drop them in to their project along with the static library.

I thought I’d see if I could make the process just a little neater, and successfully devised a way to compile the images straight into the library, so the distribution remains nice and clean — just the library itself and a few header files.

Now, I can pop image resources into a folder, and after compiling, access them within the static library with:

UIImage *image = TPGetCompiledImage(@"Button.png");

It automatically handles “@2x” Retina images (although it doesn’t currently do “~ipad” versions).

Here’s how it’s done.

The magic is in a shell script which uses the xxd hex dump tool to create C code that represents the image data as a byte array, then creates around it a set of utilities to turn those arrays into UIImages on demand.

Along with it is a couple of template files — a header and implementation file — that describe the format of the derived code.

Finally, a little tweaking of the project in Xcode (with a brief foray into a text editor to work around some Xcode shortcomings) puts it all together.

Seamlessly manage portrait and landscape view controller layouts

A headache-inducing scenario: I’m working on a view controller, and I realise that in order to support landscape and portrait modes, I’m going to need to provide two different layouts.

So, I create two different views within the nib, one portrait, one landscape, each with the same view hierarchy, but with a different layout.

When the orientation changes, I set self.view to the appropriate view. I initialise both views on load, and keep both of them synced to properly reflect the app’s state — basically, I’m double-handling everything, which bloats my code and increases the chance I’ll make a mistake.

So, here’s an easier way: Rather than maintaining two separate view hierarchies and switching between them when the orientation changes, why not just change the layout of one single view hierarchy? The only changes between the portrait and landscape views are layout changes, so if we can extract just the layout information from each view, then we don’t have to worry about maintaining both view hierarchies.

Basically, we’re talking about using each view version as a layout template only.

That’s what [TPMultiLayoutViewController](https://github.com/michaeltyson/TPMultiLayoutViewController) class does. It’s a drop-in UIViewController subclass that automatically manages switching between different view layouts for portrait and landscape orientations, without the need to maintain view state across two different view hierarchies.

It works by defining portraitView and landscapeView outlets which it traverses upon loading the nib. It matches each subview element to its counterpart in the other layout (based on tag, target/action, title, etc.), and stores just the layout attributes of each element.

Then, when the orientation changes, the view hierarchy is traversed and these layouts are applied to each subview.

To use it,

Set the superclass for your view controller to TPMultiLayoutViewController.
In Interface Builder, create two different views: one for portrait orientation, and one for landscape orientation.
Attach your portrait orientation root view to the “portraitView” outlet, and the landscape orientation root view to the “landscapeView” outlet.
Attach one of the views (whichever you prefer) to the “view” outlet, and connect any actions and outlets from that view.

Grab it from the [TPMultiLayoutViewController GitHub repository](https://github.com/michaeltyson/TPMultiLayoutViewController), and let me know what you think.

A drop-in universal solution for moving text fields out of the way of the keyboard

There are a hundred and one proposed solutions out there for how to move UITextField and UITextView out of the way of the keyboard during editing — usually, it comes down to observing UIKeyboardWillShowNotification and UIKeyboardWillHideNotification, or implementing UITextFieldDelegate delegate methods, and adjusting the frame of the superview, or using UITableView‘s scrollToRowAtIndexPath:atScrollPosition:animated:, but all the proposed solutions I’ve found tend to be quite DIY, and have to be implemented for each view controller that needs it.

I thought I’d put together a relatively universal, drop-in solution: UIScrollView and UITableView subclasses that handle everything.

When the keyboard is about to appear, the subclass will find the subview that’s about to be edited, and adjust its frame and content offset to make sure that view is visible, with an animation to match the keyboard pop-up. When the keyboard disappears, it restores its prior size.

It should work with basically any setup, either a UITableView-based interface, or one consisting of views placed manually.

Coming soon: Bulk downloading of offline maps

Here’s something I’ve just finished working on, ready for release very soon: Offline map downloading.

You can grab [The Cartographer on the iPhone App Store](http://itunes.apple.com/app/the-cartographer/id393312081?mt=8) — version 1.1 will be available shortly, and is a free update. When we release version 1.1, we’ll be ending our introductory 50% off sale, so grab a copy soon before the price goes up!

A trick for capturing all touch input for the duration of a touch

If you’ve ever tried to implement an interactive control that makes use of gestures within a UITableView, or tried to implement a view that you can drag around, like pins on a MKMapView, you’ll know that you’re either generally thwarted by the scroll view (and the table view will just scroll, instead of your control getting the vertical drag gesture), or as soon as the touch moves outside the bounds of your view, you’ll get no more touchesMoved events, making for a very frustrating dragging interaction.

Some platforms give you a way to capture all pointer input for a time, but this doesn’t appear to be available out of the box on the iPhone — at least, I haven’t found it.

Here’s a way to make it work:

Subclass UIWindow and replace sendEvent: with your own method
Provide a way for objects to be registered with your UIWindow subclass to gain ‘touch priority’ – either add a property that taken a UIView/UIResponder, or add a mutable array to be able to register multiple views.
When you receive a touch began event, check to see if the touch was within the bounds of any ‘priority’ views – if they are, the view subsequently gets all events until the touch ended event.