First, the old way is to call BeginAnimations, optionally configure the animation options, make your view changes, and then call CommitAnimations. See Listing 17-1.

UIView.BeginAnimations("ImageMove");
//code to make changes to the view (move controls, swap views, etc.)
UIView.CommitAnimations();

Using this method, iOS will automatically animate any changes that occur between the BeginAnimations and CommitAnimations calls.

Technically, Apple refers to this method of animation as Animation Blocks, but as we're about to see, that's really confusing, given that the new way is called Block-Based Animation. I'll just refer to it as "the old way" to avoid confusion.

The new way is to make a call to the Animate method, specify the duration of the animation, optionally specify any of the animation options, and then pass a method (or code as a lambda) that makes the changes that should be animated. See Listing 17-2.

UIView.Animate(0.2, () => { /* code to animate */ });

In this case, to simplify things, I've used the C# lamdba syntax, but you could also pass an anonymous delegate, as shown in Listing 17-3.

UIView.Animate(0.2, delegate() { /* code to animate */ });

This approach is known as block-based animation. It's called such because in objective-c, the analog to code that's passed in to execute is called a block. If you take a look at the prototype for the Animate methods (there are several overrides), they all take NSAction objects for their blocks. MonoTouch automatically does the magic of converting an anonymous delegate into an NSAction for you, so it's a very clean and seamless integration with the underlying Objective-C runtime.

While Apple recommends the new block-based animation approach, it's not exactly forthcoming in terms of why it's recommended. It's likely because it more closely ties into Apple's new paradigm of parallel tasking (see the Grand Central Dispatch article on Wikipedia.org for more information, at http://en.wikipedia.org/wiki/Grand_Central_Dispatch).

Regardless of why Apple recommends the new approach, it's arguably cleaner. Since the code that performs the view modifications is actually passed to the animation function, there's no method wrapping magic that has to happen.

However, block-based animation is missing the following two key features that are possible with the old way:

Having to specify the duration isn't a huge deal, but not being able to specify a fixed repetition count is very difficult to work around, if you need that particular feature.

Hopefully, at some point, Apple will realize the oversight and add these features back in. Until then, if you need to specify a fixed repetition count, you should use the old approach.

In this chapter, we're going to examine both approaches to view-based animation.

View-based animation is based on a view's property changes. There are a number of properties that, when changed within the context of a view-based animation (either a block based animation or animation blocks), will get automatically animated. Those properties are as follows:

The upside to this is that, if your animations are based on changes to any of these properties, view-based animation is very easy. The downside is that if you want to animate other properties, you need to use Explicit Layer Animations (as we'll explore later in this chapter). Fortunately, however, these properties cover most animation needs.

There are a number of options that you can configure that affect the behavior of an animation, namely the following:

Animate(double duration, MonoTouch.Foundation.NSAction animation)
Animate(double duration, MonoTouch.Foundation.NSAction, MonoTouch.Foundation.NSAction
        animation)
Animate(double duration, double delay, UIViewAnimationOptions options,
        MonoTouch.Foundation.NSAction animation, MonoTouch.Foundation.NSAction
completion)

double duration = 1;
double delay = 2;
UIViewAnimationOptions animationOptions =
        UIViewAnimationOptions.CurveEaseIn | UIViewAnimationOptions.Repeat;
UIView.Animate(duration, delay, animationOptions, () => { /* animation code */ }, null);

Table 17-2 lists the animation curves available in CoreAnimation:

Table 17.1. Animation Curves in CoreAnimation

Type	Description	Graph
CurveEaseInEaseOut	Accelerates at the beginning of the animation and decelerates at the end of the animation. Provides the most natural feeling animation for most animation types and is the default animation curve.
CurveEaseIn	Accelerates at the beginning of the animation. Good for animations that send things off-screen.
CurveEaseOut	Decelerates at the end of the animation. Good for animations that bring things onscreen.
CurveLinear	No acceleration curve at all, therefore the animation speed is constant from start to finish. Linear curves are useful for animations that don't require a natural acceleration/deceleration.

In addition to using view animations to move things around on a view, you can also animate adding and removing views from a controller. This allows you to provide a cinematic way to transition between screens. For example, you could apply a flip transition that "spins" a new view onto the screen, or a "curl" animation that lifts the current view off the screen and displays another.

The UIViewAnimationOptions enumeration contains a number of values that apply only to transition animations:

If you're using the older animation methods, then behavior options are configured using various methods. See Listing 17-6.

UIView.BeginAnimations("MyAnimation");
UIView.SetAnimationDelay(2);
UIView.SetAnimationCurve(UIViewAnimationCurve.EaseIn);
UIView.SetAnimationDuration(1);
//... animation code goes here
UIView.CommitAnimations();

All the UIView animation methods are static, and the following are available to configure the animation properties if you're using the older animation methods. Most of these correspond 1:1 with either parameters in the Animate method or flags from the UIViewAnimationOptions enumeration:

If you're using the method-based animation technique, and you want to execute code after the animation finishes, you should call the SetAnimationDidStopSelector method, which takes a Selector that points to your method. See Listing 17-7.

UIView.SetAnimationDidStopSelector(new Selector("AnimationStopped"));

Since the method takes a Selector, you must also mark your method with the ExportAttribute so it's visible to the underlying Objective-C runtime. See Listing 17-8.

[Export]
public void AnimationStopped()
{ Console.WriteLine("Animation completed"); }

As the name suggests, layer-based animation involves the use of layers (represented by the CALayer object). Don't confuse CALayers with CGLayers. They are similar in concept, but are fundamentally different under the hood and cannot be interchanged.

You can create CALayers one of two ways. The easiest way is to simply get the layer from an existing UIView. All UIView objects in iOS are known as layer-backed views. This means that each view has a layer-tree hierarchy that represents the items in a view, and you can access it via the Layer property on any UIView object. The other way to get a CALayer is to create one manually, which is a bit more involved. We'll take a look at how to do that in just a second.

Layers are interesting in that they're not directly responsible for drawing themselves. Instead, they are an object hierarchy that contains information that describes the state of a UIView. However, under the hood, there is another set of layer information that is used in the rendering loop. When you change a property on the layer, it will actually feed incremental changes to the rendering loop so that the change that you've applied is rendered incrementally over the animation duration.

This functionality is all encapsulated for you, so you don't have to perform the math associated with changes, the layer system does it for you.

There are two types of layer-based animations:

Superficially, implicit animations seem easier to use. However, they required that you manually create your layers, which can be complicated. Explicit animations require more code to actually do the animation, but because you can use them with layers that are created via a view, they are actually easier to implement.

We're going to look at explicit animations first, and then we're going to turn to implicit animations and cover how to create CALayer objects manually.

Explicit Animations

Explicit layer-based animations are a little different from the other animations that we've looked at so far. Instead of creating an animation block and executing it, you configure the animation parameters and then tell the animation what property to listen for changes to. When that property's value changes, the animation specified runs. For instance, to achieve the animation illustrated in Figure 17-1, we would do something like Listing 17-9.

Example 17.9. Implementing a keyframe animation that moves an object along a path

this.btnAnimate.TouchUpInside += (s, e) => {
        //---- create a keyframe animation that listens for changes to the "position"
        // property
        CAKeyFrameAnimation keyFrameAnimation =
                (CAKeyFrameAnimation)CAKeyFrameAnimation.FromKeyPath("position");
        keyFrameAnimation.Path = this._animationPath;
        keyFrameAnimation.Duration = 3;
        //---- add the animation to the layer
        this.imgToAnimate.Layer.AddAnimation(keyFrameAnimation, "MoveImage");
        //---- kick the animation off by changing the position to the final position
        this.imgToAnimate.Layer.Position = new PointF(700, 900);
};

This would result in the animation shown in Figure 17-2.

Figure 17.2. An explicit layer animation that moves an object along a path

You can see this animation at work in the Example_CoreAnimation companion code and application.

In Listing 17-9, we created instantiated a CAKeyFrameAnimation object and passed the constructor the name of the property we want to listen for. In this case, we want to listen for the Position property, but it expects the Objective-C visible property name (generally the same name but starting with a lowercase letter), in this case it would be "position." We'll talk about the different types of animations later, but for now, know that a keyframe animation will animate movement along a path.

Next, we configure our animation, this case, because it's a keyframe animation, we supply it a path defined in a CGPath object (check out Chapter 16 for more information about CGPaths).

After we've configured the animation, we add it to the layer and give it a name. We name it so that later on, if we want to stop the animation (by removing it), we can do something like Listing 17-10.

Example 17.10. Removing an animation, If you remove an animation while it's in flight, the animation is stopped.

this.imgToAnimate.Layer.RemoveAnimation("MoveImage");

Finally, to kick off our animation, we set the property that we're listening for changes on to its final value. Once we've done that, the animation will begin.

Animation Types

In Listing 17-9 we created a CAKeyFrameAnimation that animates along a set of positional points, however, there are a number of animation classes available for use:

• CATransition: Used to provide transition animations, such as fading in/out, or pushing onto/off the view stack. You can extend the stock transition effects by creating your own custom Core Image filters.

• CAPropertyAnimation: CAPropertyAnimation is an abstract base class for providing animations for custom layer properties that can be reused.

• CABasicAnimation: Used for simple movement animations that go from from a start point to an end point.

• CAKeyFrameAnimation: Animates an object along a path, as seen in Figure 17-2.

Additionally, there is one additional class, CAAnimationGroup, which allows you to group a set of the previous animation classes together into an array and run them concurrently. For a more in-depth look at these classes, checkout the Core Animation Programming Guide as well as the Animation Types and Timing Programming Guide in the Xcode developer documentation.

//==== Method 1: create a layer from an image
protected CALayer CreateLayerFromImage()
{
        CALayer layer = new CALayer();
        layer.Contents = UIImage.FromBundle("Images/Icons/Apress-114x114.png").CGImage;
        return layer;
}

//==== Method 2: create a layer and assign a custom delegate that performs the drawing
protected CALayer CreateLayerWithDelegate()
{
        CALayer layer = new CALayer();
        layer.Delegate = new LayerDelegate();
        return layer;
}

public class LayerDelegate : CALayerDelegate
{
        public override void DrawLayer (
                CALayer layer, MonoTouch.CoreGraphics.CGContext context)
        {
                //---- implement your drawing
        }
}

//===== Method 3: Create a custom CALayer and override the appropriate methods
public class MyCustomLayer : CALayer
{
        public override void DrawInContext (MonoTouch.CoreGraphics.CGContext ctx)
        {
                base.DrawInContext (ctx);

//---- implement your drawing
        }
}

this._imgLayer = this.CreateLayerFromImage();
this._imgLayer.Frame = new RectangleF(200, 70, 114, 114);
this.View.Layer.AddSublayer(this._imgLayer);

Implicit Animations

Implicit animations are animations that are automatically invoked whenever you a change a property. This may seem like an awesome way to do layer animation, but there is one huge caveat: implicit animations are not available on layers that are created from a UIView. Instead you have to either use explicit layer animations, or view-based animations. This is because when you change the value of a property on a layer, it asks its delegate whether or not it should animate. If a layer is attached to a UIView, the view acts as the layer's animation delegate and says "no." This, presumably, is because most view changes don't require animation.

Listing 17-13 uses the layer we created and added to the layer hierarchy in Listing 17-12. When a user clicks on a button, the code changes the Frame and Opacity properties of the layer.

Example 17.13. Implicitly animating a change to a layer

this.btnAnimate.TouchUpInside += (s, e) => {
        if(this._imgLayer.Frame.Y == 70)
        {
                this._imgLayer.Frame = new RectangleF(new PointF(200, 270)
                        , this._imgLayer.Frame.Size);
                this._imgLayer.Opacity = 0.2f;
        }
        else
        {
                this._imgLayer.Frame = new RectangleF(new PointF(200, 70)
                        , this._imgLayer.Frame.Size);
                this._imgLayer.Opacity = 1.0f;
        }
};

This results in a cinematic transition between the two states, as shown in Figure 17-3.

Figure 17.3. Implicit layer animation between two layer states

You can see this animation at work in the Example_CoreAnimation companion code and application.