I am using Xcode 6 and Swift.
I have some data that I'd like to represent in two or three different ways using a segmented control.
The first view is a list, the second is a grid, and the third is a table with some labels.
Despite the different appearances, they are all drawing from the same data source.
What is a sensible way to achieve this?
Should I drag 3 views onto 1 controller (the same view controller), and do all of my design/storyboarding within each view, add constraints as needed, and then just show/hide each view accordingly?
Is there a different or better way to do this, or is this about right?
Thanks so much!
Looking at the requirement, i feel TabViewController is best. Using segmented controller you need to take care of switching views yourself. You can have a TabViewController with 3 viewControllers and these view controllers can draw waterer data they need from your data source.
There are two elegant ways to this effectively and clearly.
1)You can use different xib for each 3 views and on runtime load appropriate xib of the different views.This approch should used if you have small and clear views.There is not much work need to handle like dataSource and delgations.The three views will manage by only one view controller.It will make all your views separate and easily managable.You can load diffrent views as
//Your view property
var uiview :UIView?
//load nib from bundle in view
self.uiview = NSBundle.mainBundle().loadNibNamed("myXib", owner: self, options: nil)[0] as? UIView
2)Use container viewcontroller.By doing this you can add the different controllers to your parent controller.This approach is very clean as different views are handled by differnt controllers but it is hard to write.Use this if you have heavy work need to do by each view.See WWDC video to get more help https://developer.apple.com/videos/wwdc/2011/?id=102
I think in your case 1st approach is appropriate use the three different xib and load it on runtime and add as subview of your viewController
Related
I wanted to know if I have to create a new ViewController for each view I have. Let's say I have 3 views do I need 3 viewControllers or does 1 ViewController can manage all 3 views?
Edit: Views are Objects that I create with .xib file so following the description given me by Xcode 4.3.3: represents a rectangular region in which it draws and receive events.
My situation : What I want is the main View showing 3 buttons, each button leads to a new View. That's about it each of the 3 views will have about the same thing, a tableView to display data parsed from an XML.
Thanks again!
EndEdit
Thanks
Both are possible, depends on your needs. View controllers can easily manage more than one (sub)view (e.g. every UI control subclasses UIView and you can have many in a single view controller). Sometimes it's more convenient to put views in different view controllers, sometimes it's not.
Depends on your situation and what you want to present to the user. If those 3 view controllers have very similar functions and only minor differences, then you could use the same class and have an instance variable to indicate which mode you're in. For instance if you have a list of Songs, Playlists or Videos, those could be the same class, with an enum variable to differentiate between the 3 modes. If your views are significantly different however (like a Song list and a Video player) then you should usually have separate classes for them.
For iOS, general best practice has been for a single view controller to manage a single "screen (or "window", but of course there is only one of these on an iOS device). This view controller may support a variable number of view objects (certainly not a ratio of 1:1 views/view controller).
As of iOS 5, nesting multiple view controllers managing multiple views in single window is now technically supported, but I still consider it a practice best avoided.
One window = one view controller = multiple views.
In one view controller you can manage any number of views.
It is preferable to use a viewcontroller per view. the advantages of the approch is as follows:
Any time you can convert the Template of the application. (eg. from table view to tabview or split view can make quick change)
with each view controller you follow the MVC architecture.
if you have n controller than try to manage n MVC model so that you can shift any model any where easily.
Memory management will be easy (Push and Pop manage memory automatically.)
if we have sigle view controller and n number of view than it will be quite difficult to manage memory.
Also we need to keep the screen ID for each view and need to mantain also their switching.
there are N number of advantages if you use N numbers of viewcontroller over N number of views.
I want to create a view that will appear only once (on first time). After, I want to show another view.
Can I declare 2 views in 1 xib file?
Yes but you you will need some funky looping code to extract the proper view or you could get the view via index, if you know it will always be at a given index. Personally this is not an ideal solution for me because I like to have strong pointers to all objects.
Your Could create a ViewController subclass with 2 views and then bind each view to variable via interface builder. This might be a little cleaner?
You can, but there's no reason to do so. Just use two separate view controllers, each with their own view (in separate nib files).
I have a User Filter section of my iPad app. There is a segmented bar with 5 buttons for 5 types of filters.
Clicking each of the buttons will load up the respective view..
My question is.. would the best way to handle the UI of each filter to have several views in this nib and load/unload accordingly.. or would best practice be to create the information in a scrollable view?
below is the setup..
http://imgur.com/iuufU.png
Thanks in advance...
Generally, go with separate views. The Scrollable view is an approximation of what you're trying to achieve (by the looks of things), whereas the separate-views more closely reflect your aims.
Some typical dvantages:
if you change your UI design, e.g. if one of those filters has to go in a different page, but 4 stay here ... then it's easy to move the whole View without changing the eixsting ones.
you can put each view in a separate NIB file (if they're different), or loaded from a separate ViewController instance (if they're the same), and you get some of the advantages of Apple's automatica memory management of VC's / NIBs.
Usually, people start with the same view for each filter, using a single VC class (instantiated multiple times, once per tab).
Then, as the app evolves, they find that one tab needs a different layout, so they add another VC class, and only need to update the alloc/init line for that one tab.
The View controller programming guide states this regarding view controller's usage:
Each custom view controller object you
create is responsible for managing all
of the views in a single view
hierarchy. In iPhone applications, the
views in a view hierarchy
traditionally cover the entire screen,
but in iPad applications they may
cover only a portion of the screen.
The one-to-one correspondence between
a view controller and the views in its
view hierarchy is the key design
consideration. You should not use
multiple custom view controllers to
manage different portions of the same
view hierarchy. Similarly, you
should not use a single custom view
controller object to manage multiple
screens worth of content.
I understand that if we use multiple custom view controller's to control the parts of a view (i.e. a view controller to manage subViews of a main view which in turn is managed by a view controller) the default methods like:
didReceiveMemoryWarnings
viewWillAppear
viewWillDisappear
viewDidUnload
etc. etc. will not be called.
Apart from this, is there any other solid reason why we should not be using multiple view controllers to manage the respective subviews of a view?
The documentation also provide an alternative solution which reads as:
Note: If you want to divide a view
hierarchy into multiple subareas and
manage each one separately, use
generic controller objects (custom
objects descending from NSObject)
instead of view controller objects to
manage each subarea. Then use a single
view controller object to manage the
generic controller objects.
But there is no mention as to why multiple view controllers should not be preferred. My question is:
Why should not we prefer it this way?
I am concerned because I prefer using UIViewController's subclass to manage my views since I load them from nib each time and I segregate nibs for each view controllers. It becomes easy to cater the changes in later stages of the project. Is this wrong? Should I necessarily change my programming style, or is it ok if I go ahead with this approach?
Thanks,
Raj
Well, I'd say "as long as it works", you can keep on doing like you do !
But to keep things "cleaner", I'd use my own objects.
Since ViewControllers are designed with other general features in mind (like working with navigation controllers and tab bar controllers), which makes it a bit "heavy" for a simple usage, like you do.
Plus, like you mentioned, some events are only called when the viewController's view is added to the main window.
Can't you use your own objects with Interface Builder ? If you create one (or several) UIView IBOutlet(s), it should work the same.
I have an app that does use two UIViewControllers on a single screen. The child is a UITableViewController. I don't rely on any of the UIViewController behavior of the child -- only the UITableViewController methods. This is convenient because there are other cases where the child UITableViewController does manage the whole screen. And in that case, it does use the UIViewController methods. Questionable design? Maybe. It has worked fine for two years now. But I'm not sure I would recommend the pattern.
I'm trying to add multiple views inside a UITabBarController. Currently my object hierarchy looks like this: UITabBarController -> UIViewController* -> UIView*. As a more concrete example, the first view controller for my UITabBarController is a UIViewController, and that has three subviews, which are controlled by a UISegmentedControl. Depending on what segment is selected, I push the corresponding view to the front.
I understand that I can use a UINavigationController to manage my three views; however, the data I wish to present is not really hierarchical.
Are there examples of container controllers other than UITabBarController or UINavigationController that I can use for this case? Or is there another approach I should use (I'm currently managing views manually).
Thanks!
Custom view controllers are covered in the View Controller Programming Guide.
If you wanted to change your layout to use the UINavigationController you could remove the segmented control view and have the first view be a table view inside a nav controller. The table would have the three options the segmented control had and tapping on them would push the view associated with that option. This way you've created a hierarchical view layout rather than using the segmented control, which is typically used to toggle functionality rather than control views.
If you choose to do this, these two guide sections would be a good place to start.
There's not really any supporting framework for this - usually you have to manage switching out views in a switched container view yourself.
One approach I have taken in the past is to maintain an array of ViewControllers for each switching view, and take the viewController.view to add as a subview of your switched container view. Then I write code around the switching of the view controllers to call viewWillAppear and viewWillDisappear on the contained view controllers as they are swapped in and out, that makes things much simpler since you can treat them totally separately.
You can write that class kind of generically and then re-use it.