Xamarin.Forms Label controls do not have the capability to adjust their font size to accomodate the width of the content. You have to use a view renderer in the platform-specific project to accomplish this. This blog post shows how to customize a label control for use in XAML for the iOS platform.

In the Configure your new project dialog, leave the Solution and Project names set to LabelWorld, choose a suitable location for the project, and then click the Create button.

Run the app in the simulator by pressing the Start button (looks like a Play button):

Add a XAML Page

In Xamarin Studio’s left-hand pane, Solution, click the gear icon next to the LabelWorld project and select Add > New File…

In the New File dialog, select Forms > Forms ContentPage Xaml, name the new file LabelWorldPage, and click the New button. This will add a XAML page named LabelWorldPage to the project. This includes a XAML page:

Run the project and you can see that we’ve now adjusted the font size of each label to fit the text in one line.

We have used text which exaggerates the effect for demonstration purposes. In a real app, you would want to make only small adjustments of the font size. Large adjustments, as we’ve done here, are likely to make your app less usable.

What’s next?

Android version

In some cases, it would be useful to adjust the height of the label to reflect the font size. When you fetch font metrics in iOS, you can get only the original font size and metrics, not the adjusted size. Please leave a reply if you know how to do that.

The vast majority of the text of this article is from the original article. Rather than setting the original material in block quotes or double quotes, we’ve chosen instead to highlight the Xamarin.iOS-specific material by setting it in bold.

Note from Ray: This is an abbreviated version of a chapter from iOS 7 by Tutorials that we (raywenderlich.com) are releasing as part of the iOS 7 Feast. We hope you enjoy!

You have probably come to realize that iOS 7 is something of a paradox; while you’re being encouraged to do away with real-world metaphors and skeuomorphism, Apple encourages you at the same time to create user interfaces that feel real.

What does this mean in practice? The design goals of iOS 7 encourage you to create digital interfaces that react to touch, gestures, and changes in orientation as if they were physical objects far beyond a simple collection of pixels. The end result gives the user a deeper connection with the interface than is possible through skin-deep skeuomorphism.

This sounds like a daunting task, as it is much easier to make a digital interface look real, than it is to make it feel real. However, you have some nifty new tools on your side: UIKit Dynamics and Motion Effects.

UIKit Dynamics is a full physics engine integrated into UIKit. It allows you to create interfaces that feel real by adding behaviors such as gravity, attachments (springs) and forces. You define the physical traits that you would like your interface elements to adopt, and the dynamics engine takes care of the rest.

Motion Effects allows you to create cool parallax effects like you see when you tilt the iOS 7 home screen. Basically you can harness the data supplied by the phone’s accelerometer in order to create interfaces that react to changes in phone orientation.

When used together, motion and dynamics form a powerhouse of user experience tools that make your digital interfaces come to life. Your users will connect with your app at a deeper level by seeing it respond to their actions in a natural, dynamic way.

Getting started

UIKit dynamics can be a lot of fun; the best way to start learning about them is to jump in feet-first with some small examples.

Open XcodeXamarin Studio, select File / New / Project …File / New / Solution … then select iOS\Application\Single View ApplicationC#\iOS\iPhone\Single View Application and name your project DynamicsPlayground. Change the Location if desired. Once the projectsolution has been created, open ViewController.mDynamicsPlaygroundViewController.cs and add the following code to the end of viewDidLoad:

Build and run your app, and you’ll see a lonely square sitting on your screen, as shown below:

If you’re running your app on a physical device, try tilting your phone, turning it upside-down, or even shaking it. What happens? Nothing? That’s right—everything is working as designed. When you add a view to your interface you expect it to remain firmly stuck in place as defined by its frame—until you add some dynamic realism to your interface!

Adding gravity

Still working in ViewController.mDynamicsPlaygroundViewController.cs, add the following instance variables:

I’ll explain this in a moment. For now, build and run your application. You should see your square slowly start to accelerate in a downward motion until it drops off the bottom of the screen, as so:

In the code you just added, there are a couple of dynamics classes at play here:

UIDynamicAnimator is the UIKit physics engine. This class keeps track of the various behaviors that you add to the engine, such as gravity, and provides the overall context. When you create an instance of an animator, you pass in a reference view that the animator uses to define its coordinate system.

UIGravityBehavior models the behavior of gravity and exerts forces on one or more items, allowing you to model physical interactions. When you create an instance of a behavior, you associate it with a set of items—typically views. This way you can select which items are influenced by the behavior, in this case which items the gravitational forces affect.

Most behaviors have a number of configuration properties; for example, the gravity behavior allows you to change its angle and magnitude. Try modifying these properties to make your objects fall up, sideways, or diagonally with varying rates of acceleration.

NOTE: A quick word on units: in the physical world, gravity (g) is expressed in meters per second squared and is approximately equal to 9.8 m/s2. Using Newton’s second law, you can compute how far an object will fall under gravity’s influence with the following formula:

distance = 0.5 × g × time2

In UIKit Dynamics, the formula is the same but the units are different. Rather than meters, you work with units of thousands of pixels per second squared. Using Newton’s second law you can still work out exactly where your view will be at any time based on the gravity components you supply.

Do you really need to know all this? Not really; all you really need to know is that a bigger value for g means things will fall faster, but it never hurts to understand the math underneath.

Setting boundaries

Although you can’t see it, the square continues to fall even after it disappears off the bottom of your screen. In order to keep it within the bounds of the screen you need to define a boundary.

Add another instance variable in ViewController.mDynamicsPlaygroundViewController.cs:

The above code creates a collision behavior, which defines one or more boundaries with which the associated items interact.

Rather than explicitly adding boundary co-ordinates, the above code sets the TranslatesReferenceBoundsIntoBoundary property to YEStrue. This causes the boundary to use the bounds of the reference view supplied to the UIDynamicAnimator.

Build and run; you’ll see the square collide with the bottom of the screen, bounce a little, then come to rest, as so:

That’s some pretty impressive behavior, especially when you consider just how little code you’ve added at this point.

Handling collisions

Next up you’ll add an immovable barrier that the falling square will collide and interact with.
Insert the following code to viewDidLoad just after the lines that add the square to the view:

Build and run your app; you’ll see a red “barrier” extending halfway across the screen. However, it turns out the barrier isn’t that effective as the square falls straight through the barrier:

That’s not quite the effect you were looking for, but it does provide an important reminder: dynamics only affect views that have been associated with behaviors.

Time for a quick diagram:

UIDynamicAnimator is associated with a reference view that provides the coordinate system. You then add one or more behaviors that exert forces on the items they are associated with. Most behaviors can be associated with multiple items, and each item can be associated with multiple behaviors. The above diagram shows the current behaviors and their associations within your app.

Neither of the behaviors in your current code is “aware” of the barrier, so as far as the underling dynamics engine is concerned, the barrier doesn’t even exist.

Making objects respond to collisions

To make the square collide with the barrier, find the line that initializes the collision behavior and replace it with the following:

collision = new UICollisionBehavior (new [] { square, barrier });

The collision object needs to know about every view it should interact with; therefore adding the barrier to the list of items allows the collision object to act upon the barrier as well.

Build and run your app; the two objects collide and interact, as shown in the following screenshot:

The collision behavior forms a “boundary” around each item that it’s associated with; this changes them from objects that can pass through each other into something more solid.

Updating the earlier diagram, you can see that the collision behavior is now associated with both views:

However, there’s still something not quite right with the interaction between the two objects. The barrier is supposed to be immovable, but when the two objects collide in your current configuration the barrier is knocked out of place and starts spinning towards the bottom of the screen.

Even more oddly, the barrier bounces off the bottom of the screen and doesn’t quite settle down like the square—this makes sense because the gravity behavior doesn’t interact with the barrier. This also explains why the barrier doesn’t move until the square collides with it.

Looks like you need a different approach to the problem. Since the barrier view is immovable, there isn’t any need to for the dynamics engine to be aware of its existence. But how will the collision be detected?

Invisible boundaries and collisions

Change the collision behavior initialization back to its original form so that it’s only aware of the square:

The above code adds an invisible boundary that coincides with the top edge of the barrier view. The red barrier remains visible to the user but not to the dynamics engine, while the boundary is visible to the dynamics engine but not the user. As the square falls, it appears to interact with the barrier, but it actually hits the immovable boundary line instead.

Build and run your app to see this in action, as below:

The square now bounces off the boundary, spins a little, and then continues its journey towards the bottom of the screen where it comes to rest.

By now the power of UIKit Dynamics is becoming rather clear: you can accomplish quite a lot with only a few lines of code. There’s a lot going on under the hood; the next section shows you some of the details of how the dynamic engine interacts with the objects in your app.

Behind the scenes of collisions

Each dynamic behavior has an action property where you supply a block to be executed with every step of the animation. Add the following code to viewDidLoad:

Here you can see that the dynamics engine is using a combination of a transform and a frame offset to position the view according to the underlying physics model.

While the exact values that dynamics applies to these properties are probably of little interest, it’s important to know that they are being applied. As a result, if you programmatically change the frame or transform properties of your object, you can expect that these values will be overwritten. This means that you can’t use a transform to scale your object while it is under the control of dynamics.

The method signatures for the dynamic behaviors use the term items rather than views. The only requirement to apply dynamic behavior to an object is that it adopts the UIDynamicItem protocolimplements the IUIDynamicItem interface.

Your class can do this by implementing the IUIDynamicItem directly or by inheriting from the UIDynamicItem abstract class.

Since the UIView class inherits from UIResponder, it implement the IUIDynamicItem interface.

The UIDynamicItemprotocolIUIDynamicItem interface gives dynamics read and write access to the center and transform properties, allowing it to move the items based on its internal computations. It also has read access to bounds, which it uses to determine the size of the item. This allows it to create collision boundaries around the perimeter of the item as well as compute the item’s mass when forces are applied.

This means that dynamics is not tightly coupled to UIView; indeed there is another UIKit class that adopts this protocolimplements this interface—UICollectionViewLayoutAttributes. This allows dynamics to animate items within collection views.

Collision notifications

So far you have added a few views and behaviors then let dynamics take over. In this next step you will look at how to receive notifications when items collide.

Open ViewController.mDynamicsPlaygroundViewController.csadopt the UICollisionBehaviorDelegate protocol.

Still in viewDidLoad, set the view controller as the delegate just after the collision behavior has been instantiated, as follows:

Next, add an implementation for one of the collision behavior delegate methods:

This delegate method is fired off when a collision occurs and prints out a log message to the console. In order to avoid cluttering up your console log with lots of messages, feel free to remove the _collision.actioncollision.Action logging you added in the previous section.

Build and run; your objects will interact, and you’ll see the following entries in your console:

From the log messages you can see that the square collides twice with the boundary identifier barrier; this is the invisible boundary you added earlier. The (null)lack of an identifier refers to the reference view boundary.

These log messages can be fascinating reading (seriously!), but it would be much more fun to provide a visual indication when the item bounces.

The above code changes the background color of the colliding item to yellow, and then fades it back to gray again.

Build and run to see this effect in action:

The square will flash yellow each time it hits a boundary.

So far UIKit Dynamics has automatically set the physical properties of your items (such as mass or elasticity) by calculating them based on your item’s bounds. Next up you’ll see how you can control these physical properties yourself by using the UIDynamicItemBehavior class.

The above code creates an item behavior, associates it with the square, and then adds the behavior object to the animator. The elasticity property controls the bounciness of the item; a value of 1.0 represents a completely elastic collision; that is, where no energy or velocity is lost in a collision. You’ve set the elasticity of your square to 0.6, which means that the square will lose velocity with each bounce.

Build and run your app, and you’ll notice that the square now behaves in a bouncier manner, as below:

Note: If you are wondering how I produced the above image with trails that show the previous positions of the square, it was actually very easy! I simply added a block to the action property of one of the behaviors, and every fifth time the block code was executed, added a new square to the view using the current center and transform from the square.

In the above code you only changed the item’s elasticity; however, the item’s behavior class has a number of other properties that can be manipulated in code. They are as follows:

elasticity — determines how ‘elastic’ collisions will be, i.e. how bouncy or ‘rubbery’ the item behaves in collisions.

friction — determines the amount of resistance to movement when sliding along a surface.

density — when combined with size, this will give the overall mass of an item. The greater the mass, the harder it is to accelerate or decelerate an object.

resistance — determines the amount of resistance to any linear movement. This is in contrast to friction, which only applies to sliding movements.

angularResistance — determines the amount of resistance to any rotational movement.

allowsRotation — this is an interesting one that doesn’t model any real-world physics property. With this property set to NO the object will not rotate at all, regardless of any rotational forces that occur.

Adding behaviors dynamically

In its current state, your app sets up all of the behaviors of the system, then lets dynamics handle the physics of the system until all items come to rest. In this next step, you’ll see how behaviors can be added and removed dynamically.

Open ViewController.mDynamicsPlaygroundViewController.cs and add the following instance variable:

bool firstContact = true;

Add the following code to the end of the collision delegate method collisionBehavior:beganContactForItem:withBoundaryIdentifier:atPoint:

The above code detects the initial contact between the barrier and the square, creates a second square and adds it to the collision and gravity behaviors. In addition, you set up an attachment behavior to create the effect of attaching a pair of objects with a virtual spring.

Build and run your app; you should see a new square appear when the original square hits the barrier, as shown below:

While there appears to be a connection between the two squares, you can’t actually see the connection as a line or spring since nothing has been drawn on the screen to represent it.

Where To Go From Here?

At this point you should have a solid understanding of the core concepts of UIKit Dynamics.

If you’re interested in learning more about UIKit Dynamics, check out our book iOS 7 By Tutorials. The book takes what you’ve learned so far and goes a step further, showing you how to apply UIKit Dynamics in an real world scenario:

The user can pull up on a recipe to take a peek at it, and when they release the recipe, it will either drop back into the stack, or dock to the top of the screen. The end result is an application with a real-world physical feel.

I hope you enjoyed this UIKit Dynamics tutorial – we think it’s pretty cool and look forward to seeing the creative ways you use it in your apps. If you have any questions or comments, please join the forum discussion belowadd a comment below or join the forum discussion of the original article.

The full sourcecode for the Objective-C version of Dynamics Playground you have built in this tutorial is available on github, with a commit for each ‘build and run’ step.

In our last episode, we displayed and updated the current time based on an NSTimer. We experimented with timer periodicity and finally settled on using a cross-platform timer from System.Threading. Today, we will add an iAd banner to the app. Apple has made this really easy.

In our last episode, we created a new project in Xamarin Studio, created a custom view controller, initialized its view, and added a clock view. Today, we will explore several ways to display and update the time.

Display the Current Time

To display the current time, add a method to the class CurrentWeatherClockViewController to update the clock view:

A shortcut for entering this method is to first type override. As soon as you type a space after override, Xamarin Studio will provide a completion list. Choose ViewWillAppear from that list. The IDE will then automatically insert a skeleton of the ViewWillAppear method, including the call to base.ViewWillAppear. All you have to do is add this line:

this.UpdateClockView ();

When you build and run the project, your app will display the current time. But the time is still not being updated like a real clock. Let’s do that now.

Update the Current Time

To update the time, we need a timer. Add a private field:

private NSTimer timer;

Note that the IDE sets NSTimer in red. Right click and choose Resolve > using MonoTouch.Foundation.

It’s a good idea to stop timers, tasks, and other continuously running resources that a page is using when the user navigates away.

Timer Periodicity

Let’s take an informal look at whether our timer really is firing at a one second interval. Change the clock display format:

timeLabel.Text = String.Format ("{0:hh:mm:ss.ff}", DateTime.Now);

Build and run. In my experiments, it looks pretty good on both the simulator and an iPhone device. However, let’s not take any chances. A common technique, when sampling a continuous fuction is to sample at twice the frequency1. The clock is not a true continuous function, but appears to be from our persepctive of displaying samples once per second.

Change the timer interval rate to one half second, then build and run again. Note that the clock is updated approximately every half second.

Cross-Platform Timer

This timer works fine, but when using Xamarin and C#, we’d like to use the .Net libraries where we can. This makes the app more cross-platform in case we wish to port to Android later. Of course, Android does not have a UIViewController, so that will have to change anyway. But in a larger application, you likely would have implemented the timer in a separate class that could be cross-platform.