I'm confused somewhat by the MVC implementation as used in Objective C programming.
What is described as 'Controller' in Objective C tutorials and documentation, I understand as simply a view or mediator.
Which is correct?
A model is what holds your application's data — its model of the world.
A view is what interfaces with your user. It displays things and receives input back.
A controller handles the interactions between the other components. It tells a view how to find its content, it responds to changes in the view by updating the relevant parts of the model, and it responds to changes in the model by telling the view what needs updating.
View displays
Model holds data
Controller responds to user events and controls view and model.
Controller can't be a mediator, because view and model do not communicate with each other through it. But it controls them.
Related
I am just learning some Core Data and have run into an issue with the idea of having and being able to access separate stores for application-wide and document-only data.
I have a document based application that currently uses some of the entities within a managedObjectContext to populate a table via an NSArrayController.
However, some of these entities should be application wide (part of the experience for all documents - e.g. like data for buttons representing tools that are commonly used)
So for this reason, I pasted in the AppDelegate code for the non-document based application, which creates a separate, application-wide store and managedObjectContext, for the application. What I want to do is to access this MOC within each NSPersistentDocument (readonly) via an Array Controller (as before) to populate the table view of each opened document.
How would this best be done? And if this is not the way to populate a TableView that appears in each document from an application-wide MOC, which way should I look for?
P.S I am working in Swift, but am familiar with Objective-C - Thank you for any help!
According to Apple you should pass your MOC to the controller. From Core Data Snippets. Note the last two paragraphs.
By convention, you get a context from a view controller. You must implement your application appropriately, though, to follow this pattern.
When you implement a view controller that integrates with Core Data, you can add an NSManagedObjectContext property.
When you create a view controller, you pass it the context it should use. You pass an existing context, or (in a situation where you want the new controller to manage a discrete set of edits) a new context that you create for it. It’s typically the responsibility of the application delegate to create a context to pass to the first view controller that’s displayed.
A view controller typically shouldn’t retrieve the context from a global object such as the application delegate—this makes the application architecture rigid. Neither should a view controller create a context for its own use (unless it’s a nested context). This may mean that operations performed using the controller’s context aren’t registered with other contexts, so different view controllers will have different perspectives on the data.
Sometimes, though, it’s easier or more appropriate to retrieve the context from somewhere other than application or the document, or the view controller. Several objects you might use in a Core Data-based application keep a reference to a managed object context. A managed object itself has a reference to its own context, as do the various controller objects that support Core Data such as array and object controllers (NSArrayController and NSObjectController in OS X, and NSFetchedResultsController in iOS).
Retrieving the context from one of these objects has the advantage that if you re-architect your application, for example to make use of multiple contexts, your code is likely to remain valid. For example, if you have a managed object, and you want to create a new managed object that will be related to it, you can ask original object for its managed object context and create the new object using that. This will ensure that the new object you create is in the same context as the original.
I'm a little confused about input processing in regards to Apple's MVC pattern. According to Apple, your objects should be divided into model objects (which handle the data), view objects (which display stuff), and controllers (which bind the two and also process events and input). However, many of Apple's native UIKit views — UIScrollView, UIControl objects, etc. — do all the input processing themselves, possibly letting their controllers know about it via delegates and data sources. This really confuses me. In my mind, the sturdiness of the MVC triad depends on both the model and view being fairly dumb (and thus easily swappable). When all the OS-level event complexity is centralized in the controller, you have a very nice separation of concerns. On the other hand, adding input processing to the view seems to turn it into a sort of controller of its own.
Am I missing something here? What's the correct way to think about this?
User Input is part of the View in the MVC pattern. They directly interact with the user and provide their data, either on request or through delegation, to a Controller, which might then use that input to affect changes to the Model.
"Dumb" and "easily swappable" are not necessarily the same thing.
Buttons contain a lot of functionality that we don't want to rewrite in every single controller: tinting of the image to indicate highlighting, allowing for cancellation if the tap strays a certain distance before touch-up, etc. Scroll views contain a lot of physics.
In other words, "which display stuff" is a mischaracterisation of view objects. UIView -- the base class -- just provides event data, but subclasses provide higher-level data such as "the button was tapped" or "the scroll view decelerated to a stop".
One thing to think about is your perspective.
When most of us code, our Model is a data object (maybe backed by files or databases, etc), our View is a UIView (possibly setup/configured in Interface Builder) and our Controller is the UIViewController.
What if you weren't coding an app though? What if your world was a UITableView? You can still have a basic MVC separation. Your Model is represented by the UITableViewDataSource protocol, your View still a UIView with it's setups and configurations and your Controller is the UITableViewDelegate protocol. All the pieces there and even separated, the separation is just different than when using a UIViewController. You can see a practical example of the separation a data change. When you the data in the data source protocol nothing happens. You have to call a reloadData method on Controller bit for the table to realize data was changed.
The smaller the item, the harder it will be to see the MVC pattern. A "button" would be a lot harder to use if it was broken into 3 different objects, but you can use MVC patterning inside a single object to create well encapsulated. A UIButton has it's Model in the form of a both public and private properties, a View (UIView still) and a Controller which is bunch of code that accepts events and makes modifications to the View and/or Model as appropriate.
Maybe it is a dumb question but I would like to know when we have to or when it is recommanded to create new class. This is not really clear in my mind. For now, I've only one class per Controller and that's it... All my code is in this class.
I think it could be better...
Regards
If you're following the MVC pattern, for the most part your classes should be separated into one of those categories:
Controllers: UIKit/NS view controllers, which are responsible for presenting views and receiving messages from interactive elements on those views.
Views: If the view presented by one of your controllers requires a lot of custom logic in order to present itself, it might be a better idea to separate it into its own class. In essence, this is done when creating views using Interface Builder (.xib files).
Models: Objects that encapsulate logic in your application.
For example, if you are building an RSS viewer according to this design pattern, you'd likely make the following classes:
Models representing an individual RSS item, as well as one that represents an RSS feed. If you roll your own RSS feed parser, you would want to isolate the logic required to fetch entries within another class.
Controllers to handle displaying the feed and individual views. Controllers should only be concerned with presenting data. In the case of an RSS viewer on iOS, you would likely use a UINavigationController with a root view controller of the UITableViewController class. Tapping on a table cell pushes another UIViewController responsible for displaying an individual RSS item.
While the UITableController has a default view to display a list of items, the individual item likely needs custom logic to be displayed well. You might want to create a view class or .xib to present these. The UIViewController is responsible for populating data on the view (setting values on IBOutlets on the .xib, etc).
As a general guideline, you should try to adhere to the single responsibility principle--every class should have a single responsibility, and it can perform its tasks more or less autonomously.
In this vein, controllers are responsible for handling the display of a single kind of view and for delegating messages from that view. Views are responsible for displaying data. Models are responsible for the singular purpose they were created for--an RSS item for mapping data from an RSS feed to an object, an RSS feed object for managing a group of RSS items (adding, removing, possibly fetching more via an NSURLRequest).
Note: Your question is a bit vague according to Stack Overflow guidelines, so that may be why it is being down-voted. Consider adding a specific example or description of the dilemma you're facing.
I've built an iOS 5 iPad app which makes use of a second screen. We have an admin view (on the iPad) and an external view through an HDMI enabled TV connected via the Apple DVI adapter. Both the iPad view and the TV view get the same data updates from a service call which is made every few seconds. We then present the data received as a series of charts; the charted data is presented very differently for the TV and iPad views - but the core dictionary of data is the same. I'm wondering about an elegant way to architect this solution. At the moment I have one of the view controllers (the admin iPad VC) doing the service calls using GCD and then dispatching NSNotifications which update the data (charts) properties on the other (TV) view controller. I'm considering moving the service calls away from the VC and creating a singleton which is initialized in the app controller. I then (somehow) set the two VCs as delegates and they get updated using a simple protocol. I'm not entirely sure if this is a good approach or if I should consider something else? Can I even set both VCs as the delegates of another class or is it typically only one delegate per class instance?
Thanks for any input.
Ben
Why not abstract the chart data into its own model class, which you can share in both view controllers? The model class can be responsible for fetching the new data. To make the controllers aware of updates, they can either use KVO on the model object, or they can observe notifications sent from the model object when an update occurs, or you can have an array of delegates for the model object and each view controller can be a delegate.
There doesn't seem to be any compelling reason to make it a singleton, although you can if you really want.
I have a strong j2ee background, and I am trying to move to objective-c for some desktop/iphone programming.
I used many java web frameworks with mvc in mind, spring and struts ecc... so I am used to have servlet or controller which pass attributes to jsp pages, which is the view.
In jsp pages with jstl you can call this attribute and render to video.
In this way controller and view are (in theory) clearly separated.
With xcode, I can easily recognize the controller and the view built with IBuilder.
All the tutorial I found, shown the controller which go and change directly labels or text fields.
So my two questions:
seems to me that there's no separation between the two (controller and view), where I am wrong in that ?
is there a way for a controller to pack all objects in a kind of context in a j2ee way and have the view read that context ?
thanks
Leonardo
In most of the examples you have read you probably saw something like this:
[myTextfield setStringValue:myString];
now in this case sure the controller is updating the textfield directly, however as myTextfield is usually an IBOutlet it can be any textfield in your view, or even nil. quite possibiy it doesn't even need to know that it is an NSTextfield just that it responds to a setStringValue method. In this sense there is a seperation between the controller and view.
Now in your comments above you were concerned with seperation of responsibilities within MVC but did not mention the model much. With Cocoa bindings you can bind directly to model keypaths, in this case the model neeed not know anything at all about the view.
MVC is a bit of an ambiguous concept with no hard definition. It can mean different things to different people. For me it means that the view has knowledge of the controller ( through outlets or bindings) limited knowledge of the model(through bindings). The contoller has full knowledge of the model and limited knowledge of the view(through outlets). Finally the model has zero knowlege of the view and ideally no knowledge of the controller.
With regard to your second question, I don't use j2ee, but I think you can acheivee what you want by having your controller update a context ivar ( probably a NSDictionary) then in your view bind to this context with a keypath. However there is no real need to wrap everything up bindings are very versitile and u can bind to any property.
I do not understand your second question (I've never used J2EE), but I think I can make some headway answering your first.
Cocoa does not enforce MVC; it just strongly encourages it -- especially for larger projects. Consider an example program, one that has an NSTableView bound to an NSArrayController.
In this case, the NSTableView is clearly the view (it has the word "view" in its name) and the NSArrayController is clearly the controller (it has the word "controller" in its name).
The model is an NSArray that the NSArrayController knows about, but you probably don't interact with that model directly. You will instead ask the NSArrayController to manipulate its model by sending addObject: and removeObject: messages to the array controller (and not to the array itself).
When you do this, the NSArrayController will effect a change in the NSTableView via bindings. Again, you don't ever ask the NSTableView to do anything.
So you never talk to the view and you never talk to the model. Everything you want to happen goes through the controller.
MVC. QED.
Of course, maybe the way your project works, the view should be its own controller. The world won't end, although you might find it to be a little more difficult to go against the grain of the framework. But you should always try to use the best approach for the job at hand instead of insisting on some sort of design pattern purity.