We have a custom MonoTouch Dialog (MT D) Element that we want to expand as we type into it.
We experienced the common MT D issue of the height not recalculating. The common solution for that is to call
this.GetContainerTableView().BeginUpdates();
this.GetContainerTableView().EndUpdates();
Stack OverFlow Question
Monotouch: Force UITableView to recalculate height of each cell without reloading data
This has always worked fine for us if even it does smell of HACK. However a user is reporting an issue on their iPhone X that means the whole MT D container (the UITableView) is being scrolled every time which causes the screen to jump.
I have tried temporarily disabling the scroll on the Element's Container and on the immediate RootElement but that made no difference.
Can anyone suggest something to stop the jumping?
I had tried setting scroll position back to it values before Begin and EndUpdates but was getting exceptions trying to hook the scroll event
UIKit.UIApplication.EnsureEventAndDelegateAreNotMismatched
However this suggestion does teh resetting without using Scroll Event. Thanks Kyle Shank
http://www.kyleshank.com/2015/12/05/prevent-uitableview-from-scrolling-during-updates.html
Note:
I spent about a few hours trying to hack my way out of this problem before I posted to SO . In writing the question I found the Kyke Shank solution but decided we'd all be better off if I still wrote up as a question and subsequent answer.
Related
In my application, there's a View controller with bounce-disabled UITableView that covers the entire screen.
However, there is a situation where the table view contains only few items, which the sum of their heights is pretty equals to the screen's height.
As a result the table doesn't scroll (which is fine).
When the user tries to scroll in this situation, it triggers the didSelectRowAtIndexPath of the start scrolling point. How can I avoid this?
One easy solution is to allow bounce effect :D
Couldn't find any other solution :(
to make a better experience make the bounce situational
only allow tableView bounce if the (cellHeight * numberOfCells) < self.tableView.frame.size.height
Looks like some sort of bug in framework (excuse me if it is not). I got this issue today morning and now I am not getting it.
Try adding the below line of code to the cell.
cell.selectionStyle = UITableViewCellSelectionStyleNone
That is the only change I made to the tableview today, and not getting the issue any more. Reverting the change is not reintroducing the issue. Hence I am suspecting a framework issue.
I have a question regarding scrollToRowAtIndexPath. It works ok, but sometimes, it shows a blank content until the selected row get's to the top of the tableView. I read somewhere that it has something to do with the fact that the animation is running on main-thread. Any idea how can I solve this issue ? As you can see, the same problem, without any solution Thanks !
I have an uicollectionview with paging enabled. One cell per page which is full screen basically. The thing is that when I want to use scrollToItemAtIndexPath and move one cell forward/backward along with animation it will do a swipe but it will go back instantly to the cell/page where I called scrollToItemAtIndexPath. There is really nothing special besides stuff I've described. When I omit animation it's working.
For faster debugging I've setup test project on github - ScrollToItem
EDIT: This might be a bug. Bugreport (18864560) submitted. If someone can provide me a workaround or even solve this issue it will be still appreciated.
I have a UITableView displaying a table of data with a somewhat large contentInset value. As a result, the user cannot trigger the UIRefreshControl because it expects them to scroll too far.
Basically, I'm wondering if it's possible to make UIRefreshControl adjust for contentInset values.
Edit: This question is mostly about curiosity, so I removed the extra details and rephrased the question to be more direct.
I think you're going about this a bit wrong. If you've encountered this issue because of the mechanism you've created to preload cells, you should think of a different approach for preloading them. If there's any content to be rendered / loaded / downloaded, you could be doing this in a background thread and leave a minimal amount of work for cellForRowAtIndexPath. If you insist on keeping this implementation, I'd suggest looking up a custom refresh control as there is no way to customize the build in UIRefreshControl in terms of content offset for refresh (AKA sensitivity). I believe this is ultimately a good thing - there should be consistent user experience across apps running on iOS which use a refresh control.
I've noticed a problem when using UIPickerView, and I'm wondering if anyone has ever encountered it before: Sometimes when scrolling one of the wheels, it gets stuck between two rows (after touches have ended), and just stays like that indefinitely. Dragging the wheel again slightly and releasing always corrects the problem, but regardless, I'm puzzled as to why this is happening in the first place. It occurs when testing both in the simulator and on an actual device.
The problem isn't so much the annoyance of having to re-adjust the wheel when it gets stuck, but rather that sometimes it gets stuck when it's extremely close to selecting a row (but hasn't actually selected it) which can give the user the impression that they have chosen a given row, when really they haven't.
Has this happened to anyone else, and if so, is there a way to fix it?
Thanks,
Chris
Still haven't figured out a good way to solve this... the best solution I've been able to think of is including the following line in the pickerView:didSelectRow:inComponent: method:
[pickerView selectRow:[pickerView selectedRowInComponent:0] inComponent:0 animated:YES];
This will make the specified component roll back onto the correct row, ensuring that the user is always seeing an accurate representation of what's selected, however it sometimes looks strange when you think the component is going to stop on a certain row, only to see it animate backwards in the opposite direction before stopping.
I had an issue very similar to this. The UIPickerView would scroll and stop between rows. Normally this view will not stop between rows it will scroll itself to the next row even if you try to stop it in-between two items. I have many apps that did not show the problem even though they used the same code to instantiate UIPickerView.
After much investigation I found my problem was over usage of CPU. My application is an OpenGL game, so I have a game loop running as fast as possible to update the frames. Admittedly my game was CPU bound and not achieving a full frame rate. I was leaving the game running in the background while the pickerView popped up to allow the user to make a selection. This seems to have left no CPU for the UIPickerView to detect it had stopped between rows and pull itself to the nearest row.
My simple solution is to pause the game while the picker view is up.
I see this answer is a year late, but it took me a while to figure out so hope it helps someone.
I think I've figured it out. When the view that you are using the UIPickerView in loads, you need to set the pickers delegate, like this:
picker.delegate = self;
That should fix the issue and cause the picker to automatically center on a value rather than floating between rows.
you should check frames of the subviews in pickerview delegate method (pickerView:viewForRow:forComponent:reusingView:). frames height should should not exceed from content view's height.