I'm beginner at IOS. I don't quite understand what is difference between collection view and collecionviewcontroller and in what cases can I use each of them
UICollectionView inherits from UIScrollView (just another UIView)
UICollectionViewController inherits from UIViewController..
and it implements some protocols.. like UICollectionViewDelegate and UICollectionViewDataSource .. it means everything is already done for you.. and you just have to use it.. but as everything is already done for you.. you may not be able to do some stuff.. like resizing your collectionView ..
if you want full control I recommend you to use your own UIViewController.. and add a UICollectionView as a subview.. so you can place it wherever you want and resize it.. don't forget to implement UICollectionView protocols for delegation and datasource :)
It's based on your requirements. You may change some properties with your View controllers. But when you use as part of its' controllers, you can't change it.
For example you Can´t change UICollectionView Size of UICollectionViewController.
In these case, you must use UICollectionView in viewcontroller. As like this, if you want to customize some property but functionality are same in all.
Here I mention some ref for you: refrence
UICollectionViewController is specialized in managing UICollectionView. Collection view controller is inherited from UIViewController specifically for collection views so if collection views are removed then there is no use for Collection view controller.
Having said that,collection views can be used inside UIViewController whereas UIView can't be added inside UICollectionViewController.
Related
I'm learning swift and I have gone through tutorials where some developers delete the View Controller entirely and just drag in a TableViewController and start using that. While other developers in tutorials create a TableView from within the View Controller.
Is it better to delete the View Controller and add a Table View Controller or just work with a TableView within the View Controller?
It is all about the requirement. Both are correct way. Don't be confuse.
When you using TableViewController then it only behaves with the UITableview. i mean controller totally dedicated itself as tableview.
When you using TableView inside UIViewController then you can create whole UI deign in your own way.
Note: As you'r new so I suggest you to go with TableView Inside UIViewController because you can achieve any type of UI with this even you can create ditto functionality(UITableViewController) with this but vice versa not true.
For eg.
tableView inside UIviewController
You can do it in either way. If your viewcontroller is going to have a tableview alone, then u can use a UITableViewController or else use UIViewController and set the delegates and datasource
Is it possible to add a pull to refresh in a normal UIViewController that does not have a tableview or tableviewcontroller? I want the functionality to repopulate some fields that I have in my view controller.
Are you using a UIScrollView or UICollectionView? In both of those cases you can add UIScrollViewDelegate methods, specifically scrollViewDidScroll to your delegate and there begin your update when you want to.
If you are not using a scroll view, you could use a UIPanGestureRecognizer to do the job.
You have to make your own. You can e.g. use UIScrollView for this.
you can use this custom control (https://github.com/spbvasilenko/VASRefreshControl) it can be used with a scroll view.you will need to put your view in scroll view. hope it helps
I have a reusable UIViewController subclass (an audio/video player, let's call it MediaController). It works ok when I add it to some other view controller as a child view controller, however my requirement is to also add it in a UITableViewCell subclass. Since -addChildViewController: is a method of UIViewController, I'm adding my view to the cell like that:
self.mediaController.view.frame = self.containerView.bounds;
[self.containerView addSubview:self.mediaController.view];
(containerView is just a placeholder view in the cell's view hierarchy).
However, this causes problems, first because MediaController is having some logic in -viewWillAppear and -viewWillDisappear (that of course never get called) and second because it seems that autolayout does not work properly when MediaController's view is added to the cell.
Do you think I have some other option (maybe use the UITableViewController that owns the cell as a container?) or I will not be able to use this MediaController at all?
This question is the most relevant when I search, but it still doesn't solve my problem.
Thanks!
One thing I might try if it's possible is to have a UITableViewController that has static cells.
If you're using a UIStoryboard drag and drop a UITableViewController and change the content to Static Cells then in the cell you want to have your MediaController drop a Container View into that cell. Then drag and drop from that Container View to your MediaController and setup an embed segue.
The appropriate viewLifecycle methods should be called when displaying.
Here is the UIStoryboard setup
The other answer from aahrens did not work for me since I have a complicated table view and I was not using storyboards from the beginning.
What I ended up doing was to pass a weak reference of the UIViewController to the cell, so that I can make the "normal" call to -addChildViewController:. Ugly, but works fine.
What I have: 10+ view controllers using a UITableView with custom UITableViewCell. Each view controllers load different data and forward to different sub-pages, thus they cannot combine together.
The aim of the change is to centralize the management of table view's look & feel in a single custom UITableView subclass. But since the data loaded by each view controller is different, I think the UITableViewDataSource and UITableViewDelegate have to be assigned to its original view controller class.
How do I make the change? Or I am thinking at wrong direction?
A tableview's datasource can be separate and independent from its delegate. So, put all of your appearance configurations in a UITableView subclass that implements its own delegate methods, and then create a separate NSObject subclass for each tableview that is responsible for the datasource implementation.
You could make a superclass for all your view controllers that collects all the common logic.
In the Object Library of Xcode, there are two options one can use to create table view - table view and table view controller.
What is the difference between the two and when would they be used ?
A TableViewController is a ViewController with a TableView built in. This will have the delegate methods needed already declared and setup. This VC is already a TableView delegate and datasource. It cannot be resized. Upside is ease of use, downside is very limited flexibility.
A TableView is just that a TableView (subclass of UIView). It can be added to a ViewController and resized, used alongside another view based object, etc. The upside is the flexibility, the downside is that you have to setup the delegate and datasource methods yourself (in my opinion, well worth the time to get the flexibility).
One other note is that when using the new Static TableView cells (part of iOS5), you have to use a TableViewController.
The UITableViewController is a subclass of the UIViewController. It already assumes you will have UITableView as your rootView, so you already have access from the code to a tableView (self.tableView). It implements the UITableViewDataSource and the UITableViewDelegate protocol. It also gives you alot of methods for you to override. It allows you to not depend on XIB file, because you already know what you will have (UITableView as a rootView).
The UITableView is just UIView, normally you will have to comply to the protocols I have referenced above in your UIViewController in order to populate (data source) and work with it (delegate), and you probably have to create an IBOutlet for your UITableView.
On one hand you have speed but you are not as flexible as the other path. On the other you have the opposite.