KVO vs delegate protocol

Discussion in 'iOS Programming' started by jgaz, Dec 14, 2011.

  1. jgaz macrumors member

    jgaz

    Joined:
    Dec 30, 2007
    Location:
    Colorado
    #1
    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.
     
  2. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #2
    You could also use NSNotifications. Your viewController would listen for the desired notification and the timer object would post it.
     
  3. jnoxx macrumors 65816

    jnoxx

    Joined:
    Dec 29, 2010
    Location:
    Aartselaar // Antwerp // Belgium
    #3
    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.
     
  4. jgaz thread starter macrumors member

    jgaz

    Joined:
    Dec 30, 2007
    Location:
    Colorado
    #4
    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?
     
  5. PhoneyDeveloper macrumors 68040

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #6
    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.
     
  6. North Bronson, Dec 14, 2011
    Last edited: Dec 14, 2011

    North Bronson macrumors 6502

    Joined:
    Oct 31, 2007
    Location:
    San José
    #7
    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?
     
  7. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #8
    There are three kinds of notifications: internal notifications (NSNotification), local notifications (UILocalNotification) and push (i.e. remote) notifications.
     
  8. ppilone macrumors 6502

    Joined:
    Jan 20, 2008
    #9
    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.
     
  9. North Bronson macrumors 6502

    Joined:
    Oct 31, 2007
    Location:
    San José
    #10
    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.
     
  10. jgaz thread starter macrumors member

    jgaz

    Joined:
    Dec 30, 2007
    Location:
    Colorado
    #11
    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!!
     

Share This Page