I can't tell you how many times I've been asked lately how to do the "
UrbanSpoon Effect".
Note: There is a newer version of this code available here.
Now, I have no idea exactly how the folks at
UrbanSpoon did their application, but they did it well. I don't have time for a full tutorial right now, or to do a full implementation of the effect, but in the process of helping somebody in a forum, I did write a little sample application that shows the basic theory of how to make your
UIPickerView go round and round for longer.
As I said, this project nowhere near as polished as what UrbanSpoon does - I cheated on the blurring because I hit some bugs while porting my
NSImage convolution kernel code to work with
UIImage and I don't have the time to debug something that gnarly right now. My "blur" is just a double resize - down then back up. It's really just interpolation, but it sorta makes it blurry. I probably wouldn't use that method of blurring in a real application but, then again, I'd be getting paid for a real application.
This application does support using the accelerometer to start the spin. In order to make the picker view spin longer, I subclassed
UIPickerView. My subclass had exactly one method. This is an undocumented method that returns the duration of the spin, so you just return the number of seconds you want your spin to go for:
#import "JLPickerView.h"
@implementation JLPickerView
- (double)scrollAnimationDuration
{
return 5.0;
}
@end
The other key thing to note in this application is that my
UIPickerViewDataSource lies about how many rows each component has. I have a constant called
kRowMultiplier. I take the count of the array that corresponds to a particular component, and I multiply it by kRowMultiplier. This value is currently set to 100, so if the array that feeds a component has ten items, my datasource lies and says there are a thousand, and then it just keeps feeding the same ten items over and over in the same order by calculating the actual row in the array to use:
int actualRow = row%[[self arrayForComponent:component] count];
This creates a component with the same values repeated over and over.
When the view first appears, I load arrays with views containing both the blurred and unblurred data. You don't want to be programmatically blurring the values over and over when the spin happens, so we do it once and store the values in arrays. I then set the component's row to a value in the middle. This means that the user will never see the blank rows above and below the real values, which helps create the illusion of endless spinning.
[picker selectRow: [component1Data count] * (kRowMultiplier / 2) inComponent:0 animated:NO];
Now, when a value is selected in the picker, I do a bait-and-switch back to the middle. I move the component to the same value they're currently on, but back in the middle of the wheel. This way, no matter what happens, they'll never see the blank rows at the top or bottom. Since I'm moving them to the same value and the surrounding values are the same, and I tell it not to animate the change, the user has no idea it has happened.
- (void)pickerView:(UIPickerView *)pickerView didSelectRow:(NSInteger)row inComponent:(NSInteger)component
{
NSArray *componentArray = [self arrayForComponent:component];
int actualRow = row%[componentArray count];
int newRow = ([componentArray count] * (kRowMultiplier / 2)) + actualRow;
[picker selectRow:newRow inComponent:component animated:NO];
}
Finally, when the spin button is pressed, or the user shakes the phone, I calculate a random number for each component. This number is a value between 0 and the size of the array minus 1. This tells me what the new, randomly selected value will be. Then I move the components (again, without animating) to the corresponding row near the top or bottom of the dial, and then animate to the selected value at the other end of the wheel.
- (IBAction)spin
{
if (! isSpinning)
{
spin1 = arc4random()%[component1Data count];
spin2 = arc4random()%[component1Data count];
spin3 = arc4random()%[component1Data count];
[picker selectRow:([picker selectedRowInComponent:0]%[component1Data count]) + [component1Data count] inComponent:0 animated:NO];
[picker selectRow:(kRowMultiplier - 2) * [component2Data count] + spin2 inComponent:1 animated:NO];
[picker selectRow:([picker selectedRowInComponent:2]%[component3Data count]) + [component3Data count] inComponent:2 animated:NO];
[picker selectRow:(kRowMultiplier - 2) * [component1Data count] + spin1 inComponent:0 animated:YES];
[picker selectRow:spin2 + [component2Data count] inComponent:1 animated:YES];
[picker selectRow:(kRowMultiplier - 2) * [component3Data count] + spin3 inComponent:2 animated:YES];
isSpinning = YES;
[self performSelector:@selector(stopBlurring) withObject:nil afterDelay:4.7];
}
}
I set a variable called
isSpinning so that I know whether to provide blurred or unblurred data to the spinner. I have the spin set for 5 seconds, so 4.7 seconds in the future, I set the value back to
NO. This cause it to stop blurring a moment before the spinning stops. This is done so that the final words displayed will not be blurred.
You can download the sample project here.
One note, though: I have used a couple of undocumented, private methods in this project. I ordinarily shy away from doing that, but in the sake of getting this code out the door quickly, I did. I use one undocumented method for resizing the
UIImage in order to create the fake blur effect, and another one to keep the picker from making sounds when I initially set the values because I don't want the user to realize I'm moving the picker - that would shatter the illusion. These are pretty subtle uses of undocumented methods so I doubt they'd get your application rejected, but they could. They're also not methods that are likely to change. But, again, they could - that's always a risk with undocumented methods, so caveat emptor - use at your own risk. If you want to play it safe, to a real motion blur and take out the calls to
UIPickerView's
setSoundsEnabled: method.
iPhone is a device with practically unlimited possibilities and potential. Well, the hardware of iPhone is fantastic, however, what makes it a real wonder device is the abundance of applications and software that have been pouring in for the past several months.
Effective and efficient 
