I'm just learning the iOS, so my question is very basic... I've read a lot about organizing subviews in the application, but there are so many things there, that I would like to ask you if I've understood it well...
The main part of the app is a window. ViewController manages only one view. In a window I can set the rootViewController. This controller manages the view during entire application workflow. Next I can create some subviews, connect these subviews to the main view (parent) using outlets, and the when instatiating rootViewController I can add my subviews by :addSubview method. Am I right more or less?
And one question more... Should each subview be managed by a dedicated ViewController (then, the parent has outlets to these controllers) or I can change the subviews state directly from parent ViewController?
And short example:
I would like to create an iPad app which has (both visible at a time):
- at the top: short form and button (user enters some data and clicks "Save" button)
- at the bottom: a table displaying provided values
So:
I can create one main view, and two subviews (for form and table). Each time I add some values table will be refreshed using the parent controller... Does it make sense?
It you see that I understand something wrong, please tell me what should I read about.
Thanks for patience.
iOS follows MVC pattern.
The controller class is a manager which binds data to the view. So you can have separate classes for your view and data.
Your understanding is right. To achieve the things you have mentioned,
Create a subclass of UIViewController.
Add two subviews to it (TableView and Button). This could be done using xib or programmatically
Add the delegate methods of your tableview inside your controller class and set tableview's delegate as your controller class.
Add the event for button.
.
rootViewController is the starting point for your application and you can create more viewController and add subviews on the viewController depending on your needs for application.
I would like to create an iPad app which has (both visible at a time): - at the top: short form and button (user enters some data and clicks "Save" button) - at the bottom: a table displaying provided values
you can create UITableView & UIButton as subView to the UiViewController(will be Owner of the subviews) or any other subviews like labels,textfields etc.
The subviews are connected to the files owner that is the viewcontroller..not the parentview.
Related
I have a UIViewController with a UITableView that is fed with data from the local database. When the user first launches the app (after installing) the table view is empty and I display a UIView in the middle of the table view that contains a UIImage, a UILabel and a UIButton (a call to action).
The first version of this view I built programmatically, which was no good to me because every time I tweaked something I had to build the app again. Then I switched to the storyboard but had to drag a UIView to the middle of my tableView. It is working now but I don't like the way it is, I can't edit my table view cells without having to move the UIView out of the table view.
I'd like to have a way to build this view entirely separated from my tableView (or even from my view controller in question) and then reference it in the viewDidLoad call of my view controller.
Unfortunately Xcode does not allow us to drag views directly to the storyboard so I'm pretty lost here.
Please tell me if I haven't been clear enough. I appreciate any help you could give me.
UPDATE: It'd be particularly awesome to me if I could also create a custom Swift class for this view of mine and reference it in the storyboard. And then in my viewDidLoad I could simply instantiate my custom view.
Thanks in advance.
Create a XIB file in which you can drag a view (without a view controller).
In your code you can load the XIB using NSBundle.mainBundle().loadNibNamed("MyXibName", owner:self, options:nil).
In the XIB file you can give the UIView a custom class (like you can do with view controllers in storyboard).
You then of course have to retrieve the view from the array returned by loadNibNamed and cast it to your custom class.
I need to implement an accordion control for iOS. By accordion, I mean a UI like this:
I see two basic ways to do this, but I'm not sure which one to choose.
Method #1: Create a ViewController container, something like a UITabBarController, except that instead of showing tabs at the bottom, I draw a vertical stack of buttons, and when you tap one, the corresponding panel opens and shows the corresponding view controller's view.
Method #2: Create a composite view, add a bunch of views directly to it, and show/hide them as needed.
How do I choose here? What would make me want to treat the sub-units as view controllers vs views?
Generally speaking, if I can avoid it I try not to subclass UIView and instead do everything within UIViewController subclasses. A controller is usually required anyway (model/view glue code, user interaction, delegate stuff, notification handling, etc.), so if no custom drawing is needed it is usually possible to do without a UIView subclass.
In your case I could envision one reusable UIViewController subclass that represents a list entry. It has the following responsibilities:
Create two alternate view hierarchies (collapsed/button, expanded/panel)
Toggle between the view hierarchies in reaction to user interaction (with/without animation)
And another UIViewController subclass that represents the entire list. It has the following responsibilities:
Override the appropriate methods from UIViewController to make it into a container VC
Add/remove child VCs as appropriate to the internal model
Possibly adjust the container view in reaction to collapse/expand events in its child VCs
I have a view controller with a table view in it and several buttons. I would like to add an additional tableview on top of the view like this (or at least what it would look like if anybody wanted to be my friend :-)):
I don't want to just add this as a subview (like here or here)enter link description here since I don't want to check which table view is being used in my tableview delegate and datasource methods. I would rather use a separate view controller.
I don't want to use a picker because I need to display a bit of info with the items in the list.
I have no problem creating the view with the corresponding controller, but how do I add it on top of the current view, just hiding portions of it?
Thanks!
Apple has a sample code of TableView which deals with this issue. https://developer.apple.com/library/ios/#samplecode/TableViewUpdates/Introduction/Intro.html%23//apple_ref/doc/uid/DTS40010139
Above URL is the link to download the sample code from Apple developer library.
Hope it helps.
This might be overly simplistic for your application, but I have found it to be effective when I have had to do something similar.
You can add this 'drop down menu' view controller's view to the main UIWindow of the entire application. You can add a UIGestureRecognizer on the window as well. If the tap is outside of the view, make it fade away and remove it from the view hierarchy.
Initially I simply added logic in my tableview datasource and delegate methods to destingwish between the two tableviews (as suggested by Scott Bossak above. But I have since switched to building my two views in storyboard and adding their view controllers as usual. However, to present the second table view I instanciate it like so:
SecondTableViewContriller *secondTVC = [self.storyboard instanciateViewControllerWithIdentifier:#"secondTVC"];
then add it as a child view controller:
[self addChildViewController: secondVC];
[secondVC didMoveToParentViewController:self];
I then implemented a protocol to pass the information back to the parent view controller once a row has been selected.
Overview
I am doing an iOS project using the MVC architecture. Pardon my ignorance, I am just confused, I am looking for a good design.
The view I am planning to use will have some buttons on it and some labels and text fields. My view wouldn't need any custom
implementation of drawRect.
All my logic as to what needs to be done when a button is pressed or event occurs is in my view controller
I have a couple of doubts:
for the above scenario, is it still better (good practice) to create a separate view (a view other than view controller's view) ? If so why ?
Other than drawing and displaying the view (in my project, I don't have much of it) what else should a view's implementation code
contain ?
I would like to disable a set of buttons when the user touches on a textfield and the keyboard comes up.
a) So should I place this logic of disabling some buttons in the separate view's implementation (view created in question 1) ?
b) From my parent view (view created in question 1), can I create outlets to the buttons (which are subviews) to disable some of the buttons ? I am not able to do this. Or should I use the method subviews and loop through the button that i am looking for ?
My understanding
Model contains the data
View is responsible for displaying and shouldn't contain business
logic.
View controller is the only one to interact between the model and the view and contains the business logic
There's no need to create a separate view -- the view controller's view (usually just a plain UIView) can certainly contain your buttons and text fields. If you did want to put some of those in a separate container (perhaps so that you could move them as a group), you could use a plain old UIView for that.
Views are responders, so UIView subclasses can override the touch handling methods if you want to do any special touch handling.
a) It's common to put the code that manages views (such as disabling buttons) in the view controller. b) Again, you'd normally put the outlets for your buttons in the view controller.
When people talk about "business logic" they usually mean the logic that's required to maintain and operate on the data that the application deals with. That sort of thing is often best placed in the model. On the other hand, code that manages views, such as enabling or disabling buttons or moving data from the model into views (or vice versa) belongs in the view controller.
Q1. for the above scenario, is it still better (good practice) to create a separate view (a view other than view controller's view) ? If so why ?
If you create your view by Interface Builder, that's a separate view I think. ;) But if you try to create a view hierarchy programmatically without using a n/xib, you can put all your view layouts in loadView method, and populate the data in viewDidLoad, that's what the View-Controller does. And also, you can create a UIView class to implement the layout of the view, just like n/xib, but programmatically.
As the DOC said,
... One can merge the MVC roles played by an object, making an object, for example, fulfill both the controller and view roles—in which case, it would be called a view controller. ...
... A view controller is a controller that concerns itself mostly with the view layer. It “owns” the interface (the views); its primary responsibilities are to manage the interface and communicate with the model. Action methods concerned with data displayed in a view are typically implemented in a view controller. An NSWindowController object (also part of the document architecture) is an example of a view controller. ...
The MVC in Cocoa is a litte different as what you known. You can refer the official doc HERE.
Q2. Other than drawing and displaying the view (in my project, I don't have much of it) what else should a view's implementation code contain ?
You can customize your view, e.g., set text color or font style for your button, etc.
Q3.a. So should I place this logic of disabling some buttons in the separate view's implementation (view created in question 1)
It is better to put logic in controller (or view-controller), just as MVC prefer.
Q3.b. From my parent view (view created in question 1), can I create outlets to the buttons (which are subviews) to disable some of the buttons ? I am not able to do this. Or should I use the method subviews and loop through the button that i am looking for ?
You can set tag (setTag:) for your buttons and get the right one you want. But keep in mind, firstly you need to let the button shown to parent.
I am trying to learn programming for the iPhone and I keep seeing these files and I am not sure when is each file and content of those files referred to in the execution of a program built for the iPhone. I am trying to follow tutorials and tips available online but nowhere is there a point by point comparison or something like that. It would be great if any of you could list a few basic differences like when is each file referred and what should ideally go into each file and so on. Thanks for your time already.
In general, delegates can be thought of as event handlers. Accordingly, the AppDelegate is the main event handler for your entire application. It is told when the application has launched, when it will exit, when a Push notification comes in, when the app has gone into the background, etc. One of those events - applicationDidFinishLaunching - is typically responsible for creating the application's window and adding views to that window.
In most applications, the view that is added to the window is actually controlled by a UIViewController. Each UIViewController is responsible for managing the appearance of one main view plus all of its subviews. For example, a UITableViewController is responsible for managing a UITableView (main view) and all of the UITableViewCells (subview) that are inserted into that UITableView. The UIViewController typically acts as a delegate (event handler) to the views it is responsible for. When a user taps a table view cell, a method in the UITableViewController is called. When the user swipes to delete a separate method is called.
A generic UIViewController provides the same basic functionality, but for custom views. For example, the UIViewController may be responsible for displaying a few text views and a button. The UIViewController would create its main view, the text views and the button view. The text views and button view would be added to the view controller's main view as subviews. The UIViewController would register itself as the delegate for events from the text view (for example learning when the user has finished editing the text in the text view). It would also register a method to handle a button press originating from the button it owned. When any of these registered events occur, methods on the UIViewController are called allowing you to take whatever action is needed.
The rootViewController is a specific type of view controller used with navigation controllers. If you want an application that has the typical iOS navigation view hierarchy, your AppDelegate would typically add a UINavigationController to the app's window. That UINavigationController is useless without actually having content to display. That is where the rootViewController comes into play. You are responsible for providing a view controller (such as the one described above) to act as the first view stored in the UINavigationController's stack of views. This view will be displayed when the app starts up and anytime that the user pops subsequent ViewControllers off of the UINavigationController's stack.
Long winded I realize - but hope it helps.