It just sounds like trying to subclass UIScrollView is overkill for the problem you're trying to solve. What you want is a custom view inside a UIScrollView and be able to provide the whole view hierarchy as an object for consumption. You don't require special scrollview behavior. If you don't want to use UIViewController, there's no reason you can't write a generic controller/container object that creates a UIScrollView along with your custom view and packages them up. Then, when someone asks your controller/container object for the view, you provide the UIScrollView with hierarchy all neatly made.
Maybe that doesn't even need to be an object....it could be a C function or a class method that returns the built hierarchy that you want. Yet another option is putting the UIScrollView and its custom subview into a nib, and having the owner be NSObject so that anyone can unarchive a copy and put it to use even without using UIViewController. Just a few possible paths that spare you from the fact that subclassing UIScrollView is easy to get wrong. Luke On Jul 1, 2010, at 3:47 PM, Rick Mann wrote: > I don't use a UIViewController. That is in this case, the view controllers > will be provided by others who just want to use my view. Currently my view > has properties that must be set for displaying data, but I may switch that to > use a data source model like UITableView. > > I know it's no problem to drop a view into a UIScrollView. I want to avoid > that, and I'm simply looking for the best way for my UIScrollView subclass to > actually get updates as its scrolled. > > If it's really not good to subclass UIScrollView, why does UITableView do so? > > TIA, > Rick > > On Jul 1, 2010, at 15:36:21, Luke the Hiesterman wrote: > >> If you use a UIViewController, then dropping your custom view into >> UIScrollView in IB should be completely straightforward for all your uses. >> >> Luke >> >> On Jul 1, 2010, at 3:29 PM, Rick Mann wrote: >> >>> I'm developing a custom scrolling view, and I could either subclass >>> UIScrollView, or subclass UIView and drop it into a UIScrollView in IB. I >>> prefer the former approach, because it's more straightforward when using >>> the view (which we use in many places). >>> >>> However, the only way to update the view is to either become the scroll >>> view's delegate, or override the contentSize property setter, and call >>> setNeedsDisplay. Neither of these solutions seems very elegant or obvious. >>> >>> And just for reference, UITableView subclasses UIScrollView, and doesn't >>> make itself the delegate (at least, it doesn't declare the protocol in the >>> header). >>> >>> Is there a smarter way to do this? >>> >>> TIA, >>> Rick >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com >>> >>> This email sent to luket...@apple.com >> > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
