I need a "PickerView", that behaves like a normal UIPickerView, but only shows one row of data and has a custom design.
Something like you see in the image, showing the transition from subview 1 to subview 2. After the user lifts his finger and after the scrolling stops, only one subview will be shown:
IMAGE
So basically a scrollview which:
is endless in both, positive and negative directions by showing the same entries over and over
uses paging across several subviews
only shows one subview when not scrolling, and no more than two subviews when scrolling.
I can get a endless scrollview to work, but not with paging enabled. Paging will always limit my scrolling to the next subview.
So I'm thinking about creating my own UIView subclass which custom scrolling behaviour to mimic a UIPickerView. But before doing so, I wanted to get some opinions about the idea in general. Is creating a custom UIView the right way to go? Anyone has some experience with the expected performace? (There will be timers to handle the scrolling algorithm, which has to be recreated of course... :)
Another approach would be to subclass UIScrolView and implement the paging myself. I know when the scrollView starts decelerating
, so maybe there is a way to overwrite the contentOffset to have it scroll into the right position...?!
Any help is appreciated! Thanks!
Here is a great custom component, which seems to be able to do everything you need:
http://dev.doukasd.com/2011/04/infinite-scrolling-dial-control-for-ios/
It's not endless, but rather a modified UITableView with a huge number of cells.
Would it be feasible to just use a UIPickerView, but clipped to the middle row? You could turn off showsSelectionIndicator to remove the overlay and have the delegate pass back custom row views.
Related
I have got a uitableview inside of a uiscrollview.
So the uitableview is smaller than the uiscrollview. And when I start to scroll down on the uitableview and it reaches the bottom, I am able to scroll in the uiscrollview.
And it works fairly. But not perfectly.
I would like to make the ux perfect so the scrollview would be kind of an extension (or another section of the uitableview). I don't want to add any section or footerview at the bottom of the tableview.
I was wondering on doing this by implementing something like this:
//
if tableview didscroll to bottom
then scrollview scrolltorect xxx
//
but it would only work if the uitableview was scrolling down.
I am not sure if this would replicate the correct ux behaviour.
Could you guys give me your advice on how to do this?
Thank you and best regards.
I found this very hard and difficult to execute so I changed my UI in order to put the bottom of the interface inside the tableview footer's view. This way the experience of scrolling my app got much smoother.
I have a page enabled scrollview on an iPad. On the first page, I have a child scrollview that scrolls horizontally through image buttons. The buttons scroll the outer scroll view to the correct page. Its basically like a table of contents that jumps to the correct page.
My end goal is to be able to categorize the buttons seen in the child scroll view. So there would be a segmented control that changes what buttons you can see. So maybe one category would be ALL, and another category would be A-M, and another would be N-Z for example.
My question is, should I use a uiscrollview or a uitableview?
Right now I use a scrollview and it is really easy to get the buttons in. I could implement the different categories kind of gimmicky by having all of the buttons in the scrollview and then just showing or hiding the buttons accordingly. I feel that it'd be bad memory usage though.
For a uiscrollview i was looking at using EasyTableView, butI'm not 100% sure if this is compatible with what i want to do or if it'd even be better.
Any ideas for what the best way to implement this is? Specifically, I'm not sure of the best way to change the buttons when I change categories.
Thanks!
Use a tableview when you are dealing with data that is best expressed as sections and rows.
I think for your situation I'd have a UIView subclass that can display the images you need for a given category. Stick that on the outer scrollview as needed. You can keep memory low by only keeping the currently visible view and the ones on either side on the scrollview. When you scroll to a new location you can recreate the view needed for that page, and the ones surrounding it. Then you release the ones that are far away and let the system reclaim their memory if needed.
Is it possible to change the 'gravity' (stop speed) when scrolling through a UIScrollView with paging enabled? I've implemented a horizontal UIScrollView that acts like the UIPickerView. I want to be able to scroll through many items based on the flick speed. Thanks!
Unfortunately there's no simple property you can change to achieve this, but you can use the scrollview delegate methods to roll your own (it is somewhat complex, but achievable - I've modified table views to 'snap' to rows when the scrolling comes to an end).
Effectively, you'll have to code your own paging implementation.
I have a UIScrollView with textviews as subviews. Now in my app there are multiple UIScrollViews like these. And depending on the selection I display the appropriate UIScrollView on top of the previous view. This works fine in all cases except when the previous view has been a UIScrollView as well. In this case the behavior I get is of two UIScrollViews stacked on top of each other and both the views capture the scrolling events. The textViews from previous scrollView is also visible (not editable though) and overlaps and causes all sorts of issues. The thing is a full screen UIScrollView placed as subview to a previous view causes problems when the previous view is a full screen UIScrollView as well.
Any pointers on how to overcome this would be great. Is there anyway to notify the parent scrollview of the child's scroll events and move it the exact same way so this mess is masked?
Thanks!
UIScrollView documentation says:
Important: You should not embed UIWebView or UITableView objects in UIScrollView objects. If you do so, unexpected behavior can result because touch events for the two objects can be mixed up and wrongly handled.
As far as I know, it is generally not recommended to embed a UIScrollView subclass instance in a UIScrollView. In one of my projects, which is an IM application, I have a UIScrollView that contains many UITableViews, it works when you try enough but it really takes a lot of effort to handle subtle bugs and make it work properly.
It is really hard to say something useful for your problem without diving in to code, but i can recommend you to not add UIScrollViews one on to another like a stack. I'd try doing it by allowing only one UIScrollView at top, and removing others. When you need to show another one, remove the top one from view hierarchy and add the new one. I wish this helps, good luck.
Found a crude solution by presenting an empty view before I present the next scrollView. Added the scrollView as subview to this empty view (with a BG image) and added the to-be presented scrollView as a subview to it and then presenting this on top of the previous scrollView.
I want to put a scroll view inside of the table view cell. I have a number of buttons in one cell of table view and I need to scroll that cell to show the appropriate button.
If you want to use a vertical scroll view then I wouldn't suggest you doing it because, as TechZen wrote, there will be a mess in this case.
If you want the inner scroll view to scroll horizontally then it might be achieved by 2 ways:
Implement a custom table view cell that will include a scroll view inside it.
Add a scroll view as a sub-view to your cell that you will return from tableView:cellForRowAtIndexPath: method.
I suggest you to use the second approach.
There are plenty of examples online. Usually the sub-views are labels or image views, but it is not complicated at all to add a scroll view instead...
I don't think you can do this. It would require nesting of scrollviews which isn't really supported.
Even if it was, it would be very difficult for a user to know which scrollview they were hitting with their pudgy finger. Remember, you don't have the one pixel precision of a mouse on the iPhone. You have an area of at least 15x15 pixels. You don't have a scroll bar but instead just drags anywhere on the screen.
Instead, you should use a master-detail pattern. Selecting the cell in the tableview pushes a detail view which has the scroll view with all the buttons.
Why do you want to do it like this?
I think the best idea is to draw your table view manually above your uiscrollview. I did it, and it works. It just takes more effort and drawing accuracy. But that takes a lot of time. :)