Planet Cocoa

The Talk Show With John Gruber

2012-05-25T18:40:45+00:00

For the past few years, John Gruber and Dan Benjamin recorded an informal, off-the-cuff-seeming podcast called The Talk Show. I didn’t listen to every episode, but I listened from the very beginning, before Dan had even founded the 5by5 network that later became its home.

I see The Talk Show’s format as the prototype for many other successful 5by5 podcasts: Dan plays the cool, somewhat disinterested straight-man to a “star,” whose own temperament, philosophies and interests ultimately define the show. After the initial success of The Talk Show, Dan threw the net wide, inviting folks such as Marco Arment, Andy Ihnatko, Merlin Mann, John Siracusa, Horace Dediu, and Jim Dalrymple to indulge audiences with their own personalities and areas of expertise. I even had the pleasure of playing the star myself on one episode of Build & Analyze.

Last week, John announced matter-of-factly that The Talk Show would no longer air on the 5by5 network, and would be joining the lineup at the fledgling Mule Radio Syndicate. Dan does a great job at 5by5 of emphasizing that the star of each show is who makes the show what it is. Nonetheless, Dan’s personality is unavoidably material to the mood and progression of these shows, so it’s safe to say that The Talk Show’s departure from 5by5 marks the end of an era.

The good news for fans of John Gruber, is it doesn’t mark the end of The Talk Show. John’s obsessive, meandering, sometimes distracted personality lives on at Mule, and I think this promises to be another great era in The Talk Show’s history. Episode 1 featured John Moltz of Crazy Apple Rumors fame, and the two delved into all the kinds of topics I’d expect. I thoroughly enjoyed the show.

I enjoyed it so much, I decided to co-sponsor this week’s episode, along with my good friends from Bare Bones Software:

The Talk Show Episode #2: Dare I Say, Kubrick?

Much to my delight, the episode turned out to feature one of my favorite “internet stars,” Mr. Adam Lisagor of Sandwich Video fame. John literally can’t go wrong if these folks are representative of the stature of future guests. So, give the new Talk Show a try, won’t you?

Carlos Garcia Campos is now a WebKit reviewer!

2012-05-23T10:48:29+00:00

We’re happy to announce that Carlos Garcia Campos is now a WebKit
reviewer. Carlos has most recently been the fearless leader of
Igalia’s efforts to release a stable version of WebKit2 for GTK+. You
may also remember his work porting much of the GTK+ platform layer to
GTK+ 3.x.

Congratulations Carlos!

Last week in WebKit: Input padding, 8-bit canvas and CSS Variables

2012-05-22T19:07:04+00:00

This update addresses last week’s 820 changes to WebKit’s repository, up to revision 117727.

The debugger sidebar for Web Inspector’s Script Panel can now be toggled using a button. Console messages about Content Security Policy violations now name the directive and support for saving snippets has been implemented.

Using the latest CSS Flexible Box module now requires you to define an element’s display property as “-webkit-flex” as opposed to the previous “-webkit-flexbox”. Input elements are now two pixels smaller in width, as one pixel of unnecessary padding has been removed from either side.

Image smoothing for the <canvas> element may now be disabled. Loading video files served through scripts without a supplied mime-type will now work, and two issues with CSS 2.1 support have been fixed, namely text baselines in the first row of a table and wrapping stand-alone table columns in anonymous tables.

A compile-time flag has been introduced for toggling support for CSS Variables in WebKit ports. Furthermore, an initial test-suite to test the status of the implementation has landed as well.

Other changes which occurred last week:

Cloning DOM nodes has become ~10% faster, as WebKit no longer reparses the style attribute.
Chromium has enabled support for <datalist> for e-mail input fields.
The Qt port enabled support for SVG Fonts, while the EFL port is working on Web Intent support.
Both the BlackBerry as the EFL ports have enabled support for the Full Screen API.
No warning will be shown in the console anymore for sites using layerX/layerY.
Levi Weintraub now is a WebKit Reviewer, congratulations!

Announcing Skyscraper

2012-05-21T20:37:25+00:00

I’m happy to announce that I’ve acquired Pandora from Positive Spin Media, and renamed it Skyscraper in order to reduce confusion with the music service. Skyscraper is a web scraper specializing in finding and downloading images. It can take advantage of Google Image Search to do keyword searches or simply scrape images (or other kinds of files) from a URL that you give to it. It automatically downloads the images into folders and allows you to perform some simple management. It also has a built-in slide show.

Skyscraper has a free limited trial, so there’s no reason not to give it a try. Skyscraper is free for existing Pandora customers, otherwise $29.99 for new customers.

You can read more about the acquisition in the press release.

WWDC 2012 Preparation

2012-05-21T15:33:44+00:00

WWDC is one giant fire hose of knowledge. From Monday through Friday it's non-stop cool demo and amazing content. To get the most out of the sessions it's often helpful to go in with at least a passing familiarity with the content so your brain has some pre-processing done on the info and has some hooks to hang the new info on. To that end I offer a list of my favorite WWDC sessions from 2011. You can watch them on-line or download them to iTunes and sync them for watching on the flight in.

100 - What's New in Cocoa Touch
101 - What's new in Cocoa
102 - Implementing UIVC Containment
103 - Cocoa Autolayout
104 - Advanced Scroll View Techniques
111 - Visualizing Information Geographically with MapKit
116 - Storing Docs in iCloud Using iOS 5
117 - Performing Calendar Calculations
121 - Understanding UIKit Rendering
128 - Advanced Text Processing

203 - Introducing App Sandbox
204 - App Sandbox for the Mac App Store
206 - Introducing XPC
209 - Inside the accelerate Framework for IOS
210 - Mastering GCD

318 - iOS Performance in Depth
319 - Effective Debugging with Xcode 4
321 - Migrating from GDB to LLDB

401 - What's new in OpenCL
402 - Essential Game Technologies for iOS, Part 1
403 - Essential Game Technologies for iOS, Part 2
404 - Audio Dev for Games
405 - Exploring AVFoundation
408 - HTTP Live Streaming Update
414 - Advances in OpenGL ES for iOS 5
415 - Working with Media in AV Foundation
416 - Tools for Tuning OpenGL ES Apps on iOS
417 - Introducing AVFoundation Capture For Lion
418 - Best Practices for OpenGL ES on iOS
419 - Capture from Camera Using AVFoundation on iOS
422 - Using Core Image on iOS and Mac OS X

500 - What's new in Core Location
503 - Hidden Gems for Web Apps
504 - Building Newsstand Apps
507 - iBooks
509 - What New in CSS Effects and Animation
516 - Understanding Layout and Gestures

Of course since the content is going to be downloadable shortly after the show so the most important thing is not the sessions. Make sure to read Jeff's guide. He has a ton of practical advice on how to survive/thrive at WWDC.

MarsEdit 3.5.3: Mea Culpa

2012-05-19T21:46:20+00:00

MarsEdit 3.5.3 is now available as a direct download from the MarsEdit home page. A release in the Mac App Store is pending review (Update: now available). This is a free update for licensed MarsEdit customers.

MarsEdit 3.5.2 yesterday, 3.5.3 today. Shipping subsequent updates a day apart is almost never a sign that things went the way a developer expected. In this case, I discovered a bug in MarsEdit 3.5.2 (and 3.5.1, as it happens) that would cause the blog settings editing panel in MarsEdit to fill up all of a blog’s settings with default values when you opened it to tweak a blog. Then, if you innocently click “OK”, wham, all your blog settings are updated with default settings. Not good.

So the focus on MarsEdit 3.6 was instantly sidelined, and MarsEdit 3.5.3 was brought to existence in the space of about an hour today, taking this critical bug fix and a couple other less urgent fixes that didn’t make it in time for 3.5.2.

Fix a serious bug that reverted blog settings to default values when opening the settings panel
Avoid a crash when running on a 10.6 system with older versions of Safari installed
Fix a rich-mode editing paste bug that could cause unwanted
entries in HTML

I also submitted an expedited review request to the Mac App Store. Here’s hoping that will request in a shorter wait time for Mac App Store customers. Please note however that if you own the Mac App Store edition of any of my apps, you are also entitled to download and run the direct-sale versions from my site without limitation.

Friday Q&A 2012-05-18: A Tour of PLWeakCompatibility: Part I

2012-05-18T16:53:00+00:00

A few weeks ago, I introduced PLWeakCompatibility. This is a small library that can be dropped into an app to enable use of the __weak qualifier on OSes that don't support it. ARC is officially supported on Mac OS X 10.6 and iOS 4, but __weak is only available on 10.7 and iOS 5. PLWeakCompatibility adds support for __weak on those older OSes when using ARC. Today I'm going to discuss how PLWeakCompatibility works on the inside.
(Read More)

MarsEdit 3.5.2: Character Count

2012-05-18T13:34:48+00:00

MarsEdit 3.5.2 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed MarsEdit customers.

Mostly just another batch of bug fixes here, but I snuck in one small feature-tweak that should please writers in character-based languages and authors who aim for character-based writing goals rather than word-based.

If you weren’t aware of MarsEdit’s live-updated word count feature, it’s located in the “Status Bar”, which you can activate by selecting View -> Show Status Bar. Here is an example of how it looks when editing a post in MarsEdit 3.5.2:

Here’s the complete list of changes for this release:

MarsEdit 3.5.2

Status bar in post editor now includes character count along with word count
Restore ability to paste HTML with “embed” tags in the Rich Editor
Restore expected list manipulation behavior with tab and return keys
Fix a crash that occurred when editing a Tumblr quotation post with no attribution
Work around issue with WordPress pages showing up as empty posts if not permitted to edit
Fix autoconfiguration of IBM Lotus Connections blogs
Fix the scrolling behavior of custom fields text input

Onward to MarsEdit 3.6!

Levi Weintraub is a WebKit Reviewer

2012-05-18T04:06:23+00:00

Levi Weintraub has been with webkit.org a long time. He’s known for various projects including his bidi work and most recently our subpixel layout support. Please join me in congratulating our latest reviewer!

Testing Pagesmith Footnotes

2012-05-18T00:06:04+00:00

I have footnotes working in Pagesmith and polished enough that I can show it to other people. I need some help find bugs in the edge cases, so if you’d like to give footnotes a spin before everyone else, shoot me an email: andy at fortunatebear.

Quick VoodooPad 5 Postmortem

2012-05-17T22:32:08+00:00

I was pretty floored by the response to VoodooPad 5's release. I really didn't expect it to make much of a dent- but I was sent tons of positive feedback and sales were much better than I anticipated. The Mac App Store even featured it last week. So thanks to everyone who purchased it and sent in feedback!

Nobody complained about VoodooPad Lite not making the jump to version 5- so I think that was a good move on my part. And swapping out the old page event system with a new one based on JavaScript seems to be a hit. I keep on seeing interesting bits of code that people are writing in VP to automate things.

Another thing I wasn't expecting was the response to adding Markdown as a page type in VP5. Turns out tons and tons of people really wanted this- much more than I would have figured. I think I'll be spending more time in future releases making Markdown even better (5.0.2 has some improvements in this area, as I'm starting to get hooked onto Markdown myself).

I've also recently released VoodooPad 5.0.1 which fixed some pretty important bugs, and I'm currently finishing up 5.0.2. VoodooPad for iOS 2.0.1 was also released today- so if you've been running into any issues with Dropbox syncing, make sure to update.

For fun, here's a couple of recent reviews of VP5:

TUAW: VoodooPad 5: wiki magic
MacStories: Building Our MacStories Wiki with VoodooPad 5
TenOneHundred: VoodooPad 5 Review

Unit Testing with Core Data

2012-05-15T21:43:58+00:00

Whether you subscribe to Test Driven Development (TDD) or another testing practice, when it comes automated unit testing with Core Data, things can be a little tricky. But if you keep it simple, and take things step by step, you can get up and running with unit testing using Core Data fairly quickly. We’ll explore the what, how and why of unit testing with Core Data. We’ll also be using the helper library MagicalRecord. MagicalRecord not only lets us get up and running faster, but helps to cut down on the noise in our tests.

Testing Environment

When you set up a Core Data stack using a file based store (say, using the sqlite store), that file becomes tied to the data model. That is for good reason. Core Data needs to first verify several things before it can use that data store. It must verify the entities have all the attributes the data model expects, as well as to ensure all entities are present in the store. The data and the description of that data must match exactly. However, when you are developing an app using Core Data, this schema changes fast. Adding a new attribute, or even simply changing it’s type can alter the version hashes enough so that the file version and the model version don’t match.

All this is to say that using a file based datastore for unit testing is problematic. Even if you were to set up your file based Core Data model to be auto migrating, it’s still highly likely you’ll perform a refactoring that is simply not compatible with automigrations. Another likely scenario when testing is that you’ll want to create simple test data for a single test, or suite of tests, and then delete it.

While testing with a file based Core Data store is possible, it’s fairly tricky and error prone. Generally, when you setup your test cases, you’ll want to load your sample set of data. When you’re finished, you’ll then want to delete all that data. Unit tests should fail on an error with our application code, not our test infrastructure, setup or teardown code. And besides, I know you’ve already jumped to the same conclusion I have by now, and that’s to use an In-Memory persistent store. Not only are there no file deletions to deal with, you will never have to perform a migration. Since during unit testing, you want a temporary store, the in-memory store is a perfect setup.

Note: Using an in-memory store to perform tests against a Core Data store is not an entirely new concept. Graham Lee has also previously described his process and setup for testing Core Data with an in-memory store.

Quickly Setting up Tests

Now that we’ve gone over a little background, let’s get to how we can use MagicalRecord to easily setup our Core Data tests.

As we’ve discussed previously, MagicalRecord comes with a set of helpers to build a simple Core Data stack for you. We’ll use one that’s fairly straight forward:

[MagicalRecord setupCoreDataStackWithInMemoryStore];

We’ll also want to clean up the Core Data stack after some tests, and, yes, MagicalRecord provides a handy cleanup method for you:

[MagicalRecordHelpers cleanUp];

Let’s explore when and where to incorporate these method calls into your tests.

Testing Frameworks

Up to this point, the discussion hasn’t been geared toward any particular testing framework, although the syntax is common to the SenTestingKit testing framework that is now built in (and a first class citizen in Xcode4). However, there are now several testing frameworks now that provide many structural similarities, while improving on the syntax. Let’s see how things differ across a few of the more popular testing frameworks available for Objective C.

SenTest, OCUnit, GHUnit

SenTestingKit and GHUnit offer a very similar experience from a testing perspective. Primarily, you create a new subclass of SenTestCase, or GHTestCase, and author all your tests in methods starting with the word “test“. You can also run a method before all tests in the class are performed, or before each method.

Depending on how you set up your tests, you have two options on where to put the simple MagicalRecord setup method. If you want a pristine data store for every test (useful for isolating tests), then you’ll want to put this method in the setUp method like so:

- (void)setUp;
{
	[MagicalRecord setupCoreDataStackWithInMemoryStore];
}

However, there are certain cases where you’ll need to preload a larger test data set to test against. I would recommend doing this before each and every test as it will only slow your test runs down. And making tests slower can eventually lead to you not running them at all. I recommend setting this up once per test suite:

- (void)setUpClass;
{
	[MagicalRecord setupCoreDataStackWithInMemoryStore];
}

And to clean up your stack, simply add a call to the clean up method using the appropriate post-test method, tearDown, or tearDownClass.

Kiwi, Cedar

Kiwi and Cedar are the Behavior Driven Development (BDD) style frameworks. Rather than methods, you format your tests using blocks, however there are similar mechanics when runnings tests. That is, you also have ways to setup and teardown your test Core Data stack even if the methods aren’t called setup and teardown. However, with it’s block type syntax, you can have nested setup calls to beforeAll and beforeEach, afterAll and afterEach (the BDD versions of the setup and teardown methods). You will want to place your calls to set up your test core data stack at an appropriate level within your block contexts.

describe(@"MyEntity", ^{
 
  beforeEach(^{
	[MagicalRecord setupCoreDataStackWithInMemoryStore];
  });
 
  afterEach(^{
	[MagicalRecord cleanUp];
  });
 
  it(@"should do something awesome", ^{ /* Put your test here! */ });
 
});

As you can see, setting up and cleaning up after your tests is fairly easy with MagicalRecord.

Supporting Xcode’s Unit Test Support

When using a testing framework like GHUnit, the afore mentioned steps are all that’s required to get started. However, when it comes to using Xcode’s built in unit test bundle, there is one extra step required in order to get the stack setup.

When you first need to load up the Core Data stack, you typically use the method:

[NSManagedObjectModel mergedModelsFromBundle:nil];

This method, give the parameter of nil, will look in the main bundle, which is generally the application bundle, and look for all data model files, and merge those files into a single Core Data model instance for use when instantiating an NSPersistentStoreCoordinator and it’s related NSPersistentStore. However, with the Unit Test bundle, this call does not return the correct answer, as documented by Graham Lee. The solution to this problem is simple: we need to specify the correct bundle so that the Core Data stack initialization process can continue on it’s way. To do this with MagicalRecord, we use the following setUp method for our tests:

- (void)setUp;
{
	[MagicalRecord setDefaultModelFromClass:[self class]];
	[MagicalRecord setupCoreDataStackWithInMemoryStore];
}

The setDefaultModelFromClass: method will perform the solution provided by Graham Lee, which is to load the model from the specified class, which, in turn, is the class of the currently executing test case. And now that we have something more generic, we have the ability to create a very simple boilerplate Core Data unit test case:

//CoreDataTestCase.h
 
@interface CoreDataTestCase : SenTestCase
@end
 
//CoreDataTestCase.m
#import "CoreDataTestCase.h"
 
@implementation CoreDataTestCase
 
- (void)setUp;
{
	[MagicalRecord setDefaultModelWithClass:[self class]];
	[MagicalRecord setupCoreDataStackWithInMemoryStore];
}
 
- (void)tearDown;
{
	[MagicalRecord cleanUp];
}
 
@end

This means that when you begin authoring unit tests requiring Core Data, you can simply inherit from this base test case, and you’re ready to start writing tests.

A Test Case

First of all, it goes without saying that when you’re using Core Data, you create a set of custom entity classes, which are subclasses of NSManagedObject. And, to make your life easier, you should always use mogenerator to create your custom entities. This is where your custom logic will live. Let’s author a sample test:

@implementation SampleTestCase

- (void)setUp;
{
	[MagicalRecord setDefaultModelWithClass:[self class]];
	[MagicalRecord setupCoreDataStackWithInMemoryStore];
}
 
- (void)tearDown;
{
	[MagicalRecord cleanUp];
}
 
- (void)testSomeCalculationOnMyEntity;
{
	MyEntity *testEntity = [MyEntity MR_createEntity];
	float expectedValue = …;
	STAssert([testEntity customCalculation] == expectedValue, @"expected a good calculation");
}
 
@end

The MR_createEntity method will use the default context that was set up when the setupCoreDataStackWithInMemoryStore method was called earlier on in the test run. This makes for clean tests based on Core Data, but doesn’t let the Core Data syntax get in the way of expressing the intent of the test. And, when the test has completed, this sample entity will be deleted by virtue of the store being released from memory, so that the next test can have a clean slate with which to work.

Conclusion

And with that, you have an extremely simple and fast way to get a test environment setup for unit testing with Core Data. What I enjoy most about this setup is that when authoring unit tests which require Core Data, I am not focused on the details of setting up and tearing down Core Data. Rather, I’m focused on a single entity, and the things it requires in order to work properly. A sample set of unit tests which, in turn, test MagicalRecord itself are included in the MagicalRecord source on github.

Compiling Image Resources into a Static Library

2012-05-15T20:12:23+00:00

I’ve recently been working on a static library for distribution to other developers — Audiobus — 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.

Update: Fellow dev Cocoanetics pointed out that they’d solved a similar problem, and have a great write-up on how they create compiled resources using custom build rules on their blog.

The Image Resources

…Just a bunch of png files within a folder inside your project directory. The script assumes there are normal and retina (@2x) versions of each.

The Template

These are the template source files from which the end result will be derived. It contains a few tags that the accompanying shell script will process. I created it in Xcode, placing it within the same folder as the source png images, but removed it from the target’s compile phase, as we’ll be adding the derived source instead.

First the header, TPCompiledResources.h:

//
//  TPCompiledResources.h
//
//  Created by Michael Tyson on 13/05/2012.
//  Copyright (c) 2012 A Tasty Pixel. All rights reserved.
//
 
#import <UIKit/UIKit.h>
 
UIImage *TPGetCompiledImage(NSString* name);

And the implementation file, TPCompiledResources.m:

//
//  TPCompiledResources.m
//
//  Created by Michael Tyson on 13/05/2012.
//  Copyright (c) 2012 A Tasty Pixel. All rights reserved.
//
 
#import "TPCompiledResources.h"
 
/*{%IMAGEDATA START%}*/
/*{%IMAGEDATA END%}*/
 
UIImage *TPGetCompiledImage(NSString* name) {
    /*{%LOAD_TEMPLATE%}
    if ( [name isEqualToString:@"ORIGINAL_FILENAME"] ) {
        static UIImage *_SANITISED_FILENAME_image = nil;
        if ( _SANITISED_FILENAME_image ) return _SANITISED_FILENAME_image;
 
        if ( [[UIScreen mainScreen] scale] == 2.0 ) {
            _SANITISED_FILENAME_image = [[UIImage alloc] initWithCGImage:
                                                     [[UIImage imageWithData:[NSData dataWithBytesNoCopy:SANITISED_2X_FILENAME 
                                                                      length:SANITISED_2X_FILENAME_len freeWhenDone:NO]] CGImage] 
                                                                   scale:2.0 
                                                             orientation:UIImageOrientationUp];
        } else {
            _SANITISED_FILENAME_image = [[UIImage alloc] initWithData:[NSData dataWithBytesNoCopy:SANITISED_FILENAME 
                                                                                           length:SANITISED_FILENAME_len freeWhenDone:NO]];
        }
 
        return _SANITISED_FILENAME_image;
    }
    {%LOAD_TEMPLATE END%}*/
 
    /*{%IMAGELOADERS START%}*/
    /*{%IMAGELOADERS END%}*/
    return nil;
}

The Shell Script

Here’s the script that does all the work. The script looks for all “png” images in the given folder, then creates C code representing each image along with wrapper code to give access to the image byte arrays, with help from the template.

This script goes into a “Run Script” phase, placed at the beginning of the library’s build process.

#!/bin/sh
 
# Where the images are (get this from the first "Input Files" entry)
RESOURCES_FOLDER=`dirname "$SCRIPT_INPUT_FILE_0"`
 
# The name of the source template, minus extension
SOURCE_NAME="TPCompiledResources"
 
# Create C arrays, representing each image
tmp="$TEMP_FILES_DIR/compile-images-$$.tmp"
cd "$RESOURCES_FOLDER"
for image in *.png; do
    xxd -i "$image" >> $tmp.1
done
 
# Read the code template
TEMPLATE=`sed -n '/{%LOAD_TEMPLATE%}/,/{%LOAD_TEMPLATE END%}/ p' "$RESOURCES_FOLDER/$SOURCE_NAME.m" | sed '1 d;$ d'`
 
# Create loader code for each image
for image in *.png; do
    if echo "$image" | grep -q "@2x"; then continue; fi
    ORIGINAL_FILENAME="$image"
    SANITISED_FILENAME=`echo "$ORIGINAL_FILENAME" | sed 's/[^a-zA-Z0-9]/_/g'`
    SANITISED_2X_FILENAME=`echo "$SANITISED_FILENAME" | sed 's/_png/_2x_png/'`
    echo "$TEMPLATE" | sed "s/ORIGINAL_FILENAME/$ORIGINAL_FILENAME/g;s/SANITISED_FILENAME/$SANITISED_FILENAME/g;s/SANITISED_2X_FILENAME/$SANITISED_2X_FILENAME/g" >> $tmp.2
done
 
# Create the source file from the template and our generated code
sed "/{%IMAGEDATA START%}/ r $tmp.1
1,/{%IMAGEDATA START%}/!{/{%IMAGEDATA END%}/,/{%IMAGEDATA START%}/! d;}
/{%IMAGELOADERS START%}/ r $tmp.2
1,/{%IMAGELOADERS START%}/!{/{%IMAGELOADERS END%}/,/{%IMAGELOADERS START%]/! d;}" "$RESOURCES_FOLDER/$SOURCE_NAME.m" > "$DERIVED_FILE_DIR/$SOURCE_NAME.m"
 
# Copy the template header file in
cp "$RESOURCES_FOLDER/$SOURCE_NAME.h" "$DERIVED_FILE_DIR/$SOURCE_NAME.h"
 
rm "$tmp.1" "$tmp.2"

The “Run Script” phase that hosts this script also needs a couple of additions, to tell Xcode what the inputs and outputs to the script are: In the “Input Files” section, the path to the image resource folder, with a “*.png” wildcard at the end, and also the path to those template files, TPCompiledResources.{h,m}. Finally, the two output files go in the “Output Files” section:

Project Setup

Now it was just a matter of setting up the project to include the derived source files in the build. This was a bit messy and took a little doing, but with guidance from this article by Ben Zado on file references relative to DERIVED_FILE_DIR, it wasn’t too painful:

Build, in order to generate the derived source files.
Navigate to the derived sources folder within the build products, and drag the TPCompiledResources.{m,h} into the project, placed within a new group (I called the group “Derived Sources”).
The path type for those files (accessible from the properties viewer — Cmd-I) should be “Relative to Enclosing Group”, and consequently the “Path” field should just show the filename, with no path component. This was a bit touch-and-go for me, and I had a hard time making this happen, so I left it as-is for now, fixing it manually later in step 8.
Under Xcode Preferences » Locations » Source Trees, add an entry with setting name “DERIVED_FILE_DIR“, display name “Derived Files” and path “$(DERIVED_FILE_DIR)“.
Set the path type for the group containing the two derived sources to “Relative to Derived Files”.
Quit Xcode, and open the project.pbxproj file from within your project’s bundle.
Find the “Derived Sources” group (or whatever it was named in step 2), and delete the “path” property from the list of attributes.
I had to also find the TPCompiledResources.{m,h} file sections and delete the “path” attribute for those, too.
Reopen Xcode, and build — it should be good to go (don’t worry that the derived sources are shown in red in the project group — Xcode’ll find them).

Now that’s done, images can be accessed by TPGetCompiledImage(@"ImageName.png"). Yay!

Permanently Unhide Library

2012-05-15T14:20:32+00:00

When Apple shipped Mac OS X Lion 10.7, the “Library” folder located within every user’s home folder, which had previously been visible to users in the Finder, was made invisible. To access the Library folder, users must now hold down the option key while selecting the “Go” menu in the Finder.

This is probably a good move for the vast majority of Mac users, but for folks with even a small amount of interest in tinkering with the configuration files and caches of various applications, it’s an outright nuisance.

The nuisance is exacerbated by Apple’s decision to build in the “make invisible” action into every single dot-update to the OS. So if you’ve taken the trouble to undo Apple’s work and make the folder visible again, you’ll notice that when you updated from 10.7.3 to 10.7.4, poof!, it’s gone again.

I solved this very early on for my own needs by adding the command-line instructions for re-showing the Library folder to my Terminal configuration script. Every time I open a new Terminal window, the Library folder is aggressively set to visible again. In practice, this has meant that since 10.7 shipped, I’ve never been bothered once by Apple’s disappearing act.

For less Terminal-intensive Mac users, this solution might not be sufficient. If you, or somebody you love, truly wants the Library folder to be forever visible in the Finder, a good trick is to add a script Login item to do the deed. Here are detailed instructions for achieving this:

Download UnhideLibrary. Make sure it unzips to a script application file after downloading. You’ll need to keep this file around, so I recommend storing it somewhere in your home folder.
Open System Preferences.
Click the Users & Groups icon.
Select the Login Items tab for appropriate user.
Click the + icon and select the downloaded UnhideLibrary script item.
Log out and log back in again.
Never curse Apple’s Library folder policy again.

The script file is just a few lines of AppleScript code to invoke the appropriate shell script. I originally used a plain shell script file but Thomas Borowski noticed it sometimes opens as a regular document at login time. He also wrote his own post essentially stating all the things I’m now repeating here!

So long Library folder, see you again, automatically, on 10.7.5.

Last week in WebKit: Tab sizing and strings for IndexedDB

2012-05-14T14:54:07+00:00

A total of 650 commits landed in WebKit’s repositories last week, ending with revision 116915.

Web Inspector’s search box supports CSS selectors again, JavaScriptCore timers will now show up on the timeline and a context menu has been added for tabs.

Text decorations, such as underlines, will now be rendered for text in :first-line selectors. Implementation of the :first-letter selector was aligned with the specification. Eric landed stylesheet inheritance support for seamless iframes, as well as the ability to inherit styles from their parent iframe. The RadioNodeList interface is now supported, background-size is now part of the “background” shorthand and, albeit disabled, the <intent> element has landed.

IndexedDB now uses strings instead of numeric constants. Violation reports generated by Content Security Policy now also include the referer, original policy and the URL which got blocked. The File System API is now able to deal with cross-file system operations, widths and heights are now exposed for <input type=image> images, and the offsetLeft property was broken when used together with CSS Columns.

WebKit has also gained support for the tab-size CSS property. This property, which is also supported by Firefox and Opera, allows you to define the number of spaces a tab should be equal to.

Included among other minor updates on the WebKit website, the conditions under which the WebKit trademark can be used are now available on the Mac OS Forge website.

Other changes which occurred last week:

Half a megabyte of memory was saved by Andreas when viewing the full HTML5 specification.
The IETC CSS Values and Units tests have been added to WebKit’s test suite.
A first step towards implementing the HTML Media Capture API has been made.
Pages served with an XHTML-MP doctype will now automatically use a suitable viewport.

The Sandbox’s Big Red Button

2012-05-12T20:42:29+00:00

If you’ve been following the debate surrounding Apple’s Application Sandbox, you know that many developers are concerned about the implications for existing apps of adopting the sandbox.

Apple has been threatening for almost a year that apps for sale in the Mac App Store will need to embrace the Application Sandbox, or else further updates to the apps will not be accepted. The deadline for adopting the sandbox has slipped several times, but it currently rests at June 1, 2012. That’s only a few weeks away, and comes just ahead of Apple’s annual developer conference.

I’ve written a few rants about the Application Sandbox, culminating in my February 2012 piece imploring Apple to “Fix the Sandbox.” Slowly but surely, they are improving the technology that drives the sandboxing features of Mac OS X, but by June 1, it appears that many classes of application will still be “unsandboxable” under the current permissions model supplied by Apple.

The shortage of permissions, or “entitlements” in sandbox lingo, has always been at the root of my concerns. Especially because of the political move requiring existing Mac App Store apps to adopt the sandbox, it is easy to imagine a features bloodbath come June, or whenever the requirement goes into place. When Apple announced the postponement to June 1, they also took care to make assurances that bug-fix updates would still be allowed for non-sandboxed apps, which is a nice break, but will still leave many apps to die on the vine in lieu of suitable sandboxing entitlements for the features various apps provide.

Apple publicly documents the list of entitlements available to Mac software developers. One of my major concerns has always been that because the list of entitlements doesn’t cover all the nuanced, legitimate tasks that an app might want to perform on a user’s behalf, that Application Sandbox ran the risk of permanently forbidding certain types of application behavior from being conducted in the sandbox.

The high-level list of Application Sandbox permissions is intentionally coarser-grained than the lower-level “sandbox facility” which ultimately imposes the restrictions. Some developers criticize Apple for failing to embrace the sanbdbox with their own apps, while expecting developers to embrace it for the Mac App Store. On Mac OS X 10.7.4, the two notably sandboxed apps from Apple remain Preview and TextEdit, two apps that would be relatively simple to sandbox compared to a large number of complex, 3rd party products.

But Apple has applied a good deal of sandboxing to their code. For example, take a look at /usr/share/sandbox/ and /System/Library/Sandbox/Profiles/ for examples a variety of “.sb” files that specify the sandbox restrictions of a variety of system services and tools. These files are expressed in SBPL, or the Sandbox Policy Language, which is a scheme-based language used to express the fine-grained permission the sandbox facility is capable of controlling. See my “Sandbox Corners” for a bit more about the lower-level sandbox facility and SBPL files.

Today I decided to take a closer look at one SBPL file of particular interest: /System/Library/Sandbox/Profiles/application.sb. This is the SBPL file that, so far as I can tell, translates the high-level “entitlements” of the Application Sandbox into corresponding lower-level policy expressions for the sandbox facility. For example:

(if (entitlement "com.apple.security.network.client")
    (allow network-outbound (remote ip)))

You can get a taste for how the high level “I’m a network client” translates specifically to “allow out bound ip traffic” at the sandbox facility level. Other high-level rules express much more complex logic. For example, the “I want to use the printer” entitlement translates to a variety of low-level permissions to communicate with printer-system daemons, and read from printer configuration files on the system.

But by far the most interesting entitlement of all is one that I found at the bottom of application.sb. It’s not documented on Apple’s site, and from what I can tell this blog post will become the first Google match on the term. The entitlement is “com.apple.security.temporary-exception.sbpl”, and the comment above it reads simply: “Big Red Button”.

;; Big Red Button
(sandbox-array-entitlement
  "com.apple.security.temporary-exception.sbpl"
  (lambda (string)
    (let* ((port (open-input-string string))
           (sbpl (read port)))
      (eval sbpl))))

This temporary entitlement enables a high-level Application Sandbox-restricted application to supply, along with whatever other high-level entitlements it requests, an entitlement that brings with it as a parameter a literal SBPL program, that will be evaluated and thus applied by the lower-level sandboxing facility.

In short: the Big Red Button gives Apple an out.

Whatever mistakes they make in the devising of high-level entitlements can be theoretically undone after-the-fact by supplying developers with special Big Red Button entitlements that pass along specific permissions to the lower-level sandbox, liberating the application to do whatever important task it needs to do.

Of course, the fact that this facility exists does not say anything about whether Apple will indulge its use. And just because you, as a developer, could use this entitlement key to empower your sandboxed app to do practically anything, it doesn’t mean that Apple’s App Store reviewers would look kindly upon it. In fact, I’m almost positive that at this point, any developer who submits a sandboxed app with this entitlement will have to have already conversed extensively with Apple about the need for such a transgression.

But the entitlement is there, and that makes me breathe a little easier. The Application Sandbox is, so far as I can tell, technically capable of granting whatever permission any app could reasonably need. The only obstacle, and it’s a big one at that, is the political challenge of App Store approval.

Update: John Brayton made an interesting point in the comments, that regardless of MAS policy, the Big Red Button might be useful to non-MAS developers who wish to adopt the Application Sandbox , but can’t manage to squeeze all their functionality into the confines of its entitlements. I originally thought this made good sense, but then realized how risky a move this would be in practice. Because the entitlement in question here has not been documented by Apple, and is furthermore only listed in an implementation file for the system itself, the behavior of this entitlement can’t be relied upon.

Indeed, above I suggested that the entitlement would grant developers the power to enable virtually any capability in their sandboxed apps, but we have no idea how Apple has actually implemented support for the entitlement inside Apple. They could very well have a special case inside the SBPL language evaluator itself that looks for and rejects scripts that it doesn’t recognize as its own.

The application.sb file even has a strong disclaimer to this effect:

WARNING: The sandbox rules in this file currently constitute
Apple System Private Interface and are subject to change at any time and
without notice. The contents of this file are also auto-generated and
not user editable; it may be overwritten at any time.

In other words: you can’t count on the details of this file remaining stable from release to release. It would be foolish to base the behavior of any shipping app on entitlements listed there, but not documented by Apple. I think the Big Red Button is a very interesting find, and I’m very curious about it. But that’s how it should be considered: as a curiosity.

Illuminate 1.2 Overhauls the Window Switching UI

2012-05-09T17:15:52+00:00

Illuminate 1.2 is out with major changes to how the cycle windows feature works. Since cycle windows is the main feature in Illuminate, I made an effort to streamline it and make it usable in fewer keystrokes. The most noticeable change is that Cycle (All) Windows and Cycle (All) Tabs have been consolidated into one feature: Cycle Windows. Cycle Windows cycles through all the windows and tabs using just one keyboard shortcut (Option-Tab), plus they’re now grouped by application, making application switching more obvious.

In order to speed up switching between windows, sticky mode has be turned off by default so the window selection happens as soon as you let up on the modifier keys. Also, there is now a configurable delay between when the keyboard shortcut is pressed and the UI shows up. This means you can quickly switch between windows or tabs without the UI flashing up or otherwise having to wait on it.

The 1.2 includes some other features and bug fixes:

Support for Google Chrome tabs

Ability to exclude certain applications from the window switching list.

You can now change the order windows appear in when switching windows: last time accessed or alphabetical.

Improved layout in the cycle windows UI so more space is used by the window thumbnails.

Fix for a crashing bug.

The update is free for existing customers, $9.99 for new customers, and is available from Fortunate Bear’s online store or Apple’s Mac App Store.

You can read the full press release here.

Last weeks in WebKit: sub-pixel layout and seamless iframes

2012-05-08T14:07:59+00:00

Since there wasn’t an update last week, this one briefly covers changes between revisions 114867 and 116271.

Web Inspector now offers the ability to disable all JavaScript execution on a page, and also allows Web Socket frames to be inspected. The shortcut overlay has received some UI polish and the Timeline Frame Mode has been taken out of experimental.

Fixed placeholders have been implemented for date input types, a form field’s entries supplied through a <datalist> are now barred from validation. The Apple Mac port removed support for BlobBuilder and the Selector APIs have been aligned with the specification when pseudo-element selectors are used.

Retrieving a canvas’ image data will now return a Uint8ClampedArray instead of a CanvasPixelArray object. In preparation of supporting getUserMedia on Chromium, the Peer Connection API implementation has been separated with a compile time flag. Tables now support the createTBody() method and the IndexedDB implementation can now open cursors based on an IDBKey, and advance cursors as well.

Eric landed the first parts of support for seamless iframes in WebKit, namely some tests, sandbox and styling and navigation. A vendor-prefixed version of the Performance Timeline API landed, the getUserMedia() method now takes an object instead of a string and the noteOn and noteOff methods of the Web Audio API’s oscillator got implemented.

Antti made it possible to share stylesheet data structures between documents, decreasing memory usage by several megabytes (take note, kling) depending on the port’s implementation. Furthermore, parsed stylesheets may now be cached, increasing performance of subsequent page loads.

Per commit 116009, Levi and Emil were able to close the meta bug for supporting sub-pixel layout in WebKit. While this has not yet been enabled for any port, this is a significant milestone for the project. This article provides some insight in the importance.

Other changes which occurred last week:

Code supporting positioned floats has been removed from WebKit, pending proper implementation.
The EFL port has enabled support for the <track> element, the Web Timing API and the Web Audio API!
The BlackBerry port enabled support for the download attribute on anchors.
Abhishek Arya (inferno) is now a WebKit Reviewer, congratulations!
Alexis Menard is now a WebKit Reviewer as well, congratulations!
Chromium is working towards enabling getUserMedia by default.
Multiple input channels are now supported for the JavaScriptAudioNode.

MarsEdit 3.5.1: Tying Up Loose Ends

2012-05-07T23:38:40+00:00

MarsEdit 3.5.1 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed MarsEdit customers.

When I released MarsEdit 3.5 a few weeks ago, it included some very significant overhaul to MarsEdit’s handling of rich text formatting, including new support for customized formatting macros in Rich Text mode.

Given the large number of changes, I was not too surprised that a few annoying bugs snuck in as well. In particular, it became unreliable to apply some formatting options like heading and block quote in Rich Text mode. I took the opportunity while fixing those things to take care of a bunch of other little gotchas, including some more compatibility tweaks for the forthcoming Mountain Lion 10.8 release.

Fix the preview window to recognize and substitute template placeholders in the section
Fix a bug with Squarespace and Expression Engine not prompting for username/password on new blog
Restore ability to set “Warn when no title” option on Blogger blogs
Fix a bug that prevented some blog-configuration options from being selected after switching system type
Restore ability to start a Header or Blockquote before typing content
Pressing return twice to exit Preformatted works again
Improve support for future releases of Mac OS X
- Address an issue with icon view when resizing the Media Manager window
- Avoid crashes caused by conflicting system libraries

Solving Simulator Bootstrap Errors

2012-05-07T20:06:00+00:00

I'm sure every iOS developer has seen the dreaded bootstrap error. "Couldn't register com.yourcompany.yourapp with the bootstrap server. Error: unknown error code. This generally means that another instance of this process was already running or is hung in the debugger." After nearly throwing my Mac out the window for the Nth time today, I finally managed to come up with a simple fix. Run this in the shell: launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove. And your bootstrap errors magically melt away.
(Read More)

Friday Q&A 2012-05-04: PLCrashReporter and Unwinding the Stack With DWARF, Part 2

2012-05-04T18:44:00+00:00

Here I am, yet again! This week, I'm continuing where my last article left off, regarding PLCrashReporter and unwinding stack frames on x86_64. In particular, I go into how I got at and used all the various data I discussed in last week's article, and why some of the existing solutions in the wild weren't suited for our use.
(Read More)

RubyMotion brings serious Ruby development to the iOS world

2012-05-03T16:40:09+00:00

For the past several months I’ve been involved with, but unable to publicly discuss, an exciting project called RubyMotion. My friend Laurent Sansonetti, creator of MacRuby, has now officially launched a serious alternative to Objective-C for iPhone and iPad development.

RubyMotion is not a bridge; it actually generates native applications that are as fast as the ones written in Objective-C . You can check out Ars Technica’s exclusive article for more details on the project and watch the Pragmatic Studio’s 50 minute free screencast about it to get a better idea of how RubyMotion works in practice.

For a limited time you can buy RubyMotion at an early bird discount rate of 25% off. It’s such a productive and affordable solution, that I’m sure it will quickly become popular among Ruby developers who are interested in iOS development and testing, as well as among existing iOS developers.

Many of the questions you may have can likely be found in the FAQ section, but feel free to ask any additional questions here. Enjoy it.

Possibly related posts:

Alexis Menard is a WebKit Reviewer!

2012-04-30T15:02:48+00:00

Alexis (aka darktears on IRC) has been an unstoppable WebKit coder in the last couple of years working at INdT/Nokia Brazil.

Among his contributions would be the Qt multimedia backends with GStreamer/QTKit, improvements to getComputedStyle, and countless other contributions in various parts of WebKit.

We’re happy to finally remove the word “unofficial” from his reviews. Welcome Alexis!

Friday Q&A 2012-04-27: PLCrashReporter and Unwinding the Stack With DWARF

2012-04-27T14:11:00+00:00

I'm back once again for Friday Q&A. Today I'm going to talk about some work I recently did on PLCrashReporter, adding support for unwinding stack frames on x86_64. PLCrashReporter was originally targeted solely at iOS, where both ARM and x86-32 (the simulator) make crash reporting relatively straight-forward; we can simply walk the stack via the preserved frame pointer. On x86-64, matters are different, leading to the need to implement support for alternative methods for stack unwinding. This work was sponsored by HockeyApp, to support their upcoming release of Mac OS X sandbox-compatible crash reporting. I'll talk about DWARF debugging information, the compact unwind encoding, and stack scanners. I assume at least some knowledge of x86_64 architecture, for simplicity's sake.
(Read More)

Last week in WebKit: The Contributors Meeting and datalists

2012-04-26T00:01:25+00:00

A total of 652 changes landed last week in various branches of WebKit’s repository. This update covers changes up to revision 114894.

Last Thursday and Friday, Apple kindly hosted the 2012 WebKit Contributors Meeting in Cupertino. With contributors from many different vendors around, a large number of subjects were covered in presentations and discussions. Transcripts of most of these are available on WebKit’s Trac, including a group photo of all attendees.

An experimental Style Panel has been introduced to Web Inspector which mimics the interface of the Script Panel, which also features an open stylesheet-dialog. Cross-frame security error spam when typing in the console is gone, calling document.open() will now reset the Elements Panel and the Inspector is now shimming the startsWith() and endsWith() methods on the String prototype, anticipating implementation of Microsoft’s proposal.

Parsing rules of the :nth-*() pseudo-classes has been aligned with the specification. Clipping issues with the CSS drop-shadow filter have been resolved and the “-webkit-filter” CSS property will now show up when enumerating over an element’s computed style.

Support for the HTML5 <datalist> element has been enabled for Chromium. It provides similar functionality to suggestions by the browser based on what you previously entered in a text field, with the difference that these suggestions are provided by the website.

Other changes which occurred last week:

The WebKitGTK port has enabled the Web Timing implementation.
Performance of several String-returning DOM attribute and property getters has been improved for v8.
The localStorage.setItem() method cannot override methods on the Storage prototype anymore.
The footprint of an element’s attributes has been reduced to a minimum for common usage.
The IndexedDB implementation can now retrieve values or keys by IDBKeyRanges.

Abhishek Arya is now a WebKit reviewer!

2012-04-25T23:03:04+00:00

Abhishek, better known to the community as inferno, joined the WebKit community in March 2010, and he has been fixing security bugs in CSS, DOM, editing, rendering, and various other components in WebKit. Abhishek has contributed more than 260 patches, many of which are fixes to severe security bugs.

Please join me in welcoming Abhishek Arya as a new WebKit reviewer.

SkyDrive

2012-04-23T23:26:09+00:00

I just found out about Microsoft's SkyDrive from Macworld: "New and improved SkyDrive is a threat to Dropbox".

Since it works similar to Dropbox, I figured I'd try out syncing a VoodooPad 5 document from Mac to Mac. And sure enough, it worked just fine. I saw new pages being added and modified, without having to close a document.

An RSS-feed and location-based iOS application

2012-04-23T22:46:54+00:00

The purpose of this post is so that I will have a link to give people when they ask: how do I write an iOS application that pulls data from an RSS feed, displays it pretty and can put things on a map. I'll show you all of that and more as I rewrite my oldest iOS application from scratch: FuelView.

The app presented in this post, FuelView, is freely available on the Australian App Store.

Introduction

I am commonly asked to write a post where I show a basic "pull data from the network and display" application.

But I think "basic" is boring and I try to avoid it in my blog posts. Instead, I decided to rewrite an application that looks simple but actually has a deceptively large amount of work to perform. It's a far better example of a real-world iOS application since there should always be enough work done transparently by your application that it leaves the user with a "Wow!"

The actual application is only 3 screens. While a truly simple three screen application might take about 2-3 hours per screen to implement (even if you're just stumbling your way through), this program actually took me about twice that time to implement (around 15 hours or two full days of programming) and I definitely knew what I was doing, since I've written the entire program before.

If you're curious though, in its first incarnation, this program took me 2 weeks to fully implement — way back in July 2008. It was the first program I ever tried to write for iPhone OS 2.0 and I did a lot of things the wrong way. Having a vague idea what you're trying to do really does make a 5 to 10 times difference to implementation time and unfortunately, the only way to learn is to stumble headlong into things and run the risk of getting everything wrong the first time.

There's a reason why this version is a rewrite from scratch.

Useful code in this post

While the application in this post is only directly useful to people living in Western Australia, I think this is a really interesting project as it contains a lot of very useful snippets of code (some of which I've written posts on before) including:

An iOS version of my Gloss Gradient drawing code (you can see the Mac version in Drawing gloss gradients in CoreGraphics)
Two persistent stores with one NSPersistentStoreCoordinator. It seems like a strange scenario that would only be needed in strange situations but the use case turns out to be really common.
A full set of "single line Core Data fetch" methods (something I've previously written about in Core Data: one line fetch)
Getting the GPS location (which you can also see in my earlier posts: WhereIsMyMac, a Snow Leopard CoreLocation project and A sample iPhone application with complete unit tests)
Pulling data from an RSS feed (using my XMLFetcher class from Classes for fetching and parsing XML or JSON via HTTP)
Caching data in the Application Support directory (using a DirectoryLocations category from Finding or creating the application support directory)
Function to create a two point CGGradientRef from two UIColors (another in a long list of convenience functions that I'm surprised aren't part of Cocoa)
An example of using a category as an Adapter interface (something I discussed in Adapter interfaces in Objective-C, using categories without giving any concrete examples)
Scrolling a text field that isn't in a table (a similar idea but different implementation to my earlier post Sliding UITextFields around to avoid the keyboard)
A Core Data Postcode database (originally created from a CSV file as shown in Writing a parser using NSScanner)
A flexible, reusable controller/table/cell structure (as I discussed in UITableView construction, drawing and management)
A CheckmarkCell that self-manages radio button style selection (without the UITableViewController needing to do anything when the cell is selected, the cells in the section will automatically ensure only one is selected at a time)
Forward geocoding using Google's Maps API (MKReverseGeocoder goes the other way but a non-Cocoa approach is needed to go from an address to longitude/latitude)

Plus a whole lot more. It really is a densely packed little program.

So where is all the "useful code"? If you skip forward to the second last section, I reveal where in the program you can find all of these code samples.

About FuelView

FuelView is an application for getting fuel (petrol/gasoline, diesel, etc) prices in Western Australia. It pulls its information from an RSS feed provided by the Western Australian government's "Fuel Watch" scheme that provides fuel prices for all stations in that state.

(No, I don't live in Western Australia — I'm on the opposite coast of Australia — but it seemed like a good idea for an iPhone app at the time.)

The application looks like this:

Download the complete project associated with this post: FuelView.zip (330kb).

Note: the code is all freely available under a zlib-style license but this license does not extend to the other assets. You may not use the icons or application name in your own programs.

The previous version of FuelView (1.1.10 is available for free from the iTunes App Store in Australia. I'll be resubmitting this version (probably 1.2) in a week or two.

Deceptive complexity

It all looks very simple; you get the location from the GPS, you pull the correct RSS feed for the location, stick pins in a map for the result.

If that were the actual number of steps involved, it would be great. However, it's not so simple. Let's take a quick look at the issues that will cause the most trouble for this program.

User location issues

The GPS gives latitude/longitude but the getting the RSS requires a Western Australian suburb name. In order to make this work, you need to be able to look up all the Western Australian suburbs and find the nearest one for your longitude/latitude. This requires a database of suburb names and their longitude/latitude and some code to search this.

Additionally, I want to be able to let the user specify a postcode for their location instead of using the GPS. Again, I need to be able to look up the suburb name for the postcode. Additionally, any code that requires the user's location must be able to tolerate the location being a postcode, not a raw longitude latitude.

A further complication arises because the FuelWatch RSS feed only exists for "larger" suburbs. Names of smaller suburbs can't be used, so the list of suburbs must be filtered to match the list that the FuelWatch website recognizes.

Station location issues

The RSS feed gives the fuel station locations as street addresses but I need longitude and latitudes for them so I can stick pins in the map or calculate the distance between the user and the station.

While this is a similar problem to resolving the user's location, it is actually trickier since new stations appear all the time, so this database must be dynamic (unlike the static postcode database).

I need to actually perform geocoding of fuel stations but there's a problem: Google's APIs are highly restrictive about how often you can make requests. The only way to avoid problems is to pre-populate the database and then have users only perform forward geocoding requests when an unknown fuel station appears and immediately add the new station to the database.

Custom drawing

Then I have the more straightforward complexity of custom drawing. I want to have most of the interface follow a custom aesthetic (because plain is boring) and that takes time and effort. I also need to ensure that drawing and layout function properly on an iPad and an iPhone.

The real design of the program

In the diagram here, the green objects are the 3 main view controllers, the orange objects are the main "model" of the program (being the data that is actually displayed and passed between the ResultsViewController and the MapViewController) and the blue objects are the data controllers or functional pipelines of the program.

You can see some of the "deceptive complexity" here: the ResultsViewController is managing three different kinds of model data, and is also managing input from the CLLocationManager and UITextField. All this is apart from the normal responsibility of showing and displaying the UITableView and its rows.

Initial design of the program

While I'd love to say: I had this entire design ready when I started, it's simply not true. What I actually had was a quick UI design and a quick sketch of the data pipeline.

My inital sketch for the UI looked like this:

I didn't really need to do this sketch for this program (since the UI is pretty simple) but it's a good way to start all user programs.

As you can see, in the three years since I wrote FuelView, I had entirely forgotten about the need to resolve postcodes to suburb names and resolve station locations — instead I've simply shown the network pipeline.

This forgetfulness is pretty disappointing. Not only does it make me think the program is taking longer than it should but it ultimately leads to some of the design problems I discuss later.

But we're not there yet.

First implementation iteration

I'm going to refer to the design stages as "iterations". These steps are often called milestones (or mini-milestones when they're this small) but milestone implies you're only going forward, instead of the reality where you normally need to update the existing interfaces on your classes as part of integrating new features — so I prefer to think about it as iterating the program.

The first iteration involved implementing the program as described in the "FuelView Initial Dataflow design" shown above.

Created a new project from my PageViewController template
Pulled in an XMLFetcher
Hardwired the code to pull the RSS feed for a specific suburb
Displayed the list of addresses from the results as a basic text list

Second design iteration

Now I need to be able to resolve locations from the CLLocationManager to suburb names. I also need to be able to resolve user-entered postcodes to actual suburb names. Finally, there needs to be logic so that a manually entered suburb name supercedes the GPS.

Again, I wouldn't ordinarily draw little design diagrams for this but — its a blog post and big walls of text are boring.

Second implementation iteration

To make the second design iteration work, I go through the following steps:

Modified the CSVImporter from my Writing a parser using NSScanner post to generate a list of Western Australian postcodes with longitude and latitude. At the same time, I need to filter out suburbs that won't be recognized by the FuelWatch website
Brought in a standard class for managing a Core Data NSManagedObjectContext and used the class to perform lookups on the list of Postcodes
Added code to the ResultsViewController for CLLocationManager GPS locations
Added code to the ResultsViewController to switch between the CLLocationManager and user-entered Postcode data sources

Design Mistake #1

In a general sense, the program is "well-designed" but it still contains two design mistakes. I could fix these mistakes but (a) I'm lazy and (b) I wanted to talk about both of them since I think they're under-discussed design problems.

By this point in the implementation, the first mistake has emerged: the ambiguous overuse of the word "location".

Yes, ambiguous naming is a design mistake. It's not exactly an aspect of design that is thoroughly discussed — probably because it's considered self-evident — but as your program evolves and new functions, roles and elements are added to existing classes, it is sometimes necessary to change the names of the classes.

In this program, the word location has a few different meanings:

GPS location from the CLLocationManager (gpsLocation in the program)
User-specified postcode (usingManualLocation/postcodeValue in the program)
Resolved suburb name used for searching (location property on ResultsViewController — a Postcode object
The location of fuel stations (instances of the Location class)

Yuck, what a nightmare.

The single biggest mistake here is that the location property on the ResultsViewController is a Postcode object, despite the name implying the Location class. This is an ambiguity you should work really hard to avoid — and fix when it occurs.

A far better approach would actually be: rename the PostcodesController to SuburbsController, rename Postcode to Suburb, rename the suburb property on Suburb to name and rename the location property to suburb. In addition, it would be better to rename Location to Station.

Third implementation iteration

Now that the main data path is working, it's time to start on the custom views.

The GradientBackgroundTable will be the main UITableView class in the program. Its name is a bit of a misnomer: not so much of a misnomer that it's a design mistake but the table can draw as a gradient but can also draw as a flat color — it would be better named "Custom colored background table" or something like that.

Each result row will be represented using the following classes:

ResultCell — controller that constructs the rest of the row
ResultCellBackground — set as the backgroundView of the cell. Draws the gray gradient background and not much else
ResultView — draws all of the text (does not use UILabels) and uses the Gloss Gradient code to construct the backing for the actual price display

This now brings us a main screen that looks like this:

Note that each row simply shows an orange "cents per litre" line under the price. Ultimately, this should show the distance from the user's current GPS location to the station but since I don't yet have the locations for the stations, I can only show "cents per litre". Note that this "cents per litre" will continue to display in the final program if the user is using a manually-entered postcode (and I don't necessarily know their GPS location).

Fourth implementation iteration

Now I need to resolve station locations. I have the street addresses from the FuelWatch RSS feed results but I need to turn this into longitude and latitude to calculate the distance or stick a pin in a map.

I'll use the Google APIs for this. As I've said though, the Google Maps API won't let you perform a large number of requests per second so I need to aggressively pre-cache station locations and only perform a geocoding request when a new fuel station appears for the first time.

The LocationsController and the Location lookup generally work like the Postcode lookup on the PostcodesController when the station is cached, otherwise, I need a callback when the actual response comes back from Google.

The LocationsController normally uses two Core Data data stores: one is read-only and is the "pre-cached" set of fuel station results (shipped with the application). The second is the read-write data store, saved in the Application Support directory (which is writeable, unlike the application's bundle). This second location will get all new locations for which we need to query Google.

To prepare the pre-cached file of stations that we can ship with the application, the best approach is simply to run in the iPhone Simulator with the LocationController's primary data store set to Read/Write (and the read-only store removed) and when the primary data store fills with results, let it save to file, copy the cached results file from the iPhone Simulator's directory back into the Project.

Once the location is resolved to a longitude and latitude, I can calculate the approximate distance to the user's GPS location, using the approximate kilometres per longitude and latitude at 30 degrees latitude (this is not highly accurate but is sufficient given that most of Western Australia is relatively close to 30 degrees latitude.

With the locations available, I can display the distance in the ResultsView and color code the distance bar based on how far away the station is.

Maps Key Note: I have removed my Google Maps API key from the code. If you want to use this code, you'll need to apply for your own Google Maps API key and set it the MapsKey at the top of the LocationsController.m file.

Fifth implementation iteration

Implementing the SettingsViewController to switch fuel types and the MapsViewController to show the current array of results on a map turns out to be very simple. There's not a significant amount of complexity in either of these views.

Design Mistake #2

One point to notice in the implementation of the MapViewController is that I needed to implement an "Adapter category" on NSDictionary to allow the NSDictionary to respond to the MKAnnotion protocol so I could use the dictionaries to display the pins in the map.

How is this a design mistake?

Needing to put categories on generic classes like this is an indication that you probably should have used a dedicated class to contain your data. The results in the program should not be generic NSDictionary objects.

Until this point, the "generic"-ness of the main data type in the program has been ignored. The reality though is that the construction of NSDictionary results from XPathResultNodes and the resolving of station location for each result has been handled by the ResultsViewController — this is all work that a Result class should be performing for itself instead of using a generic NSDictionary class and making the ResultViewController handle all the work.

But ad hoc trickery like adding categories to generic container classes is a big flag that you've forgotten to use a custom class for objects that genuinely need their own behaviors. If you find yourself needing something like this: replace the generic container with a proper custom class.

I'm not saying that adapter categories are a bad idea. Sometimes you can't or shouldn't change the underlying class — in this case and adapter is a good thing. But here in FuelView I can change the underlying class and should, in order to reduce the code burden on our controllers.

So where is all the "useful code"?

An iOS version of my Gloss Gradient drawing code

The GlossGradients.m code is in the project. It's very similar to the original code except that there aren't HSV conversion methods on UIColor like there is on NSColor, so I've had to write these methods myself. It is used in the ResultsView drawing code.

Two persistent stores with one NSPersistentStoreCoordinator

The LocationsController uses two different persistent stores: a read-only store inside the application bundle that is shipped with the application contains the pre-supplied results for station lookups. But the application bundle can't be changed, so I create a read-write store in the Application Support directory. The NSPersistentStoreCoordinator is smart enough to save the store to the correct location automatically.

A full set of "single line Core Data fetch" methods

The NSManagedObjectContext+FetchAdditions.m file contains a range of different fetch request creation methods and single line fetching implementations (for set, array and single object results). It is used in the LocationsController and the PostcodesController to perform the actual queries on the Core Data context.

Getting the GPS location

The ResultsViewController operates as a CLLocationManagerDelegate. The location receiving code is pretty simple but I think the error handling code in locationFailedWithCode: is more interesting.

Pulling data from an RSS feed

Of course, an RSS feed is just XML. We're after the <item> nodes in the result so I use an XMLFetcher to with an XPath query of "//item". You can see this in the setLocation: method and the response is handled in the responseReceived: method (the XPathQueryNodes are turned into an NSDictionary).

Caching data in the Application Support directory

The application support directory is accessed/created in the persistentStoreCoordinator method of the LocationsController. As I said above, this is for writing extra Locations to the Locations Core Data context.

Function to create a two point CGGradientRef from two UIColors

The function TwoPointGradient is pretty simple; it just creates a CGGradientRef taking two UIColors to use as the endpoints of the gradient. However, it's 23 lines of code that don't need to be retyped in the ResultCellBackground, ResultView and the PageCellBackground.

An example of using a category as an Adapter interface

Putting an adapter on a generic container class is a bad idea if you can easily change the class to something of your own implementation. But this is still an example of adapting a class' interface to suit your own needs — something that is very useful when you don't have control over the underlying class.

Scrolling a text field that isn't in a table

The manually entered postcode is in a text field on a UIToolbar and when the keyboard appears, the entire UIToolbar scrolls up with the keyboard. This behavior is handled by the PageViewController (everything below the "Handle the sliding/scrolling of the view when the keyboard appears" pragma except the dealloc method). The PageViewController needs to be set as the delegate of the UITextField for this to work.

A Core Data Postcode database

The PostcodesController shows how to implement a static data store using Core Data. I think I could probably write a base-class for this type of singleton that would dramatically reduce the common code between the PostcodesController and the LocationsController.

A flexible, reusable controller/table/cell structure

The PageViewController, PageCell, all the view controllers and all the table cells are directly based on the code I presented in UITableView construction, drawing and management.

A CheckmarkCell that self-manages radio button style selection

It's strongly reliant on the PageViewController and PageCell classes but the CheckmarkCell shows an easy way (easy for the rest of the program) to manage a section in a table where only one row can be selected.

Forward geocoding using Google's Maps API

The locationForAddress:receiver: method in LocationsController performs an XML request on Googles Maps API to forward geocode addresses into longitude and latitude (the response is handled in mapsResponseReceived:). Again: you'll need your own Maps API Key to make this work.

Conclusion

Download the complete project associated with this post: FuelView.zip (330kb).

Note: the code is all freely available under a zlib-style license but this license does not extend to the other assets. You may not use the icons or application name in your own programs.

The app presented in this post, FuelView, is freely available on the Australian App Store.

I did this rewrite of FuelView for three reasons:

I hadn't written any code at work for a week or two — I needed to scratch my codemonkey itch with a few hours of actual programming instead of meetings and documentation.
Preparing code like this for my blog motivates me to review my reusable classes and make them more presentable.
I'm often asked to show an iOS program that pulls data from an RSS feed.

The first two points are entirely for my own purposes and went fine, thanks.

On the third point — this is definitely code that pulls from an RSS feed. I hope the scale of the program doesn't make it hard to see how the basics work. In addition to RSS feed handling though, there's lot of other code here so I hope there's something here for programmers at a range of different skill levels.

VoodooPad 5.0 Released

2012-04-21T19:47:19+00:00

VoodooPad 5.0 is finally out.

You can read about my favorite new features on the FM Blog, and you can download VoodooPad 5 from the VoodooPad website.

It feels really really good to finally release this; VP5 was one of the most difficult releases I've ever done. So much internally has changed, and combined with VP for iOS 2.0 being released at the same time- I'm surprised I didn't kill myself.

Even though Acorn brings in the lion's share of my revenues for Flying Meat (over 90%), I still love using and working on VoodooPad. It works like I do, and it allows me to squirrel away thoughts and info and write my documentation and everything in it. If you're a long time VoodooPad geek, I think you're really going to like this update.

Forbes: It's Time to End the Drug War

2012-04-20T18:49:45+00:00

Forbes: It's Time to End the Drug War:

"April 20 is the counter-culture “holiday” on which lots and lots of people come together to advocate marijuana legalization (or just get high). Should drugs—especially marijuana—be legal? The answer is “yes.” Immediately. Without hesitation. Do not pass Go. Do not collect $200 seized in a civil asset forfeiture. The war on drugs has been a dismal failure. It’s high time to end prohibition. Even if you aren’t willing to go whole-hog and legalize all drugs, at the very least we should legalize marijuana."

I'm tempted to quote the whole (relatively short) article since it touches on just about every reason I support full legalization of marijuana.

Planet Cocoa

The Talk Show With John Gruber

Carlos Garcia Campos is now a WebKit reviewer!

Last week in WebKit: Input padding, 8-bit canvas and CSS Variables

Announcing Skyscraper

WWDC 2012 Preparation

MarsEdit 3.5.3: Mea Culpa

Friday Q&amp;A 2012-05-18: A Tour of PLWeakCompatibility: Part I

MarsEdit 3.5.2: Character Count

Levi Weintraub is a WebKit Reviewer

Testing Pagesmith Footnotes

Quick VoodooPad 5 Postmortem

Unit Testing with Core Data

Testing Environment

Quickly Setting up Tests

Testing Frameworks

SenTest, OCUnit, GHUnit

Kiwi, Cedar

Supporting Xcode’s Unit Test Support

A Test Case

Conclusion

Compiling Image Resources into a Static Library

The Image Resources

The Template

The Shell Script

Project Setup

Permanently Unhide Library

Last week in WebKit: Tab sizing and strings for IndexedDB

The Sandbox’s Big Red Button

Illuminate 1.2 Overhauls the Window Switching UI

Last weeks in WebKit: sub-pixel layout and seamless iframes

MarsEdit 3.5.1: Tying Up Loose Ends

Solving Simulator Bootstrap Errors

Friday Q&amp;A 2012-05-04: PLCrashReporter and Unwinding the Stack With DWARF, Part 2

RubyMotion brings serious Ruby development to the iOS world

Alexis Menard is a WebKit Reviewer!

Friday Q&amp;A 2012-04-27: PLCrashReporter and Unwinding the Stack With DWARF

Last week in WebKit: The Contributors Meeting and datalists

Abhishek Arya is now a WebKit reviewer!

SkyDrive

An RSS-feed and location-based iOS application

Introduction

Useful code in this post

About FuelView

Deceptive complexity

User location issues

Station location issues

Custom drawing

The real design of the program

Initial design of the program

First implementation iteration

Second design iteration

Second implementation iteration

Design Mistake #1

Third implementation iteration

Fourth implementation iteration

Fifth implementation iteration

Design Mistake #2

So where is all the "useful code"?

Conclusion

VoodooPad 5.0 Released

Forbes: It's Time to End the Drug War

Friday Q&A 2012-05-18: A Tour of PLWeakCompatibility: Part I

Friday Q&A 2012-05-04: PLCrashReporter and Unwinding the Stack With DWARF, Part 2

Friday Q&A 2012-04-27: PLCrashReporter and Unwinding the Stack With DWARF