Recent versions of Xcode have been a lot better. I’m not sure when they really improved, but in the most recent build of Xcode they take only a split second. So far, they seem reliable. And they work by storing the source in a private git repository, so they’re pretty efficient, too. This does not affect your real git repository, even if you’re using git. This is entirely separate, deep in Xcode’s private directory tree deep in your home folder.

Xcode can run a behaviour when a build succeeds. I noticed a few days ago that there’s also an option to Create snapshot.

This means that every time my project builds successfully, a snapshot is created. The snapshots are small, basically containing only the changes since the last build. I expect I can leave this on basically forever without running out of disk space.

I commit to git many times during the course of the day, but occasionally I’ll be in a refactor and I won’t be committing every time the project builds. I’ll make a few changes, build and fix any errors, make a few more changes. I’ll keep this up several times, until I’ve made the full refactor I want. Only then will I fully test what I’ve done and commit.

Sometimes I’ll make the wrong change, and break the build in ways I can’t easily fix. At that point, I either need to struggle my way out of the errors I’ve introduced or abandon all the changes I’ve made. Yes, I could commit to git every time. But the smaller each individual change is, the less likely I am to bother.

In my defence, I still think the way Xcode uses snapshots by default is useless. They’re offered before major but atomic changes, which is right after I’ve committed to my source control repository manually.

But these continuous snapshots are another matter. This means I can back out of any particular change back to the previous working code without losing all the changes so far in what I consider the full, atomic refactor.

I’m thrilled this feature exists, and I’ll be using it from now on. I think you should give it a try, too. Even if you commit to your source control system constantly, this will make commits you won’t think to, and without any action on your part.

I’ve heard that this isn’t real GPS or that it’s somehow inferior to real GPS. AGPS is actually superior to “real” GPS. However, there are ways the iPhone is also inferior to a standalone navigational GPS like a Garmin or Tom Tom. I’m going to explain the differences between them.

Positioning

The iPhone includes a regular GPS receiver, just like your standalone GPS. The “assisted” part means the iPhone is able to get a quick lock based on other data sources, such as nearby cell phone towers or WiFi networks.

I’m not going to try to write an explanation of this. There’s a great article on this in Macworld by Glenn Fleishman, “How the iPhone knows where you are,” which you should read. He’s a journalist who specializes in wireless technologies, and anything I could write on that subject would fail to measure up to his writing.

But I can summarize that article for you in one paragraph, if you didn’t bother to read it:

Because the iPhone has a GPS radio and these other data sources, it’s quicker at finding your location than a standalone navigational GPS.

Your iPhone does this without sacrificing final accuracy, but may give you several approximations along the way. (These are times a real GPS would still be trying to figure out where you are.) This is simplifying a little; the iPhone needs to conserve battery more than your standalone GPS. If you’re not actually using Maps or some other application that needs pinpoint accuracy, it probably powers down the GPS and uses whatever radios it has powered up to do approximate positioning rather than the most accurate positioning it’s capable of. But when you need accurate positioning, it’s there.

Maps

So why do people think the iPhone’s GPS isn’t a real GPS? It’s because of the one way the iPhone is weaker than your standalone GPS. As shipped by Apple, the iPhone is completely dependent on the Internet for map tile data.

That means that without a data signal, whether WiFi or 3G, the iPhone is unable to show you a map. You end up with a screen like this:

From this, you might conclude that without a data connection your iPhone isn’t very good as a navigational tool. You’d be right about that! But you might also conclude that the iPhone doesn’t know where you are. In fact, it knows where you are. It just isn’t able to put it on a map, because it doesn’t actually have a map of the area.

This is where standalone GPS devices are better. Because they don’t have the extra radios that the iPhone has, they can’t download map data from the Internet. Instead, a standalone GPS includes map data on the device. Storing an entire country’s (or even an entire continent’s) map data takes a lot of space, so it’s often rendered more crudely than the iPhone’s maps.

Imagine drawing a map for a friend to get to your house. You know which road they’ll be coming on, and you know where they’re trying to go. You can fill in the roads they need to pay attention to from memory, and mark turns and the destination. This is how a standalone GPS works, except that if it’s up-to-date it knows all the roads and can quickly draw everything quickly and to scale. It’s rendered using just its memory, without the aid of a 3G or WiFi network.

The iPhone’s maps, on the other hand, are from the cloud. The iPhone basically asks for a graphical map from the cloud, with the location and zoom it’s interested in. The image the cloud returns can be beautifully rendered and completely up-to-date, but without the cloud, the iPhone can’t get anything.

But what if your iPhone did have map data on device? Then it would be able to render maps without a data connection AND get a fix faster than a real standalone GPS. This is where the App Store comes in to play. Tom Tom and Garmin both sell apps that include map data. When running one of these apps, the iPhone is able to find its location faster than a standalone GPS. However, even without a connection to the Internet, the app is able to provide a map.

Turn-by-turn navigation

If you’ve reached this point, you’re probably wondering why the iPhone can’t do turn-by-turn navigation. It’s a fair question. The answer is complicated, but boils down simply: Apple does not provide the map data. Instead, Apple’s map display uses data provided by Google. And Google does not allow Apple to use that map data for turn-by-turn navigation. Apple, in turn, does not allow iPhone developers to submit turn-by-turn navigation apps that use the iPhone’s map system.

So why can some Android phones provide turn-by-turn navigation? Google allows it.

This is why any turn-by-turn navigation app is going to require its own map data, rather than working off the cloud when it’s available. There’s been a few hints that Apple may switch to their own data at some point, but it hasn’t happened yet. Being dependent on a competitor interested in keeping your device inferior isn’t a good position to be in, even if the reasoning has nothing to do with competition.

Conclusion

The iPhone’s GPS us very good. Without extra software, however, iPhone navigation is entirely dependent on the Internet. But you can see maps as long as the iPhone can reach the cloud. You can download software so you can see maps while away from the cloud. And any photo you take, even while away from the cloud, will still be tagged with the location of the iPhone.

The iPhone makes its connection to the cloud a strength, whereas standalone GPS units have made the lack of a radio their strength. It’s a complicated tradeoff. Saying the iPhone does not have “real” GPS or that AGPS is not “real”, though, is inaccurate.

This soon after my post on Steve Jobs, I’m unable to write much on the subject. But the C programming language was a major invention in the history of computers, and a significant step in the evolution of computers from academia and processing centres to programs for the real world.

So why am I choked up about his death? Because I love the man for what he accomplished, and how he’s changed the world.

Way back in elementary school, I used an Apple //e. I moved Logo’s turtle around on the screen. I discovered something odd: being able to understand that computers were predictable machines, rather than mysteries had separated me. There are an infinite number of things others can do better than I. Other kids could run, they could play team sports and not let down their team. But this, I could do. But what use was it? Computers were only good at being computers. FORWARD 10. RIGHT 45. Repeat 8 times, it was a stop sign.

I learned BASIC and Pascal, but on some level I was still drawing stop signs. I was solving problems no one had.

Around age nine or ten, I was at a school looking at various displays. Most were uninteresting. But there was an original beige Macintosh, running MacPaint.

The Macintosh was something else entirely. That was something useful. I had only a few minutes with it. I moved the mouse about, watching the cursor. I clicked a few things; I think I doodled a bit with the pencil, typed some text, and used the eraser. It made sense to me. More than that, it dawned on me that computers could be things other than a computer. The complexity behind it was boggling, but someone had solved it. Therefore, it was solvable. It wasn’t actually magic, it just felt like it. I didn’t know it at the time, but Steve Jobs had made that experience happen. He didn’t write the code, and exactly how much of the design was his I’ll never know. Many talented individuals had brought that experience into being. But he drove the team, and he pushed the vision.

It would be several more years before my next encounter with the Macintosh, but something had changed for me. I knew a bit about programming already, but now I wanted to solve real problems for real people.

I practiced for years, and I impressed some people, and ended up with a job programming computers. And I enjoyed that job, and I enjoyed what we were building, but it wasn’t what I yearned to build. It wasn’t accessible to enough people. It was still hard-to-hit buttons, activated by sliding a cursor around the screen using a plastic box.

It turns out that computers, even the Macintosh, were too complex. It was tough to master the indirectness of the interface. For a time, I smugly assumed I was smarter than the people who couldn’t get this, but that wasn’t the case at all. If anything, just the opposite: these machines were far more hostile than I was willing to admit. I couldn’t see the problems in front of me.

There was Palm. They made a hesitant half-step in the right direction, but it didn’t last. I knew we were going backwards again, but I didn’t know how or why.

Years passed. And finally, the iPhone. In the iPhone, you could see at last the future, what Apple intended for the next generation. Even if it was just a small, 3.5″ cut of it. Again, that was Steve Jobs. Not solely responsible. I don’t even know that it was his idea. But either way, he owned that idea. He nurtured it, he cultured it, and he grew it. He turned complex computers and crappy phones into something entirely new.

But I think you could also see echoes of the past: What Apple had wanted to produce with the Macintosh, but been unable to.

A few years later, we got a bigger slice of the future with the iPad. The iPad does not represent finished by any means, but I believe it is the realization of what Apple truly had in mind with the original Macintosh, and an extension of what they tried to achieve with the iPhone. It’s more than a computer — so much immeasurably more — by being less than a computer. And, again, Steve Jobs was responsible. Not solely, of course. But in the same sense that had it gone wrong, one person would be to blame, if one person must be given credit that person is Steve Jobs.

And along they way, he reinvented the music industry. And he’d have reinvented both television and movies for the better, too, had the existing powers in those industries been more eager to follow.

Through demonstration, Steve Jobs had taught me a few things:

• Great products are worth using, so they’re worth building.
• Great things can achieved, even under pressure from others who don’t see the same future.
• Greatness is revolutionary, but does not ignore what’s gone before.
• It’s okay to not achieve perfection. Producing something amazing is good enough.
• Having achieved something amazing, there’s something more amazing just ahead.
• True greatness means the result is not just easy to use, but unbelievable easy. Magical, even.

There are thousands of developers in the world who’ve learned these same lessons. Many of them learned before me. Some of them learned from different sources. But the entire industry has been influenced by the revolutionary evolution of computing from Apple and Steve Jobs. We make up a small part of his legacy. Part of our job is to use these lessons to build magic. The greater part is to inspire others to build magic.

Thank you, Mr. Jobs. Tomorrow, the temptation will be to say the sun rises on a world with less magic. But that’s only true if we don’t create more of our own.

Me: Yeah?

Xcode: You want to enable snapshots yet?

Me: No.

Xcode: I’m just asking.

Me: No.

Xcode: They’re good for you, you know.

Me: I’m sure they are, but see, I’ve already backed up my project. In fact, I checked it all into source control. You were there, right?

Xcode: Yeah, but can I enable snapshots? Please?

Me: No. Stop asking.

Xcode: I’ve caught you at a bad time.

Me: That’s not it. I don’t actually want snapshots. They’re redundant, and frankly a bit stupid. It makes me feel like you don’t respect me enough to make my own backups, you know?

Xcode: Oh. I can see that. I’ll ask again later, then.

After a couple years, I’ve come to adopt some very simple rules for memory management.

Concepts

The first step is to pick up a few concepts that will help you as you code.

• Be lazy in memory management. Rely on the compiler to do everything it possibly can. The compiler can synthesize property setters that handle memory management according to the rules you set. Rely on this.
• Ownership. Think in terms of ownership, rather than reference counting. Thinking in terms of ownership makes problems and solutions obvious. Thinking in terms of ownership will help you keep in mind the why of what you’re doing, rather than the what. After you’ve got a good grasp of why, the what becomes obvious.
• Protect your objects. Own any object that you want to keep around as long as self is around.
• Avoid circular references. Never own an object that could own self. This means never owning self‘s delegate or data source.

Practical guidelines

But how does this translate to code? There’s a few specific and concrete things you can do to make this easier on yourself:

• Use properties to centralize memory management rules. Use @property to establish the rules for memory management of an instance variable. (And @synthesize your properties to underscored instance variables to prevent naming conflicts.)
• Pick the right memory management rule. Use retain properties as your default. Data sources, delegates or other objects that might own the object you’re working in should be assign properties instead of retain.
• Rely on the centralized memory management rules. Use property set notation (self.foo = nil;) or the property setter ([self setFoo: nil];) everywhere you change the property’s value except in the property’s setter (if you need one) In this way, you rely on the retain or assign in your @property to specify the memory management. If you need to use retain, release or autorelease outside of a setter you’re doing too much. (And, also, you’ll have more work to do to be compatible with ARC.)
• Avoid being called once deallocated. In dealloc, nil any delegates you’ve set to self. (This eliminates the possibility that the object will survive longer than self and try to send messages to self.)
• Protect your private bits, too. Don’t use raw instance variables in objects requiring memory management. Use anonymous properties.
• Containers own their contents. You not only don’t need to but must not try to manage memory in a system container. An NSArray will send a retain to objects that are added to it, and a release to objects as they are removed. If you try to manually retain and release objects, you’ll miss a case.
• Verify. Analyze your code frequently. And profile your code early and often for leaks.

I searched for this for a while and found a few wrong and complicated answers.

One way is to use the composite cable instead of the component cable. Your Wii came with a composite cable, and if you’re only using 480i the component cable does nothing extra for you anyway.

But what if you can’t find the composite cable? This was the case for me, after my move. The answer is ridiculously simple:

1. Unplug the component cable on the Wii end.
2. If the Wii is already on, press the Reset button. If it was off, turn it on.
3. Wait a couple seconds. The Wii will notice there’s no component cable plugged in, and switch to 480i mode.
4. Plug the component cable back into the Wii.

Here’s a common operation for me: Split a list into sublists based on some piece of data changing within a loop. When the loop is over, dump whatever’s left into another sublist.

Without blocks, this looks like this:

- (NSArray *)splitArray: (NSArray *)array
               valueKey: (NSString *)valueKey
               labelKey: (NSString *)labelKey;
{
    id sections = [NSMutableArray array];
    id sectionValue = nil;
    id sectionRecords = [NSMutableArray array];
    
    for (id record in array) {
        id recordValue = [record objectForKey: valueKey];
        if ( ![recordValue isEqual: sectionValue] ) {
            if ( [sectionRecords count] ) {
                id lastRecord = [sectionRecords objectAtIndex: 0];
                id label = [lastRecord objectForKey: labelKey];
                id section = [NSDictionary dictionaryWithObjectsAndKeys:
                              [NSArray arrayWithArray: sectionRecords], @"Records",
                              label, @"Name",
                              nil];
                [sections addObject: section];
                [sectionRecords removeAllObjects];
            }
            sectionValue = recordValue;
        }
        [sectionRecords addObject: record];
    }
    if ( [sectionRecords count] ) {
        id lastRecord = [sectionRecords objectAtIndex: 0];
        id label = [lastRecord objectForKey: labelKey];
        id section = [NSDictionary dictionaryWithObjectsAndKeys:
                      [NSArray arrayWithArray: sectionRecords], @"Records",
                      label, @"Name",
                      nil];
        [sections addObject: section];
        [sectionRecords removeAllObjects];
    }
    
    return [NSArray arrayWithArray: sections];
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

- (NSArray *)splitArray: (NSArray *)array
               valueKey: (NSString *)valueKey
               labelKey: (NSString *)labelKey;
{
    id sections = [NSMutableArray array];
    id sectionValue = nil;
    id sectionRecords = [NSMutableArray array];
    
    for (id record in array) {
        id recordValue = [record objectForKey: valueKey];
        if ( ![recordValue isEqual: sectionValue] ) {
            if ( [sectionRecords count] ) {
                id lastRecord = [sectionRecords objectAtIndex: 0];
                id label = [lastRecord objectForKey: labelKey];
                id section = [NSDictionary dictionaryWithObjectsAndKeys:
                              [NSArray arrayWithArray: sectionRecords], @"Records",
                              label, @"Name",
                              nil];
                [sections addObject: section];
                [sectionRecords removeAllObjects];
            }
            sectionValue = recordValue;
        }
        [sectionRecords addObject: record];
    }
    if ( [sectionRecords count] ) {
        id lastRecord = [sectionRecords objectAtIndex: 0];
        id label = [lastRecord objectForKey: labelKey];
        id section = [NSDictionary dictionaryWithObjectsAndKeys:
                      [NSArray arrayWithArray: sectionRecords], @"Records",
                      label, @"Name",
                      nil];
        [sections addObject: section];
        [sectionRecords removeAllObjects];
    }
    
    return [NSArray arrayWithArray: sections];
}

The redundancy makes this hard to maintain, but I don’t really want to split it off into a different function. That means passing all the parameters in to the second function.

But wait! Can we use blocks to clean this up? Yes, we can! We can define the code we want to execute in a block, then use the block as necessary within the function.

With blocks, the code looks like this:

- (NSArray *)splitArray: (NSArray *)array
               valueKey: (NSString *)valueKey
               labelKey: (NSString *)labelKey;
{
    id sections = [NSMutableArray array];
    id sectionValue = nil;
    id sectionRecords = [NSMutableArray array];
    
    dispatch_block_t split = ^{
        if ( [sectionRecords count] ) {
            id lastRecord = [sectionRecords objectAtIndex: 0];
            id label = [lastRecord objectForKey: labelKey];
            id section = [NSDictionary dictionaryWithObjectsAndKeys:
                          [NSArray arrayWithArray: sectionRecords], @"Records",
                          label, @"Name",
                          nil];
            [sections addObject: section];
            [sectionRecords removeAllObjects];
        }
    };
    
    for (id record in array) {
        id recordValue = [record objectForKey: valueKey];
        if ( ![recordValue isEqual: sectionValue] ) {
            split();
            sectionValue = recordValue;
        }
        [sectionRecords addObject: record];
    }
    split();
    
    return [NSArray arrayWithArray: sections];
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

- (NSArray *)splitArray: (NSArray *)array
               valueKey: (NSString *)valueKey
               labelKey: (NSString *)labelKey;
{
    id sections = [NSMutableArray array];
    id sectionValue = nil;
    id sectionRecords = [NSMutableArray array];
    
    dispatch_block_t split = ^{
        if ( [sectionRecords count] ) {
            id lastRecord = [sectionRecords objectAtIndex: 0];
            id label = [lastRecord objectForKey: labelKey];
            id section = [NSDictionary dictionaryWithObjectsAndKeys:
                          [NSArray arrayWithArray: sectionRecords], @"Records",
                          label, @"Name",
                          nil];
            [sections addObject: section];
            [sectionRecords removeAllObjects];
        }
    };
    
    for (id record in array) {
        id recordValue = [record objectForKey: valueKey];
        if ( ![recordValue isEqual: sectionValue] ) {
            split();
            sectionValue = recordValue;
        }
        [sectionRecords addObject: record];
    }
    split();
    
    return [NSArray arrayWithArray: sections];
}

Since the block by default has read-only access to any variable it wants as long as it’s in scope, there’s no need to pass parameters into the block.

As I said in the introduction, blocks are a lot more powerful than this. See Apple’s Block Programming Topics for more about that. However, they’re a great tool for small problems as well that you shouldn’t overlook.

Hint: Objective-C doesn’t follow the C++ pattern. You probably want foo(void).