I've read in some forums that UICollectionView is better than UITableViewController when displaying feeds, some like Twitter feed or Medium feed.
Is that true? And if it is why should we use Collections over tableViews?
Thanks for your pov
[Your question is a possible duplicate of this one here: When to use UICollectionView instead of UITableView? but I decided to give you a short overview here.]
That's kind of true. It always depends on your use case and UI. In the end you can also use a UICollectionView to build your Table. It's all just easier one way sometimes. And sometimes not possible with one of them.
This is how Apple would describe it:
UITableView Displays hierarchical lists of information and supports selection and editing of the information.
Apple Developer Documentation - UITableView
UICollectionView Manages an ordered collection of data items and presents them using customizable layouts.
(Apple Developer Documentation - UICollectionView)
To answer your question:
I would mostly use a UITableView because they do a great job in displaying lists of information. But if you see it's going to be more complex, use UICollectionView. There is a good YouTube video series on how to customize them to build a twitter news feed. It's a good example of how to use it and when to use it. Check it out
To sum up:
Use UICollectionView for more complex and advanced things where you need a lot of customization.
Use UICollectionView for things that are placed in a grid with for example three pictures in every row.
Use UITableView for simple and advanced lists but not necessarily if you need a feed like twitter uses (to point out an example).
Keep in mind that you can use custom cells (with or without XIB files) in a UITableView!
However just choose the way you are most comfortable with.
Related
I develop an app for online shop that should has some design features that I don't know how to implement. Lurking for it second day, but no profit. I suggest, that it should be the simple CV with some custom cells for different needs (banners, products).
Problem - design has scrollable horizontally content in each section and I see no simple way to implement it instead of writing custom flow layout.
I tried to make a tableView with collection view in its rows, but its not working correctly.
May be you know some examples of implementation of same thing in swift or a good way to make such feature without flow layout?
Refer mention link May be help you from this link:- https://ashfurrow.com/blog/putting-a-uicollectionview-in-a-uitableviewcell-in-swift/
I'm just wondering what's the best way to do a screen that looks pretty much like the feed view in the Facebook app. I guess the most obvious answer would be to use a UITableView but there are lot of challenges.
There are comments in every feed item and for that we will have to use another UITableView. And that means a UITableView sitting inside a UITableViewCell.
We can't re-use the cells as there are several different content types.
Determining the height of the cell is again a problem as that depends on the number of comments in a feed item.
I'm not planning to do an app that looks like Facebook but this is just a food for thought! I guess there is a better approach that using UITableView. What do you guys think ?
You can design this type of complex interfaces also with hard code but if the code is organised it will save you more time than taking the challenge of using UITableView.
I am new to iOS development, and I have been doing a fair amount of research. Unfortunately, as the title of my post suggests, neither possibility seems exactly suited to my needs.
I need a lot of customization with respect to the look and feel of each individual table view cell, and I need for my table to have header sections which are clickable. I would actually like for the section headers to have the drill down quality and not the cells beneath each section header.
To my knowledge, the problem with PFTableViewController is that it doesn't easily allow for multiple sections (even less so if I need for these section headers to be clickable and of a different look and feel from the regular cells.) Furthermore, customizing the PFTableViewCells doesn't seem terribly simple either.
However, if I use the regular UITableView even with Parse as my backend, won't I run into some difficulties with respect to loading, pagination, etc...?
I have a pretty good idea of how I would implement this app with regular UITableViews so I guess here is my question: is it worth it for me to try and figure out all of this PFTableViewController stuff?
I should also mention the fact that my table view controller will not take up the entire view but only half of the screen.
Thanks in advance for any and all advice
It seems that a normal UITableView will suit your needs. If you want to customize the look and feel of individual cells, you can just subclass a UITableViewCell and modify it.
In terms of your needs with the headers, it's hard to say without knowing more about your app, but you want to follow standard user interface conventions. Users don't expect headers to be clickable. Instead, they attempt to traverse information hierarchies by selecting table view cells, which then bring them to new views with more information. Based on your, needs I think that a standard table view controller with some customization is what you want.
I have an app which will show over a 1000 items, all of those item details are local ( saved via coredaata) and will ship with the app.
In researching the UI mechanisms to show those items, I am in between choosing uicollectionview or tableviewcontroller with a customized cell.
My question is : Which choice would be more efficient and provide a smoother UI in terms of
dragging?
which one can I customize to load out the 1000 entries I have only enough the provide a smooth scroll, and load more cells as needed?
Thanks.
Both approachs will handle 1000 entries easily if you follow the good practices of view/cell reusing. Additionally both APIs are very similar, so jumping from one to the other is not that hard.
The main difference between the two is how you want to display those 1000 items. UITableView has a couple of styles of cells stacked one over the other. You should not try to bend it to do any other kind of things too much complex than that kind of layout. UICollectionView is a much more powerful set of classes that allow to modify almost every aspect of how your data will appear in screen, specially its layout, but also other things. You can see UITableViews in almost every iOS application (for example Contacts or iPod), while UICollectionViews are more difficult to see (the grid in Photos, but also the coverflow in iPod).
So, if you need something standard like most table views in iOS I will choose the UITableView, but if you need more control over your layout, go with UICollectionView.
It's slightly unclear what you're asking, so I have summerized the advantages of both.
UITableView
UITableView is the base mechanism for displaying sets of data on iOS. It's a simple list, which displays single-dimensional rows of data. It's smooth because of cell reuse and other magic.
UICollectionView
UICollectionView is the model for displaying multidimensional data - it was introduced just a year or two ago with iOS 6, I believe.
It's also smooth because of the same tactics used in UITableView - cell reuse, etc.
I am currently working on an iPad application that uses a table view to present data, I was inspired by the iTunes application in iPad that present it's data in multiple columns in a very nice and neat manner, and the most interesting thing is that during the portrait mode the itunes application displays data in 2 columns but when the user switches to landscape mode, it switches the display to 3 columns (since there are plenty of space to display data horizontally).
This is what i'm talking about:
but i found out that iOS SDK only supports single column for tableview (it would be nice to utilize the entire space provided on iPad screen to present data), i did some research and i found out that the best way to present data in multiple columns yet like spreadsheet style is to use datagridview instead, but iOS SDK did not provide any data grid view controls for iOS developers.
I found out over the internet some customized tables like:
AQGridView.
DTGridView.
and also the one from this:
http://usxue.is-programmer.com/posts/14176.html
and the one from this:
http://xebee.xebia.in/2011/04/14/building-editable-gridview-for-iphone-apps/
But sadly none of these ever met the requirements of the application i was working on.
Could you guys provide me some ideas or share some sample codes or links on how to display data in somehow-data grid view, to achieve similar effect used in iTunes application (as shown above).. Any form of help would be pretty much appreciated. Thank you guys!
The summary answer is, place multiple data "views" across in a single cell.
The more detailed answer:
Create custom views that represent the single cells you want. You can for this purpose make them resizable enough to work two across or three across (they will get loaded into 1/2 or 1/3 of the cells bounds).
Then make a custom UITableView cell, that can take two or three data items - load up an instance of the custom view previously created in the cell for each data item you have, placing them next to each other. You can have the cell do the view layout when groups of data items are added.
In the cellForRow code in the table delegate/datasource, you use your data source in groups of two or three (and report the row count accordingly) to pass along to the custom cell.
Sorry I can't share code, but I have used this technique before in other applications.
What's wrong with creating a UIView class to represent a single cell, and another that lays out an array of those cells in a grid? Put your grid view in a UIScrollView and you're about done.
UITableView is obviously a pretty complex class. Much of that is to make it very general, very reusable, and able to support a huge number of rows. Your class doesn't necessarily need to be that complicated -- if you have a fairly small number of cells, your "grid" could really just be a UIView in which you lay out cells in rows and columns. UITableView removes cells that aren't seen in order to save memory; you might need to do something similar if you have hundreds of cells, especially if they're large, but a few dozen probably won't require that.
In short, since you need a grid view for a particular use, you don't need to do all the extra work that would be required for a general, reusable solution.