I have a UIImageView whose instance has a repeating pulse-like animation.
I want this UIImageView to move with the force of the accelerometer. To do this I have added another animation, this time a translation.
However, once this translation happens, it stops the pulse, even when its not animating.
As these two animations are separate, I cannot use the CGAffineTransformConcat method to combine both animations.
I have tried adding one to the UIView and one to the layer property of the same UIView but it does not work.
I have also tried adding the movement directly to the frame of the view, however, this just causes my view to disobey the constraint constraining it to the center x of the superview.
Does anyone use/know of a work around to this?
Thanks as always!
Related
So I want to add a PanGestureRecognizer to a UIView class that I have made. Everything is working well, however: when I drag the view, it's subviews are also moving/updating etc.
-I am using SnapKit for my view's constraints
-I tried setting translatesAutoresizingMask to false, no result
-I tried to set constant constraints on the subviews,not result
Here is a gif of what it looks like:
https://media.giphy.com/media/oI0Wf5T6B0jIY/giphy.gif
Thanks for the help everyone.
This is expected and is how UIKit (and essentially all 2D/3D scene graphs) are designed to work. The geometry of a view is relative to its parent view. If the parent view moves, so do its decedents.
If you do not want a view to be dependent on the position of the view being moved, it probably should not be a subview of that view in the first place. It's possible to apply the inverse movement to the subviews to make it appear that they're not moving, but that is most likely a lot more work than just not making them subviews in the first place.
I'm new to core animation and I'm struggling with one thing - how to combine autolayout with core animation. Actually I've found only one sentence in the documentation of Core Animation which refers to Autolayout here is it
Remember to Update View Constraints as Part of Your Animation
If you are using constraint-based layout rules to manage the position of your views, you must remove any constraints that might interfere with an animation as part of configuring that animation. Constraints affect any changes you make to the position or size of a view. They also affect the relationships between the view and its child views. If you are animating changes to any of those items, you can remove the constraints, make the change, and then apply whatever new constraints are needed.
But as I've tried all is not as strait-forward as it may seem.
Here is my scenario.
I've designed a sliding menu which uses autolayout extensively. Here is the appearance of that view.
I'm using autolayout constraints to force proportional positioning of those items in the sliding menu. Actually there are a lot of constraints there and I didn't want to post all of those in my question, and even may be they are not needed for direct answer of this question, however if you need them I can update the post with those constraints.
The animation that you see in the gif was reached by only autolayout. I just added outlet to the height constraint of the sliding menu and changed it in this way: (the code is written using Xamarin Monotouch, but I believe it should be clear what is done here for pure iOS developers)
private void AnimateSlideMenuAppearance()
{
float height;
if (isSlideMenuShown) {
height = 0;
} else {
height = slideMenuHeight;
}
UIView.Animate (0.4,
delegate {
this.slideMenuHeightConstraint.Constant = height;
this.View.LayoutIfNeeded ();
},
delegate {
isSlideMenuShown = !isSlideMenuShown;
});
}
Now I want to get more sophisticated appearance transition. CLICK HERE to see the effect that I want to reach.
Just to try out I tried to implement the disappearing part of that animation with series of CABasicAnimations, but it was unsuccessful, I get strange behaviour.
Can anybody suggest what I should do here? Is that possible to use autolayout to calculate the positions of the views, but somehow override the animation between autolayout size changes? I mean in my concrete example instead of proportionally decreasing the sizes of all buttons in menu I need to add FadeOut animation to them, animate the bounds to zero and also radically increase begin time of the animations from button to button in order to get the effect that I want. Or may be I need to completely get rid of autolayout and manually calculate the sizes and animations?
What is the best practice in these kind of scenarios - when you have complex autolayouting and you need custom Core Animation transitions between autolayout changes? I hope that I described the question well.
Thank you for your answers.
This is completely feasible, while it may be complex solely because it looks like your desired cases will have multiple animations.
However, I noticed one thing in your code that's odd: you change the constant on the constraint (this.slideMenuHeightConstraint.Constant = height) in the animation block, instead of before it. For nearly all cases I can imagine, you should change the constraint before the animation block. Constraints are not visually rendered until either the next UI run loop (or by setNeedsUpdateConstraints to force it for the next run loop), or immediately by layoutIfNeeded. And since [UIView animate:...] is doing this for you, layoutIfNeeded should (generally) be the only thing in your animate block, when animating autolayout.
In your case, you will have to make the animation somewhat reactive, however - for e.g., if you want to add those buttons in like in the example and have them pop in, animate out, and grow. After calling layoutIfNeeded, you can safely check the frame size. If it's beyond your threshold (or some other metric), you can trigger then animations of the buttons. (So yes, this may be a case where I'd add more code inside the animate block -- check the threshold, begin other animation, etc).
I have a UIView subclass object that animates and therefore changes its position over time as a subview in my UIViewController's view. Actually my moving UIView subclass is just an image of a ball and it's moving as if it was hanging down from my devices screens top border. But to be a real pendulum I'd like to also draw a line between my ball and the CGPoint it hangs down from on top of my screen.
My idea was to just draw a line every time the UIView changes its position. But as the moving is done within an iOS API (I'm just calling something like [myBallView swing]) I can't do this at the same place the movement is happening. I'm actually not animating the view myself.
The only solution I have in my mind to solve my issue is pretty bad: subclassing UIView, adding it as a superview to my moving UIView and adding a line every time drawRect is called. But I'm not even sure drawRect is going to be called there. Either way, there must be a better solution for this.
Does anyone know a good solution to my problem?
Making a custom subclass of UIView as the superview is reasonable.
However, rather than drawing the line yourself, I would suggest implementing +layerClass in your custom view, and making the backing layer a CAShapeLayer.
Then you can create a CGPath in the view's shape layer that is a line, and manipulate the start and end points of the line when your other view's center moves. Shape layers are designed to draw as part of the screen update process, and you could even make the change animate by changing the endpoints of the path with a CABasicAnimation.
Seems like a very simple problem! But I'm having great difficulty.
My ideas and attempts so far:
scrollView.backgroundColor = [UIColor colorWithPatternImage:myImage]]
Doesn't scroll with contents
Create UIView the size of contentSize (actually, larger due to elastic bounces on scroll view), and use pattern as above on this sub view of UIScrollView.
Causes massive memory hit (and crash) when UIView gets too large. See also: Large UIScrollView with background pattern fails
Similar to (2), exept I only create a UIView the size of the maximum number of repetitions of the background image that will be seen, and cleverly move the view to wherever is needed to show the correct background repetitions.
Causes this background view to shift left and right unexpectedly when animating the scroll.
Create UIView subclass and override drawRect. Use various Core Graphics techniques to draw content by hand.
Not animatable. Implementing my own contentOffset property isn't a standard Core Animation property.
Overriding drawRect on UIScrollView doesn't respect the content offset, and doesn't get called multiple times as it scrolls/animates. The rect parameter is always simply the bounds of the UIScrollView.
As with (4), except I set the bounds.origin of my UIView subclass in my setContentOffset implementation, since it's an animatable property.
drawRect doesn't seem to get called every frame.
Use CATiledLayer, as suggested in this answer: Large UIScrollView with background pattern fails. Implementation details here: http://www.cimgf.com/2011/03/01/subduing-catiledlayer/.
I really don't want the ugliness of seeing tiles asynchronously being drawn as user scrolls. It's just a simple background pattern!
This seems like the simplest thing! Why is it so hard!?
Maybe the sample code:ScollViewSuit->3_Tiling can help you. You can search it in the official docset.
This works like CATiledLayer but only use UIKit, the tile was loaded on the main thread.
And I really don't think this is a good solution.
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!