I currently have a UICollectionView with a header of a fixed size.
If you pull down then the header moves down leaving a gap above it between the header and the nav bar. The header has a button at the top, a couple of labels at the bottom and the BG is an image.
If you push up then the header scrolls upwards to display more of the UICollectionView items.
This is all working fine. However, we require a change to the behaviour.
What we want...
What we want is for the header to start off the same as it is now.
Pull down
But if you pull down the top of the "header" should stick to the nav bar and the header should grow.
I can do this easily by making the collection view frame smaller, faking a header and accessing the UIScrollViewDelegate methods in the controller.
Push Up
If you push up then the header should do exactly what it's doing now. i.e. stay the same size and disappear underneath the nav bar.
This last bit is tricky. If I go my proposed change for the pull down then it will make this much harder.
Question
How can I include both of these functions?
I'm thinking of maybe having a header but making it completely blank?
Another idea I just had... Make the collection view full screen but set the section inset so has enough space for the fake header. Then I can intercept the scroll view delegate methods like above?
I think this sounds best unless anyone has a better idea?
Can't you just make the header the desired (maximum) size but keep it hidden under the nav bar by calling scrollToItemAtIndexPath:atScrollPosition:animated: in viewWillAppear: of your UICollectionViewController?
As the UIScrollViewDelegate the controller could also take care of positioning the upper right button at the desired position while scrolling.
Related
I have a tableView and I have a UIView as the tableView header. I want the header to move up the screen when I scroll down and act just like any normal cell. But when I have reached the top of the view, where if I scroll up it will just bounce back, I want the tableView header to stick to the top.
One example is like the Facebook app headers. They scroll when you scroll, but if you're at the top of the page and you scroll up, they wont scroll down, they stay stuck to the top.
How do I achieve this?
If you're using a normal tableView (not grouped style) and you only have one section, you can accomplish this by using the section header instead. The default behaviour of this type of tableView is as you described. You'll just have to provide a custom view for the section header that looks like your cell.
If this isn't a possibility, you'll need to take advantage of tableView being a subclass of scrollView, and implement the scrollViewDidScroll delegate method to check content offsets etc.
I have a pretty weird setup due to time restrictions and UI requirements.
The layout is pretty simple: the root view is a ScrollView, with a StackView in it. StackView has two elements, a header (which I wish to collapse), and the content (which is a custom tab bar, and below that, a container view for the tab bar's linked content).
Latter is constrained in height to the ScrollView, resulting in a kind of "sticky header" (the tab bar's top sticks to the navigation bar's bottom) and "collapsing header" (the header view is "collapsed", as it is scrolled out of the view).
This works fine, however I can't seem to find any information regarding how to handle scroll events. What I want is a "single" scrollable view with the tab bar being sticky.
The end result would work like this:
User starts scrolling, ScrollView handles scrolling up until the moment it "bottoms out", then hands over scrolling to the UITableView currently visible. When the user starts scrolling up, the UITableView currently visible scrolls until it hits the top, and immediately hands over scrolling to the outer ScrollView, which will then scroll down the tab bar and reveal the header.
On Android it's quite simple to implement, due to the Toolbar component's extendibility, but on iOS I'm dead in the water how to implement this. I've tried looking up scroll handover, but haven't found anything related to my issue - possibly I've used the wrong search query, but not sure.
How could I hand over the scroll event the easiest way?
I am trying to recreate a UIView I have seen in multiple apps, mainly Shazam. The top half of the screen has some interactive buttons, and the bottom half looks like a tableView with custom cells. When the bottom half is panned/swiped up, the tableView scrolls over the top half with velocity, much like a scroll view.
I have been researching this and experimenting for a couple days now. I have gotten close, but not quite there.
My last approach was a view that had a tableView inside it. When the view was panned, the view would move to wherever the finger moved it to, but then would not have any velocity afterwards. Also when the tableView was panned/swiped down, it wouldn't move the whole view down.
Before that I tried a scrollView that took up the whole length of the screen. That gave the desired effect, but the button wasn’t tappable, and you could scroll the view in the button area, which is undesired.
Does it utilize ScrollViews or is it using a tableView that acts much like a ScrollView somehow.
Here is the Shazam UI/UX I am looking to recreate:
The top portion has interactive buttons, and doesn’t scroll. The bottom half shows content and when scrolled, covers up the top portion.
Below is what I have tried so far: This one is the panning view, which sort of works, but doesn’t have velocity and the tableView doesn’t scroll the view back down.
Any thoughts on a direction I can take from here is greatly appreciated. I am using Swift.
Cheers
This sort of thing is perhaps best done with a collection view and a custom layout — you can have some items for which you set layout attributes absolute to the view, and others relative to the scroll content offset.
There's a great (if wandering) discussion of this and other techniques in the Advanced User Interfaces with Collection Views talk from WWDC 2014.
This is actually simple than it seems at first. Here's how you can achieve this:
Create a UIViewController (not a UITableViewController).
Add some buttons to the top area of the screen.
Add a table view spanning the entire view controller's view. Make sure the table view is on top of the buttons added in the previous step.
Configure the top cell of the table view to be transparent (by setting its background color to Clear). Set the background color on the table view to Clear as well. This way it won't obscure the elements at the top of the screen, unless the table is scrolled up.
Because your table view is now transparent, you'll need to explicitly set the background color on the table cells other than the top one.
Profit!
I am currently using the https://github.com/telly/TLYShyNavBar class to hide my nav bar when scrolling, it works great and is extremely simple to use. But I am using it on a table view controller so when I scroll up my section headers don't move and it looks like this.
How can I move up the section headers to the top of the screen. Or use a different way to move the nav bar when scrolling.
Thanks for the help in advance.
You could use the first TableViewCell as a custom navigation bar by adding buttons to the contentview contained in the TableViewCell. It would scroll up like any other TableViewCell. TableViewCells are mostly just a wrapper for a UIView. You can modify that UIView like any other UIView. Every TableViewCell has a property called contentview which is the main UIView in the Cell.
As an example, you could add a button to the first cell that sends the following message
[self.navigationController popViewControllerAnimated:YES];
You could call that button "Back"
https://developer.apple.com/library/IOs/documentation/UIKit/Reference/UITableViewCell_Class/index.html#//apple_ref/occ/instp/UITableViewCell/contentView
I found a solution for this!
The problem is that, the section header stays at the top value of the contentInset. Even though the navigation bar is out of view and the tableView is visible below, the contentInset will remain same.
You would have to modify the library to increase or decrease the top value of the contentInset, according to the scrolling offset. Try this out and you may post it as a pull request in github.
Hope this helps! :)
I'm having a hard time finding the best way to structure this design.
The top view has a minimum height and becomes sticky when it reaches this height. The bottom view hosts a paging controller with three views within. Each of these views hosts either a collection view or table view with vertical scrolling.
I'm really at a loss on how to approach this. Is the entire view scrollable and I should prevent scrolling on the second view until the top view has reached it's sticky height? Or are each of these views separate uitableviews and the pagingcontroller is just one cell? Should I even be using a pagingcontroller or should I use a scrollview with paging enabled? (the latter was a little rough interaction-wise)
Thank you!
Take a look at the Advanced User Interfaces using Collection View from WWDC this year. This view is very very very similar to the iTunes Connect app interface. The entire session video explains how they created that interface.
I used a similar method to this to create the keyboard in the Emojicate app.
I think what I'd do is actually fake the sticky header. So something like this...
Use only one collection view.
Create a "segmented data source" that contains three data sources. (See the video from WWDC about this)
When the segmented control is changed then update the collection view by changing its layout and (if you want) dataSource.
Make the entire top section a header on the collection view.
When the collection view scrolls past a certain point (when you want to sticky the header) then have a second view that is the compressed header and make it visible at the top of the screen. This is not attached to the collection view at all.
When the segmented control changes you can update the collection view by changing the "selected datasource". The datasource can also contain a UICollectionViewLayout that will update it.
Essentially, the tableview you are talking about is just a collection view where the cell width is equal to the screen width. i.e. fake a table view.
The sticky header isn't sticky at all. Just when it starts to go off screen you can put a fake header there instead.
It will require a duplicate (ish) view and some thinking about how to structure the data but I think this will be easier and less resource hungry than having multiple collection views and page controller and stuff.
If you want me to go through it in more detail let me know but it's a complex subject. Watch the video first.
I would make this part a navigation bar. Should be relatively easy. Just have to customize the back button with a barButtonItem and do a couple of labels in the titleView.
I would make the next part a Table View.
The tableView has 2 sections. The first section doesn't have a section header and the second section doesn't have any cells but just a section header.
First and only cell in this section:
And the rest would be the second section header's view:
This gives you the stickiness that you want because the section header will remain there even if you scroll past it and since the collection has only 2 sections the controls will always remain on top.
I think the collection/table paging part is the hardest part and I don't know clearly how it can be done. But I was thinking it could perhaps be a ContainerView. Each view of the container view would be either a tableview or a collectionview. You would have to add some code to handle the movement of the containerview relative to the second section header (possibly an autolayout constraint that attaches the containerview to the buttom of the first tableview that you implemented above).
I don't think having your tables/collections in a scrollview would be a good implementation. I think I have even read in documentation that developers should stay away from that (but I might be remembering it incorrectly).
I would have:
A "header view" with three subviews:
Fixed height top and bottom views (they stay visible at any size).
A middle view that appears/disappears as the superview grows/shrinks.
A scroll view (table or collection view are subclasses) on that partially covers the header view with a top inset set enough to reveal the underlying header view (the same way pull to refresh views are revealed).
The paging buttons could be set as table/collection view section header views.
Finally track the scroll view's scroll position to keep manually adjusting the header view height.
Another way to see this solution.
Two completely separated parts, a header view and a table view.
A simple header view (blue) that adjusts its subviews as its height changes. More precisely hides its middle subview (light blue) when it shrinks.
A table view that a) partially covers the header view in Interface builder but b) has a top inset as to avoid hiding the header view in the actual device (tableView.contentInset = UIEdgeInsetsMake(60.0f, 0.0f, 0.0f, 0.0f);).
The two parts are only "connected" by resizing the header view height as the table view scrolls up/down.