Question

For quite a while I’ve been looking at objective c examples, watching the Stanford lectures, and playing around with some code to get a hang of creating an iOS app.

However there are a few things that I can’t find a good answer on:

1. How do I properly separate my layers? I understand the MVC structure, and I saw some examples of creating Categories for models to implement business logic. Is that the proper way, by enriching models or should I create dedicated classes (e.g. to authenticate users, extract models from json, group orders)?

2. How smart should views be? Can I make a view that displays a Contact (by assigning the contact property) or should I create separate properties for all of the Contact fields or should the view request it’s information via a delegate call?

3. I’m using a Storyboard in my application. On my screen I want to
   have a navigation bar, and let’s say a view that displays orders. On
   other screens I want to reuse the order-view.

   • How can I re-use the order-view’s ViewController and View in other ViewControllers?
   • If I have 4 screens with the same look-and-feel, do I have to simply copy them in the Storyboard? This seems like a pain to main, what if I want to change my background? Or add a button to all of the views? When I create a setup-wizard I don’t want to define the look-and-feel for every screen separately.

Coming from a C# background I probably have to get into the objective-c mindset 🙂
Any help on this would be great.

Answer 1

1) ObjC-Categories will easily distort your understanding of the main problem you’re facing. ObjC-Categories are completely unnecessary. You could always approach these extensions by subclassing, object composition, additional methods in the actual model, or some customization in the controller or view. So if you need to format data (e.g. which is present in the model) for display in a view — that task would often land in the controller. As far as the examples you provide: You may opt for models in simple cases — as well, any of the examples could merit dedicated class, if complex enough or if it would keep you from redundant implementation. Note that these may be accessory classes, which simply produce a model, or they may be composites of multiple concrete of abstract classes. Not everything needs to land squarely in the definition of M-or-V-or-C. You’re free to use many design patterns with ObjC. Think of MVC as the patterns Cocoa typically uses — you will need to know them, and you will need to know how to subclass and extend these types, but these patterns lose dominance as implementations move away from Cocoa’s libraries (e.g. as complexity increases).

2) They can be smart. However, under MVC, you want to focus its implementation on the view/presentation aspect. A view which represents a collection of information could in fact perform some tasks which are typically reserved for the controller — however, you would generally cede that the implementation were a dedicated MONContactView in doing so. If you go that route, you would generally do so for easy reusability or to achieve a simple interface. Displaying information about a Contact could be very complex – In simple scenarios, these tasks are often handled by the controller. Specifically, a MONAwesomeContactView is likely less complex (e.g. in SLOC) than MONAwesomeContactViewController (unless you have some very special drawing or layout to perform). It would be more common to set the controller’s contact, and let the controller push the contact data to the views’ fields. Again, in the case of a very specialized subclass — a view could very well hold its own controllers in some cases.

3a) There’s nothing wrong with creating multiple instances of a class.

3b) No need to copy. When duplication is smelled, I push the implementation to actual code — the programs can apply the look and feel you desire, or add or manipulate the subviews as you desire. Of course, they will not be present in Xcode’s NIB editor. There are of course alternate approaches, but this replication often makes me move the implementation to compiled code. Achieving a good balance of both is not so difficult (personally, I do most of my views programmatically, rather than using NIBs).