I'm currently creating an update of my iOS application and I'm a bit stuck. I've tried to googling around but cannot find a decent answer on this.
I've a menu which links to different views. And I'm not really sure if I've done it the best method.
I've created a view, and added the links into a stack view. Should I considering changing it all to a tableview? or a collection view? Or maybe there's another way?
The current look:
Should I change this to a tableview? collection view? or something else? Or just let it stay as it is?
If the number of items in your menu changes at runtime and is large, you should use a table view, because a table view is good for efficiently displaying a screen's worth of items from a large list of items.
If the contents of your menu is small (under maybe two screenfuls of items) and fixed at compile time and you are using a storyboard, then you could use a table view with static cells, if you can make it look the way you want.
If the contents of your menu is small, then you can use a stack view (inside a scroll view) if that is easier for you. There is no particular advantage to using a table view over a stack view to display a small amount of content, unless you need other features of the table view (like the ability to select/deselect rows).
Based on the screen shot you posted, I'd either use a table view with static cells (since the screen shot is from a storyboard) or a stack view, depending on whether I can get the appearance I want from a table view. If, as in the screen shot, the buttons must be centered vertically, I'd use a stack view, because it's easier to vertically center the content with a stack view.
Look, the fact of have many itens on your screen is clear on the mobile applications, to make it easy, we have collecions view like UITableView and UICollectionView. On the UITableView's case, this implements the scrolling and have methods do handle the operations' list, you can see the documentation to check these methods: https://developer.apple.com/documentation/uikit/uitableview.
Main reasons to use UITableView
Implements scroll behavior.
Independent of size screen you can access all itens.
Easy to detect interactions like tap on cell.
Easy to make changes, like insert and remove content.
The UITableView exists precisely to solve problems like you has.
I have a collectionView with each cell showing an image. I want to implement a drag and drop. This will solve two purpose.
Rearrange cells.
When a image is dragged into other, it forms a collection (think of it as a group containing two or more images).
This behavior is inline with the home screen folder where app icon can be grouped into folders.
Please suggest how I can implement this.
This isn't trivial but it is not impossible either.
Reordering is simpler, and you can take advantage of UICollectionView's methods:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionView_class/#//apple_ref/doc/uid/TP40012177-CH1-SW67
Reordering Items Interactively
Collection views allow you to move
items around based on user interactions. Normally, the order of items
in a collection view is defined by your data source. If you support
the ability for users to reorder items, you can configure a gesture
recognizer to track the user’s interactions with a collection view
item and update that item’s position.
To begin the interactive repositioning of an item, call the
beginInteractiveMovementForItemAtIndexPath: method of the collection
view. While your gesture recognizer is tracking touch events, call the
updateInteractiveMovementTargetPosition: method to report changes in
the touch location. When you are done tracking the gesture, call the
endInteractiveMovement or cancelInteractiveMovement method to conclude
the interactions and update the collection view.
During user interactions, the collection view invalidates its layout
dynamically to reflect the current position of the item. If you do
nothing, the default layout behavior repositions the items for you,
but you can customize the layout animations if you want. When
interactions finish, updates its data source object with the new
location of the item.
The UICollectionViewController class provides a default gesture
recognizer that you can use to rearrange items in its managed
collection view. To install this gesture recognizer, set the
installsStandardGestureForInteractiveMovement property of the
collection view controller to YES.
To implement the "grouping" behavior, you need to define your cell in such a way that it can determine whether it is a single item and should just display itself, or if it consists of multiple items, in which case it should be able to pop up a view to act as a tray, possibly its own view controller to handle taps independently. This part is going to be hard as you'll need to implement reordering again, and dragging out, etc.
You might want to search Github and others to see if anyone has implemented a "Springboard" type of app that can get you started.
I guess this question is more of a best practice question than a problem solving question.
I would like to have a page on my app that has a UITableView at the bottom of it and some buttons/text above the UITableView but instead of just the UITableView scrolling, I would like the whole page to scroll.
I have been searching around and some people say to put the UITableView inside of a UIScrollView and disable scrolling on it and recalculate the height so the table view is as tall as all of it's rows.
Then I have read some other people say just to put the buttons/text in a Table Row Header and just have that scroll with the whole table view.
Which is the better practice and are either of them frowned upon?
Thanks!
Open the main storyboard and on the bottom right hand side you should see a list of view controllers, buttons, gestures etc.. In that list there should be a controller called "page control" that opts for the page-scroll you are looking for as well as the continuous one which you are trying to get rid of, you can just insertt this in to your basic view controller (via drag and drop). As for the button responsible for the segue (turning the page) you can find that in the list too. I can't explain how to program the button to turn the page step by step as I am typing this on my phone at work right now. If you want I can edit this later in more detail
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 am using a standard grouped style UITableView that returns a custom header view for one of it's sections (using the tableView's delegate method viewForHeaderInSection:). The view that is returned for the section header contains a control. It displays an image and is a control so it can tapped to let the user change the image. My desired UI is similar to the photo for a contact in the Apple Contacts app (a floating imageView-like control in a grouped style table).
The problem I'd like to solve is that touches on the tableView section header go straight to the control. I'd like the table to get a chance to determine if the touch is actually the beginning of a scroll gesture. If not, then the table can pass the event to the section header view for processing.
This is how all the rows in the table behave since I have "delaysContentTouches" for the table on. I suspect the problem is because the section header view is not in the table's view hierarchy. So everything is probably working per spec. just not the way I want.
I want the section header view to behave regarding touches just like rows do (table gets first chance to process).
BTW I am not placing this control in a table row (which would solve the problem) because I want the rounded rect grouped style for all table rows, but not for this one UI element. This control is in the center of my table (header for section 1) which is why I want drags on it to scroll the table.
OK, so apparently this is simulator issue only. On a device my tableView gets the first chance at the event. So I guess I need to listen to the Apple mantra of "always test on an actual device" before posting to StackOverflow. Sorry friends... may my error be helpful to others who, like me, probably spend too much time in the simulator.