Is it possible to navigate directly from a view to another view without having to go down to the controller level?
If by "navigate" you mean to render one view in another, you can use Html.RenderPartial. If you mean creating a link with a URL that will invoke some other view directly when it is clicked, no: it would break the "C" part of MVC.
Related
I am currently working with Swift and I was learning about MVC - one question that popped out was this: I am trying to implement a WKWebView - and I already know how to do this within a ViewController.
My question is: should I create my own WebView class to place the WKWebView or should I only house it with in the ViewController? I am trying to follow the MVC structure.
It's a web view, so it should be placed in the view controller in the storyboard. This really has nothing to do with MVC, per se.
The view controller is your Controller.
The view controller's root view and the web view you're putting in it are the View.
The Model may or may not be relevant here since a model is usually just a data structure that the Controller uses to populate the View. It could just be the HTML that you pass to the web view.
My question is: should I create my own WebView class to place the WKWebView or should I only house it within the ViewController? I am trying to follow the MVC structure.
The view in Model View Controller really refers to a view and its entire graph of subviews. If a WKWebView instance is the view that contains everything that the controller will manage, then it's fine to make that "the" view; there's no need to put it inside another view just for the sake of containing it. On the other hand, if you want the same controller to manage other views not contained in the web view, then you can put the web view and the others all inside some other view and let the controller manage that.
How you organize your views really isn't determined by MVC -- just do what works. MVC really speaks to the way that the information your app operates on is owned and managed by a model, displayed in a view, and how the interactions between model and view are mediated by the controller.
I want to know what is best practice when triggering an event from a base model class, which will have a common outcome on all View Controllers. Say I have a shared, global variable, which can trigger an event based on different inputs. Wherever I am in my app, I wish to show a popup with the same information. With my knowledge of view controllers and swift, my only option is to implement the same code in each view controller, as I have to add that same popup to each view, depending on where I am.
Wouldn't it be nice if I could pop that popup from a global-root'ish view controller?
Is there a general coding-practice I've missed?
My first idea is to use a navigation controller (UINavigationController) as the root controller, and then just use
navigationController?.topViewController
from any view controller added to that navigation controller.
There might appear a problem: in case if you already displayed the alert view controller, the app will try to present an alert controller on top of another one. You can keep some kind of global state, or check the type of topViewController.
I have two tabs on my app that handle different flows.
For each tab I want to have a controller that determines (based on info in the app) which view to display.
So you click on tab 1, the app goes through some logic and displays either View B or View C. From there I use a navigation controller to go to other views within that tab.
To handle the initial logic of figuring out which view (B or C) to display I have a view controller (View A) linked to the tab that handles all the logic. My issue is that if I click on tab 1 while I'm already "on" the tab it displays the view for View A, which is a blank page.
Does anyone have an idea of how to architect this or make it so the view for View A is never displayed?
UITabBarControllerDelegate
in your implementation of:
tabBarController:shouldSelectViewController:
you should try to detect if you are already on the first tab or not. if so just return NO and it won't pop to the root controller (in this case A)
The idea behind the MVC model is that such logic is not execute by ViewControllers but by the Model.
You could create a class or method who's purpose is to make the decision between view B or C, call the appropriate method on a button click and display the view depending on the result.
My point is: the way you describe it view A should not exist.
I have a table view that contains a list of Project objects. When an item is selected it brings up a detail view. Pretty standard. What is the best way to implement "add" functionality (popup a modal view controller to input new values and save the item)?
Currently I have view controllers for my root view, detail view, and add view. Essentially the detail view and add view are exactly the same except for a save & cancel button in the add view. Is it possible to reuse the detail view in the add view?
Finally, what is the best way to display the list of project properties in a grouped table view separated into sections?
Thank you for your responses.
Most likely, you are already passing your detail view controller a managed object that it is supposed to display when in detail view mode. When the user decides to add a new project, just create a blank object, pass it to the detail controller and display it. (You might want to insert this blank object into another "empty" managed object context in case the user cancels the add process to avoid having to clean up your main managed object context in that case.)
The detail view controller would also need a flag that tells it whether it is in edit or add mode so it can adjust its controls (and possibly delegate messages it sends to its owner) accordingly. You would set the flag to the appropriate value before you display the controller.
It sounds like you're looking for a UINavigationController. The UINavigationController lets you push new view controllers on top of existing ones. It gives you a navigation bar at the top that will allow the user to go back to the root controller. I think it's the kind of controller Apple uses it in the default email application, to give you an example.
Concerning organization: you design your root view controller and a detail/add view controller. In your app delegate, you attach a UINavigationController to the window and you set its root controller to the main controller you want to display. That root controller can then push the add/detail controller onto the stack (and when it does so, it can tell the add/detail controller which types of button to display.)
I can't answer your grouped properties question, but it sounds like a separate question anyway.
XCode: "This template provides a starting point for an application that uses a single view. It provides a view controller to manage the view, and a nib file that contains the view."
What does that even mean? (ie what does Single view actually mean)
1) This means that your application will only have a single view screen that is active
2) This means that your application will be able to have as many screens as you like using a single view controller.
Ok now what if your application has multiple screens? not a single view screen, is still suitable under a view based application template?
Example
Screen1(main): on this screen you have 3 buttons, "Open Form1", "Open Form2", "Open Form3"
When the button is clicked it opens up the associated screen,
Press the "Open Form1" button opens up "Form1" screen2
Press the "Open Form2" button opens up "Form2" screen3
Press the "Open Form3" button opens up "Form3" screen4
When the user completes the form and submits it, a thank you screen is displayed
therefore in this example there would be a total of 5 screens.
Each form screen contains is different, textfield inputs, and information, is this considered as a view based application?
View-based app is just a template to say that your app will be view-based. That means that you can have any number of views you want, as this template comes with a view controller (that, as the name says, can be used to control the views... show/hide them with animation, for example).
The template starts with ONE VIEW that is added to the app view controller. You can add any number of views to that controller.
So, yes to your questions. You can use this to create the app you mention, where any of the "screens" you mention would be a view, for example and you can show each one using, for instance, the app view controller to animate each view showing or hiding.
That means the template will create one view and corresponding view controller along with app delegate, main window. That will also do the necessary things to add this view to main windows, and load when app runs. This is just a template. Then you can crate any number of views and view controllers as you want.
This means that the template you are starting the project with provides a single ViewController, and associated XIB for the View. As the first answer says you could use this template to build the application mentioned.
HOWEVER you may wish to think about how the user is going to interact with your app. Will you allow stepping back and forwards through the screens, in which case you may want to consider the Navigation Based app where you push/pop screens onto a stack to allow easy movement between then.
You might also have a concept of allowing the user to jump at will between each of the screen pages in which case you might want to implement a TabBar application.
Or you could just implement it all yourself. At the end of the day it will be your application design, and the template is only a starting point to get you going. I would suggest that if you are starting out with iOS development however to go with 1 ViewController matched a XIB for each screen you wish to implement to keep things simple.