Multiple XIB how-to

[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?

[Abel]

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.

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?

[hcosta]

Originally Posted by myersn024

After reading all this discussion, I've decided that I should probably re-do the tutorial to show proper MVC based design.

Please...
Or could you at least create and upload a project with the proper MVC based design? It would a big help.

Thank you very much for the original tutorial, i learned a lot, and the this thread is very informative.

Thank you.

[dalef84]

I have a question. How do you solve the problem with simulated metrics, when having separate .xib files?

As you can see, I've uploaded your sample[1] with a minor modification: I added a label at the top of the screen in your settings view. This label gets covered later by the status bar.

I've been having this problem for quite a while, and the only solution I've found (so far) is NOT to use IBuilder...

[1]

TwoViewApp has a problem with StatusBar

[Abel]

It seems like all IB does is tell the view what size frame to use. IB however (for me, at least) has never removed the status bar. Usually I remove it programmatically.

Originally Posted by dalef84

I have a question. How do you solve the problem with simulated metrics, when having separate .xib files?

As you can see, I've uploaded your sample[1] with a minor modification: I added a label at the top of the screen in your settings view. This label gets covered later by the status bar.

I've been having this problem for quite a while, and the only solution I've found (so far) is NOT to use IBuilder...

[1]

TwoViewApp has a problem with StatusBar

[myersn024]

Yeah, I don't use interface builder much any more unless I have to. It's so much easier to do things in code.

[Abel]

Its faster too since the NIB files need not be parsed and inflated into objects.

Originally Posted by myersn024

Yeah, I don't use interface builder much any more unless I have to. It's so much easier to do things in code.

[myersn024]

Yeah, the drawRect function can be a PITA sometimes. However, I still use IB to prototype my interfaces. Then I'll just get each object's frame info from the Inspector window and use that for all my drawing.

[Abel]

I still use IB as it makes it easier for developers to find what they are looking for but ye there are so advantages to doing it in code. I wouldn't discourage the use of Interface Builder unless your app has certain exceptional needs.

Originally Posted by myersn024

Yeah, the drawRect function can be a PITA sometimes. However, I still use IB to prototype my interfaces. Then I'll just get each object's frame info from the Inspector window and use that for all my drawing.

[backwardselvis]

I am really enjoying this thread, keep up the great tutorials and conversation.