One of the things sorely lacking from iOS is the ability to set keys on an attribute/attributes and interpolate between them using a spline. Has anyone thought about this and/or found an approach to get around this? Is everyone using Cocos2d for this sort of thing? Cocos2d is way more capability then I need?
Thanks,
Doug
Check out the CAKeyframeAnimation class. UIViews use Core Animation layers, so a Core Animation...er...animation that you apply to a view’s layer gets applied to its contents as well. Most appearance-related properties on CALayer are animatable—obvious ones like frame and opacity, for instance, but also things like backgroundColor and cornerRadius.
Related
I'm creating a rather complex animation, using UIViewPropertyAnimator, where I have the need to make precise movements like this one:
I was wondering what's the difference if I achieve this while animating the constraints, or animating the transform?
I achieved, what you see in the gif, using transform animations. But I got curious, and I got few more screens like this to animate so I wanted to know if there is a preferred way, or any 'animation rules'.
I'm mostly curious if there is a performance difference, but I'd also like to hear if someone got stuck using one of the mentioned ways.
I'm working on building a custom control. Basically I want to allow the application to generate rectangles (positioned at x = 0 with a variable y value that increases as each rectangle is added).
I'd like them to respond to gestures where they have two positions (closed - which mostly hidden, open - expanded fully so that the entire rectangle is still visible but tethered to the side).
I've already designed an application with this in mind. Seeing as the rectangles will be generated by the users, I assume core graphics would be best for the job. Also, I want the rectangles to display different information based on their gesture-related position.
Is it possible to combine core graphics with these types of controls? I know this is asking a lot.
It's just that I'm having trouble determining how to combine each component in code.
Any advice would be greatly appreciated. Thanks!
Clearly, we're not here to write code for you, but a few thoughts:
You say that you assume Core Graphics would be best for the job. You definitely could, but you could also use CAShapeLayer, too.
So you might create a gesture recognizer whose handler:
Creates a CAShapeLayer when the gesture's state is UIGestureStateBegan and adds it as a sublayer of the view's layer.
Replace that shape layer's path property with the CGPath of a UIBezierPath which is created on the basis of updated location that the gesture recognizer handler captures when the gesture's state is UIGestureStateChanged.
I'd suggest you take a crack at that (googling "CAShapeLayer tutorial" or "UIPanGestureRecognizer example" or what have you, if any of these concepts are unfamiliar).
If you really want to use Core Graphics, you would have a custom UIView subclass whose drawRect draws all of the rectangles. Conceptually it's very similar to the above, but you have to also writing your own rectangle drawing code that you'll put in drawRect, rather than letting CAShapeLayer do that for you.
What is the difference between CGContextDrawLinearGradient, called in a UIView's drawRect method, and a CAGradientLayer? How do they compare performance wise? What is the best practice for creating gradient views? I'd really like a nice explanation of how they relate to each other and why one is better performance than the other.
Thanks.
If you just want a box with a gradient in it then performance isn't really an issue. You should go with whatever is simplest to implement for your particular requirements.
Adding a CAGradientLayer means you don't have to create a view subclass, you can just add the layer to an existing view. The setup is also slightly easier, since you don't need to worry about frame sizes or any c-style core graphics functions. You can also add rounded corners, shadows etc without too much effort.
However, if you want more than one gradient view, a subclass might be a good idea, so you can just instatiate new ones.
So, unfortunately, there isn't a clear cut answer to your question. Neither is definitively better. If you are concerned with performance, implement both and test using instruments.
You know how the iPad can invert colors? For the app I'm working on we wanted to have a button that would invert the colors for one of the views the same way. Does the sdk have any kind of support for something like that already?
I don't think that there is an easy way at the moment. CALayer has a compositingFilter property which is described as
A CoreImage filter used to composite
the receiver’s contents with the
background. Animatable.
It's available since iOS 2.0 but it also says:
While the CALayer class exposes this
property, Core Image is not available
in iOS. Currently the filters
available for this property are
undefined.
Core Image would have been ideal for that purpose, it does provide a filter (CIColorInvert) to invert colors.
Another apporach would be: Change the color properties of the UI controls you are using, though I doubt that everything will look they way you expect, as there may be gradients and such. You have to implement your own small algorithm to invert a given color.
I see only the hard way: You have to draw your controls manually with drawRect and invert the colors with your own algorithm there.
I'm struggling with conceptualizing animations with a CALayer as opposed to UIView's own animation methods. Throw "Core Animation" into this and, well, maybe someone can articulate these concepts from a high level so I can better visualize what's happening and why I'd want to migrate UIView animations (which I'm quite familiar with now) to CALayer animations on the iPhone. Every view in Cocoa-Touch automatically gets a layer. And, it seems, you can animate one and/or the other?!? Even mix them together?!? But why? Where's the line? What's the pro/con to each?
The Core Animation Programming Guide immediately jumps into Layer & Timing Classes and I think need to take a step back and understand why these varied pieces exist and how relate to each other.
Use views for control and layers for eye candy. Layers don't receive events so it's easier to use a view for those cases, but when you want to animate a sprite or backgrounds, etc., layers make sense. Events pass right through layers to the backing view so you can have a pretty visual representation without messing up your events. Try to overlay a view that you're just using for visual representation and you'll have to pass tap events through to the underlying view yourself.
An UIView is always rendered to a CALayer. When you use UIView methods to animate a view, you are effectively manipulating the underlying CALayer.
If you need to do simple things, use the UIView methods. For more complex situatins, or if you want layers not associated with any view in particular, use CALayers.
I've done a bunch of apps in the past year. Here's my rule of thumb:
Use UIView until it doesn't do what you want.
Then move to CoreAnimation. But before you get into it too much...
If you write more than a few animations, use Cocos2D.
UIView transforms are only 2D and are restricted to that, LAyer transforms however can be 3D and you should use those if you want to do 3D stuff, UIView animation will work if you change either the UIView transform or the CALayer transform. So at a basic level, you can do a lot more manipulation when you are working with a Layer rather than the View.
I am not sure if I am misunderstanding Chris' response to "What's Cocos2D doing better? Don't you have other problems then, regarding the touch event handling and many other stuff that misses in openGL ES?"
It sounds like the answer suggests Cocos2D is not based on the OpenGL ES framework when in fact it actual is. While it is a great 2D game engine it does implement OpenGL for much of it's rendering - attached to a physics library it allows for a lot of very interesting possibilities for animation - and Chris is correct - it is a lot less coding indeed.