So I read about the VIPER architecture and I was wondering, how you would implement a master-detail view combination using the proposed layer separation between View, View Model, Presenter and View Controller Routing?
Let's say I want to display some contacts. I have the ContactsListViewModel with its properties name, photo and maybe some detail text. This is known to the ContactsListPresenter and ContactsListViewController.
Now I select a contact in my table view, the view controller tells this to the presenter and the presenter tells the wireframe to show the detail view for ... what?
The view model that is known to the List module does not contain enough information to be displayed in detail (like further notes, call list, whatsoever …).
In this case, should there be a view model that can be used for both list and detail view? Would that be a violation of separation of concerns?
As I understand you have 2 options -
Pass a model that includes all the data you need to the Contact List View controller. By that you will have all the data you need. - I personally think its ok in some circumstances, even though it's a bit wasteful.
Pass to the wireframe of the detail view the id of the contact. Then in the loading part of the viewcontroller load through the presnter and then interactor the full data of the contact, then display it.
Related
I used to consider a CustomUITableViewCell.xib as the view and the corresponding CustomUITableViewCell.swift class as the controller of a table view cell.
Is this correct? A youtube video I stumbled upon considers the class as the view: https://youtu.be/n06RE9A_8Ks?t=177
Edit:
To clarify the question: Which one of the following is the view and controller? Are both considered the view?
CustomUITableViewCell.xib
CustomUITableViewCell.swift
I'd absolutely consider it a "view" (in terms of MVC). It's of the group of logic that (along with the .xib) handles 1 particular view of information, rather than orchestrating some aspect of the general logic of the app.
I also consider a UIViewController as belonging to the "view" part of MVC for the same reason. Of course, if you put far more business logic into your view controllers than that which is necessary to support the single view, then your view controller is some mix of MVC. For example, if your view controller chooses what scene of the app comes next, your view controller then participates in controller logic and it's not really following MVC. Your view controller is forced to do a lot of single view-related work, though, because there's a single view it's responsible for and that the view-work is more practically done in the UIViewController rather than the UIView.
So when you ask about a cell view class's stance in MVC, if it's doing single view work, then it's a "View". If you mix in controller work or model work, then you've muddied up the separation of responsibilities that MVC espouses.
In my personal opinion it is a view. It should be handling only UI components in the class. Think of both files as a complete view. One cannot be without the other. Thus I consider them one.
I'm using MVVM for my view controllers and I'm facing an issue that I'm not really sure what would be the best way to solve it. Basically, view controller A shows a table view which is populated with data from view model A. Each cell has its own view model. View model A is responsible for creating these view models and expose them to the view controller. But now that I select one of these items I found that my models (the data I need to pass to the other view controller so it can create its own view model off that data) are hidden behind the view models. View models shouldn't expose the model, but then how could I pass this data to the other view controller? Should the cell view model also expose everything that is needed by the other view controller and just pass that view model? That doesn't seem right either.
After evaluating and playing around with suggestions listed in this post, I decided to go with an approach where the view model of view controller A is responsible for creating the view model of view controller B, considering that it is the one having the data. I got the approach from http://www.martinrichter.net/blog/2015/08/20/navigation-with-mvvm-on-ios/ and I think is the best way to not break MVVM abstraction.
I would strongly suggest using protocols for passing data. You could set the view-controller which is to receive the data as the delegate of the view-controller from which the data would be sent. Delegation is a very widely used pattern in the iOS since much of the architecture of the iOS itself is designed around that.
Let me know if you need help or would like to see some code which accomplishes this.
I have a store application, which I built by reading Big Nerd Ranch's iOS Programming, and I advanced my application to the another level and I have created another Item Detail View Controller. It is similar to iPhone's Settings.app, it is a table view controller. This table view consists 2 static table view cells with UITextField's. There is no problem about accessing this text fields, however I'm not able to save data taken from them. My table view controller has no idea about it's parent view controller (which is also another table view controller). So with basic - (void)viewWillAppear and - (void)viewWillDisappear methods I couldn't succeed save data. Having read some documentation about protocols and delegates, I couldn't help myself. Also I have no storyboards or .xib files. Just .h and .m files, may seem stupid but I hardcoded all of them. Ideas???
Let me show you what application looks like:
I am at the beginning of developing an iOS app I am having trouble understanding the MVC (Model-View-Controller) design pattern. I thought I had it down but the more I read the more confused I get. I don't know if this should be an iOS specific question or if the same goes for every use of MVC. I am not using storyboards btw, I want to do it all programmatically.
I believe I understand the basic relationship between Controllers and Models, it's the separation of Views and Controllers that I don't get. Let's say I want to create a UIButton and display it on the screen. Should I initiate the button in the Controller or the View? The controller is responsible for what should be displayed, correct? Wouldn't you just call on a View to display that and not worry about creating the button in the Controller? From what I understand, View Controllers are just Controllers and should therefore control the View, not be the View. It seems like most people do just about everything in the View Controllers. I guess my question boils down to what code goes where?
UIViewController is controller part in the MVC pattern of code.
M(Model)
C(ontroller)
V(View)
Controllers handle navigation between different views , etc.
From here you can get more idea : view and viewcontroller
A view is an object that is drawn to the screen. It may also contain other views (subviews) that are inside it and move with it. Views can get touch events and change their visual state in response. Views are dumb, and do not know about the structure of your application, and are simply told to display themselves in some state.
A view controller is not drawable to the screen directly, it manages a group of view objects. View controllers usually have a single view with many subviews. The view controller manages the state of these views. A view controller is smart, and has knowledge of your application's inner workings. It tells the dumb view objects what to do and how to show themselves.
A view controller is the glue between you overall application and the screen. It controls the views that it owns according to the logic of your application
About View Controllers
View controllers are a vital link between an app’s data and its visual appearance. Whenever an iOS app displays a user interface, the displayed content is managed by a view controller or a group of view controllers coordinating with each other. Therefore, view controllers provide the skeletal framework on which you build your apps.
iOS provides many built-in view controller classes to support standard user interface pieces, such as navigation and tab bars. As part of developing an app, you also implement one or more custom controllers to display the content specific to your app.
Not sure about any iOS specifics but from a PHP standpoint controllers are there to get any data that is needed for the view (via models) and then pass that data to the view.
The view is there to render things to the screen only and should have no logic in it.
So from a website point of view if you wanted to display a users name on the screen:
The controller would request the username from the model
The model would get the username and return it to the controller
The controller would then pass the username to the view
And the view would then render the username.
Hope that helps.
To be not specific, but on a upper layer, you can say as following :
You can put controller code in class extending UIViewControllers
You can put view code in class extending UIView
You can put model code in class extending NSObject
I am implementing a scroll style page view controller for my app, based on the page based application template.
In the data source class, I am storing the list of view controllers in a dictionary (could also use array I guess) so that I can reuse them if the user swipes back to a view controller they already viewed. There are about 15 total view controllers in the page view controller.
I wonder if this is a good idea compared to calling the story board instantiateViewControllerWithIdentifier each time. (I understand the pageviewcontroller itself stores its own array of view controllers anyway.)
I could instead just store the model object in the dictionary or array and instantiate the view controller and pass in the model object after calling instantiateViewControllerWithIdentifier.
I am interested in what is likely to be the better approach.