I was wondering if this nice master-detail transition where you click on the tableView cell and it expand to disclose the detail , with the cell's label being the navigation bar title is an interface which is part of the SDK object library or it is a customised one?
This is a custom transition between ViewControllers.
There's a nice example of a few transitions (including this one) in this library.
Of course you'll need to add the tableview etc' but this is a great place to start.
I've tried few things but so far this is the best option I could think of.
Animating the frames of all the visible cells and making use of childViewController is how I achieved it.
Animation test project
https://github.com/armaluca/iOS-App-Store-Explore-Section-Animation
Would be nice to know any other possible solution and ultimately to know how Apple did it!
It is custom implementation.There is no API in UIKit/UITableView which implements this behaviour. Only animation to present a cell is there(which I think is used here).
This behaviour can be implemented like-
Add sections(News, Productivity, etc) in table with zero cells(numberOfRowsInSection: = 0 for all sections). Then on tapping any section just reload that section(reloadSections:withRowAnimation:) by adding a cell to it(numberOfRowsInSection: = 1) and animation(maybe UITableViewRowAnimationMiddle). Scroll that section/row to top in same animation loop(UI update cycle).
Is the iOS 7 Apple Mail app is using a UITableview for the composing and viewing message screens? If so, why?
The composition screen appears to be using a UITableView with a UITextfield for the subject row and a UITextView for the message row. What is the benefit? There aren't any table rows similar enough to be reused (Max is 6 if you include cc and bcc), so I don't see a performance benefit. There is no Edit mode (i.e. move, delete rows) on these two screens. The resizing table rows necessary to accommodate long messages seems like an unnecessary headache.
I'm working on an app with a similar text input layout and number of fields. I initially planned to use a UIViewController with UITextField and UITextView placed on a UIScrollView. Examining the Mail app, I'm assuming there's a reason Apple would use a UITableView. Though I don't see what it is.
Insight appreciated.
Table views are REALLY good at a few things, and one of those things is creating forms. All you really need to do is add the fields to the cells and do a little cell customization, and the table view handles all the spacing, formatting, rotation, scrolling, etc.
I built an open source iOS form building library that is build on top of UITableView for just these reasons. (https://github.com/mamaral/MAFormViewController) In my case, if you need to move around or add a new field to the form, it's as simple as updating the data source with a new form-field cell, as opposed to creating a totally new textField, configuring it, determining the frame, moving everything above and below it around accordingly, etc. I would suspect these reasons are similar to why Apple would use table views for forms like the above.
The class chain is:
NSObject - everything subclasses this. you have to be really crazy to not subclass it
UIResponder - anything that responds to user input should be a subclass of this. the message view responds to user input
UIView - anything that draws to the screen should subclass this. the message view draws to the screen
UIScrollView - anything that scrolls should subclass this (note: that's not how it works on OS X! Only on iOS!). The message view scrolls, so it needs to subclass UIScrollView
UITableView - anything that has rows of data should subclass this. The message view has four rows, so it should subclass it.
Basically, it subclasses UITableView because it needs all of UITableView's functionality. So why not subclass it? You are saving yourself thousands of lines of code by doing so.
Duplicating all of UITableView's functionality is very difficult.
Chances are if you write an app without subclassing UITableView, it will be so sucky Apple might even reject it from the store, telling you to go back and make it work properly. Which would mean subclassing UITableView or else writing thousands of lines of code — for example Voice Over is a huge pain in the ass if you don't subclass UITableView.
If you don't want to restrict yourself to rows of data, consider using a Collection View.
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
What I’m basically trying to is to implement the control segment/tableview as in Mailbox (see it around 2:00: http://www.youtube.com/watch?v=FG-h8pDXfoE&feature=youtu.be&t=2m)
I am using Core Data in one UITableViewController hooked up to a UITableView.
When user toggles the UISegmentedControl, the TableView is reloaded with a different set of NSPredicate, and UITableViewRowAnimationRight/Left, kind of makes it appear that that a different table view slides in and replaces the old one.
As the number of cells increase, the performance of this design decrease dramatically, and it could also look much better.
I can see a few different ways of going about it, but I figured I'd ask you guys for some pointers to head me in the right direction:
What is the best way to have a segmented control to toggle through multiple tableviews? Should these tableviews be connected to the same data source/delegate?
Take a look at this pod: https://github.com/xmartlabs/XLMailBoxContainer. It makes the UI animation among the view controllers. These view controller can extend UITableViewController or any other view controller.
UITableViewCell swipe animation can be accomplished using https://github.com/alikaragoz/MCSwipeTableViewCell.
I hope this could help you!
It really depends how different each of these table views is. If they are quite similar, it's probably easiest to just share the delegate and data source and have some conditional code.
In fact you can just have a single table view, but have different cells / configuration depending on your current context.
Could be as simple as having adding some conditions to
-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
Another approach would be to use view controller containment. You would create a UITableViewController for each and then have parent view controller with segmented control which swaps child view controller accordingly.
As for the animation and performance, I can't really see any problem. You can get the animations without much effort if you use NSFetchedResultsController, see an example here: https://developer.apple.com/library/ios/documentation/CoreData/Reference/NSFetchedResultsControllerDelegate_Protocol/Reference/Reference.html.
See SBSegmentedViewController. I wrote it for exactly what you're trying to do.
I am trying to build a custom UIPickerView replacement class mainly for learning purposes but with a view to implementing this within an application I am developing. I have put a lot of time and effort into the UI of my application and now the default UIPickerView just doesn't fit right.
I saw this Dribble mock up of a really slick looking date/time picker but realise that theres not a chance in hell that UIPickerView can be customised this heavily without some major hacking.
After a whole lot of reading and investigation, I have found that UIPickerView uses UITableViews for it's components rather than a plain UIScrollView as I had first assumed. This is confusing for two reasons:
Customising UITableViewCells is a major pain in the derriere. It's not that it's hard work, just laborious and rarely yields the required result. Somehow UIPickerView manages to pull this off though with very little overhead. I would assume that each row in a component just uses UITableViewCellStyleDefault with a custom view for it's contentView but you know what they say about assumptions.
The second thing that is throwing me off is that UIPickerView conforms to the UITableViewDataSource protocol, but not the UITableViewDelegate protocol. This seems a little odd as the delegate is responsible for providing the correct height via – tableView:heightForRowAtIndexPath: UIPickerView however does allow you to set the size of a component via – pickerView:rowHeightForComponent:
In line with this, it also seems a strange choice to utilise a table view as natively these do not "snap" to a specified row the way a scroll view would with pagingEnabled.
Can anyone offer up an explanation of why the default UIPickerView doesn't conform to the aforementioned delegate? Would it be easier for me to implement my custom picker with a UIScrollView instead or should the UITableView provide the functionality required?
UIPickerView actually conforms to UITableViewDelegate protocol but just does not expose that in public headers. You can check that yourself using class_copyProtocolList function.
Using UITableView internally makes it much easier to implement pickers with large amount of rows as UITableView provides great support for reusing cells, otherwise Apple would need to reimplement that logic once again for picker - that would not make much sense (sorry I don't see any big problems in customizing UITableViewCell for this case, so it is hard to comment on that)
As UITableView is UIScrollView subclass you can make it "snap" to a specific position, check scrollViewWillEndDragging:withVelocity:targetContentOffset: method in UIScrollViewDelegate protocol that can be used for exactly that purpose.
Custom UIPickerView are done by mimicking it's behavior using an UIViewController subclass containing as many UITableView you need for fields.
Eg: if you want a time picker, use 2 tableviews
You should style them in a xib using images and such.
What's -kinda- hard about reproducing the behavior is the part where UIPickerView "snaps" to the closest cell, and especially getting it right.
Also, cells in a UIPickerView are simple, just no borders/delimiters between cells, text label is centered, and voilà. What you see are just images overlaid in front of the UITableViews.
As to why it doesn't fully conform to the UITableViewDelegate, it's because in fact, it's a lightweight UITableView that snaps automatically that is used internally in UIPickerView. Thus, it lacks some delegates that are not specially useful for this.
But I guess we all agree on one thing: Indeed, building custom UIPickerView is a big pain and should be easier.
Take a look at this component, looks quite nice, though I haven't tested it myself. computerlogicx/AFPickerView
I managed to implement an "alternative" UIPicker by extending UICollectionView.
Although UICollectionView is usually used for cases where you have multiple items in a section, you can just have one item and it works fine. If you enable paging you get similar behaviour to a UIPicker, but it has a "stickier" scroll that only lets you scroll one item at a time, which might be better if that is what you want. Furthermore, you can scroll vertically or horizontally. You could even have a 2D picker with some extra code.