I have some Viewmodels wirh instances of another viewmodels, or Reactivelists with viewmodels.
What is the best moment to dispose the viewmodels?
Related
Part of Apples description of the MVC-pattern is: ”The controller updates the model.” I interpret this to simply mean: The controller calls methods on the model, causing its internal state to change.
But for a controller object to call a method on a model object, it needs a reference to the model object. If multiple controllers need to update a model object, we need multiple references to the model object – one for each controller.
I don’t want my controllers to reach out in to global space locating other objects. I want higher level application objects to wire up lower level domain objects.
I’m coming from other plattforms where we use IOC containers for this stuff.
Looking for best practices as how model objects gets passed around in a cocoa application.
A concrete example: If I add CoreData to the cocoa application project template in xCode, the managedObjectContext is instantiated in the app delegate. How do I pass this instance to, for instance, a view controller or a nested view controller?
I’m using Swift.
concrete example: If I add CoreData to the cocoa application project template in xCode, the managedObjectContext is instantiated in the app delegate. How do I pass this instance to, for instance, a view controller or a nested view controller?
So personally I find this an anti-pattern: stuffing 'global' data in the app delegate.
But, that is what is very common on iOS and as you have noticed, what the standard Xcode template does. Unfortunately.
To make this a bit more workable, what I usually do is make the managedObjectContext private to the app delegate. Then when another object, mostly a UIViewController, needs to access this context, I explicitly pass it to the UIViewController when I instantiate it.
And when that view controller needs to display a new view controller, like for example some detail view, I again pass the context to it.
Then at least there a clearer form of responsibility. And it makes testing simpler because view controllers simply need to be configured (or injected in IoC terms) instead of grabbing hard coded global objects.
I know this not a full answer to what you were asking but I thought this bit was the most interesting of your question.
In the classic MVC:
The setup mechanism is the following:
Instantiate model
Instantiate view (Has reference to a controller, initially null)
Instantiate controller with references to both (Controller registers with view, so view now has a (non-null) reference to controller)
The question is why in the second step the view should have reference to the controller (i think the controller having a reference to the view is enough) ?
In the Extended MVC:
The setup mechanism is the following:
Instantiate model (Has reference to view, initially null)
Instantiate view with reference to model (View registers with model)
Instantiate controller with references to both (Controller registers with view)
The question is why in the the first step the model should have a reference to the view (what i know is that the model shouldn't know anything about the views, and the pattern Observer should be used in this case) ?
Here is the source link.
Thanks for advance.
The answer for both questions is the same. Your diagram is very abstract and you are totally right there should be no direct reference in both cases. You can either reference by a well defined interface(duck typing) or by subscribing to events happing at the observable object.
Look at your observer example. According to it, the only thing an observable knows about its observer is the fact that they respond to the notify method. So technically there is actually a circular reference between the two, but in case of the reference from the observable(model) to the observer(view), it's a week one.
Same applies for the first case. The View does not directly know the controller. But the controller has to be notified on UI events(e.g button clicked) and respond to them. This is often done by having the controller register to events happening in the view. But technically the view will maintain a list of its event responders. So there is actually a reference, but again a weak one. It will not stop you from reusing the same view with another controller.
So, your concerns are right, circular dependencies are a smell. But on the low technical level they are required and in order to achieve lose coupling you just have to make one side of them weak, which will make the dependency exchangeable
If I am using multiple viewControllers, do I need to create a separate UIViewContoller class for each one of them or can I associate this same new class with each individual viewController? Under what circumstances would I create a new class to associate with a separate VC?
thanks.
View controllers manage the logic of your view, providing a way to channel the data between the view and the mode, and react to events initiated by end-users through the user interface.
If multiple views happen to share the same logic of model-view interaction, it is a good idea to share view controllers among them. However, this is somewhat rare: in practice, different views call for different view controllers. So in practice you create a new class for a new view controller almost every time that you need a view controller. You can also start with several view controllers, and then unify some of them if you spot sufficient number of commonality in their code.
So from what I understand the basic application structure for cocoa programs is an AppController in MainMenu.xib. The AppController then initializes the WindowControllers and ViewControllers which has all the UI logic and in turn load the xib files for the rest of the application. The AppController also creates the Model classes.
My confusion is over how to get the data from the model classes into the views. I would like to use bindings and key-value observing. Should each view controller have a pointer to the AppController and the ModelController? If so how would you do that?
[[ViewController alloc] initWithModel:ModelController];
Is the only solution I can think of and it doesnt seem very clean.
I make a controller that creates/loads and owns the model. My application delegate creates and owns this controller.
That same controller usually also owns the window or view; I rarely use dedicated window controllers, and have never used view controllers. If you do use window/view controllers, the model controller would create and own those, too.
Thus, one controller is responsible for both the model (or some specific portion of it) and the (controller for the) window that displays that (portion of the) model.
A common way to link a NSViewController to a model is to set its representedObject value. There is no need to set a pointer to the AppController, as it can always be obtained through [NSApplication sharedApplication].delegate.
I have a object that is responsible for controlling screen navigation. A presenter can call one of two methods on this navigator object NavigateTo(string screenName) and NavigateTo(string screenName, object data). This latter method allows some context data to be passed to the navigator object.
Would it be the wrong approach when calling the NavigateTo(string screenName, object data) to pass the calling presenter as the data to the navigator and then allow the navigator object to use this to extract data from the view and/or model.
Some advice on this matter would be greatly appreciated.
Passing the Presenter to NavigateTo is a good choice. If you have multiple presenters you may want to write a interface that NavigateTo can use and have each presenter implement that interface. But if you just using one presenter for this or they already share some common interface then this is not needed.
One idea behind MVP is that you are change the view without effecting the underlying UI Logic. Passing the presenter doesn't effect this goal of MVP as you can change the view the Presenter is using. Now if you are allowing direct access to the raw view through the presenter (by exposing a view property) then that not good. What you want are methods on the presenter to expose the needed information to NavigateTo. That way when you chance the view you re implement the code behind those methods.