Sticking to Apple's guidelines, I create one subclass of UIViewController per screen of my iPhone application. However I consistently find that these classes become very large, both in terms of sheer lines of code and number of member variables.
By definition they end up being responsible for quite a number of different concerns (e.g. view life cycle, mediating between views and models, sometimes touch handling, control logic, managing alerts and other UI state).
Not only does this violate the Single Responsibility Principle but it also results in large swathes of code which are near impossible to unit test.
What responsibilities/concerns do you tend to divide off into new classes? What kinds of responsibilities do you think make good candidates for clean separation in the case of UIViewController subclasses?
This is an interesting question and I also struggle on how to properly separate responsibility. It all depends on the context but since testing subclasses of UIVieController can be a pain I try to move as much as I can into model classes. In the spirit of Skinny Controller, Fat Model.
When it comes to tables I have created a base model class for handling all the table view stuff, basically encapsulating what you get when you create a new Navigation Based Core Data project. The in the controller I just forwards the calls to my table model.
I'm trying to keep the methods of the controller as small as possible. Depending on the context I may have several model classes, each responsible for a specific part.
I have also looked into the possibility of using controller factories for getting detail controllers for certain data models.
UIViewController *detailController = [self.controllerFactory controllerForItem:item];
[self presentModalViewController:detailController animated:YES];
This way I can unit test that I get the proper controller for a specific data item without having to involve the parent controller.
With mine, I'm creating categories, abstract parents and using a variety of patterns I've learned in the Java world to reduce complexity and code duplication. But when it comes down to it, I still have one view controller per screen because every screen has at least one thing on it thats unique in some way. There just might not be much code left in the controllers thanks to the infrastructure I've placed around them.
Related
I'm having a hard time wrapping my head around MVVM as I'm in the progress of learning SwiftUI development with Swift for iOS. After reading various tutorials and watching YouTube videos, this is my understanding:
View: The UI
Model: Data layer
ViewModel: "Glue" between view and model. Contains business logic.
However, after doing additional research, I found this article which talks about the role of controllers in MVVM. Now, this confuses me a lot because my understanding was that the ViewModel in MVVM already takes care of what a controller would do e.g. in MVC and therefore controllers would not exist in apps based on MVVM.
Question: Do controllers exist in apps based on MVVM or is the article simply wrong?
It is merely a question of terminology. This author’s choice of terminology is a bit unusual, and I would not get hung up on that. As you dive into these architectural patterns, you’re going to see all sorts of different uses of terminology. (Usually it is the term “view model” that is subject to some creative interpretation.)
Regarding this author’s particular use of the term “controller”, earlier in the document, when talking about view controllers, he starts referring to them as simply “controllers”. This is imprecise, but it is the terminology that he adopts throughout the article.
(As an aside, I would avoid referring to view controllers just as “controllers”, because for many of us, the term “controller” refers to something far more abstract, unrelated to the UI. E.g., see the discussion of “controllers” late in Dave Delong’s excellent video A Better MVC. But let’s set all of that aside and talk about the role of view controllers in MVVM.)
If you are employing MVVM in UIKit or AppKit, then you have a model, a view, and a view model. But you still have view controllers, too. So what happens to them? They do not disappear (unless you switch to something like SwiftUI).
Most/many of us simply consider the view controller as part of the broader “view” layer. A view controller is a UIKit object. It configures views. It is not some abstract object, but rather is an integral part of the UI. In MVVM, it often bears responsibility for hooking up the views to the view model, etc. Regardless of what architectural pattern you adopt, the hallmark of a good view controller implementation is that it is almost entirely restricted to UI related tasks.
So, in short, in that article you reference, the author is merely saying that view controllers are still in the mix (for non-SwiftUI projects, at least). He decided to describe it as a separate layer in his MVVM diagram. Many of us just consider the view controllers to just be part of the “view” layer. It is a question of terminology.
I'm still quite new to Cocoa and Objective-C (<1 year). My App now has some 50+ classes, but some of the ViewControllers get quite crowded with code, like 700 lines or more.
My question is: is it fine to have a "large" ViewController or are there patterns for splitting up code into fractions? A lots of the code is implementing delegate methods, thats why I don't have an idea how to move it away.
I know, I can structurize with pragma marks though.
Thanks for any input.
EDIT (Dec 2013): there is a great article from Chris Eidhof of objc.io regarding this subject. He also talked about that subject on Macoun 2013/Frankfurt. Separating out the UITableView protocols are a great pattern.
EDIT2 There are also 2 videos on NSScreencast explaining concepts of refactoring ViewController (episode #102 and #103).
One of the most common causes of large view controllers that I have seen, is lack of separation b/w Model and Controller in MVC architecture. In other words, are you handling your data in your view controllers?
If yes, rip out the model component from VC and put it into separate class. This will also force your thinking towards a better design.
For reference, In View Controller:
Handling of all changes in the UIView and the UI elements contained within.
All animation, transitions and CALayer operations.
In Model:
All processing of data, including sorting, conversion, storage, etc.
IMHO, 700 lines is not (yet) huge for iOS code, I've seen and handled much worse. Of course, if all your VCs are this big, you have a problem.
You should definitely use and abuse #pragma mark, it's very useful under Xcode at least.
Then if you find you got too much code in one file, you can extract functionality to classes or categories, as better fits.
Creating classes can be very rewarding in the long term to manage recurring tasks in projects (ie connecting to webservice, parsing XML/JSON, interacting with SQLlite, logging, etc...). If you are doing recurrent iOS programming, you can create a 'common' library of useful code that way.
Creating categories, especially on UIViewController can help reducing boilerplate code that takes a lot of place. You can (and probably should) also create a common base UIViewController for your app, that will handle stuff like rotation, maybe logging, navigation, etc... in a centralized part of the code.
You should try to identify what your ViewController is really doing.
If you can separate some concerns you can move them to classes of their own. Find out which properties and ivars are used by the viewControllers methods. If you can find a subset of functions, that use a common subset of ivars/properties, these together are very likely to become a class of their own. The controller would then own such a new class and delegate work to this.
If your ViewController is managing some sort of state, eg. you find the same switch statement or if-chain in 2 or more methods the STATE pattern could make your VC much more readable. But basically you could use any pattern that helps to reduce the VCs responsibilities.
IMHO the ViewController is the place were you would connect the model to the views. Propagating model changes into views and handling user interaction with the views are the only things, that should happen there. All other responsibilities, like calculation, network transfer, parsing, validation... should happen in different classes the VC uses.
You might like the book Clean Code by Robert C. Martin. He explores in depth how code could be structured to increase it's readability and reusability.
You can distribute the code using categories depending on the functionality. Refer http://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/Category.html
Prefer the use of NSObject class to manage part of your view controller functions. Main reasons code is more clear and easier to debug
AFAIK view controller classes should be used for managing their views, IBActions, IBOutlets and other view-screen related stuff only. This means that view controller class should be as lightweight as possible, only concerning about managing its root and inner views. However, sometimes we are tempted to leave the code inside view controller class and not to move to other custom class.
Currently, I always create custom classes for models(database tables or custom objects), parser wrappers, heavy computations and for other logic that is more or less big and might be considered as a separate class. However, very frequently, I'm leaving some relative small computations, simple checking, simple download and other small code stuff inside view controller classes, because I'm lazy (and who is not?) and I'm not comfortable with having a bunch of tiny classes just because, theoretically, some several code statements does not belong to some view controller class. I understand that those tiny classes might evolve to bigger and real classes later, during other versions of an app, but however, might not.
IMHO, if you will be very concerned about the 100% pureness and cleanness you will spend more time (well, at least during initial versions of the app), but you will never know if the product will evolve or if it will be abandoned. There's always some trade-offs the developers are facing with.
It would be interesting to hear, what in-house rules do you use for designing your classes.
Two questions really that when/where you should do something which is whether you've stuck to the pattern or not.
And how
How is much less clear cut, particularly when practicality and pragmatism start getting in your face.
We tend to go for a static class for simple stuff e.g. a DateUtility class for parsing and formating dates in different formats.
And Aggregation for larger stuff, i.e. a downloader.
If you want reuse, decouple is the basic rule, so just because something was big wouldn't necessarily mean a different class.
Personally i like to have a strict class separation also if that means have a huge amount of files :(
Every object has its purpose and if i found some really generic operations i prefer create an "helper" class where encapsulate methods that cannot be specific of a context.
The really difficult step is to be strict on your decision and don't be lazy :) because by your question it's clear that you understand how it's important be rigorous on your code!
I've been working on my iphone game recently and came across a forked road when deciding the design of my various classes. So far I've adhered to the MVC pattern but the following situation had me confused:
I have 4 buttons displayed visually. Each button though consists of a container UIView (which I've subclassed) and 2 UIButtons (also subclassed) as subviews. When you press a button, it does the flip effect plus other stuff. The user input is using target-action from my container UIView to my controller. This part is ok, the following part is the debatable part:
So I've subclassed the container view as well as the UIButtons and I need to add more data/methods (somewhere) to do more things. Putting data that needs to be serialized and non-rendering related code in the view classes seems to break the MVC design but at the moment, it makes the most sense to me to put it there. It's almost like my subclassed views are their own little MVC's and it seems neat. Separating out the data/methods from the view to my main controller in this case seems unnecessary and a more work. How should I be doing it?
Thanks heaps.
The MVC pattern is quite useful because it lets you reuse at least 2 parts of the MVC model (usually the model and the view) so usually, the best way to write clean code is avoid the use of inheritance and use instead delegation (based in protocols) and dependency injection (for the services) so you can generate unit tests for your systems and a better way to upgrade the develop of code
Here are some interesting articles:
when would I use the delegation pattern instead of inheritence to extend a class's behavior?
Inheritance is evil, and must be destroyed
Dependency Injection
i have a UIViewController class that do the following:
detect movement.
array a bunch of images and do some orders manipulation.
insert images to the view.
animate some images.
btw there are a lot of objects in the class (60).
do i need to separate some of this steps to different classes ?
if so why and to which class type.
tia.
Usually you'll want to have separate classes for your model, view, and controllers. Therefore if you'll usually have something like this:
MyViewController.m, MyView.m, MyModel.m
at the very least. Note that if you build your view with IB then you'll have a MyView.xib file instead of MyView.m.
This would be only a beginning point however. Depending upon the complexity of your app you'll probably wind up with many more classes that factor out common state and functionality. In general it is a bad idea to put everything into one class. This holds as much for any oo language as it does for objective-c
I feel this is somewhat subjective, but personally I'd separate them as follows:
MODEL:
array a bunch of images and do some orders manipulation.
VIEW:
detect movement. (but only tell the controller, controller should react to the movement)
animate some images.
CONTROLLER:
insert images to the view.
Might be an idea to get a book like Beginning iPhone Development.
As ennuikiller said iPhone applications are built using the model, view, controllers concept. The book bring you's up the core ideas of how to develop iPhone applications.