views:

1391

answers:

3

I'm wanting to implement some custom, reusable and efficient scroll behavior in an iPhone app so I'm extending UIScrollView with my custom control and wish to track scroll movements.

Now I'm aware that I could probably assign my custom control as a UIScrollViewDelegate and internally respond to scrollViewDidScroll calls but this doesn't feel correct to me (I may be wrong).

It doesn't feel correct as the delegate is aimed at application specific UI logic and controls should be a level above this. It would also mean I'd need to relay delegate calls out if an application class assigned itself as a delegate too which seems inefficient.

As a direct descendant of UIScrollView I'd expect to be able to override the method that triggers the scrollViewDidScroll delegate call, or be given access to a template method, or listen out for scroll events, but I can't see any such options.

Looking at the UITableView.h file, UITableView doesn't seem to set itself as a UISCrollViewDelegate so I'm wondering how it manages this (I'm assuming as it recycles cells it must track their position relative to the visible bounds).

I'm pretty new to this platform so I may be missing something obvious. Any help appreciated.

A: 

(I may be wrong)

I think you are. Without understanding the details of your app, the delegate methods sound like exactly what you want. Bear in mind that the controller (UIViewController subclass) can also be the delegate of its view.

Roger Nolan
A: 

I think the delegate relay is what you want. It would let you use the published API, which is usually recommended rather than overriding functions you're not really supposed to know about. I agree that it does seem messier than it should have to be, but if the hooks in UIScrollViewDelegate are what you need for your customizations then it sounds like that's your best bet.

You can also provide your own custom delegate object/protocol to whatever UIViewController is using your scroll view to do some view specific logic too.

Loktar
+1  A: 

I agree with your original assessment. If you're changing the scrolling logic itself (rather than responding to scrolling) then that's a subclass, not a delegate.

UIScrollView is designed to be subclassed and includes a small discussion about it in the reference. In particular it suggestions overriding -touchesShouldBegin:withEvent:inContent:, pagingEnabled and touchesShouldCancelInContentView:, which are probably where you want to do the work you're describing.

Rob Napier