Using [myTableView selectRowAtIndexPath:...] to scroll to a certain table view scrolls the view too quickly to be seen as a scrolling motion, even with passing animated:YES. Setting tableView.decelerationRate doesn't seem to change the speed at which it scrolls.
Is there a way to slow down the scrolling without writing a custom animation? If so, is there a way to make sure that the scrolling has finished before calling another action? I want to call didSelectRowAtIndexPath after it scrolls, but not until it has finished scrolling.
Related
In my app, I have a UIPageViewcontroller. Inside the UIPageViewcontroller, I have a Viewcontroller with a table inside of it.
The problem I am having is, when I am scrolling down the table, I can't scroll between pages. unless I lift my finger up. (this also has to make sure that table stops scrolling completely)
I was hoping there would be a more natural way of doing this.
Is there a way to swipe between pages even when your scrolling down the table, without have to lift up your finger
I just tried Instagram, they have same UI as you are trying to achieve.
When I scrolled through Insta posts, I could not Swipe between View Controllers until table scroll stops.
1 option you can do is to reduce the speed of table scroll using following code:
self.tableview.scrollView.decelerationRate = UIScrollViewDecelerationRateFast;
This code will allow table to stop quickly and hence user can swipe.
Hence, I would say, it is not possible to swipe between view controller unless table scrolling is stopped.
I'm building a chat using UITableView. Naturally, the row heights of each chat message cell will vary widely. I've correctly calculated the row height for each cell and the Table View performs as it should.
However, I want to implement estimatedHeightForRowAtIndexPath: to speed up performance in case of many messages. The problem with this is that it affects the scrolling behaviour of scrollToRowAtIndexPath:atScrollPosition:Animated:.
In my viewWillAppear life cycle method I tell the Table View to scroll down to the latest message (i.e. the bottom message), which performs well if I don't use estimatedHeightForRowAtIndexPath:, but as soon as I do it seems as if only the value returned from this method is used to calculate the scroll position and I end up in the wrong position.
Is it possible to benefit from the efficiency gains of using estimatedHeightForRowAtIndexPath: without it affecting scroll behaviour?
UITableView is a subclass of UIScrollView so the method
- (void)scrollRectToVisible:(CGRect)rect animated:(BOOL)animated
of UIScrollView may help you to achieve what you want
I'm creating my views programmatically. I have a UITableView in my UIViewController subclass that I want to add a scrolling subview to that is not a cell. I want to add some text-based subview to the UITableView that scrolls with the table and starts out above y=0 so the user will only see it if he pushes the table down. That is, it should reside above the first section of my table. If it helps for visualization, I intend to make something similar to those "scroll down to refresh" features and want some indication to the user that scrolling down causes a refresh. Is there any way to do this without something messy like using another UITableViewCell to represent it or abusing the UITableView delegate methods to move a view around whenever the user scrolls?
Simply using [tableView addSubview:] in my viewWillLoad only makes it appear for a split-second then disappear once the table data is loaded. This seems weird to me because UITableView is a subclass of UIScrollView, which is meant to hold other views in it. Using [tableView.backgroundView addSubview] does nothing.
P.S. Why not use a UIRefreshControl for this? I'm still undecided but leaning towards not using one because I don't like how slow that spinning wheel "feels" when the refreshes are usually very very quick. I've been looking at other options like flashing the background subtly and only showing a wheel if it's taking a longer time than usual.
I You can implement pull to refresh with only a table view
To do this using the scroll view delegate, since tableview is a subclass of scroll view.
Set view controller to be the tableview delegate and implement
(void)scrollViewDidScroll:(UIScrollView *)scrollView
When scrollview content offset y value passed a point, add a label to the viewcontroller.view not tableview. When you scroll back or release, remove the view.
You might also be able to add label to the table view and set the frame origin to negative y value, so when you pull the label will move into view (Never tested this do might not work)
I'm puzzled with this.
I have a UIScrollView and inside I have placed 4 tableViews.
The whole thing is used to allow scrolling horizontally and switching tableViews like the Groupon app.
As soon as you start scrolling the 4th (left or right) tableView, is moved in the scrollView and a reloadData is initiated on that tableView, so it will load the data from the datasource for that category.
However, when I scroll into that tableView, it still has the data from the previous category, meaning the cell's didn't get refreshed.
Can anyone shed a light on why this is happening?
I'm guessing only that because the tableView is not in a visible frame when I call the reloadData command, actual drawing is not happening in the tableView (the datasource methods are being called normally, but no drawing is happening).
Any ideas, or tips ?
I have an app with a TableView which is contained inside a ScrollView (horizontal pagination).
In each TableView is a custom TableViewCell which has a number of views.
To handle a singular tap on an area within the cell, I add a UITapGestureRecogniser to views within the cell.
Rendering performance is fine. But when I tap, I notice a sizeable delay from the point of tapping, to the point where the selector is called (i.e. I believe most of the time is being spent inside UIKit doing hitTests and finding out which element responds to what).
Is there a way to make this faster? What should I be looking out for that may be causing this problem?
You could try adding a single tap recognizer to a transparent view that fills the cells contentView, add it last so it's front most in the subViews array, then have it to the hit test for just the views of interest.
That said it would seem the delay comes from some other interaction.