Looks like iOS makes our life difficult for simple things that should be accomplished in seconds with auto layout.
Anyway I want to place a UITableView inside a UIScrollView (I know that tableview contains scrollview but this is not what I want). The View ierarchy is
OuterView
ScrollView
ContainerView
View 1
TableView
The expected result is to disable tableview functionality and the scrollview to scroll view1 and tableview together.
The problem is that the height of the scrollview is the devices height whatever the device orientation. If i change the tableview frame and content size to the one calculated by all rows it does not adapt to the scrollview content size. Why? What's auto layout doing then?
I have set constaints like Trailing-Leading-Top-Bottom spacing to all view as well as width and height equality between outer and container view.
I cannot find a SIMPLE tutorial for scenarios like this one.
The Apple documentation discourages embedding UITableView within a UIScrollView because it can cause unexpected behaviour:
You should not embed UIWebView or UITableView objects in UIScrollView objects. If you do so, unexpected behavior can result because touch events for the two objects can be mixed up and wrongly handled.
This is likely why you are having trouble finding a tutorial. Why do you want to embed a table inside a UIScrollView? It may be more effective to designate rows in the UITableView to act as the content you wish to put in the UIScrollView.
Related
I am using scroll view. In my scenario, When contents are added dynamically in content view of scroll view. The view height must be increased automatically and content is added to the bottom with scrolling functionality. I tried the following. There is no particular way of scroll functionality. I don't know why scrolling is much complicated in iOS. Why scroll view not work the way like table view scrolling, table view taking any number of amount and scrolls. Finding youtube videos too not working as it has fixed height in advance .
Inside your scrollview you must add a UIView. Add a height constraint to the UIView and programatically change the height of the UIView depending on the content you are adding to this UIView. This scrollview will work if the height is large.
I have Viewcontroller in which I set the scrollview. In the scrollview I have tableview which is in the Container and just below the container I have an textview and some other UIViews when I set the tableview frame size equal to content size and tableview scroll property false so that only scrollview scrolls when the content size increase the textview goes up to tableview and I want that when tableview content increase then textview also goes down and parent view frame size increase and decrease as the content size
This look like a job for a UICollectionViewController. If you want to take a look here
you can get a better understanding of what they are and how to use them.
Basically you want to put each of those UITableViews, UILabels and the UIButtons in it's own cell(buttons need to be arranged) of the collectionView then the cell with the buttons try to use a stack view with the image. This will automatically set the different sections apart from each other. I know the idea of a collectionViewCell containing a tableView may seem weird but check this out
Another solution is to get crazy with constraints and autoLayout. I don't recommend this route because autoLayout will make decisions on it's own if the exact layout is not explicitly declared. Basically you'll set the constraints by pinning the tableView and labels to each other and the container they are in.
Checkout Apple's docs here
Good luck and let me know how it goes
I would recommend using a xib (if storyboards is your preference) or programmatically embed a tableview in the Scrollview Controller. Set a default cell height and then calculate the height of the Tableview by grabbing the amount of cells (which you'll normally get from .count in an array).
Afterwards, constrain the top, left, and right constraints of the tableview to its parent. You can imbed these in a scroll view for ease. Then if you want default text underneath it, all you have to do is constrain the top of the textview to the bottom of the tableview.
Do the cell for the button's. As the post above said, buttons might be best done in a CollectionView, so you can either create a default cell (xib again is useful) or use a prototype cell in storyboard. Collection views are the same principle as tableviews when it comes to populating data, they are just formatted differently and insets/spacing between cells.
This should help!
I am looking for a way to build a UICollectionView with a vertical flow layout that is embedded in a UIView. the UIView acts as the datasource/delegate for the containing collectionview. The behavior I am looking for is that the collectionview itself has its scroll disabled and the containing UIView grows as you add more rows to the collectionview. How can this be achieved?
I think you can achieve this by following steps,
Embed the UIView which you currently have into a UIScrollView(Make its constraint respective to its super view).
Then add height constraint to your UIView and create an outlet for that height constraint in our view controller, so as of now when the height of UIView gets increased the scrollView content size will also get increased.
Then place the UICollectionView inside the UIView and make its top, bottom, left & right constraints to UIView.
Now increase the height constraint constant value based on the number of collection view cells in the collection view.
I hope this will work for your scenario.
But if in case you are free to explain why you need to achieve this kind of behaviour it would be nice, because I cannot able to figure out the need for it.
This kind of scenario could be achieved. Here is rule of the thumb:
You should not specify height of you view, that will be contains unscrollable collection, pinned to it, and it should be embedded in UIScrollView using equals width, and pinned to all sides with margin. Auto layout makes things work.
Otherwise, is there any important reason to disable scrolling and make UIView delegate / data source for collection?
The problem I am forcing is:
I have 1 big scrollView and I have to add to it 5 subviews programmatically
when I don't know what heights the sub views will have :(
Is there some API to do so ?
or I have to count the subviews heights manually and add them with CGRectMake
based by calculated sizes?
What I would do is use Auto Layout. If you add your subviews to the scroll view using internal constraints, then these constraints can determine not only the distance of the subviews from one another but also the distance from the imaginary content view that surrounds them. The scroll view then uses the size of the content view as its contentSize, and the whole thing becomes scrollable. And this works despite the fact that you don't know the heights of any of the views, which is exactly what you're after.
I have been struggling with this for a few days now, and I am looking to see if someone can help me with this AutoLayout problem.
In my iOS7 application, I have a UIView that has a UIScrollView and inside it a UIView(container) with some elements positioned. I have in there, a UIImageView, UITableView, UICollectionView, UITextView and a MapView. There is no height constraint on the UIScrollView and the container UIView. There are no height constraints on the UICollectionView and the UITextView.
What I want to accomplish is
The UITextview should expand to the content size as in all the text should appear without any vertical scrolling enabled for the UITextView.
The UICollectionView should always show all items and there should not be any scrolling enabled there as well.
Overall, I want a UIScrollView with items in it, that scale based on content. I have tried numerous things, but failed.
If anyone has pointers or suggestions on how to go about doing this, it would be very helpful.
OK, I would go about this in a completely different way.
First, get rid of the scrollView completely.
Just use a UICollectionView for this entire interface.
The UICollectionView can take a UIView for a section header. Make this UIView with your UITextView inside. You will need to manually calculate the correct height for your UITextView (and UIView).
Something like...
CGSize size = [theText sizeWithFont:<the font used> constrainedToSize:CGSizeMake(desiredWidth, CGFLOAT_MAX)];
Then just populate your collection view.
By doing this your collection view will control all the scrolling. Because you have set the textview to the correct size in the header you will have all the text there.
This is how I would go about it:
I assume your issue is with the height of the views, that affect the scrolling.
In the textViewDidChange: I would set the frame of the UITextView same as it's contentSize. When they are both the same, scrolling gets disabled.
After populating your UITableView and calling reloadData, I would set it's frame same as it's contentSize.
The mapView (MKMapView, I suppose) has the same frame throughout, I suppose. So you just use it's fixed height. If it changes height, you must store it's changing height each time it changes.
Once you have all the heights, add them up, and set the frame of the outer view same as then combined height of the inner view. Iterate this to all nested views, beginning from innermost views, and moving to outer views.
The catch here is, every time your content changes, the frames have to be resized. Hence changing the frames in textViewDidChange:, after reloadData, etc makes sense.
EDIT : One thing you might want to do first is, getting rid of redundant views. Your view hierarchy seems Rube Goldberg to me. The lesser views you have, the lesser work you will have to do.
Ok.. so I solved this problem by creating a IBOutlet for my NSLayoutConstraint on the UITextView in question.
I simply computed the height and then applied it on the constraint and it worked..
#Fogmeister - Your solution will also work, but it would require me to rewire a whole UI page.. Your approach is definitely a feasible one and shall keep in mind for future iOS apps..