How to control scrolling sound of uipicker? Any available sample code?
There is no documented way. That being said:
[myPickerView setSoundsEnabled:NO];
Like Peter said, there's no public way to do this. However, if it's really critical you could implement your own picker-type object. Basically, all you need to do is create a UITableView and customize the cells as you like. Then create an image to add as a UIImageView subview that's the same size as the table. At its simplest, all you need is a little bit of gradient fade-to-black at the top and bottom so the cells of the table appear to fade in/out. You could also add a bit of a frame around the table, or anything else really, as you like.
If you take a look at a picker and think of the wheels as just UITableViews with a gradient at the top and bottom, you'll see that the curved effect is just that simple. If you look closely as you scroll the cells offscreen, you can see that they never change shape; they just fade out.
As for the sounds, you could then use any of the UIScrollViewDelegate and UITableViewDelegate methods to monitor when the "wheel" moves and check to see where the table cells are on-screen. Perhaps when a cell passes the mid-way point, you play your custom sound.
It would definitely take a little bit of work to implement this, but is certainly possible if it's critical for your app.
Related
Is it possible to change the scrolling on a UITableView? Such as the following?
http://dribbble.com/shots/1176252-Events-iOS7?list=users
In this example, the cells have an accordion effect to them. It's like when the user drags a cell from the top of the page down the ones underneath the dragged location pinch into it, and the ones above it pull away.
I feel like I could do this if I were just use UIView's as cells and custom animate them but I believe that I would be wasting so much making a ton of UIViews.
Any tips, or direction would be so helpful. Thanks!
I was wondering how to make image display through a table like the application Pulse on iPhone. I used UIScrollView but it did not help much. It only displayed images in a nice array-like manner but you could not produce an event or click on the image.
What's the best way to produce a Pulse like application for displaying images and heading information in an array-like style?
use Ray Wenderlich tutorial about THIS topic
tutorial
The Ray Wenderlich pulse tutorial does have an issue where if the horizontal table view has not been scrolled (or its first element is aligned with the left of the screen) you can't drag right and have the content pull that way and then bounce back. This makes the scrolling experience feel pretty bad.
The simple solution though is to put the horizontal table view inside a scroll view and then everything just works.
It looks like a UITableView with rows that are composed of UIImageViews. Its got a nice touch where you can scroll horizontally within a row, like with Twitter's app. That's most likely done with a UIScrollView (scroll bars removed, with end bounce). Peter Boctor wrote a web blog post on how to do something similar, if I recall.
It's a UITableView with each row containing a UITableView that is rotated by 90°. The cells for the UITableView in each row are custom views that are likely either subclasses of UIImageView or just plain UIView.
So I have a UITableViewController. The cells in this tableview have the following UIControls:
2 UILabels, one of which has a shadow and a clearColor background color.
1 Custom Progress view resized to be larger and with a different color
3 UIButtons
Functionally, they do exactly what they are supposed to do. However, I've noticed when looking at it on device that scrolling performance quickly tanks and has dropped frames all over the place, even with other interactions like pushing one of the buttons.
So I was reading around today and found http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ this article by the Tweetie guy about how to achieve fast scrolling performance by subclassing UITableViewCell and doing the drawing yourself.
The example works extremely well, but when I tried to adapt it to work with my desired configuration I realized that he isn't using any predefined UI Controls, he's mapping out everything by hand.
While I can see how this would be an extremely efficient way to do things, it strikes me as problematic for things like the progress view and the buttons, and even one of my labels to a certain extent.
So my question is this: Do I need to completely write my controls from scratch if I want my scrolling performance to be good, or is there a way to use the standard UI Controls and get good scrolling performance?
If you're adding custom controls to your cell, you should still be subclassing UITableViewCell, adding your controls in the init function, laying them out in layoutSubviews, etc. - just like any other view. As VdesmedT says, make sure you're re-using cells via the dequeue mechanism, so that you aren't allocating new cells with each scrolling operation.
OK, I will propose something obvious but to achieve UIScrollView performance, you need to be sure that the dequeue mechanism works well. I often see developers not properly set the identifier in IB and therefore missing the UITableViewCell cache benefit
I'm trying to figure out if I can get what I want out of UIScrollView through some trickery or whether I need to roll my own scroll view:
I have a series of items in row that I want to scroll through. One item should always be centered in the view, but other items should be visible to either side. In other words, I want normal scrolling and edge bouncing, but I want the deceleration when the user ends a touch to naturally settle at some specified stop point. (Actually now that I think of it, this behavior is similar to coverflow in this respect.)
I know UIScrollView doesn't do this out of the box, but does anyone have suggestions for how it might be made to do this, or if anyone's spotted any code that accomplishes something similar (I'm loathe to reimplement all the math for deceleration and edge bounce)
Thanks!
There is not a whole lot of trickery to this. Just use an UIScrollView with paging enabled. Make it the size of one of your items, and locate it where you want that item to appear. Next, disable the "Clip Subviews" option on the scroll view (either in IB, or programmatically), and you are all set.
I'm trying to avoid putting a button in my UITableViewCell subclass so that I don't unnecessarily lag up the scrolling speed.
The button would push another view onto the navigation stack.
I figured since UITableView already has built-in and optimized methods for managing this, that simply limiting the touchable area of my cells would be the easiest and most effective way of achieving my goal.
I really have no idea how I would implement something like this. I have a feeling I would have to override pointInside:withEvent: or hitTest:withEvent:, but I'm not sure how. Managing touchEvents and the UIResponder stuff still escapes me.
So my question is ultimately, in my rootViewController, how would I implement that selecting a row will only work at lets say 220,10,40,40 ?
Thanks!
A UITableViewCell should have a normal selection style(i.e. not UITableViewCellSelectionStyleNone), generally speaking. You shouldn't have buttons on cells that you are reusing an arbitrary number of times.
If you're using a lot of UIButtons in your UITableView, you may want to rethink how your UI is designed.
You can't easily (to my knowledge) change "selectable" parts of a cell - the whole cell must be selectable no matter what(you can set the style to no selection, but you'll still recieve touch updates).
The behavior you're describing sounds like a job for UITableViewCellAccessoryDetailDisclosureButton, actually. If you're going to be pushing another view onto the stack but don't want to do that when the user selects the cell proper, use a detail disclosure button to maximize your consistency with existing UI convention. It's hard to say without more information.
As for doing the work necessary to detect touches in a sub-region, that may be more trouble than it's worth. True, adding subviews to a cell incurs a compositing cost but if you're only talking about one button, and a button whose background you can set to opaque, you'll probably be just fine. The alternative is reinventing the wheel to recreate button behavior in a subregion of the cell and that doesn't sound like functionality that will be much fun to maintain as the SDK matures.
That said, adding views to a cell doesn't incur a compositing cost per se, it's drawing those views that's the trouble. So if you really wanted to go nuts on the optimization, you could create a pre-rendered cell background image that includes the appearance of a button you want and then place a custom, image-free, see-through UIButton instance right over top of it. Nothing to draw, so no additional compositing cost. Worth a shot.
You didn't come here for a premature optimization speech, so I won't bother with one, but I say just do the cell with a normal button for now, make sure you like how the functionality feels to use then optimize toward the end if you're looking at performance that you're not happy with.