Modifying Views at Runtime IPHONE APPS

As applications receive input from the user, they adjust their user interface in response to that input. An application might rearrange the views in its interface, refresh existing views that contain changed data, or load an entirely new set of views. When deciding which techniques to use, consider your interface and what you are trying to achieve. How you initiate these techniques, however, is the same for all applications. The following sections describe these techniques and how you use them to update your user interface at runtime.

Animating Views

Animations provide fluid visual transitions between different states of your user interface. In iPhone OS, animations are used extensively to reposition views, change their size, and even change their alpha value to make them fade in or out. Because this support is crucial for making easy-to-use applications, UIKit simplifies the process of creating animations by integrating support for them directly into the UIView class.

The UIView class defines several properties that are inherently animatable—that is, the view provides built-in support for animating changes in the property from their current value to a new value. Although the work needed to perform the animation is handled for you automatically by the UIView class, you must still let the view know that you want the animation to happen. You do this by wrapping changes to the given property in an animation block.

An animation block starts with a call to the begin Animations: context: class method of UI View and ends with a call to the commit Animations class method. Between these calls, you configure the animation parameters and change the properties you want to animate. As soon as you call the commit Animations method, UIKit performs the animations, animating changes from their current values to the new values you just set. Animation blocks can be nested, but nested animations do not start until the outermost animation block is committed.

Table lists the animatable properties of the UIView class.

Table lists the animatable properties of the UIView class.

Animatable properties

Configuring Animation Parameters

In addition to changing property values inside an animation block, you can configure additional parameters that determine how you want the animation to proceed. You do this by calling the following class methods of UIView:

  • Use the set Animation Start Date: method to set the start date of the animations after the commit Animations method returns. The default behavior is to schedule the animation for immediate execution on the animation thread.
  • Use the setAnimationDelay: method to set a delay between the time the commit Animations method returns and the animations actually begin.
  • Use the set Animation Duration: method to set the number of seconds over which the animations occur.
  • Use the setAnimationCurve: method to set the relative speed of the animations over their course. For example, the animations can gradually speed up at the beginning, gradually slow down near the end, or remain the same speed throughout.
  • Use the set Animation Repeat Count: method to set the number of times the animations repeat.
  • Use the set Animation Repeat Auto reverses: method to specify whether the animations reverse automatically when they reach their target value. Combined with the set Animation Repeat Count: method, you can use this method to toggle each property between its initial and final values smoothly over a period of time.

The commit Animations class method returns immediately and before the animations begin. UIKit performs animations in a separate thread and away from your application’s main event loop. The commit Animations method posts its animations to this separate thread where they are queued up until they are ready to execute. By default, Core Animation finishes the currently running animation block before starting animations currently on the queue. You can override this behavior and start your animation immediately, however, by passing YES to the set Animation Begins From Current State: class method within your animation block. This causes the current in-flight animation to stop and the new animation to begin from the current state.

By default, all animatable property changes within an animation block are animated. If you want to prevent some changes made within the block from being animated, use the set Animations Enabled: method to disable animations temporarily, make your changes, and then reenable them. Any changes made after a set Animations Enabled: call with the value NO are not animated until a matching call with the value YES occurs or you commit the animation block. Use the are Animations Enabled method to determine whether animations are currently enabled.

Configuring an Animation Delegate

You can assign a delegate to an animation block and use that delegate to receive messages when the animations begin and end. You might do this to perform additional tasks immediately before and after the animation. You set the delegate using the set Animation Delegate: class method of UIView, and use the setAnimationWillStartSelector: and set Animation Did Stop Selector: methods to specify the selectors that will receive the messages. The signatures of the corresponding methods are as follows:

The animationID and context parameters for both methods are the same parameters that were passed to the begin Animations:context: method at the beginning of the animation block:

  • animationID - an application-supplied string used to identify animations in an animation block.
  • context - another application-supplied object you can use to pass additional information to the delegate. The set Animation Did Stop Selector: selector method has an additional argument—a Boolean value that is YES if the animation ran to completion and was not canceled or stopped prematurely by another animation.
  • Responding to Layout Changes

    Whenever the layout of your views changes, UIKit applies each view’s autoresizing behaviors and then calls its layout Subviews method to give it a chance to adjust the geometry of its contained subviews further. Layout changes can occur when any of the following happens:

  • The size of a view’s bounds rectangle changes.
  • The content offset value—that is, the origin of the visible content region—of a scroll view changes.
  • The transform associated with the view changes.
  • The set of Core Animation sublayers associated with the view’s layer changes.
  • Your application forces layout to occur by calling the set Needs Layout or layout If Needed methods of the view.
  • Your application forces layout by calling the set Needs Layout method of the view’s underlying layer object.

A view’s autoresizing behaviors handle the initial job of positioning any subviews. Applying these behaviors guarantees that your views are close to their intended size. For information about how autoresizing behaviors affect the size and position of your views, see “Autoresizing Behaviors”.

Sometimes, you might want to adjust the layout of subviews manually using layout Subviews, rather than rely exclusively on autoresizing behaviors. For example, if you are implementing a custom control that is built from several subview elements, by adjusting the subviews manually you can precisely configure the appearance for your control over a range of sizes. Alternatively, a view representing a large scrollable content area could display that content by tiling a set of subviews. During scrolling, views going off one edge of the screen would be recycled and repositioned at the incoming screen edge along with any new content.

When writing your layout code, be sure to test your code in each of your application’s supported interface orientations. Applications that support both landscape and portrait orientations should verify that layout is handled properly in each orientation. Similarly, your application should be prepared to deal with other system changes, such as the height of the status bar changing. This occurs when a user uses your application while on an active phone call and then hangs up. At hang-up time, the managing view controller may resize its view to account for the shrinking status bar size. Such a change would then filter down to the rest of the views in your application.

Redrawing Your View’s Content

Occasionally, changes to your application’s data model require that you also change the corresponding user interface. To make those changes, you mark the corresponding views as dirty and in need of an update (using either the set Needs Display or set Needs Display InRect: methods). Marking views as dirty, as opposed to simply creating a graphics context and drawing, gives the system a chance to process drawing operations more efficiently. For example, if you mark several regions of the same view as dirty during a given cycle, the system coalesces the dirty regions into a single call to the view’s drawRect: method. As a result, only one graphics context is created to draw all of the affected regions. This practice is much more efficient than creating several graphics contexts in quick succession.

Views that implement a drawRect: method should always check the rectangle passed to the method and use it to limit the scope of their drawing operations. Because drawing is a relatively expensive operation, limiting drawing in this way is a good way to improve performance.

By default, geometry changes to a view do not automatically cause the view to be redrawn. Instead, most geometry changes are handled automatically by Core Animation. Specifically, when you change the frame, bounds, center, or transform properties of the view, Core Animation applies the geometry changes to the cached bitmap associated with the view’s layer. In many cases, this approach is perfectly acceptable, but if you find the results undesirable, you can force UIKit to redraw your view instead. To prevent Core Animation from applying geometry changes implicitly, set your view’s contentMode property to UI View Content Mode Redraw. For more information about content modes, see “Content Modes and Scaling”.

Hiding Views

You can hide or show a view by changing the value in the view’s hidden property. Setting this property to YES hides the view; setting it to NO shows it. Hiding a view also hides any embedded subviews as if their own hidden property were set.

When you hide a view, it remains in the view hierarchy, but its contents are not drawn and it does not receive touch events. Because it remains in the view hierarchy, a hidden view continues to participate in autoresizing and other layout operations. If you hide a view that is currently the first responder, the view does not automatically resign its first responder status. Events targeted at the first responder are still delivered to the hidden view. For more information about the responder chain, see “Responder Objects and the Responder Chain”.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status