I have to build a tableView with a top bar "slider" like the one in the youtube app in the picture below.
I just wanted to ask if it's better to:
Use just one tableView and switch the content by changing some switches in the delegates methods and reloading all the rows
or
Use two tableViews and hide the one that's not displayed
If none of the two methods above is the best one please point me in the right direction, thank you.
Option 1 :
Take a UISegmentView on the top and have a single UITableView. Change the content of UITableView on valueChange event of segment.
Option 2 :
Have look at this awesome library by Yalantis - Segmentio. I have myself used this on couple of occasions. Handy when you have to horizontally scroll the segments (exactly what you need in your case). You can have a single UITableView for this as well.
Option 3 :
Check out another useful library by Yalantis - Persei. Just hard scroll the table to see these options. Again, single UITableView.
In all, the best solution, in my opinion is to have a single UITableView. Working with multiple tableView might seem a clean way for a start, but trust me, maintainability is the key and having a single UITableView would be a better approach.
There are lots of stack-overflow thread and community articles but i just want to know which one is better to show data like App store App(Vertical scrolling of apps and sometimes horizontal scrolling inside vertical scrolling). So far i understand below might be possible solution.
Solution 1:
Collection View inside tableView. So that products can be scrolled horizontally inside tableView cell.
Solution 2:
Number of collection View inside a scrollView stacked one after another if categories are specific.
Is there any better solution to make such type of scenario?. Your opinions will be highly appreciated. Thanks
A general suggestion based on my usage, create a tableview and inside it's tableviewcell create a collectionview. You may use staggered layout for a better user interface. That is what I have been doing, you will build it much easier.
Rest depends on your usage and requirement.
I found that UICollectionView is like an upgraded version of UITableView introduced in iOS6, but when should I choose UICollectionView instead of UITableView?
There are still Apps using UITableView, if UICollectionView can do anything UITableView can do , why people still use UITableView? Is there a difference as far as performance is concerned?
Thanks!
That depends on the requirements. How the application flows determines which type of UI to integrate into the application.
People mainly use the UICollectionview for creating types of UIs with multiple images shown in a grid. This would have complex logic using UITableView, but with UICollectionview, it would be easy.
When using UICollectionview, you don't need to set buttons with tags or other things by getting selected items values. You can simply get -(void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath and in UITableViewDelegate:
`-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath`
You get the selected row instead of the item, so for creating grid or modified items, using UICollectionview is best.
For the listing details of each item, people use UITableView because it shows more info on each item.
Apple Docs:
UICollectionView Class Reference
The UICollectionView class manages an ordered collection of data items and presents them using customizable layouts. Collection views provide the same general function as table views except that a collection view is able to support more than just single-column layouts. Collection views support customizable layouts that can be used to implement multi-column grids, tiled layouts, circular layouts, and many more. You can even change the layout of a collection view dynamically if you want.
UITableView Class Reference
A table view displays a list of items in a single column. UITableView is a subclass of UIScrollView, which allows users to scroll through the table, although UITableView allows vertical scrolling only. The cells comprising the individual items of the table are UITableViewCell objects; UITableView uses these objects to draw the visible rows of the table. Cells have content—titles and images—and can have, near the right edge, accessory views. Standard accessory views are disclosure indicators or detail disclosure buttons; the former leads to the next level in a data hierarchy and the latter leads to a detailed view of a selected item. Accessory views can also be framework controls, such as switches and sliders, or can be custom views. Table views can enter an editing mode where users can insert, delete, and reorder rows of the table.
Here's my criteria:
If a UITableView can do it, use it
If a UITableView needs lots of code to do it or can't do it at all, use UICollectionView.
You have to consider the restrictions on UITableView before making a decision: It's a single column. And you can only customize the cells, but not section backgrounds and such. So if you have a straight-up list of things with no extra frills - that looks like a bog standard iOS view, basically - then use UITableview. If you have custom insets, or a border around each section, use UICollectionView.
I'm actually considering UICollectionView for all things simply because it's very expensive when you start developing your view as a table view, then later find out it can't do that one thing that you need it to do. 1st hand experience ;)
Edit after even more experience with the two: Disregard that last paragraph. UICollectionView requires a lot of boilerplate code to make it work like a UITableView. Use UICollectionView only when really needed. ;)
For simple lists and forwards/backwards navigtaion, use UITableView.
If you need a high degree of customisability, use UICollectionView.
Generally speaking, in software development, it's best to choose the approach which represents "The Simplest Possible Thing".
EDIT: As of iOS 14, UICollectionView can now do lists as well and is now the recommended approach. See this session from WWDC20 for more information and implementation details: https://developer.apple.com/videos/play/wwdc2020/10026/
According to my point of view main difference between collectionView and tableView is that
TABLEVIEW --> show list of items in only one column.
COLLECTION-VIEW -->show list of items in multiple column.
Hope it will help you.
If you choose UITableView for iPhone, make sure you have considered your iPad strategy first. If you want an iPad-specific layout, you may want that single-column layout to become a grid.
Although it's not required, I always use a collectionview. That way I can easily adapt how my collections are presented for differing resolutions. A plus is that it's ready to quickly add new types of cells when refactoring in the future.
I see no point of tableviews. It's very simple to use a collection view to represent a table. IMO.
From my personal experience the two elements should only be compared loosly.
TableView
A TableView is a UI element designed for showing data in a list format. There is certain functionality that comes as standard with a UITableView, such as:
Accessory View
Cell Selection Style
Editting Style (Delete and edit buttons).
The above elements enhance the usability of data when displaying and interacting in a list format. Such as viewing emails.
CollectionView
A CollectionView is a UI element designed for showing content using a custom layout (usually anything that isn't a list). CollectionViews improve functionality of displaying data in completely bespoke layout styles and also dynamically changing layouts on the fly. Some examples are:
Horizonal Lists
Photo Galleries
Thumbnail views
Carousels
Dials
Laying out elements on a map
etc.
CollectionViews also allow for multiple selections.
Conclusion
As you can see from the above, both have completely different use cases and are designed for enhancing the development and usability of their own specific data sets.
If you are looking at displaying anything in a list style with the followin interactions:
- Adding
- Deleting
- Re-ordering
Then a UITableView will simplify this process by providing the support straight out of the box.
Anything else, you should leverage the benefits of CollectionView as you have more flexibility.
Its totally dependent on how your data to be shown.
As mentioned by many above, if you require only single set of data and that too not complex, go for UITableView else use UICollectionView.
UICollectionView is customization friendly.
If you are dealing with multiple cell heights or so, then go for UICollectionView.
Both are depends on the requirements. Table Views also have support for a variety of editing scenarios. This support has not been implemented in the Collection View classes.
If you are converting from a Table View that relies on these methods, expect to do a little extra heavy lifting in the Collection View.
Collection View section headers can be placed anywhere within the view.
and UITableView don't need to set buttons with tags or other things by getting selected items values.
In practice, everyone uses UICollectionView that I've come across, when they only need a UITableView. "It's one-dimensional. It goes up and down. Why are you adding unnecessary delegate methods for layout AND data?". I once spent an extra 2 hours helping a startup find out why their UICollectionViewCell got squished because the owner, who didn't read the Animations manual, nor HIG, nor the UICollectionView guide, decided to use it and add variable heights and anims. Needless to say, he gave himself a headache and much lost time on a non-business-critical issue he could have avoided by simply using a table cell, since there's no extra layout delegate + Nib.
Let me get this straight, I am all for UICollectionView's when your data and display need it. They're very powerful. But in practice, most people I've seen have been using them on lists.
This brings up another flaw. They're also used on short, constant lists that won't change, ever. In this case, just make a Xib. Or write a custom view that stacks them. Why? Because you don't need the memory management for 5 sets of labels with a button or switch. If they might change, then yes, use a list. If you want physics, then UICollectionView works well with a some cool effects. But do you really need to add 5 delegate methods and a layout system for 5 labels that will never move?
Also, I'm not forgetting that iOS has a native stacking view now too. I can never get it to deform how I want, even though I'm quite adept at the 2D and animation systems, so I never use the built-in one.
All I'm saying is, define your requirements. Maybe you don't need either of these, if your UI isn't adding/removing items and refreshing itself. Or maybe you want to write a Card Game and throw them out virtually on a table, then use UICollectionView with a physics system for its layout guide.
Personally I think the UICollectionView can do most of the work which UITableview can do. well, at the same time, it's more complex to use.
I suggest you use UICollectionView as TableView just in case your manager change requirements in the future.
Based on our need we are choosing TableView or CollectionView.
Example:
For phone contacts tableView is best option.
For photo gallery, collection view will be best option.
I had this issue in my current project. Which to use. In my case it was simple really. I needed both. I needed my view to look like UITableView and also to change its change / layout. So, UICollectionView was used. I also use UITableView everywhere I don't need any extra customisation. Since UiTableView comes with a default layout that includes images and text - I use it for simplicity.
Based on our requirement we choose UITableView or UICollection view.
If we want to display images or items in grid type or if we need more customisability we use UICollectionview.
For listing each item with details and subdetails we use UITableView.
UICollectionView:
The UICollectionView class manages an ordered collection of data items and presents them using customizable layouts. Collection views provide the same general function as table views except that a collection view is able to support more than just single-column layouts.
UITableView: A table view displays a list of items in a single column. UITableView is a subclass of UIScrollView, which allows users to scroll through the table, although UITableView allows vertical scrolling only.
As per my view for Grid View display use UI Collection View.All other list view use UITable View
I have a table view with expanding cells for each of them. I want to make every expanding cell be a new table inside of the bigger one. Is that possible? I've done the research, someone said that duplicate UITableView cannot put in one file.
For example
dish order1
=================
dish order2
rice
coke
===============
dish order3
which every "dish order #" is a cell of a table, and when you expand one cell, there will be a smaller table appears. I've done all the expanding stuff. But don't know how to put a small table into a bigger one. Thanks
Well if i understand your question correctly, what you search is called nested tableView, here's some examples:
SDNestedTable
ExtensiveCell
CollapseClick
JKExpandTableView
Good luck.
It would likely be impossible to put one table view inside of another table view, and if you did manage to do it, it would be awful. Ask yourself, have you EVER seen this in a commercial app? If not, as a novice iOS developer, you are out of your depth trying to invent new UI paradigms.
Master the existing UI tools first. Don't try to use the UI elements in totally novel ways until you have a strong feel for the standard way to use them. Expect this to take 6 months or more.
Others have suggested a sectioned table view where initially only the first element of a section is visible, but when you tap on it, it expands to add other rows. This works quite well.
Another approach would be to use a master/detail UI, where tapping on one table view cell pushes a new view controller the uses a new table view to display detail information about the previously selected item. There are some use cases where you might have several levels of increasing detail.
I really do not think you want two instance of UITableView, instead what you want is a sectioned UITableView which expands when it's header is tapped. Apple has a good sample code for this here:
UITableView expand/collapse
i have demo for you , just got from github..
https://github.com/mitsBhadeshiya/ExpandingCell
i hope this is helpfull for you...
Have you considered using one UITableView with multiple sections? You can accomplish what you are depicting above with only one tableView.
Since this was a problem for many people in the past, iOS 9 has a thing called Stack View, it does exactly what you are saying.
Check out this article.
This is related to this question
ios filter options similar to the apple store (dropdown list)
I tried using a uitableviewcontroller instead of a pickerview as I couldn't understand how to use the picker view if I need it popping out (any info on it would be appreciated).
Now this is what I did.
I have a VC that calls out a "FilterVC". I only have one FilterVC that is called by 3 different "filter buttons", and I will just populate the VC depending on the button. The issue is, one button might have just 2 items that is needed to be shown, another one might containg up to 50. Was wondering how do I adjust the height of the popovercontroller that contains the uitableview? Also, is this the right way in dealing with popovers, 3 segues connected to one VC??? (It needed an anchor point)
Here's what it looks like
As a follow up question:
Is this the right way to do it on an ipad? I feel like most people prefer the uipicker. The guy that answered my first question said it's more of a design thing. Now since I'm no designer, as a user, do you think uitableview is more appealing?
Thanks for your time!!
In the view that you're showing in the popover, set self.contentSizeForViewInPopover as soon as you know the size and before the view is displayed.
The main benefit of using a table view over a picker is that it has a scroll indicator so you can see how long the list of options is. Also obviously that you can control exactly how the list is displayed. So the table view should be better if it fits in with your UI style and particularly if the list of options is long.