Ok, so I have a normal viewController that has a UIScrollView in it that gives details about distilleries. What I wanted to do was have a list of spirits that are distilled at the distillery that they are reading about. So I attempted to implement a UITableView inside of my UIScrollView, and after hooking everything up and writing all the delegate and datasource methods I come to find out that a UITableView will not work inside of a UIScrollView. So does anybody have any ideas as to what kind of User Interface Object I can use to accomplish something like a UITableView's dynamic characteristics? I don't want to use a UITextView because it just looks cheap and unstructured. I need something that can dynamically change the number of items shown because not all distilleries will have the same amount of spirits distilled there.
If you are implementing a UITableView, there is no need to create a UIScrollView.
As a UITableView will automatically increase its size and behave like a scrollable view whenever the content size is larger than the screen.
Related
When should I use which, and what are the disadvantages or disadvantages of each? I'm mainly confused with scrollview vs collectionview, I know tableview is limited to one column (I heard it gets messy when more than one column), but scrollview difference with collectionview seem the same to me.
Both CollectionView & TableView are basically subclasses of UIScrollView.But as compared to UIScrollView here you are provided with proper methods to provide your dataSource & delegates to handle operations user performs on data. Along with this you are provided predefined layout classes.
Now to choose between them completely depends on your UI Requirements. Suppose you want to display just a list of items with a simple UI go with TableView.If you want a custom Layout like a grid or like the one you see in Apple's photo's app CollectionView is the choice.
if you have a complex UI & you have no idea about Custom CollectionView layout classes go with scrollView.
Consider UITableView and UICollectionView first and if you cannot achieve the effect you want with them, try UIScrollView then. UIScrollView is more basic class. UITableView and UICollectionView have more delegate method for us.
If you want a list,UITableView would be better. And if you want a multicolumn,use UICollectionView.
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'd like to implement a feed in iOS 7 that is only pulling new data if it appears the user has a chance of viewing it. I know UITableView is a subclass of UIScrollView that does this well, but I can't get the cells to behave the way I'd like - I'd like it to look similar to facebook or twitter's newsfeed where you can reload by pulling down and load more by hitting the bottom.
I've seen other questions such as this but I'm looking for vertical scrolling only, with absolutely no horizontal movement. I'd like to use a method calling (for example) nextTenPostsFromIndex: that instantiates from zero, and applies to whatever index was the last on the screen if hitting the bottom.
My question: Is the best way to go about this to create a UIScrollView, place a subview inside of it, and programmatically space them on the available scrollview space, and apply the same drawing methods again with repopulated data if nextTenPostsFromIndex is called or checkForNewPosts (if pulling down from the top)? Would this be a reasonable way to implement Facebook's iOS7 newsfeed, or others like it?
Short answer: No. You really ought to use UITableView for things like this. You can use a custom cell or whatever you want. If it helps you, also know that since UITableView is a subclass of UIScrollView, you can do anything you would normally do with a scrollview, including assigning a delegate which acts based on the current position when scrolling.
I would like to know how to handle, for my iOS app, the following situation:
I have to deal with something like this (basicly this is an article with comments, received from a server):
=- Text and Images -=
=- UIWebView -=
=- List of Comments -=
Now, I came up with two solutions:
Have the content above the list of comments wrapped in a UIScrollView, and create Views for each and everyone of the comments (don't know many of them could be), and
Make the list of comments a UITableView, and the above content its Header.
Which of these (or possibly another if you have any recommandations) should I choose? It may look not very important, but I would like to know this, so I could use the idea in further developing.
I would use a UITableView with a custom UITableViewCell wich holds the comments.
It will definitely have a better performance the UITableView than the UIScrollView since the UITableView re-uses the cells.
Using a UITableView you will just have to worry about customising the cells for the comments.
Otherwise if you want to use the UIScrollView in case you have a lot of comments you will have to create manually a way to reuse them which is what the UITableView does.
If you want something like facebook, so that the context + comments both are movable,then go with option 2.
But, if you want content always at the top, go with option 1.
Indeed, UITableView is a subclass of UIScrollView.
And If you think you might have many comments like (50+),
If you use scrollView, then you should have to supply scrollView with those number of UIView objects.
But, if you use tableView, it perfectly reused already created views.So evenhough you have 1000+ comments, it just uses 5 UIView objects
So Path uses this type of page where there is a view above their customized looking table that is a background photo, which contains some user info among other things. I'm trying to recreate something very similar to this.
So lets say that I hypothetically wanted to make a view that shows exactly the way the Path app does, but instead of that weird customized version of a table view that they have, there is an actual table. How would I do something like this? The reason why I would need there to be another UIScrollView embedded into the view is because the entire thing needs the capability to scroll. I'm trying to be as detailed as possible, but its a little difficult to explain.
What I'm imagining is going to happen if I just tried it right now, is that I'd embed a UIView above a UITableView within a UIScrollView that's the size of the frame, and when I'd go to scroll, the user would only scroll the UITableView, and not the entire thing at once. Hopefully that helps convey my doubts.
Another possibility is that I'm totally over thinking this, and I can simply just subclass a view in the header of a UITableView and it would stretch the width and height that I'd like. Hopefully this is the way as this would be easy!
Anyways, can anybody weigh in on this?
Path just uses a normal UITableView with UITableViewStyleGrouped.
The custom view at the top is the header of the first section of the table.
They also access the UIScrollViewDelegate method of the UITableView to change the look of the view (I think the image is moved) when the scroll view scrolls.
If you'd like a tableview that only scrolls within a part of the view and other stuff above it then you need to use a UIViewController. Then you can make it conform to UITableViewDelegate and UITableViewDatasource and add a UITableView and make the view controller the datasource and delegate.
Then you can also add a UIScrollView to it as well.