7 min read

(For more resources related to this topic, see here.)

Motion and physics in UIKit

With the introduction of iOS 7, Apple completely removed the skeuomorphic design that has been used since the introduction of the iPhone and iOS. In its place is a new and refreshing flat design that features muted gradients and minimal interface elements. Apple has strongly encouraged developers to move away from a skeuomorphic and real-world-based design in favor of these flat designs.

Although we are guided away from a real-world look, Apple also strongly encourages that your user interface have a real-world feel. Some may think this is a contradiction; however, the goal is to give users a deeper connection to the user interface. UI elements that respond to touch, gestures, and changes in orientation are examples of how to apply this new design paradigm. In order to help assist in this new design approach, Apple has introduced two very nifty APIs, UIKit Dynamics and Motion Effects.

UIKit Dynamics

To put it simply, iOS 7 has a fully featured physics engine built into UIKit. You can manipulate specific properties to provide a more real-world feel to your interface. This includes gravity, springs, elasticity, bounce, and force to name a few. Each interface item will contain its own properties and the dynamic engine will abide by these properties.

Motion effects

One of the coolest features of iOS 7 on our devices is the parallax effect found on the home screen. Tilting the device in any direction will pan the background image to emphasize depth. Using motion effects, we can monitor the data supplied by the device’s accelerometer to adjust our interface based on movement and orientation.

By combining these two features, you can create great looking interfaces with a realistic feel that brings it to life. To demonstrate UIKit Dynamics, we will be adding some code to our FoodDetailViewController.m file to create some nice effects and animations.

Adding gravity

Open FoodDetailViewController.m and add the following instance variables to the view controller:

UIDynamicAnimator* animator;
UIGravityBehavior* gravity;

Scroll to viewDidLoad and add the following code to the bottom of the method:

animator = [[UIDynamicAnimator alloc] initWithReferenceView:self.view];
gravity = [[UIGravityBehavior alloc] initWithItems:@[self.foodImageView]];
    [animator addBehavior:gravity];

Run the application, open the My Foods view, select a food item from the table view, and watch what happens. The food image should start to accelerate towards the bottom of the screen until it eventually falls off the screen, as shown in the following set of screenshots:

Let’s go over the code, specifically the two new classes that were just introduced, UIDynamicAnimator and UIGravityBehavior.

UIDynamicAnimator

This is the core component of UIKit Dynamics. It is safe to say that the dynamic animator is the physics engine itself wrapped in a convenient and easy-to-use class. The animator will do nothing on its own, but instead keep track of behaviors assigned to it. Each behavior will interact inside of this physics engine.

UIGravityBehavior

Behaviors are the core compositions of UIKit Dynamics animation. These behaviors all define individual responses to the physics environment. This particular behavior mimics the effects of gravity by applying force. Each behavior is associated with a view (or views) when created. Because you explicitly define this property, you can control which views will perform the behavior.

Behavior properties

Almost all behaviors have multiple properties that can be adjusted to the desired effect. A good example is the gravity behavior. We can adjust its angle and magnitude. Add the following code before adding the behavior to the animator:

gravity.magnitude = 0.1f;

Run the application and test it to see what happens. The picture view will start to fall; however, this time it will be at a much slower rate. Replace the preceding code line with the following line:

gravity.magnitude = 10.0f;

Run the application, and this time you will notice that the image falls much faster. Feel free to play with these properties and get a feel for each value.

Creating boundaries

When dealing with gravity, UIKit Dynamics does not conform to the boundaries of the screen. Although it is not visible, the food image continues to fall after it has passed the edge of the screen. It will continue to fall unless we set boundaries that will contain the image view. At the top of the file, create another instance variable:

UICollisionBehavior *collision;

Now in our viewDidLoad method, add the following code below our gravity code:

collision = [[UICollisionBehavior alloc] initWithItems:@[self.foodImageView]];
collision.translatesReferenceBoundsIntoBoundary = YES;
    
[animator addBehavior:collision];

Here we are creating an instance of a new class (which is a behavior), UICollisionBehavior. Just like our gravity behavior, we associate this behavior with our food image view.

Rather than explicitly defining the coordinates for the boundary, we use the convenient translatesReferenceBoundsIntoBoundary property on our collision behavior. By setting this property to yes, the boundary will be defined by the bounds of the reference view that we set when allocating our UIDynamics animator. Because the reference view is self.view, the boundary is now the visible space of our view.

Run the application and watch how the image will fall, but stop once it reaches the bottom of the screen, as shown in the following screenshot:

Collisions

With our image view responding to gravity and our screen bounds we can start detecting collisions. You may have noticed that when the image view is falling, it falls right through our two labels below it.

This is because UIKit Dynamics will only respond to UIView elements that have been assigned behaviors. Each behavior can be assigned to multiple objects, and each object can have multiple behaviors. Because our labels have no behaviors associated with them, the UIKit Dynamics physics engine simply ignores it.

Let’s make the food image view collide with the date label. To do this, we simply need to add the label to the collision behavior allocation call. Here is what the new code looks like:

collision = [[UICollisionBehavior alloc] initWithItems:@[self.foodImageView, 
self.foodDateLabel]];

As you can see, all we have done is add self.foodDateLabel to the initWithItems array property. As mentioned before, any single behavior can be associated with multiple items. Run your code and see what happens. When the image falls, it hits the date label but continues to fall, pushing the date label with it.

Because we didn’t associate the gravity behavior with the label, it does not fall immediately. Although it does not respond to gravity, the label will still be moved because it is a physics object after all. This approach is not ideal, so let’s use another awesome feature of UIKit Dynamics, invisible boundaries.

Creating invisible boundaries

We are going to take a slightly different approach to this problem. Our label is only a point of reference for where we want to add a boundary that will stop our food image view. Because of this, the label does not need to be associated with any UIKit Dynamic behaviors. Remove self.foodDateLabel from the following code:

collision = [[UICollisionBehavior alloc] initWithItems:@[self.foodImageView, 
self.foodDateLabel]];

Instead, add the following code to the bottom of viewDidLoad but before we add our collision behavior to the animator:

// Add a boundary to the top edge
CGPoint topEdge = CGPointMake(self.foodDateLabel.frame.origin.x + 
self.foodDateLabel.frame.size.width, self.foodDateLabel.frame.origin.y);
[collision addBoundaryWithIdentifier:@"barrier" 
fromPoint:self.foodDateLabel.frame.origin toPoint:topEdge];

Here we add a boundary to the collision behavior and pass some parameters. First we define an identifier, which we will use later, and then we pass the food date label’s origin as the fromPoint property. The toPoint property is set to the CGPoint we created using the food date label’s frame.

Go ahead and run the application, and you will see that the food image will now stop at the invisible boundary we defined. The label is still visible to the user, but the dynamic animator ignores it. Instead the animator sees the barrier we defined and responds accordingly, even though the barrier is invisible to the user.

Here is a side-by-side comparison of the before and after:

Dynamic items

When using UIKit Dynamics, it is important to understand what UIKit Dynamics items are. Rather than referencing dynamics as views, they are referenced as items, which adhere to the UIDynamicItem protocol. This protocol defines the center, transform, and bounds of any object that adheres to this protocol. UIView is the most common class that adheres to the UIDynamicItem protocol. Another example of a class that conforms to this protocol is the UICollectionViewLayoutAttributes class.

Summary

In this article, we covered some basics of how UIKit Dynamics manages your application’s behaviors, that enables us to create some really unique interface effects.

Resources for Article:

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here