Question regarding ScrollView and pageControl with multiple XIBs

Question

Hi,
I am very new to iPhone programmming and OO type programming in general so please forgive me for my basic questions.
I am trying to set a paging scrollview up with each page being loaded from a different XIB and put into a view controller. This viewcontroller is attached to a scrollview that's put on a "Detail" view. I have this working OK with blank XIB pages.
My question is, when I start adding fields/buttons to the different XIBs how should I then process the actions etc. Do I create a seperate .h and .m file for each XIB and add the individual screen processing into the individual classes or do I use a single class (the "Detail" screen) and do all the processing in that class?, is that even possible?
I do hope that this makes sense. I'm still going through the basic learning books and I'm maybe trying to run before I can walk.
Any help is most appreciated.
Thanks

Answer 1

Hi Ziximo, and welcome to the Dev Forums!
Ziximo wrote:
I am very new to iPhone programmming and OO type programming in general so please forgive me for my basic questions.
No forgiveness is necessary. You came to the right place.
I am trying to set a paging scrollview up with each page being loaded from a different XIB and put into a view controller. This viewcontroller is attached to a scrollview that's put on a "Detail" view. I have this working OK with blank XIB pages.
In case it's useful to you, here's a thread which shows how to use the PageControl sample app as the template for what you're doing: [Re: Flipping through views help|http://discussions.apple.com/thread.jspa?messageID=10417960&#10417960].
My question is, when I start adding fields/buttons to the different XIBs how should I then process the actions etc.
The advice you have from thomas-r is right on target, so I'll just try to add to that. Firstly, I think you may be making a diligent attempt at "top-down" design, which is commendable. However there's a dirty little secret that working programmers don't share with managers: Quite often we don't produce the functional specification until we get the code working.
In other words, thomas-r's reference to Murphy isn't an insult. That's just how software gets designed.
In general, the decision to make a new class should be based on encapsulation and re-usability. For example when you get a memory warning, you might want to release all of the resources required for a screen that isn't currently visible. If that screen and its controller can be fully regenerated from one nib, this can be an easy task.
As another example, say the top-level controller is an instance of your ScrollViewController class. If you limit that controller to managing the scroll view and page control, you'll probably have a class you can reuse the next time you need a paging scroll view. But if you pack the functionality for multiple content views into that same controller, the class will only be useful for an identical app.
.. or do I use a single class (the "Detail" screen) and do all the processing in that class?, is that even possible?
So, no, I would definitely not attempt to put all the control in one class. Yes, it's possible, but besides being bad practice, it's awkward to implement. For example, when you make a nib which is owned by a view controller, it's easy to connect that controller's outlets and action methods to controls which are defined in that nib. There are ways to connect controls to an object defined in another nib, but it's much more difficult. It's not a "natural" configuration, and that by itself should give us second thoughts about our design. On the other hand, if we make one giant nib which is owned by the top-level controller, memory management goes out the window. We would need to unload everything in that nib to gracefully handle a memory warning.
Do I create a seperate .h and .m file for each XIB and add the individual screen processing into the individual classes ...
Yes. This gives us the reusability and encapsulation we want. The only remaining question is: "Do I need a separate controller class with it's own custom xib for each screen?". Well you may not. There could be two or more screens that are so similar (e.g. the same layout and functionality but with a different image) they can each use an instance of the same controller class and share the same xib.
I usually start with a different controller class and a different xib for each screen. Then, near the end of the project, I'll look at all those controllers and see if two or more are nearly identical. If so, I might get rid of one or more classes, and possibly one or more xibs as well. But I'd almost never assume I can merge two controller classes at the outset. If I did that, I might start adding kludges to the merged class as I found differences between the screens I hadn't seen earlier. When the merged class finally got too complex for anyone to maintain, the job of splitting it up might be nasty.
I do hope that this makes sense.
I think that's my line.
I'm still going through the basic learning books and I'm maybe trying to run before I can walk.
If you've suceeded in getting the skeleton working--i.e. you're paging through blank screens, each with it's own vanilla controller/xib, without any bugs, I'd say you're more than ready for the question you're asking here. And it's a very good question.
\- Ray