UIPickerView getting stuck between rows? - ios

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.

Related

Alternative to UITableView.Begin/EndUpdates

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.

How to avoid didSelectRowAtIndexPath being trigged when user tries to scroll bounce-disabled UITableView?

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.

WKInterfaceTable scroll up to refresh

I have seen some Apps on my Watch with the "scroll up to refresh" feature, like the email app. If you scroll up when you are on the top, the content gets refreshed and a little wheel is shown on the top.
How is that done? I can't find anything in the documentation
I´ve only seen this on Apple-apps. So i guess they have a wider API. Anyway you can do a workaround. When you initialise your table you could use the
- scrollToRowAtIndex:
And specify row 1. This will now be your first row for your data. The row at index 0 will be a row with a button that will refresh the table. When you tap row 0 you could insert an WKInterfaceImage with an animation (or perhaps look for a way to do the spinning wheel yourself).
This is not the optimal way, but if you play around a little bit with it you can make it work and make it look good. Hope this helps you.

Use scrollToItemAtIndexPath in UICollectionView with paging

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.

IOS UITableView Selection Highlight is sometimes very quick and did select is not being called

Have a strange issue where about 15% of the time, when selecting a cell with a UITableView the cell highlight flashes quickly and didSelectRowAtIndexPath is not called. The rest of the time it is working fine.
Tested how it was being selected (fast / slow finger nail, etc), but this does not seem to be the case. Looks semi-random.
Any thoughts one what might be causing this?
IOS 6.x
[Addition]
Thanks for the comments so far.
If while clicking the mouse (simulator) is moving, the problem can be duplicated. Even if the table is set to .scrollEnabled = false it is still happening. Also, the didHighlightRowAtIndexPath does fire and the didSelectRowAtIndexPath does not in the "quick" case.
Same thing happens on IOS 5.x also...
[Conclusion]
Well, it turns out that the scrolling was turned off for the table and it seems to be even more picky with the "moving tap" Turning the scrolling on actually made the "moving tap" less picky. There were a couple of other postings that I just found that pretty much said the same thing. This is a strange conclusion for a table view that has scrolling disabled and produces a "quick highlight" with no selection. Looks like this is why they added the didHighlight in IOS 6 to try and get around this "issue".
is it possible that a view from with in the cell is absorbing the touch rather than the cell ?
maybe you have a gesture recognizer in the cell, those take priorities over simple touch events
It seems that for some reason your cell is disabled. Try setting cell.enabled = TRUE; right before the cell is displayed and see if it fixes anything.
You're moving your finger up or down slightly, causing the table to scroll. Your item will not be selected, and the highlight will disappear. I've dealt with this before by tracking the row in tableView:didHighlightRowAtIndexPath, and then doing the action in tableView:didUnhighlightRowAtIndexPath: . You might also be able to solve your problem by making the tableView not scrollable if that's an option in your ui.

Resources