I think the true turning point started at around Xcode 3.0. Xcode is now quite simply the best IDE I’ve ever used. Most all of my complaints have been solved over time, and admittedly I’ve figured out a few things along the way that made me finally get how it all works. I thought I’d point out a few of the things that made me realize that Xcode rocks. If you’re an Xcode aficionado, I’m sure you’ll already know these.

Fast Compilations

It’s just simply super fast to compile. On my last project, I was able to clean in about 5 minutes on an iMac. In Visual Studio on my quad-core PC it took like 20 minutes clean or not. Granted it has more files to build, but wow. Slow. To the point that any time you realized you’d have to build Windows and you weren’t at top-of-tree you were like “there goes a half hour”. These days, doing iPhone apps, my app at work takes about 20 seconds to clean build. And more like about 2 second to build/link and fire up the simulator for a quick change.

Settings That Are Useful

Setting project settings used to frustrate me on Xcode. You have project settings, and then you have target settings, and it just seemed like too much. I’ve finally gotten to get the how and the why around this and I understand it all now. Recently though I had to mess with settings, and I think if it weren’t for two features, I’d still be trying to find and set the settings correctly:

• ability to filter settings. Type ‘install’ in the search box and get all settings having to do with install paths, etc. Avoids having to scan a big giant list of options.
• the fact that Xcode actually shows you the computed paths. If you click something it might be generated from variables, etc. but once it’s commited you see the path it’s going to use. I can’t begin to tell me how much time that saved me the other day when I was wondering why something wasn’t working. This was always a source of frustration in Visual Studio for me.

They might not seem like OMG features on the surface, but the time it saved makes me say OMG anyway.

Code Completion

The code completion feature of Xcode used to be frustrating to use, but in recent releases it works extremely well. It’s smart completion combined with text macros completing code fragments like if statements, etc. makes it damn quick to write code. And furthermore, you can adjust the templates of the generated code to match your code style either by creating your own text macros or by setting some defaults on the command line by setting the XCCodeSenseFormattingOptions property. For example, I like open braces of a block to always be on the next line. It help readability for me and it also helps editing a bit. Just setting a few options using that default and you can get the Xcode text completion to do your bidding.

Syntax-Aware Editing

I love the syntax-aware editing, particularly with cut and paste. Often times I’ll even cut and paste a section of code just to make it fix it up (maybe there’s another way but I’m too lazy to find out). As mentioned above, you can tweak some defaults if the code style doesn’t please you. But it’s nice to type a ‘}’ and have it put it where it belongs. Or split a call to an objective-c method across multiple lines and have it line everything up for you at the colons. One other thing that I like is when you perhaps take a method and add another call to it. For example, let’s say you typed: [foo retain] and now you want to add autorelease. Just follow it up with autorelease] and Xcode will put the starting [ in the right place. It doesn’t always get it right, but in most cases it does. Very nice, as it is certainly a bit annoying to otherwise have to go back to the start yourself just to add a starting [, which has always been one of my nits about obj-c syntax. I like it when the tools make my nits a non-issue.

Refactoring Tools

The refactoring tools that Xcode provides are really nice. The current transformations that are supported are definitely helpful at times, and I hope they continue to think of more goodness they can add here.

Slipstream Drive

With all the above features — in general lots of ‘little things’ that make things just work — Xcode allows me to write code incredibly fast. I feel like code just flows out of my fingers and the IDE just knows what to do with it. Occasionally though, I’ll long for a couple of smaller niceties from Visual Studio, or perhaps the code completion isn’t quite doing what I want, and it kind of knocks me out of slipstream drive. I’ve recently filed a couple of enhancement requests for them. We’ll see what comes of them, but if they did manage to get them in, I would truly have an all-powerful programming tool at my fingertips.

I’m sure there’s more things (data modeling, etc.) but I haven’t used all those features. My bliss these days comes from just being able to sit down and get incredible amounts of work done in a relatively small amount of time. To me, that’s what makes Xcode so amazing and pleasurable to use.

Bet you didn’t expect to hear me ever say that, now did you?

As of this week, however, I’m now working in the iPhone group, back in my old stomping ground of building 2. It’s so weird to be back there. It’s been reconfigured a bit since I was there last, but otherwise, it’s the same old place I remember. I was even visiting some old co-workers of mine and noted that my original office was right across the hall. That was (gulp) just over 13 years ago! I think the building was pretty new at the time too (completed in 1993 or so?).

So yeah, I’m in the same building (different floor), and seeing a lot of the old people I used to know. But there are way more new faces than OGs. It all the same, yet different.

But the most important thing in all of this is this: now that I’ve just about settled in I’m starting to have some serious fun. I haven’t looked forward to doing my work this much since… probably since the last time I worked there. Yes, I’ve done interesting stuff and had fun times in between, but this is a whole different level.

I’m home again!

I do want to take this opportunity to thank the Tapulous guys for their open, honest dealings with me and this situation, as well as their willingness to hand it back to me.

When the app store opened, I downloaded several Twitter clients. Each was interesting in their own right, but I couldn’t use any of them because of one reason: the scrolling performance. I didn’t get why everyone’s scrolling was not as smooth as any of the built-in iPhone applications. For me, it made the apps frustrating to use, to the point that I just never used them.

A Simple Proof

As an experiment, I wanted to prove that I could make something that scrolled as good as the Apple-made stuff. I had already done other samples using the Twitter API as part of Blueprint at Yahoo! as well as in a Widget for Konfabulator I worked on but never finished. So I figured it would be fairly quick to throw something together.

I wrote a simple web fetcher and then did a rudimentary list. Originally, it was completely a navigation based app. You’d get a list of items such as ‘With Friends’, ‘History’, etc. and click those and get the listing of 20 tweets (the default that you get with the API). It was at this point that I started messing with getting the scrolling fast. In the end, it was smooth as silk. But I also didn’t have features such as the current balloon look and clickable links and @names.

The clickable links took me quite a while to get to work. I spent much time working on line breaking and making sure it was as efficient as it could be, using Instruments to find and eliminate bottlenecks.

After that, I had something that could line break beautifully and yet it still scrolled incredibly fast. Implementing the balloon look however, did slow it down a bit, but again I spent a lot of time trying to cache and get things to the point that you see it today.

But even after all that, there was still tons to do. I mean, it was really just something to prove to myself I could do this. But at this point, I realized I was onto something real here and could really build something exciting. But there were plenty of competition out there. Why build another Twitter app? I wasn’t really sure, but I kept going anyway to see where it took me. By the time I got to the end, I knew I had something big on my hands.

Making It Real

For the next few weeks I worked pretty much 24/7 getting things to cache properly, push things off onto threads as much as possible, use a real database, etc. and make sure that things just worked correctly. Despite the simplicity of what Twitter is, making an application to really behave properly and ensure that things are always as you expect is pretty darn hard. Even something as ’simple’ as clicking a tweet and then iterating your tweets with the up and down arrows in the upper right was interesting. Not because of the iteration of the items, but because you now have yet another view that needs to be aware of state changes in the application. For example, if you favorite something, I needed to make sure that if it was showing elsewhere in the UI the change was reflected. Good times.

I also rewrote certain sections more than once to get things right. The database for example, was originally just a plist, but the more complicated the UI became, the more necessary SQLite was. And that had to be threaded for even more fun. I had also originally started with MGTwitterEngine, but ended up writing my own engine for two reasons:

1. design-wise, MGTwitterEngine didn’t fit with what I needed to to (it was too centralized, I needed many delegates, not just one).
2. I decided to use JSON instead of XML to try to keep the data smaller and simpler to parse. XML really is a pain to deal with.

And since I didn’t find a JSON parser that seemed to be small enough and simple enough to integrate, I wrote one. Admittedly, it’s been something I’ve wanted to do for a while. I’m sure somewhere out there there’s a JSON parser that would have fit the bill, but I didn’t find it in my cursory search of the interweb tubes.

Details, Details

You know all those ’standard’ form controls you see in all the Apple applications? Yeah, they ain’t standard. So a bit of time was put into creating my own version of those constructs and making them look and behave as closely to the Apple stuff as I could.

I also needed to handle image uploads and tweet compositions, loading followers so you can help address messages, doing the first run screen, etc. Lots of little things to make stuff right.

And even after I thought I had everything done, I ended up rewriting the messaging section to what you see today. It originally had inbox and sent like the web site, but one of my beta testers suggested a threaded view. At first I was like “man, that’s going to take forever”, but it only took me a day or two to get right. Most of my time in fact was spent drawing the stupid balloons to try and match the SMS app, only this time in delicious purple!

That was the making of 1.0. Right before I handed it over to Tapulous, I also added:

• Flickr upload support
• Re-tweet functionality
• Ability to quit during writing a tweet and come back to where you left off the next time you launch.

I know there are several other thing that people want. I originally did envision adding things like multiple account support, etc. and I see that people also really want to have it save where you last were and not jump to the top when you load tweets. That one actually came up during development and there seemed to be strong arguments on both sides. So I left it as it was, but perhaps Tapulous can add that as an option.

People also have been asking for the ability to tap the status bar and have it jump to the top, but it already does that (the iPhone frameworks do it for you in fact). Perhaps there’s a bug in there that stops it from working sometimes.

So that’s my story, and I’m sticking to it. The best part for me has been seeing people’s comments on Twitter which echo exactly those attributes I held dear in its inception:

• UI speed. It tries its best to not get ’stuck’. It only now gets stuck when it’s loading the table for the first time. I hope.
• Simplicity. It’s not glossy black. It’s just iPhone.
• Power. You can do almost everything the Twitter API allows: follow friends, drill down in a user’s history or followers, search for your favorite terms, etc.

Thanks

I want to thank everyone that helped me test the application and suggested features, etc. This includes Arlo Rose, Rob Marquardt, Karl Adam and Aaron Hurley. These people had much input into the end design. Arlo suggested the use of the Tab Bar over the nav-style interface. Karl caused me to go to threaded messages, Rob and Aaron both suggested many different enhancements to make things more user-friendly and do what you’d expect. You can blame Rob in particular for my adding Flickr upload.

Again, thank you all. It was a great project!

This time I’m working on iTunes instead of the OS group. Definitely a different type of thing than I’m used to — I’m more a framework/API type of guy — but I think it will be fun nonetheless. Especially since I’ll be working with one of my friends that I used to work with there.

Because it’s Apple, I’m under strict agreement not to have any type of side projects, etc. so it was important to find someone to care for Tweetsville from this point forward. It’s too cool of an application to just let it drop. Especially since I just added Flickr upload support and the ability to quit the app while typing a tweet and have it pick up where you left off next time you run the app this week (both should appear in some future release).

Anyway, that’s the close of this short chapter of my life, and the start of a shiny brand new one!

First, it’s been approved for sale! But I haven’t seen it show up and sadly I don’t have a link to it. Read on for why.

The main reason the app was delayed so long coming out is because I had been been trying to figure out exactly what to do with it. I might be in a situation soon that will actually prevent me from being able to maintain the application, so I wanted to see if I could find a good stewart for my baby. I’ve chosen to hand the application over to Tapulous, maker of Tap Tap Revenge, Twinkle, FriendBook, Fortune and Collage, with whom I have a good working relation.

I think this is going to be great for Tweetsville, as they have better resources at their disposal to help support and grow the application. I also think they have some technology which can help Tweetsville be even better than it is. At the same time, there’s some stuff I did for my app that I believe will benefit Tapulous.

There is no plan to have Twinkle and Tweetsville merge. They are to be separate applications with separate audiences. Twinkle is about locality and the Tapulous network, and Tweetsville is purely a Twitter application.

One of the advantages here for users is that there will be choice. There will ultimately be two versions of Tweetsville. The first will be a paid version currently slated for $3.99. The second will come a few weeks later and will be a free ad-supported version.

I’m confident this will move is the best thing for the Tweetsville app as well as users in the long run. You’ll get more choices and better support than I would have been able to provide on my own. I feel the app is in good hands, as I have a great working relationship with Tapulous (I’m actually doing a little work on Twinkle 1.3 these days too).

So look for it to appear in the App Store on Monday the 10th of November!

Update Actually the date is apparently going to be the 12th.

self.opaque = NO;
self.backgroundColor = nil;
self.clearsContextBeforeDrawing = YES;

But all I really needed to do was:

self.backgroundColor = [UIColor clearColor];

Same transparency, and I’m guessing (hoping?) that it might be a bit more efficient (unless of course, the innards look for clear color and effectively do what I used to).

Hey, even if it’s not more efficient, it’s certainly simpler to type and it seems to have the same effect!

Sadly, this is one thing I didn’t figure out on my own, but rather spied in some other sources, but I wanted to throw it out there for ‘all uh yous’.

Before digging into it, I should say this: threads are evil. If you don’t believe this, then I believe you are made of living tissue over metal endoskeleton. You should endeavor to avoid threads at all cost. In most cases, timers are your best friend. Know them. Love them.

Of course, there are times when you need to use threads. I needed to add a few threaded operations to my iPhone application to make sure the UI stayed responsive. On the project at Adobe, we were doing thumbnailing of images, definitely something you don’t want happening on the main thread.

1. Avoid recursive locks

A recursive lock is a lock which allows the same thread that locked it to lock it again. The advantage is that you don’t need to worry about what’s locked and what’s not on any particular thread. They also make it easy to retrofit locks into existing code.

The problem though is they most often end up being used to lock large pieces of code for indeterminate amounts of time. This makes things very coarse-grained. They also lead to issues where if you didn’t unlock the exact right amount of times, you will leave a thread holding the lock forever. It’s very easy for this to happen. And these problems are nearly impossible to find because the lock that was taken is usually very far away from where the hang/deadlock happens later.

Better to use a real honest-to-goodness lock. This means that if a thread tries to lock a lock that’s already, well, locked, you’ll deadlock. This is good. I like this, just as I like crashes. I know, you think I’m crazy, but if you deadlock on your own thread, then you know you just did something bad. Most likely, you’ve called out of a function when locked to another function that ends up needing the same resource.

Most people, when confronted with this, switch to recursive locks. Problem solved, right? Wrong. You’ve just opened yourself up to a world of hurt, mostly due to what I said above. So what do you do? Well, what I typically do is split the function into two. Consider:

// Some public API
void IncrementCounter()
{
    Lock();
    fCounter++;
    Unlock();
}

// Another public API
void MyFunction()
{
    Lock();
    // do some magic that requires us to increment the counter
    IncrementCounter(); // BAD: DEADLOCK!!
    Unlock();
}

So here we have a public function that wants to call another public function, but both of them want to lock. What I end up doing is just creating an internal function.

void IncrementCounter()
{
    Lock();
    IncrementCounterWhileLocked();
    Unlock();
}

void MyFunction()
{
    Lock();
    IncrementCounterWhileLocked();
    Unlock();
}

void IncrementCounterWhileLocked()
{
    fCounter++;
}

That’s it. So basically, put the locks on the outermost (public) layer and do whatever you need to while locked on the internal layer. Yes, it’s more typing, but it’s really clarifies exactly what is going on.

The other thing about non-recursive locks like pthread_mutex is that is also forces the next two points on you, which you probably would want to do anyway.

2. Keep it short and sweet

You should hold your locks for as short a period of time as is necessary or practical. Using a non-recursive lock helps to enforce this rule. This is convenient since contention will be reduced. On the other hand, don’t go insane and lock every little thing. Make your locks coarse-grained enough to avoid many trips to the kernel via locking, but fine-grained enough to know that contention is low between threads so they aren’t running choppily.

3. Call out when locked, go to jail

Never, ever lock a mutex and then call out to some other function (unless it’s some other utility function on the same object that expects the resource to be locked). This is a deadlock waiting to happen, as that callout might end up calling something that also wants that lock. Now you’re deadlocked. Use of recursive locks over large bodies of code almost always makes this a certainty to occur.

So you should never do this:

void MyFunction()
{
    Lock();

    // ... do whatever work ...

    (*fCallback)(); // UNSAFE, could even call MyFunction again!

    // ... more work ...

    Unlock();
}

But instead, do this:

void MyFunction()
{
    Lock();
    // ... do whatever work ...
    Unlock();

    (*fCallback)(); // OK

    Lock();
    // ... more work...
    Unlock();
}

(As a side note, it is fine to use a recursive lock if you follow 2 & 3 religiously and can guarantee correctness, as then the locality of the locks should make things obvious where problem are when there is a problem. But I still prefer non-recursive. It forces you to get it right, and enough can already go wrong with threaded programming.)

My original document also had notes about other topics, but they were more specific to our project. I think the above has universal relevance, however. As I originally mentioned, our project was violation all three rules, but I’m pretty sure the root cause was #1. All other evil tends to stem from there.

I think if you follow these three rules, you’ll take a lot of the guesswork out about what’s locked when, and you’ll find problems immediately (it will just deadlock, which is typically an easy fix). This should allow you to focus on the more important issues and sidestep the nastiness that might otherwise befall you.

I had three goals in mind, in this order:

• Totally responsive, with glassy scrolling.
• Embrace the natural aesthetics of the iPhone user experience.
• Use the full power of the Twitter API.

It’s definitely fast and smooth (though admittedly it could be tweaked a bit more), and it looks like a real honest-to-goodness iPhone application. For whatever reason, I thought it would be ideal to do this app using as many standard (or standard-looking) controls as I could. The less custom stuff the better.

But the real beauty is the fact that I cache as much of your Twitter stream as I can get from the API, coupled with the depth of what you can do with this application. You can see your timeline, do direct messaging, see your favorites, history, and replies. You can also see the latest trends and do searches, including advanced searches. It is without a doubt the most powerful Twitter iPhone application I’ve seen to date. Of course, I’ve had my head in the sand for the past 8 weeks!

Will this application change the world? Hell, no. But I think it will definitely make a dent in the Twitter space. And it was fun, which was really my whole main point of writing it. It’s been a long while since coding was fun.

Even with all it does, there is still other things I’d like to do to it to improve the functionality and ease of use beyond what’s there, but there are only so many hours in the day, and I’m burnt out from coding so much. I need a vacation from my vacation!

The real question is: should I even charge for it? I’m currently thinking no, but man, it might really take off, and then I’ll be missing out. If I don’t charge for it, I will likely make the source publicly available. I’ve already got a subversion repository set up and ready for some sources if I do. Or there’s always code.google.com.

I’m hoping this will get submitted very very soon. My last build seems to be pretty stable, and I’m too paranoid to make any real changes now.

Wow, this would be the first thing I’ve ever written and released like this since… Aaron (if anyone remembers that). Again, wow.

Well yesterday, after having to do that two or three times, I finally figured out a bit of a clue. I was having trouble making xcode see the profile. Turns out, you need to have the current target configuration set to the config you are modifying in the info panel or else it just won’t show up. Made all the difference in the world.

And of course I always restart xcode after installing any profiles. Install, restart xcode, then ensure your target is set to the right config, then edit the config. Booyah!