I've read a lot about MVC as I'm ramping up with iPhone / IOS development. However in the various sample files I've see so far I'm not really seeing separate classes for model, view & controller?
How should I concretely see MVC in action with a best practice developed iPhone application? For example perhaps one based on a NavigationController & some Table Views etc.
For example:
Should there be a separate Model, View & Controller for each "iPhone UI controller" - noting that there seems to be 1 page == 1 UI controller in iPhone development from what I'm seeing, then my question is effectively should each UI Controller have it's own View file and Model file?
Given that Interface Builder and NIBs are a big part of things, to what extent is a NIB considered to be part of the MVC pattern? e.g. does the creation of a NIB effectively implement the "controller" and the "view", leaving you to create a separate class (in a separate file) for the model?
What happens when you've got shared data (or a shared model - e.g. a list of items) that is shared/used by multiple application pages (e.g. list view, edit view etc) - in this case this seems to me you would have 1 x model, but then reuse this model instance across the separate pages (which are View & Controller).
Hope this makes sense...
You'll be following MVC by using the objects and tools in their typical use. A UIView object is used to present data and receive input (View). A UIViewController responds to events and routes the data back and forth between the data model and the UIView hierarchy (Controller). Your data model lives wherever you want it to, sometimes composited together with your UIViewController subclass, sometimes present in the app as a singleton class (Model). When you specify your shared data model as a singleton class then any class that needs it can access it from anywhere in the app. By maintaining this division of labor, your application will tend to be well-organized and modular, and you can maintain/extend one aspect without having to rewrite all the other aspects of the program.
Interface builder is a tool for visually building the view hierarchy (and to some extent the control hierarchy) of your application.
Related
I know this is a bit of an ethereal question, but I'm working on an app that takes its entire structure from a remote JSON object and I'm trying to figure out the best way to approach the creation of Views, View Controllers, and Models. Currently, I am using RestKit to grab, parse, and map objects. I will have the structure of the views, controls, and fields defined at runtime, so how should I dynamically create and manage object composition, view controllers, and all appropriate delegates? (I imagine KVC and KVO will have a huge part in all of this.)
A few things to address:
Nested/chained delegation to allow leaf control events to bubble up to the root controller and then down to the proper model.
Dynamic object composition to allow a view to contain an arbitrary combination of subviews at runtime
Dynamically linking data between views and the proper model objects
Are there any good resources, guides, or examples of implementing/planning for this type of architecture?
This answer may not satisfy you but i will try to help.
Initialize dictionaries(NSDictionary) and detecet objects&values with [yourObject objectForKey:#"yourJSONKey"]; and [yourKey valueForKey:#"yourJSONValue"]; and after this create&push your views so that thay play a rol in run time(according to the JSON response)
I am creating a Universal iOs application as part of an assignment (iPad and iPhone :) ).
Naturally, they have a UI which I have been accustomed to create through the NIB files, using the fancy drag and drop schemes. This obviously seems like a great strategy when you are making a dedicated iOS device application.
However, with the universal application, I notice that this strategy can be a challenge since the 2 UIs differ and human error can promote a lack of consistency in the two UI's + double the work!!!
I noticed the solution to the assignment I am doing has the UI created through the AppDelegate file, I have never really done this, and from this stems the questions:
What is the appDelegate files for anyways?
Is it the way to create the UI for the Universal application through the App delegate? Or do you people still create the UI's through the NIB files meticulously for both iPhone and iPad?
P.S: Side question: This assignment requires me to create a Windows based application vs a View based application which is what I have naturally learnt to do. I understand a Windows based App can grow into a view based application and vice versa. However, I do not understand when you should choose to create a Windows based application?
The AppDelegate in Cocoa is your central Singleton that controls the app workflow. It's used by the underlying Framework to start the application, signal runtime envrionment changes and terminate the app. Being a singleton, it's always there and easy to reference ([UIApplication applicationDelegate]) and it loads up your first view controller.
It's generally common to let the application delegate keep refernces to model and controller objects. But what you describe, the whole UI programmed through the appDelegate, is bad style.
No matter if you use NIB's or you code your UI by manually adding UIElements to the view in code, you should do so in ViewController. Generally, the appDelegate will call the first view controller and that viewcontroller will call all view controller afterwards.
Recently I've been reading up on the MVC pattern and wish to apply it to my iPhone development. However, there seem to be so many variations of the pattern that I'm not sure exactly how it should be applied.
As far as I gather, the view will notify the controller of any actions which have been performed and the controller will in turn update the data model (if required). The data model will notify the view whenever a change to the data occurs and the view then updates it's display of the data appropriately.
In this basic model, the controller only has knowledge of the data model. However, I can't seem to figure out how to employ this design within my iPhone app.
The following page suggests an alternative version of the pattern where the controller has an awareness of both the data model and the view and all communication between the model and view is performed via the controller. It also seems to suggest that the model and view have access to the controller. Would I be right in suggesting that the data model interacts with the controller via some form of notification (notifications or KVO) and that the view interacts with the controller via actions?
Is this second model correct?
http://www.bogotobogo.com/DesignPatterns/mvc_model_view_controller_pattern.html
Many thanks,
Danny
I found Paul Hegartys explanation on MVC in iOS very helpful. see his Stanford iTunes U video. MVC starts at minute 22.
edit
The link of the video doesn't bring you there as expected. it is 1. Introduction to Cocoa Touch, Objective-C, Tools, and MVC (September 21, 2010)
MVC has been around for a long time so there are many variations (or misquotes) to the pattern. Although, the concepts are much the same for most MVC implementations I have seen.
I would focus on how Apple defines MVC. Which can be found in the Cocoa Design Patterns guide and from sample code downloaded from the SDK site (MVCNetworking example).
With iOS you will often will have Models and ViewControllers(which are a merged role of both the controller and the view).
Also, Martin Fowler has some great MVC stuff in his GUI Architectures.
iOS development is very much orientated towards the MVC pattern.
It is usually done with viewControllers and a model. The view is build in Interface Builder, assigned to the controller and the model part is retrieved from elsewhere.
I would say that for Cocoa-Touch the second "version" of the pattern is the one that best describes what usually goes on.
The idea behind MVC is that the model and the view is reusable, but the controller is often fitted to the problem at hand.
This is also true for iOS development, especially if you use interface builder.
The view is hooked up to the viewController via actions/delegates and the model either broadcast its changes through KVO notification or by the controller pulling new data.
There is tons of code available from Apples developer portal and you should start out by looking at some of that code. Having your eyes and mind tuned to looking for the MVC pattern you will see they use it constantly, with the delegate pattern on top to provide event better abstraction
In my opinion, second one is better. Model and view should be separated completely. If view receives notification from model, the view will depends on design of model. By placing controller here, tightly coupled circular-dependency created.
Finally, each part cannot be developed independently, divide-and-conquer strategy is just impossible to use.
My advise for general cases:
Make view and model passive and independent as much as possible. Major mutation must be done with only external manipulation. It should not be changed actively.
Make controller actively controls both of them and other controllers.
In iOS, a UIView is a view which is fully passive. In most cases, all major mutation always done externally by UViewController. And model part should be implemented yourself completely as you want. (Or you can integrate models into controller if it's small enough, however, I don't recommend it)
In some big featured UIView, a sub-scale MVC patterns are used. Fractal!
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.
In iPhone development for every page you see there are 2 files, a nib file, and a view Controller (books.nib, booksViewController.m), but in a Cocoa application apple suggests to have 3 files (books.nil, books.m, booksViewController).
What is the point of having 2 class files? is it a bad idea to connect the attributes to the outlets in the interface, in the same file that the logic goes?
so keep it exactly like iphone a nib file, and ciew controller?
I think you've misunderstood. If you were creating a Books app for the iPhone, wouldn't you have a Book class for your data model? That's the "third" file you're seeing. You have one file for the controller class and one for the model class. It's a basic MVC architecture (with the nib being the "V").
But there are differences in how applications are structured on the two platforms. It basically comes down the fact that iPhone apps are always fullscreen "kiosk"-style systems, while Cocoa apps are window- and document-based. In a Cocoa app, a view is just an area of a window that you can paint in and respond to mouse clicks, and view controllers are support objects for laying them out. On the iPhone, your entire app interface is essentially a stack of view controllers, each of which manages a whole screen.