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.
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.
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:
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:
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:
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”.
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”.
IPHONE APPS Related Interview Questions
|C Interview Questions||IPHONE APPS Interview Questions|
|Mobile Testing Interview Questions||Oracle apps Interview Questions|
|Java Native Interface (JNI) Interview Questions||JNDI (Java Naming and Directory Interface) Interview Questions|
|Mobile computing Interview Questions||jQuery Mobile Interview Questions|
|Mobile Security Interview Questions||Objective C Interview Questions|
|Mobile Developer Interview Questions||Mobile Application Testing Interview Questions|
|Apps Associates Manual Testing Interview Questions||Mobile Marketing Interview Questions|
Iphone Apps Tutorial
The Core Application
Window And Views
Graphics And Drawing
Text And Web
Files And Networking
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.