iOS For Beginner

iOS Development Basics

In previous chapters we saw how to code with Objective c.In this chapter we see how to use Objective c with iOS programming to create iOS app. Now we learn about View, Navigation controller, UI Elements, UIStoryboard, Autolayout, Delegates in practical not in theoretical.

Navigation controller :
A navigation controller manages a stack of view controllers to provide a drill­down interface for hierarchical content. The view hierarchy of a navigation controller is self contained. It is composed of views that the navigation controller manages directly and views that are managed by content view controllers you provide. Each content view controller manages a distinct view hierarchy, and the navigation controller coordinates the navigation between these view hierarchies.

More about the navigation controller classes and reference Here.And also learn how that navigation controller works with other view controller in apple documentation.

ViewController:
The UIViewController class provides the fundamental view­management model for iPhone applications. The basic view controller class supports the presentation of an associated view, support for managing modal views, and support for rotating views in response to device orientation changes. Subclasses such as UINavigationController and UITabBarController provide additional behavior for managing complex hierarchies of view controllers and views.

You use each instance of UIViewController to manage a view hierarchy. A typical view hierarchy consists of a root view—a reference to which is available in the view property of this class—and usually one or more subviews presenting the actual content. On iPhone and iPod touch, the root view typically fills the entire screen but on iPad this view may fill only part of the screen. In both cases, the view controller is responsible for managing the entire view hierarchy, including all subviews.

View controllers are tightly bound to the views they manage and take part in the responder chain used to handle events. View controllers are themselves descendants of the

UIResponder class and are inserted into the responder chain between the managed root view and its superview, which typically belongs to a different view controller. If the view controller’s view does not handle an event, the view controller itself has the option of handling the event before passing the event along to the superview.

The UIViewController class works with the application’s window to handle device orientation changes. If the view controller supports the new orientation (as determined by the return value of its shouldAutorotateToInterfaceOrientation: method), it animates the transition from the current orientation to the new one. As part of this change, it also applies any resizing rules in effect for the views in its view hierarchy. If you want to make changes to your view hierarchy as part of the orientation change, you can override methods of UIViewController to implement your changes. For information on the methods you need to override, see “Handling View Rotations.”

Views :

The UIView class defines a rectangular area on the screen and the interfaces for managing the content in that area. At runtime, a view object handles the rendering of any content in its area and also handles any interactions with that content. The UIView class itself provides basic behavior for filling its rectangular area with a background color. More sophisticated content can be presented by subclassing UIView and implementing the necessary drawing and event­handling code yourself. The UIKit framework also includes a set of standard subclasses you can use, which range from simple buttons to complex tables. For example, a UILabel object draws a text string and a UIImageView object draws an image.

Because your application interacts with the user primarily through view objects, those objects have a number of responsibilities. Here are just a few:

Drawing and animation A view draws content in its rectangular area using technologies such as UIKit, Core Graphics, and OpenGL ES. Some view properties can be animated to new values. Layout and subview management A view may contain zero or more subviews. Each view defines its own default resizing behavior in relation to its parent view. A view can manually change the size and position of its subviews as needed. Event handling A view is a responder and can handle touch events and other events defined by the UIResponder class. A view can use the addGestureRecognizer: method to install gesture recognizers to handle common gestures.

Delegate :

Delegate are a design pattern, there is no special syntax or language support. A delegate is just an object that another object sends message to when certain things happen.so that the delegate can handle app ­ specific details the original object wasn’t designed for.It’s a way of customizing behaviour without subclassing.More about how delegate works reference in apple documentation

A simple example for delegate in iOS:

We have created two ViewControllers (for sending data from one to another)

1. FirstViewController implement delegate (which provides data).
2. SecondViewController declare the delegate (which will receive data).

Student.h:

#import

@interface Student : NSObject

@property (weak) id delegate;

(void) studentInfo;

@end

Student.M:

#import “Student.h”

@implementation Student

(void) studentInfo

{

NSString *teacherName;

if ([self.delegate respondsToSelector:@selector(teacherName)]) { teacherName = [self.delegate performSelector:@selector(teacherName)];

}

NSLog(@”\n Student name is XYZ\n Teacher name is %@”,teacherName);

}

@end

Teacher.h

#import #import “Student.h>

@interface Teacher: NSObject

@property (strong,nonatomic) Student *student;

(NSString *) teacherName;

(id) initWithStudent:(Student *)student; @end

Teacher.m

#import “Teacher.h” @implementation Teacher ­ (NSString *) teacherName

{

return @”ABC”;

}

(id) initWithStudent:(Student *)student

{

self = [ super init]; if (self) {

self.student = student; self.student.delegate = self;

}

return self;

}

@end

Main.m

#import #import “Teacher.h”

int main ( int argc, const char* argv[])

{

@autoreleasepool {

Student *student = [[Student alloc] init];

Teacher *teacher = [[Teacher alloc] initWithStudent:student]; [student studentInfo];

}

return 0;

}

Explanation :

From main method when initWithStudent:student will execute
Teacher’s object’s property ‘student’ will be assigned with student object.
self.student.delegate = self

means student object’s delegae will point to teacher object

From main method when [student studentInfo] will be called

[self.delegate respondToSelector:@selector(teacherName)] Here delegate already points to teacher object so it can invoke ‘teacherName’ instance method.

so [self.delegate performSelector:@selector(teacherName)] will execute easily.

It looks like Teacher object assign delegate to student object to call it’s own method.

It is a relative idea, where we see that student object called ‘teacherName’ method but it is basically done by teacher object itself

UIStoryboard:

● Storyboards are nice for apps with a small to medium number of screens and relatively straightforward navigation between views.
● If you have lots of views and lots of cross ­navigation between them the Storyboard view gets confusing and too much work to keep clean.
● For a large project with multiple developers I would not use Storyboards because you have a single file for your UI and cannot easily work in parallel.
● It might be worth for large apps to split up into multiple storyboard files but I have not tried that.
● You still need XIBs: In both of my Storyboard projects I had to use XIBs for custom table cells.

We think Storyboards are a step in the right direction for UI implementation and hope Apple will extend them in future iOS versions. They need to resolve the “single file” issue though, otherwise they won’t be attractive for larger projects.

pro-grammatically create storyboard:

// Get the storyboard named secondStoryBoard from the main bundle:

UIStoryboard *secondStoryBoard = [UIStoryboard storyboardWithName:@”secondStoryBoard” bundle:nil];

// Load the initial view controller from the storyboard.

// Set this by selecting ‘Is Initial View Controller’ on the appropriate view controller in the storyboard.

UIViewController *theInitialViewController = [secondStoryBoard instantiateInitialViewController];

//

// **OR**

//

// Load the view controller with the identifier string myTabBar

// Change UIViewController to the appropriate class

UIViewController *theTabBar = (UIViewController *)[secondStoryBoard instantiateViewControllerWithIdentifier:@”myTabBar”];

// Then push the new view controller in the usual way: [self.navigationController pushViewController:theTabBar animated:YES];

storyboard is a new feature available since the release of Xcode 4.2. It offers a complete new way for iOS developer to create and design user interface. Before the introduction of Storyboard, it’s especially hard for beginner to create navigation (and tab) interface. Every interface is stored in a separate xib file. On top of it, you have to write code to link all interfaces together and describe how the navigation works.

Simple image how storyboard will look in xcode:

StoryBoard

StoryBoard

UIElements :

UI elements are the visual elements that we can see in our applications. Some of these elements respond to user interactions such as buttons, text fields and others are informative such as images, labels.

List of some UI Elements are:

● Text Field
● Button
● Label
● Icon
● Toolbar
● Status bar
● Navigation bar
● Scroll View
● Image view
● Table View

Please login to get access to the quiz
Swift 2.0 (Prev Lesson)
(Next Lesson) App Store Process
Back to iOS For Beginner
Inquire Now
close slider