Like Mac OS X, iPhone OS uses windows and views to present graphical content on the screen. Although there are many similarities between the window and view objects on both platforms, the roles played by both windows and views differ slightly on each platform.
The Role of UIWindow
In contrast with Mac OS X applications, iPhone applications typically have only one window, represented by an instance of the UIWindow class. Your application creates this window at launch time (or loads it from a nib file), adds one or more views to it, and displays it. After that, you rarely need to refer to the window object again.
In iPhone OS, a window object has no visual adornments such as a close box or title bar and cannot be closed or manipulated directly by the user. All manipulations to a window occur through its programmatic interfaces. The application also uses the window to facilitate the delivery of events to your application. For example, the window object keeps track of its current first responder object and dispatches events to it when asked to do so by the UIApplication object.
One thing that experienced Mac OS X developers may find unusual about the UIWindow class is its inheritance. In Mac OS X, the parent class of NSWindow is NSResponder. In iPhone OS, the parent class of UIWindow is UIView. Thus, in iPhone OS, a window is also a view object. Despite its parentage, you typically treat windows in iPhone OS the same as you would in Mac OS X. That is, you typically do not manipulate the view-related properties of a UIWindow object directly.
When creating your application window, you should always set its initial frame size to fill the entire screen. If you load your window from a nib file, Interface Builder does not permit you to create a window smaller than the screen size. If you create your window programmatically, however, you must specifically pass in the desired frame rectangle at creation time. There is no reason to pass in any rectangle other than the screen rectangle, which you can get from the UIScreen object as shown here:
what are windows and views?
Windows and views
Although iPhone OS supports layering windows on top of each other, your application
should never create more than one window. The system itself uses additional windows to display the system status bar, important alerts, and other types of messages on top of
your application’s windows. If you want to display alerts on top of your content, use the
alert views provided by UIKit rather than creating additional windows.
The Role of UIView
A view, an instance of the UIView class, defines a rectangular area on the screen. In iPhone applications, views play a key role in both presenting your interface and responding to interactions with that interface. Each view object has the responsibility of rendering content within its rectangular area and for responding to touch events in that area. This dual behavior means that views are the primary mechanism for interacting with the user in your application. In a Model-View-Controller application, view objects obviously are the View portion of the application.
In addition to displaying its own contents and handling events, a view may also manage one or more subviews. A subview is simply a view object embedded inside the frame of the original view object, which is referred to as the parent view or superview. Views arranged in this manner form what is known as a view hierarchy and may contain any number of views. Views can also be nested at arbitrarily deep levels by adding subviews to subviews. The organization of views inside the view hierarchy controls what appears on screen, as each subview is displayed on top of its parent view. The organization also controls how the views react to events and changes. Each parent view is responsible for managing its direct subviews, by adjusting their position and size as needed and even responding to events that its subviews do not handle.
Because view objects are the main way your application interacts with the user, they have a number of responsibilities. Here are just a few:
In iPhone applications, views work closely with view controllers to manage several aspects of the views behavior. View controllers handle the loading and unloading of views, interface rotations caused by the user physically rotating the device, and interactions with the high-level navigation objects used to construct complex user interfaces. For more information, see “The Role of View Controllers”.
Most of this chapter is dedicated to explaining these responsibilities and showing you how to tie your own custom code into the existing UIView behaviors.
UIKit View Classes
The UIView class defines the basic properties of a view but not its visual representation. Instead, UIKit uses subclasses to define the specific appearance and behavior for standard system elements such as text fields, buttons, and toolbars. Figure shows the class hierarchy diagram for all of the views in UIKit. With the exception of the UIView andUIControl classes, most of the views in this hierarchy are designed to be used as-is or in conjunction with a delegate object.
View class hierarchy
This view hierarchy can be broken down into the following broad categories:
The Role of View Controllers
Applications running in iPhone OS have many options for organizing their content and presenting it to the user. An application that contains a lot of content might divide that content up into multiple screens’ worth of information. At runtime, each screen would then be backed by a set of view objects responsible for displaying the data for that particular screen. The views for a single screen would themselves be backed by a view controller object, whose job is to manage the data displayed by those views and coordinate updates with the rest of the application.
The UIViewController class is responsible for creating the set of views it manages and for flushing them from memory during low-memory situations. View controllers also provide automatic responses for some standard system behaviors. For example, in response to a change in the device's orientation, the view controller can resize its managed views to fit the new orientation, if that orientation is supported. You can also use view controllers to display new views modally on top of the current view.
In addition to the base UIViewController class, UIKit includes more advanced subclasses for handling some of the sophisticated interface behaviors common to the platform. In particular, navigation controllers manage the display of multiple hierarchical screens worth of content. Tab bar controllers let the user switch between different sets of screens, each of which represents a different operating mode for the application.
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.