SAN FRANCISCO, CA Collin Donnell wants app developers to learn from his mistakes.
Donnell, a full-time iOS developer since 2008 whose app credits include Pinbook for Pinboard, shared some tips to a packed room at AltWWDC, which we have been all over like an snuggle iPad case. He divided them into practical and philosophical, but they sort of blend together.
Here are some of his main pointers:
- Slow down in the beginning.
Think a lot more before you start and design the code first.
“As coders, we want to be pressing the buttons right from the beginning, but that’s not always the best approach.”
He recommends going to the drawing board with OmniGraffle or a mind mapping app such as Mind Node to get your ideas down before you start typing. “Designing the code provides a roadmap, that way you can see where bottlenecks are up front. Often you’re making same mistakes and looking at it before you start can sometimes prevent that.”
- If you want fast, make sure you’re test driving a Ferrari, not a Fiat.
Donnell admits to being a “pretty naive” when testing downloading and parsing data for Pinbook, a pin board whose API works a bit like Delicious. It seemed fast enough when he tried it on his own 300 or so bookmarks, but as it turned out, heavy users had more like 30,000 or 40,000 bookmarks. The app definitely wasn’t going to be useful if it took 10 minutes to synch.
- If you need high performance don’t be afraid to take a different direction, try something a little a harder or learn something.
He needed to get that lag time down from a leisurely seven minutes to a few speedy seconds, and the way to go ended up requiring a change to LibXML streaming SAX parser, which can download as it parses. The other speed enhancer was to figure out a way to fetch objects that have been updated without a fetch request while parsing. The lesson was: however much caching you have to do upfront, it will always be faster than a bunch of fetch requests. Getting a change signature would tell if something had changed and one fetch request with core data would do it.
“I didn’t know what was going to work and there wasn’t a lot of documentation. That was a hard edge for me to bump up against,” he said. “But if you’re not into it because hard things are fun, maybe it’s not for you.”
- Google may be your best friend
Donnell swears by this method for performance issues, especially when he’s been handed an app that someone else developed.
First load the app in instruments, then tweak the settings so it shows you the reverse call tree. At that point, you have an idea what’s causing the issue. Then Donnell says he pastes that into Google, adding in the word “slow” after. “You’d be surprised how many times someone has written a really detailed blog post explaining why it’s faster to turn it into an NSData and get the range of the comparison there” and voila’, your sluggish app is now back on track.
“We all like to write blog posts about all the fun things we discover,” he said, so harness that. On the flip side: help those who come after you by sharing the cool thing you found out.
- Six degrees of Kevin Bacon is fun at a party, but not for your code
Any time you can, favor a more direct connection over a less direct one, so you can follow the path of the code from component to component. And keep those components as small as possible, so you can pull it apart to speed things up. “If writing a delegate is more typing but I know it’s the better thing to do, that’s what I’m going to do…When I do something less direct, it ends up creating problems. You can’t figure out why there are six degrees of Kevin Bacon sending out a notification” and you’re stuck.
“I’m not smart enough to write code that bad. To me, bad code that doesn’t perform well is usually complicated code, so I usually keep it simple. If I were smarter or had a computer science degree I’d probably be better at writing stuff that performed worse.”
