3846 Views 5 Replies Latest reply: Sep 11, 2010 5:52 AM by RayNewbie
It highly depends on what your program should do. You need to make a design decision: Does it even make sense to have the same Controller handling events from different views? For example, are the actions on the buttons very similar? It's up to you to decide.
Murphy's law: You're gonna make the wrong decision.
Hi Ziximo, and welcome to the Dev Forums!
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�].
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.
Thankyou Gents for your replies.
It's great be be able to just throw out a question and watch as people give their time to answer and help. It's what I just love about forums.
Anyway, I think I'll go with the separate controller per XIB way. This I know how to do, I just wondered if it was possible the other way seeing as the 4 screens provide data for the same objects. It looks like it will be way too much hassle.
I hadn't really thought about the memory management side of using a big single controller either, good catch.
RayNewbie, your comment about coding and then doing the functional spec made me laugh. I've been a coder for 20 years (IBM AS400) and that's exactly how it's always been, do a functional spec, code it and then re-do the functional spec to fit. This is the first OO type of coding that I've been involved with though and I'm still in the "Play" stage, it's not yet a natural way of thinking for me.
Again, many thanks for the help. See you in the forums.