There are pretty much two types of timers with two styles of setting the callback. There is the scheduled timer which adds the timer to a default run loop which will start the timer automatically, and there is the standard timer which must be added to an NSRunLoop (which I won’t cover here). Both types have a variation which can be initialized with an NSInvocation class, which is really a fancier way of setting the callback (target selector). So let’s start with the most basic example of how you would initialize, and use NSTimer.

// Assume this is in a controller class, or somewhere equally useful
 
- (NSTimer)createTimer {
    // Create a managed timer (don't need to add to the run loop!)
    self.timer = [NSTimer scheduledTimerWithTimeInterval:0.5
        target:self selector:@selector(targetMethod:)
        userInfo:nil repeats:YES];
 
    return self.timer;
}
 
- (void)targetMethod:(NSTimer*)timer {
    NSLog(@"targetMethod called!");
}

Now that example will fire the timer as soon as you call createTimer, and trigger the targetMethod until you quit the application or call [self.timer invalidate];. It should be noted that with this method the target HAS to take the timer as an argument.

What if you KNOW you won’t need a repeating timer though? There must be an easier way. Well, there is. Every NSObject class has the method performSelector:withObject:afterDelay: which makes life even easier.

More complete examples on NSTimer can be found in the reference library.

This morning I read an article that pissed me off. It pissed me off because there were parts I agreed with, and it pissed me off because so much of the community agreed with the parts I didn’t. It was also frustrating because I couldn’t quite express just why it frustrated me so much, but now I can. The article made some big statements about app developers, and even bigger assumptions about what consumers want.

I happen to have written some cocoa, and even a few web apps in my time, and frankly, there are downsides on either side of the fence. It’s no doubt that the web has caught up to desktop applications in a pretty big way in the last 3-4 years. There was a time I would have never considered paying for a web application, let alone think of it as replacing a desktop app. Apps like Google docs, and a few productivity apps have proven me wrong.

There are still some good reasons for native apps though, and the sales figures on Apples app store speak for themselves. I think consumers might actually know what they want.

1. Convenience

On the app store, you can buy an application in seconds, and usually for the price of a coffee. On the web, it might mean a sign-up process, and usually involves digging out a credit card or paypal password. There is effort required for something that should be serving you. Pricing is also a part of this. I’d rather pay $1.99 for an app a might only try for a few minutes, than spend $20+ a year for subscription I might have to remember to cancel in a few months. I’d rather throw a dice than make a commitment.

2. Experience

The other aspect is user experience. If I am using iPhone apps, I expect each application to behave in a certain way, and have a certain look. If I see a table view in 5 different apps, I know they are going to behave in the same way. I’m willing to pay a few bucks for that. On the web, you are at the mercy of what the developer thinks UI should behave like. Performance is also a pretty big part of this. I don’t have to wait for UI images, CSS, or javascript to load before I can start using most native apps. It’s usually just there when I want it. I know arguments can be made for local caching, and optimization, but that’s assuming a lot about the skills of the developer, and generally comes as an after thought.

3. Ownership

This is probably my lamest argument of all, but it’s hard to deny it’s importance. I like the feeling that an app is downloaded to my device all tucked away in the filesystem with my preferences in a (mostly) secure location. With a web app, I’m at the mercy of the developer deciding his app isn’t paying the server bills, the network going down, and my personal information being who knows where.

These aren’t significant issues.

I really believe in the web as a platform, but I also think that the line between native apps and “the cloud” is starting to fade. As a developer, the biggest difference is the tools and the delivery. I happen to think that building a native app and maintaining it without the worry of infrastructure would be pretty nice for a change. It can also be a joy to use proprietary tools when they are well thought out, and work when you need them to. The app store is necessary, and so is the web. It’s a great time to be developing for either. Take some time to think about which type of app your customers would want before you begin the bashing.