Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

jgaz

macrumors member
Original poster
Dec 30, 2007
34
4
Colorado
To begin I am a total beginner at programming and maybe overly ambitious.
I am teaching myself Objective-C by trying to build a countdown timer app.

I have gotten the timer working fine but did so by putting all of the timer program into the view controller.

So now I am trying to make it more flexible by creating a timer class so that the view controller is only taking care of the view (if I understand correctly this is the 'correct' way of doing things).

In my timer class have have two public methods that create the NSTimer object (startTimer and resumeTimer)
which calls a private method every second: calculateTimeRemaining that calculates the time remaining and returns it

so my problem is getting the timeRemaining back to view controller so it can update the label every second.

from what I understand and have read there seem to be two ways to go about this. Either create a delegate protocol for the timer class in which the delegate would have to take care of startTimer and resumeTimer or set up a KVO for the timeRemaing object that the view controller could observe.

I have not had any experience doing either of these and am going to play around with both.

I have a few questions concerning them:

Is a KVO even a good idea for this? Will it be reliable/fast enough to get a label updated every second?

Is there some other way to use delegation in which the NSTimer object could still be created in my timer class and still return and updated timeRemaining object every sec?

Should I not pursue either of these and look into some other way of doing this?

Thanks for your help. I really am enjoying experimenting and learning which is why I am not posting any code. Really just looking for some higher level insight into possible ways of accomplishing this.
 
You could also use NSNotifications. Your viewController would listen for the desired notification and the timer object would post it.
 
I would go for Delegates over NSNotifications, NSNotificationCenter is a nice way to make some quick fixes, and it's easy to add it to every view, without having to have delegates set etc.
but this does definitly sounds like a delegate method.
if u assign the delegate to ViewController1.
ANd you assign the method it should send on the delegate on your Timer View.
Your ViewCOntroller should certainly receive the updates.
If it's too much off a haggle, you can send NSNotifications and just add your viewController as a listener, (which is nearly same as KVO, some will kill me for this sentence), but imagene your view just broadcasting like "lolz, i updated timer", and your viewController is a receiver, and he's like, oooh, i received broadcast x, with object x (you can put NSDictionary or pure object with a NSNotification, and then show it in the corresponding receiver method.
but depends.
 
I didn't even think of NSNotification. I have not read the documentation on it yet and just kind of assumed it was for sending message outside of the app to the phones notification center. Obviously I have so much to learn and play with.

I will play with both delegation and NSNotification. I need to learn how to use and implement both if I am going to ever become a competent programmer.

Anything else I should be aware of as I play with this?
 
You can use any of those three strategies to notify a target that something has happened. KVO is probably a little harder to understand than the other two methods.

I don't think it would be bad to have the timer's callback method be in the view controller, rather than in a special timer class. But that's up to you.
 
One way to think about the difference is that KVO is handy when you are interested when variables change. Delegation is handy when you are interested when events happen. It feels more like an event if you are waiting for a certain timer to fire. That would suggest you might want to look at delegation. It can also be a matter of personal preference.

Notifications can be a handy alternative to delegation. One big liability with using delegation is that you are encouraged to make a "to-one" relationship. The object typically only carries around one delegate at a time. Notifications are an easy way to handle a "to-many" relationship. Objects can broadcast changes to multiple objects that might be interested.

You should probably stick with delegation if you know that you only need to notify one object at a time.

New alternatives to delegation are the design patterns with blocks. Delegation usually means having an object conform to a protocol and implement some delegate method. An alternative would be to create a timer object and have the object that wants to receive events pass a block to the timer. The timer would retain that block of code and launch the code when the interesting events happen. You no longer have to take up the extra room to define a protocol and a delegate method.

There can be some subtle memory issues when using blocks. You can have some extra retain cycles that you will not see with delegates. You should read through the documentation to learn a little more about how blocks might be used.

I forgot to mention target-action. You can initialize your timer object with both a target and a selector. The timer passes the selector to the target object every second. This could feel a little less restrictive than using a delegate. You do not have to create a strict protocol that the object has to conform to.

Target-action is starting to feel a little dated. That might just be me. You should for sure look through the pattern because it is used a lot of places in Cocoa. The blocks pattern just feel a little more futuristic.

Look at the NSTimer class and the CADisplayLink class. Both of these classes are designed to notify observing objects at appropriate intervals. What design patterns did Apple choose to use when building these classes? Do you see why those might be a good idea to mimic in your own classes? Do you see any way that you could use a different design pattern for better results?
 
Last edited:
I didn't even think of NSNotification. I have not read the documentation on it yet and just kind of assumed it was for sending message outside of the app to the phones notification center. Obviously I have so much to learn and play with.

There are three kinds of notifications: internal notifications (NSNotification), local notifications (UILocalNotification) and push (i.e. remote) notifications.
 
...

New alternatives to delegation are the design patterns with blocks. Delegation usually means having an object conform to a protocol and implement some delegate method. An alternative would be to create a timer object and have the object that wants to receive events pass a block to the timer. The timer would retain that block of code and launch the code when the interesting events happen. You no longer have to take up the extra room to define a protocol and a delegate method.

...

I think this situation is a great chance for the OP to experiment with blocks. Your timer class could take a "triggerBlock" when initialized and that block should be executed whenever the timer is triggered. There are some obvious drawbacks to this compared to delegation and the other patterns mentioned, which leads me to say...

This would be a really great chance to try out each of the patterns mentioned. You can implement your timer class to support multiple patterns and get used to the pros/cons of each pattern. It's important to understand each one as they are all used throughout Cocoa Touch.
 
Cocoa Design Patterns

This is a great text that all iPhone and Mac developers should read through before writing applications. Some of these patterns are commonly seen on other platforms and languages. Some of these patterns are more unique to Cocoa and Objective-C.
 
Thank you all for your insight. I am definitely drawn to using blocks for this. It seems like a very good way to keep the class very modular and flexible. I will try to implement all four of these patterns. Like I said I am brand new to programming and objective-C and am using this as a way to learn and experiment. So the more ways of doing things I can expose myself to the better. Hopefully I can find some time tonight to try some of this stuff out!!
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.