At the moment, I'm animating a UIWebView from the bottom of the screen to the top. As the UIWebView animates upwards it becomes untouchable for 50-80% of the duration time.
If I tap the UIWebviews ending destination, or model layer, the taps are registered and the Webview responds appropriately.
Why is this? And what solutions are there for tapping moving/animating UIWebViews?
To further exemplify this, I have created a side project that shows a UIWebView animating upwards. The purple squares represent touch events on the presentation layer, while the blue squares represent touch events outside of the presentation layer.
https://github.com/AdamBCo/UIWebView-Animation-Issues
As seen in the example, UIViewAnimationOptionAllowUserInteraction is set in the UViewAnimation block.
A UIWebView is complicated layout of web elements. To redraw that during animation there is simply not enough time available to entirely redraw the UIWebView, keep the controls in it available for interaction and do the animation.
However there are some settings for this inside a CALayer on what to do with its contents when animating it. I would start looking into that.
Related
I'm using a UIScrollView whose content is a simple UIView subclass whose size is set using auto layout and which uses drawRect: to render its content rather than having subviews of its own.
If the content (and the size) of the UIView changes then everything works as intended. The new content instantly appears and the scrollability of the UIScrollView enables/disables if the size of the content now needs / no longer needs scrolling.
However, if there's an animation going on somewhere else on the screen things no longer work as intended.
In that case the change to the UIView is animated along with that other animation.
So if that other animation takes say, 2 seconds, the new UIView content is instantly redrawn but at a scale so that it fits in the old content's size. Then it animates the content, growing (or shrinking) over a period of 2 seconds so that at the end of the animation its size is what it should be.
The "interfering" animator in question is owned by a ViewController quite a bit further up in the food chain and the UIScrollView and its content UIView are never told about the UIViewPropertyAnimator.
The problem only happens if the content change overlaps the animation. If that other animation has completed (or hasn't started yet) the content in the scroll view is updated instantly.
Does anyone have insight into this, or perhaps could suggest a way to force UIScrollView and/or its content view to always do their own thing and not tag along for the ride if some unrelated UIViewPropertyAnimator is chugging along elsewhere?
EDIT: A bit of extra info
The animation code is older and originally made use of UIView.Animate and some swipe gestures were triggering the animation. In that case even if the animation and the content size change overlap (using the exact same repro scenario), the new (scrolled content) size appears immediately and doesn't get linked to the UIView.Animate animation. Swapping in UIViewPropertyAnimator code (and without any gesture recognizers getting involved) the problem is triggered and content size change becomes animated.
My ImageView rotates but while it rotates it doesn't recognize touches on itself.
Do you think it's okay if I create a button via code that's over the ImageView that recognizes the touch?
When an animation is applied on any UIView or any subclass object of a UIView like UIImageView, UIButton etc then it does not detect touch events because when an animation is applied to a view, the animated property changes to its end value right away. what you are actually seeing on screen is the presentation layer of your views layer.
To answer your question, Yes, you can make a UIButton that covers up the area of the UIImageView to detect touch events on it. That sounds like the easiest to implement option in this case.
Apart from that, this link may also help you in the process. Hit testing animating layers
I am building a word tetris kind of an app. Now I have to move a Uiview containing 8 uibuttons towards the bottom of the screen based on time and also track the position of uibuttons as the user taps specified button.
Am I suppose to use Block based animation or core animation to do the task.
Currently if I am animating frame and center of superview it seems like I have to do the same for the subviews as well inside the block.
Any input would be handy.
You can use UIView block animation to animate a view and it's subviews quite simply.
However, neither UIView animation nor core animation will let the user click on buttons as they are animating. Button actions don't work at all on "in flight" animations. There's no automatic way to do that. (At least none that I know of.)
Instead, you have to add a tap gesture recognizer to the parent view, and do hit testing on the presentation layer of your parent view to see which sublayer of the presentation layer is tapped.
I'm trying to create some sort of timeline view like in video editors: media elements in a row, which are UIView's. I can successfully drag these views inside currently visible part of scroll view using UIScrollView touch events like touchesBegan and touchesMoved. I want to scroll the scroll view once subview is dragged to one of the scroll view edges. The best I can think of now is to create a timer that will scroll the view while user holds the subview with the finger near scroll view edge.
There's a lot of questions here on the same topic, but I was unable to find one that covers scrolling.
Is there a good way to do this? Should I use gesture recognizers instead?
Thank you in advance.
Actually what you want IS a timed event. As soon, as the user is at the edge of the scrollview, you start a timer, which regularly increases the contentOffset. If you don't like your animation results (i guess you're using setContentOffset:animated:?), just try another timing and distance of animation.. I guess you have to try some different settings. What I would try first is 1px at a time. Perhaps every 0.3 second?
If that doesn't work you could also try another "extreme". Start a single animation, when the user reaches the edge, which animates the contentOffset until the end of the contentSize. But over a large timespan so the movement is slow. If the user stops dragging, or moves out of the edge, stop the animation at the current position. That would even be a solution without a timer, because the animation would be your timer itself.
I seriously doubt gesture recognizers would part of a good solution to this since they tend to be most helpful with discreet gestures.
I don't think I can improve on your general direction based on the assumption, implied above, that you are looking for continuous/gradual scrolling.
What I suggest instead is that you consider designing this to use a paged scrolling approach. When your user drags the object to the edge of the scrollview, cause the scrollview to move one page in that direction (by setting the contentOffset to move in that direction according to the bounds of the scrollview). When that even occurs, move the object slightly out of the "hot zone" at the edge of the scrollview so that the user is forced to explicitly express that they want to move another page, or something along those lines - that is, since the design approach depends on this "paging events" you need to implement some sort of gestural system for the user to keep paging.
I suppose you could use a timer in that same situation, so that if the user maintains the position and touch for another second, you would page again.
I have two views that flip based on a button press within the view. The view has two CAGradientLayers as sublayers. If I flip immediately after the action method fires, the button is in the process of changing the opacity of the gradients and so you see stuttering (the UIVIew flip animation is having to accommodate the button that is itself changing.)
I can hack a solution by doing a performWithSelection:withObject:afterDelay:0.1f, but it feels like such a hack. I tried setting the layer's needsDisplay property and testing for when it was clears, but probably this is insufficient to tell me the screen itself has redrawn.
Dav
In the end this has no solution. I have since found that when animating a view there are severe performance implication if you also try to animate the super views. You can see this in many iOS apps where the app animates an image in a scrolling list - the scrolling stumbles.
So what I learned is either animate something, or it's view, but not both!