I'm looking for a way to slide a partially concealed tool panel from off screen like the JetBlue iPhone app does. I know how to do this with regular swipe gesture recognizers, but that app has a certain threshold, after which the panel "snaps" to the on-screen position, otherwise it hides back offscreen.
How can I implement this kind of swipe-to show, but with a threshold kind of gesture recognizer? Are there any open source projects that do this kind of UI manipulation?
I have a similar interface element in an app I've written. My interface element is a UIViewController for the entire tool panel. I put a UIButton over the gripper illustration, change the button's type to custom so it visually disappears. I connect Touch Drag Inside and Touch Drag Outside to an IBAction that adjusts the position of the panel according to where the drag moves. I connect Touch Up Inside and Touch Up Outside to an IBAction that finalizes the positioning of the view. If the touch up event happens too close to the bottom, I just close the panel. If it happens anywhere higher than that threshold I open the panel. I use UIView's animation methods to smooth out these transitions. The over extension element seen in the JetBlue app can be accomplished in the drag event handler. As the panel gets closer and closer to the limit, open the view a smaller and smaller amount with each move of the touch higher. Then in the finalization, just animate the panel back down into it's preferred ending position.
The JetBlue app differs from my app in that I have a small gripper area, but JetBlue's app allows you to swipe the whole panel to adjust position. To match that functionality, I would adjust my implementation to totally cover the panel with buttons. Each would respond to my drag events with the addition that dragging would set a flag. Then my touch up event handler would check if the flag was set. If so, finalize the dragging of the panel. Otherwise, perform the appropriate action associated with each button.
If you can already implement the basics with gestures, then you're almost there!
To be honest, while I've done exactly this in my application, I use the old fashioned touchesBegan, touchesMoved, etc.
In terms of gestures, you'll have to use UIPanGestureRecognizer so you can have full control of the drag. UISwipeGestureRecognizer only recognizes swipes.
Anyway, after a certain point, you simply translate the panel only a fraction of the distance the person dragged.
CGRect newPanelFrame = panel.frame;
if (newPanelFrame.origin.y + dragOffset > 275) {
newPanelFrame.origin.y += dragOffset / 2.0;
}
panel.frame = newPanelFrame;
In touchesEnded:withEvent: or if (gestureRecognizer.state == UIGestureRecognizerStateEnded)
CGRect newPanelFrame = panel.frame;
if (newPanelFrame.origin.y > 275) {
newPanelFrame.origin.y = 275;
}
panel.frame = newPanelFrame;
The reason why I've never bothered with the UIPanGestureRecognizer is because I could never figure out how to get the non-cumulative translation (translationForView: is cumulative), which is necessary if you want to essentially slow down the drag after the threshold.
I was just doing some research into achieving a similar effect, stumbled across this post, and as a result decided to give JetBlue a try.
After playing with the sliding panel for a bit, I'm actually thinking the JetBlue guys actually went about this in a slightly more different manner.
The motions of the slider in the JetBlue app seem to handle much nicer than what you could do with a collection of UIGestureRecognizers; it's capable of animating at different velocities depending how quickly the user swipes it, and the rubber-banding compensates for this properly too.
So on that note, I actually think that they're not using UIGestureRecognizers, but that panel is actually just a standard UIScrollView aligned to the bottom of the app window, and with a bit of extra logic (probably applied via the delegate) that just makes sure it isn't possible for the scroll view to stop animating between the 'open' and 'shut' state.
Related
I am trying to create a menu for my app with a few icons in a circle. User should be able to spin this menu, making the icons change their positions around this circle path, but not rotating themselves. I read this earlier http://www.raywenderlich.com/9864/how-to-create-a-rotating-wheel-control-with-uikit so I can see how to follow the finger movement, but I need this menu to have inertial spin after the touch ends. I have 2 questions about how to do this.
First one, what's the best way to make animation with icons moving around in a circle? It should be slowing down until it stops and, if user moves his finger fast enough, should be able to do more than one full circle.
Second, how do I measure speed of finger movement at the end of it? I tried to use locationInView and previousLocationInView and just spin it by difference of angles between them multiplied by some constant. Problem is, when I keep my finger in one place for a while and take it up, I still get inertial movement of the circle and in this case I don't want it to move at all.
You want to use a scroll view. Specifically you want a hidden scroll view where you attach the pan gesture recogniser from the scroll view to your custom menu view. Then you implement the delegate methods of the scroll view to redraw your menu. This WWDC video has a good overview of the process. The benefit of this approach is that you get true iOS style acceleration and deceleration for free. You don't need to worry about finger position or speed, only the content offset of the scroll view.
Unless you want to spin your finger round in a circle with the menu items. That's a different ball game...
In theory, the same approach as above can be used for spinning your finger in a circle. You would need to ensure that directionalLockEnabled was set to NO on the scroll view. The problem is that the calculations to determine the rotation of your menu view are a lot more complex. Probably you would want to be modal and check if the scroll view is dragging in the callbacks. If it is dragging you would use the touches on the pan gesture to find the exact finger location to set the rotation. You'd also want to maintain data on the instantaneous direction of finger movement so that when the touch is released... If it isn't dragging then you use the scroll view content offset to apply the deceleration effect on the rotation (using the scroll direction just before the touch was released to know how to use the content offset changes).
I have an app with a draggable UIView placed at the bottom. The draggable view isnt totally offscreen and it has a "pull tab" that the user can drag upwards or downwards. Dragging up and down currently works, but I would like to give it the same behavior as the Apple notifications slide out drawer.
For example, if I drag the view out 50% upwards and remove my finger from the screen, then I'd like the draggable view to continue to move upwards on its own. Likewise, if the user only dragged the view out, say 30% upwards, then the view should drop back down to its default position.
Ideally, while I can do the dragging up/down, the motion isnt very "organic"....
Right now, I'm accomplishing the dragging upwards and downwards via UIPanGestureRecognizer, just in case that's relevant to the question.
Is it perhaps something along the lines of some clever math with the Y position of the draggable view, then doing the rest of the moving with some CAAnimations?
It might be a bit hard to visualize, so I've added some screens below.
Default screen with the a view at the bottom
The view dragged up via the tab on the right
Thank you!
When your UIPanGestureRecognizer's state becomes UIGestureRecognizerStateEnded, use the velocityInView: message to find the velocity of the gesture.
If the velocity is close to zero, open or close the view based on the position of the view and the previous state of the view. For example, if the view was closed and it has been pulled out more than 10%, open it. If it was open and has been pulled in more than 10%, close it. Otherwise, move it back to its pre-gesture position.
If the velocity is not close to zero, use the sign of the Y component to determine the new state of the view. If the sign is positive, close the view. If the sign is negative, open the view.
You will have to experiment to figure out exactly what definition of “close to zero” feels best.
In any case, you will want to animate the view to its final position after the gesture ends, using a short duration (probably between .1 and .25 seconds). You may want to choose the duration based on the velocity and the distance the view needs to travel. The system notifications panel does this. (Try dragging it partway down slowly vs. rapidly. It animates to its final position at different speeds depending on how fast you were dragging it when you let go.)
You will want to experiment to find the best animation curve (UIViewAnimationOptionCurveEaseOut, etc.), and you may want to use a different curve depending on whether you're opening or closing the view and the velocity of the gesture.
I'm trying to have a sort of gesture that will seamlessly switch between a group of images this part I have sorted. The part that is catching me up is the gesture to do so and how I might introduce acceleration.
Basically the user would swipe as normal and after the swipe is registered it would change the image displayed and the faster once swiped the faster the image would change ideally it would then keep that speed until the users finger was lifted leaving the possibility to just scroll repeatedly through the images.
Any direction someone could give me would be great.
Thanks.
Assuming you would be using a UIScrollView for this, setting the scrollView.decelerationRate property would allow you to manipulate the deceleration rate/scroll speed. To calculate the "swipe speed", take a look here: Detecting Special touch on the iphone for some pointers.
I have a scene where there is a button. Once I click the button, a rectangular sprite slides in from the left side: http://img255.imageshack.us/img255/9867/slidei.png
Under this shape, there are several touch sensitive buttons. I don't want these to be called when I touch on the rectangular shape. So, as long as the shape remains on the screen, those touches should not respond. Instead, there are several other buttons on top of that brown shape, that respond to touches. How can I manage that?
Is it possible to temporarily deactivate touches for a certain layer in a scene? Has the rectangular shape to be a CCLayer Object on its own?
I know I could create a new scene for that shape that has a transparent background, BUT I still want the button to react to touches:
When I click that button, the shape slides in. When I click it again, it slides off the screen.
Depends on if you are using actual button objects or CGRect regions that your touchesBegan method responds to. I agree with GamingHorror that the cleanest approach would be to enable/disable the button objects directly as needed.
However, this is a workable kludge as long as the sliding touch region is a UIView subclass.
Before it slides in you can disable all user touches with:
[[[UIApplication sharedApplication] keyWindow] setUserInteractionEnabled:NO];
After your view slides in, you may need to setUserInteractionEnabled:YES on that particular view. When it slides out, you can put it all back with
[[[UIApplication sharedApplication] keyWindow] setUserInteractionEnabled:YES];
Like with any user interface, you have to let the objects know whether they are enabled or not. Your best bet is actually to send a message to the button, telling it to turn itself on or off.
Ideally you'll be using a global touch input handler, instead of allowing each individual button or slide to react inputs by themselves. This spells a lot of trouble and extra work. Instead, put all objects that should react to input on the same layer, and register that layer with the touch input handler, which will then forward all touch events to that particular layer and no other.
I'm working on an iPhone game, and trying to use a UIScrollView to display some icons, which I then want to enable the user to drag off the bar being scrolled, onto another view (basically, dragging them from their hand into play on the game board). The problem is that the UIScrollView clips everything outside it's own bounds.
Here is a picture of what I'm trying to do:
Functionally, it actually works, in that you can drag the icons up to the white board fine...but you can't see them as you are dragging...which is not acceptable.
Does anyone know if you can temporarily disable the clipping that a scroll view does, or is there some way to get around it? Hacky or not, I would really like to make it happen.
Does anyone have any other possible solutions for this? Or maybe any alternate approaches? I've considered if maybe a page view might work, but haven't tried it yet...and it's not at all as good of a solution as the scroll view.
Worst case I can just go back to not having the bar scrollable, but that really puts a damper on some of my game mechanics, and I'm really not too excited about that.
I think you're looking for the clipsToBounds property of UIView. I've used it successfully with UIScrollView:
scrollView.clipsToBounds = NO;
However, the dragging you want to do from the scroll view to the game view may require you to remove the icon view from the scroll view, place it in the superview at a position corresponding to its visible position within the scroll view (calculated using the scroll view's origin and content offset), and have that track the user's finger movements. On a release of the touch, either drop it on the game view at the proper position or return it to the scroll view.
I'm not 100% sure I understand the question but I think you should look into the z order of the scrollview and the whiteboard. It may be that the drag is just going behind the whiteboard.
Failing that, it would be useful to see all the bounds of your view heirarchy.
I also think a better solution allround might be to create a "sprite" to animate underneath the players finger - you could offset the drawpoint of the sprite from the touchlocation so that the player can see what they are dragging.