No, view state should be handled by the view controller. In VERY SMALL applications this could be the delegate.
Most complex applications that deal with tons of views would have various view controllers.
View states such as scroll position should be restored by the view controller and saved by it too. The view should only have some kind of accessor
method to determine at what point the view was scrolled to. A scroll view would have a method such as currentScrollPoint or some other accessor to access
the area where it is scrolled.
I hope all that made sense.
Quote:
Originally Posted by TheFury
Thanks for providing the discussion/debate over the proper separation of the code. This is one piece of the iPhone puzzle I'm still not crystal clear on: should all view state be handled through the app delegate? I think the answer is yes.
When my app exits, then runs again, it should restore its state and appear as it did before (not all apps HAVE to do this, but I believe it's the suggested behavior). In this case, the app delegate is responsible for restoring the data and presenting the appropriate view.
If any data were stored in the view (scroll position, perhaps the view has two modes, or some subview is either displayed or hidden), a mechanism would need to be invented to save/restore this data: either the app delegate would know about the data (perhaps as just a blob of view data), or the view would be told to save/restore its own data.
In this case, we're talking about MVC, but at two layers. There's the app data - then there's the view data. When I'm looking at an email PDF attachment, close the app, then restart mail, I get a view of my attachment scrolled to the exact place I was before. When I am in the middle of authoring an email, close the app, then restart main, I get a view with the cursor in the right place of the body of the message, but the scrolling isn't necessarily the same. So this piece of the view state isn't persisted.
Comments?
|
