I am having some scrolling issues with my tableview.
Swiping/panning upwards, the tableview scrolls down.
Swiping/panning down does not work, the tableview stays rigid.
Swiping/panning upwards, and then quickly swiping downwards works
(scrolls up).
Does anyone have any idea why something like this may happen?
Each cell has an image, and a couple of buttons.
I am using SDWebImage, and this issues occurs even once the images are downloaded and cached.
The imageviews' userInteractionEnabled are set to YES, so that should not be a problem either.
I noticed that scrolling, in general, did not work at the top 70% of my screen.
So only when swiping down past the 70% threshold, would the app detect scrolling, hence it would scroll down.
This was because I was using a Dropdown Menu that I found on GitHub (it covered the top 70% of the screen when it was open), that unfortunately interfered with the scrolling, even when hidden.
So basically, for anyone who has the same problem in the future, check for interfering views, that may be affecting the scrolling performance. Especially look for views and other elements from external code/libraries.
If this is not the case, check UIGestureRecognizers as suggested by #RandyJames and #liuyadong in the comments above.
Related
Using Xcode 10.1
I have a tableview inside a scrollview. Even though the table is larger than the scrollview and there are filled cells in those rows, it's very difficult to get the scroll to work in the simulator.
After multiple attempts using the mouse to scroll the table, I get a very thin scroll indicator that works (meaning I am able to scroll to bottom of table) intermittently. I need to keep playing with the table to get it to come back again. I also tried adjusting the inset but that just moves it from the edge, still razor thin.
Any ideas where I can look to solve?
I have a page in a UIWebview whose main element is taller and wider than the webview itself. I'd like to be able to "pan" around the page smoothly in any way the user chooses: horizontally, vertically, diagonally or swiping in a circular motion.
Usually it works, however around once in every three gestures, the UIWebView scrolls on only one axis (sometimes x, sometimes y), despite gesturing on both simultaneously.
The problem tends to happen most often just after the webview has loaded. After a successful two-dimensional scroll it tends not to happen so often again.
Has anybody else seen this problem or any idea what to do about it?
Found out what it was. I had a UIScrollViewDelegate listening to the UIWebView's UIScrollView for doing all sorts of other stuff I probably shouldn't. And the symptoms in the question are why!
In Apple's apps I notice the scrolling is perfect. Everything moves nicely and when you stop, it stops. You can have a huge image and move directly to any spot and it stays there.
I'd like to provide the same UE, but for my apps, if the content exceeds the size of the scroll view (as it should - otherwise what's the point in having a scroll view?) the scroll view never stays put, you have to drag to see content on the edges, then it bounces back and hides it again. Very annoying, especially if there is active content like a button there.
I'm not an iOS expert, e.g. I just found out recently about how critical viewWillAppear is w.r.t. UIScrollView. Is there a concise reference somewhere on how to get perfect rock solid scrolling? (i.e. not Apple's Dev docs!)
Thanks for reading,
Yimin
Are you setting the contentSize property on the UIScrollView?
scrollView.contentSize = CGSizeMake(2000, 2000);
Apple has access to internals which we don't so its products tend to perform better. Scrolling in iOS is basically take it or leave it. Have followed the guidelines in the tutorials and they all have flakey scrolling, in particular the edges aren't always visible when zoomed.
We have a UITableView that we have configured to act like a Grid, allowing both horizontal and vertical scrolling. We accomplish this by dynamically changing the ContentSize in a custom UITableView's LayoutSubviews method, which helps with autorotation, scrolling, etc.
Everything works as expected except on a couple of our larger grids. When these grids are scrolled horizontally (swipe left), as soon as the ContentOffset.X is greater than or equal to the Bounds.Width, the table view disappears. It is still present and receives input, but nothing is painted. On swiping back to the right, as soon as the width threshold is crossed, everything is repainted.
In situations where the size of the grid is less than half of the configured UITableView width, this issue does not occur. We cannot change the size of the grids because they are configured by customers in the field who expect the data to be available.
I have checked and/or removed as much of our custom drawing code as possible and the issue is still occurring. Does anyone have any ideas?
That is because although the UITableView inherits from the UIScrollView, it is only meant to have a single column, hence it draws its cells according to its Bounds.
If you want to create a grid-like control with the UITableView, I suggest using multiple table views in a parent UIScrollView side-byside and change that one's ContentSize.
I came across this same issue and posted a bug report (10561166) back in December on the Apple Developer site.
I received a response today from Apple in which they stated that
UITableView is not designed or intended for horizontal scrolling.
(I had since changed my design not to require the horizontal scrolling.)
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.