I'm trying to create custom vertical UIScrollView which could handle multiple pages with different page heights.
Assumptions:
page height is equal or greater than screen height
if page is taller than screen height, it scrolls as usual UIScrollView – with bouncing on top and bottom
if user ends up scrolling and "page break" is in the middle of screen
if there is no velocity - page snaps to closest
if there is velocity - page changes to one in direction of swipe
I've tried many approaches to achieve this, but I've stumbled upon many UIScrollView quirks, which make it hard.
Problems:
UIPanGestureRecognizer has unreliable method for getting velocity (velocityInView:)
scrollViewWillEndDragging:withVelocity:targetContentOffset: method gives me headache, because it arbitrarily can destroy my attempts to animate setting content offset
I don't know how to achieve bounce in one of the middle pages, I'm afraid i would have to rewrite whole scrolling handling
when I try to override setting content offset when UIScrollView is decelerating, what I get is
my content offset is set
deceleration continues beyond content offset I set
Bonus
I have also tried putting UIScrollView inside UIScrollView as a page, but this approach was also pain in the neck. For example when I was at the bottom of inside scroll, then i scrolled down a bit, put my finger away and quickly grabbed again and scrolled upwards, the outer scroll received touch, which messed up inside scroll presentation.
Does somebody have any idea how to do this? Any tips will be helpful as I'm completely stuck...
Try this. Might help. Based on the Circa news app.
https://www.cocoacontrols.com/controls/rscircapagecontrol
Related
I was wondering if you can help me please. I have a wkWebview that has horizontal paging content.
Outside of that I have a scroll view that also has horizontal paging content.
There is obviously a conflict when scrolling and I was wondering what is best to solve the issue.
I want a continuous scroll that when scrolling on the web view that has a content offset less than 0 I want to scroll the parent scroll view to the page before. When the content offset is greater than the size of the content size I want to go to the next page.
I considered using a pan gesture recognizer. However I can’t seem to get it working properly.
When the web view decides to call the parent setContentOffset method how do I make sure that it behaviours like it is paying the content?
Hopefully that makes sense.
Please help.
I'm having a little issue with scrollview pagination.
My intention is to have 3 pages visible on screen and when I scroll right only on page is scrolled, following the example below, scrolling right will display page 2, 3 and 4 on screen:
However I don't know how to display mutiple pages at the same time, at the moment I have it like this:
Obviously like this is not what I want.
To achieve the desired functionality I tried making the scrollview's frame the size of the page I want (1/3 of the screen width) and setting the clipToBound to NO so the other pages are visible. This indeed shows 3 pages in the screen; however since the scrollview frame is only 1/3 of the screen I can only swipe in that area, I would like the swipe area to be the whole screen width.
You're on the right path. Now you can try manipulating UIPanGestureRecognizer of your scrollView, say, re-attaching it to scrollView's superview.
Alternatively, take a look at iCarousel, it can be perfectly customized to suit your needs.
My solution in the end was the following:
I took my initial approach.
I disabled the scrollview's scrollEnabled property.
Added swipe gesture recognisers to the scrollview.
When the gesture is made I modify the scrollview's contentOffset to move 320/3 pixels to the right or left.
I am trying to build a UI in iOS in which there is an outer paging UIScrollView inside of which are multiple UITableViews, each representing a page. The problem I am encountering is that the angle at which I must swipe to trigger the outer paging UIScrollView to scroll horizontally is too narrow. Here is a screenshot showing what I mean.
Essentially a user has to swipe at a near-perfect horizontal angle in order for the UITableView to ignore the gesture and pass it along to the outer UIScrollView, thereby triggering a horizontal page movement. This behavior quickly becomes annoying.
I have done extensive research on stack, to no avail. Some people suggest setting directionalLockEnabled, but that has no effect here (the inner UITableView has its direction locked, it's just too greedy with the angles it interprets as going in its direction). Others suggest modifications to the contentSize, but the contentSize of the views is, in point of fact, correct. Still others suggest using Gesture Recognizers, but those seem to have a delay before they kick in.
Can anyone suggest how to accomplish the behavior in the image above?
Backstory
I have an iPad app that needs to allow the user to navigate through groups of images. Each group is laid out in its own vertical UIScrollView (paged) so the user can swipe up and down down to see each image. Each of the group UIScrollViews is placed in a single (only one exists in the app) outer horizontal UIScrollView (also paged). This works great.... I can swipe up and down to view the images in a group and swipe left and right to go to the next or previous group.
Problem
The problem started when I needed to add zooming for each image. I accomplished this by placing each image inside its own UIScrollView. When the image is zoomed I can pan around the image and when I get to the top or the bottom of the zoomed image the group's vertical UIScrollView pages to the next or previous image as expected. Unfortunately the outer horizontal scrollview will not page to the next group when the image is zoomed and I pan to the leftmost or rightmost edge.
Is there a better(more correct) approach than triple nesting UIScrollViews or can I somehow forward touches to the outer horizontal scrollview?
Any help or suggestions would be greatly appreciated.
hope i'm not too late but I think I have a solution for your problem.
Here you can find an Xcode project demonstrating the scrollview setup you have, your problem and the proposed solution: https://bitbucket.org/reydan/threescrollviews
Basically the solution was to add 1 pixel to the contentSize.width of the vertical scrollviews. This forces the vertical scrollview to scroll a little when you pan to the edge of the zoomed image. It scrolls a little and then continues to the next vertical scrollview.
If you download the project you will see that I've created some scrollviews in the viewDidLoad method. There, I create one horizontal scrollview containing 3 vertical scrollviews, each containing 5 images. Each image is actually incapsulated in a scrollview to enable per-image zooming. In total... triple nested scrollviews.
I've also left some colored borders so that I can easily see how each scrollview scrolls.
the magenta = horizontal scrollview
the white = vertical scrollview
the blue = the image scrollview (the one that contains the image and allows for zooming)
the red = the UIImageView
You will see that I've tagged each image scrollview with value 10. This is used in the implementation of - (UIView*)viewForZoomingInScrollView:(UIScrollView *)scrollView delegate method where I return nil unless the event came from one of the image scrollviews.
If you have any questions about the project I made feel free to ask.
In the end, I would like to say that this browsing method is a little quirky for me as I sometimes scroll in the unwanted direction. Often I think I flick my finger vertically only to find the scrollview going left or right because it interpreted some tiny horizontal movement I had.
The problem I found with paging enabled for both horizontal and vertical movement is that the scrollviews are direction-locked, or so it seemed to me.
EDIT:
Today I've investigated the problem even more. These are my conclusions:
it's not a problem with zooming, it's a problem with having larger content in the innermost scrollview than the visible area(you can try this by zooming or simply initializing the content size larger than the bounds). This enables panning inside the inner-most scrollview and completely changes the behaviour of the touch events.
the bounce for a scrollview flag affects the behaviour of the panning(dragging) gesture when it reaches the edges of the content. If bounces=false then your panning gesture will stop at the edge, not forwarding the drag event up the chain (and thus not scrolling the parent scrollviews to show you other images). If bounces=true then, when you reach the edge and continue to drag the events will be forwarded to the parent scrollview and that scrollview will also be dragged. However, I've found that the dragging while bouncing reduces the distance dragged by aproximately 50%. This also happens in the Photos app.
if you start the dragging while the innermost scrollview is at the edge of the content then the scrollview is smart and will forward all events to the parent scrollview.
for some reason, triple nested scrollviews are problematic as the events are simply not forwarded between the topmost and middle scrollviews while panning inside the innermost scrollview. I have no idea why.
My solution with that +1 pixel to the content size, partially solves the problem.
EDIT 2013
Boy, these scrollviews are something out of this world :(
After more than a year of searching (just kidding... it was actually 2 days) I think I found a good elegant solution to the triple nested scrollviews.
I created a test project here:
https://github.com/reydanro/TripleNestedScrollViews
Inside the app, there is a switch which you can use to test with/without the fix.
The setup I am using in my app is a little different than this question. I have 1 vertical paged scrollview. Inside it, I have multiple horizontal paged scrollviews.
Inside some of the horizontal scrollviews I have another vertical paged scrollview.
Without the fix, once you get to the page with the inner-most scrollview you are pretty much stuck there as the vertical scrolling gestures are not forwarded to the outer-most scroll.
The fix is a custom UIGestureRecognizer that you need to add to the inner-most scrollviews. This recognizer follows touch events and if it detects a drag beyond the contentArea, then it will temporarily disable the rest of the scrollview's recognizers. This is the only method I discovered to make the scrollview forward the events up the chain
The gesture recognizer code is very rough with limited customization but should get the job done. At the moment I am focused on the app I develop, but will continue to update the repository.
PS: I haven't tested what happens with zoom but I see no reason why this method should not work (or be adapted to work).
I have a horizontal scroll view with paging enabled, and the children of this scroll view are vertical scroll views. It's like the iOS home screen, but imagine scrolling vertically on each home screen.
Now, when the vertical scroll is in progress, it's hard to swipe to the next or previous screen, because the vertical scroll view apparently captures the events. Even if the angle of the swipe is almost horizontal, it doesn't go to the next or previous "page". Only after the scroll stops fully can one easily swipe to the next or previous pages.
Unfortunately, because of the slow deceleration, the user might think the content stopped moving when it is in fact moving very slowly and just about to stop. But the horizontal swipe is interpreted as a vertical scroll gesture, and the scroll velocity increases, making things worse from the user's perspective.
I've noticed multiple people struggling with this when they test out our app, and I wonder if anyone here knows a solution, perhaps a way to consider the angle of the swipe to determine which scroll view should process the event. Thanks.
I would suggest stopping the vertical scroll on a touch begins event. This is how most apps I've seen do something like this.