If I accidentally provide bad XML, I don’t know until my app tries to parse it. That may be some time into its run. If the XML is processed because of a specific user action, I’ve broken that specific user action.

Obviously, I want to test everything in my app before I post it to the iTunes Store. But finding this problem even hours later makes it harder to diagnose and fix. I can detect this error immediately (and fix it right away) by adding a build phase to validate my XML.

I added a run script to my target that does this:

find "${PROJECT_DIR}" -name *.xml -exec xmllint {} \;

See update below.

Xcode will run this script when building my target. It will find all XML files in my project directory, and run xmllint on them. xmllint returns an error if the document is malformed.

I gave this build phase a good name so I can find it easily later, then dragged the script as high in my build phase order as possible to get the results early. This may not actually prevent the project from building, but at least I get a big red error.

This validates all the XML in my project directory. If you have XML you don’t need, you’ll have to do something more complicated:

• Provide a more specific starting path
• Use one of the other variables validate the built .app package instead, or
• Hard code each XML file’s path

Update

This command works better:

find "${PROJECT_DIR}" -name *.xml -print0 | xargs -n 1 -0 xmllint

With this command, the error not only stops Xcode, but Xcode highlights the line that xmllint reports as the offender.

• Don’t include default feeds. I am using your app to read my feeds, not yours. I’m okay with you asking if I want some default feeds, but a clean slate should be at most one click away when I start your app for the first time.
• Don’t make my subscribe to view a feed. I want to see what’s in a feed before I make any decisions about it.
• Don’t make subscribing a big deal. Subscribing should take one click. I’m okay with being able to edit the name or categorize the feed in the preview, but I don’t want to click through any configuration where I have to do anything more than click OK.
• Do not include themes. Themes are a sign of weak design on your part. If you want to customize the appearance, make it attractive. Then grow a backbone and make it the face of your app. Neither you nor I want ten themes that suck.
• Make your text readable. Use a nice font, reasonable contrast, and good line spacing. And I shouldn’t even have to say this, but don’t use full justification.
• Have a useful full screen mode. Include width limiting (see Safari).
• Don’t use Google Reader sync. Stop whoring your customers to Google.

My mind is the part of me that questions things. It’s my inner critic. It does most of the talking in my head. Mostly, it tells me that I can’t do something. This is hard. That’s wrong. You’ve got nothing new to add to this. This is not how I solve problems, though it drives me to find better solutions to problems.

My eyes speak to me, too. This is ugly. How can you keep writing when the font is wrong? There’s a spelling error, go fix it! This is not how I solve problems, though it’s how I see that problems exist.

My creativity flows from something else, the most quiet part of me. It’s actually what I’m using right now to write this. It’s my fingers. It’s not actually my fingers, of course, but it’s the part of my brain that sets my fingers in motion, across a keyboard or across an open page. It’s the part of my brain that, when my mind said I had nothing worthwhile to type today, started typing before deciding what to type. It’s the part of me that tries to draw a face, and doesn’t care that the face looks like something an untalented preschool child might draw. It’s the part of me that produced the first draft of this, spelling errors and crappy fonts and occasional run-on sentence and all.

This is the part of me that I’ve been poor at nurturing in 2011. The part of me that’s been broken. The part of me that my mind has held tightly, that the tiny animal in me has said is worthless.

My mind wants me to stop writing this post, because it has no value. That’s its job, to question things. But when it questions not just my output, but that I am creating at all, it needs to be ignored.

My eyes want me to go change the font so I’m no longer typing in Cochin 17. (Really, Cochin 17? What kind of default is that?) That’s it’s job, to make things beautiful once problems are recognized. But when it wants me to waste time on appearance instead of typing, it needs to be ignored.

Until the words have flowed from my fingers, there must be nothing but my fingers. This is my pledge to myself for the year; to create first, to criticize my creations after they are created rather than before.

My fingers know what they’re doing, and they’re the best part of me.

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.

You may need to scroll down to see the Create snapshot option.

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.