Within frameworks, you can access an immense wealth of classes arranged in a huge hierarchy.
The NS classes come from Core Services' Foundation framework, which contains a huge number of fundamental data types and other objects. You should use the fundamental Cocoa classes like NSString and NSArray whenever you can, rather than C fundamentals like char or a plain array. This is because they tend to play nicely with each other and with the UIKit frameworks, and therefore you're less likely to encounter bizarre errors. Although it isn't shown, NSNumber is another class you should be aware of. Although it shouldn't be used in place of an ordinary number, it serves as a great wrapper when you need a number expressed as an object. This is especially useful for sending numbers via message passing. NSNumber is capable of holding many sorts of numerical values, from floats to integers and more.
The objects that can hold collections of values like NSArray (a numerical array) and NSDictionary (an associative array) are picky about your sticking to their NS brethren. You'll need to wrap C variables inside Cocoa classes whenever you hand off objects to these arrays. Finally, though NSString can take many sorts of objects when you're formatting a string, you should be aware that Cocoa objects may require a different formatting string than their C equivalents.
In two situations, you'll find that these NS classes can be a deficit. First, if you're using the Core Foundation framework, you'll often have to take advantage of toll-free bridging by casting variables Second, if you're using external APIs, you may need to convert some classes into their C equivalents. The most important of Cocoa's Foundation objects is NSObject, which contains a lot of default behavior, including methods for object creation and memory management.
The second broad category contains the UI classes. These come from Cocoa Touch's UIKit framework, which includes all the graphical objects you'll be using as well as all the functionality for the iPhone OS's event model, much of which appears in UIResponder.
As the UI classes demonstrate, the iPhone OS is deeply rooted in the idea of a graphical user interface. Therefore, let's finish our introduction to the iPhone OS by looking at some of the main graphical abstractions embedded in the UIKit. There are three major abstractions: windows, views, and view controllers. A window is something that spans the device's entire screen. An application has only one, and it's the overall container for everything your application does.
A view is the content holder in your application. You may have several of them, each covering different parts of the window or doing different things at different times. They're all derived from the UIView class. But don't think of a view as a blank container. Almost any object you use from the UIKit will be a subclass of UIView that features a lot of behavior of its own. Among the major subclasses of UIView are UIControl, which gives you buttons, sliders, and other items with which users may manipulate your program, and UIScrollableView, which gives users access to more text than can appear at once.
A view controller does what its name suggests. It acts as the controller element of the Model-View-Controller triad and in the process manages a view, sometimes called an application view. As such, it takes care of events and updating for your view. I've divided view controllers into two types. Basic view controllers manage a screenful of information, whereas advanced view controllers let a user move around among several subviews. Windows, views, and view controllers are ultimately part of a view hierarchy. This is a tree of objects that begins with the window at its root. A simple program may have a window with a view under it. Most programs start with a window and have a view controller under that, perhaps supported by additional view controllers, each of which controls views that may have their own subviews.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Marvin V. Hayels at 09232010
1. Explanation of the Embedded Linux development process
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.
Partners: Damenmode