iOS Lessons

(This post is part of hands on iOS programming series)

(For Objective C basics visit earlier part of Series)

I have now pushed code for simple todo application.

It does following things --

a) Populates a list of Todos

b) Allows Dynamic addition/Deletion/updation of Todos

c) Sync Todos between iCloud using Key/Value pairs.

Have a look at code over here.

(This post is part of hands on iOS programming series)

(For Objective C basics visit earlier part of Series)

In this post we will not go in detail, just touch up on the necessary terminology/lingos to get upto speed with GUI programming in iOS.

iOS apps are based on event-driven programming. Event-driven programming means flow of application is driven by events in the system. There are either user (Eg: Touch up/down) or system events (Eg: Low battery)

iOS application follows a popular Model-View-Controller (MVC) design pattern.

Model: Is the class which takes care of holding data of the application. Data can be dynamic or static and can be persisted depending on the needs of the application. Structure of data can be simple array or some complex data structure. All this is responsibility of Model class. Usually model interacts with Controller. Eg: Simple Array

Controller: This is the class which handles interaction between views and data. It determines which views to swap in or out. Animation between transitions and pushing data to view from model. Eg: ViewController, Navigation Controller, etc...

View: This is the class which can be a simple view or complex hierarchy of views. It represents visual representation of application and all the user events are fed through this class. Eg: TextBox, label etc...

One more thing that is not mentioned is the Window object. It is like the canvas of the system on which various views are drawn.

Starting point in any iOS application is by calling UIApplicationMain.

This creates two objects UIApplication & AppDelegate

UIApplication manages application event loop and coordinates with other high-level app behaviors.

AppDelegate creates window for the application and also provides space for state transitions within the app.

Usually when writing an application, we would first create wireframes and layout diagrams for various screens/views and their transitions.

iOS simplifies this by introducing Storyboards. After iOS 5.x it is the way forward. Before that it was Xibs. Many developers prefer Xibs over Storyboards.

We will look at storyboard example in our tutorial.

Storyboards: A storyboard is a visual representation of the app’s user interface, showing screens of content and the transitions between them. You use storyboards to lay out the flow—or story—that drives your app.

Segues: Transitions between scenes are called segues.

We are now ready to jump into code. If you want more detailed step by step tutorial apple has one. It talks at length about all the concepts etc...

I hope you are familiar with Objective C basics. If not visit my series on basics.

This series is more hands on. We will cover following topics.

(I will expand the list as the application starts evolving and new issues worth discussing open up)

iOS Storyboard Lingo

Brief introduction to our Todo app.

Todo App Stage 1: Simple Static List of Todos

Todo App Stage 2: Dynamic List of Todos

Todo App Stage 3: Retrievable Todos

Todo App Stage 4: Sharable Todo List

Todo App Stage 5: Syncable Todo List

Todo App Stage 6: More Features

After learning Objective C basics, its time to move to real iOS programming. I will come out with a series soon on iOS Programming using Storyboards. We will briefly look at Concepts around it and then jump to some live example.

This is part of iOS Basics series.

Reference code can be found here. (git log tag is v1.5)

(Changes  31010af9b57a43cf19fd01730660244a9bf08f17 & fa6dc300c9e432ca83bdc60572596894c17e7321)

In the previous post we saw we had to introduce a copyMe or deepCopyMe method so that we can make a copy of our own object. But problem with this method, is that every creator of class can name his copying method as he wishes to. In a big code, figuring this out would be difficult.

Objective C offers a simple solution, in the form of NSCopying / NSMutableCopying & NSObject.

Any method needing to implement a copy function, should call copy and/or mutableCopy of NSObject.

Internally copy & mutableCopy call copyWithZone & mutableCopyWithZone respectively.

Since we want to perform deep Copy our AddressBook and ContactCard classes, both the classes conform to NSCopying protocol.

(Note: Deep Copy or Shallow Copy is a matter of choice. It depends on what program expects at the end.)

As can be seen, there are following steps that take place underhood when a (deep) copy of Addressbook is requested.

a) Call "copy" function of AddressBook

b) Call "copy" function of ContactCard

c) Call "copy" function of NSString to create separate copies of email & name variables.

We can implement a similar implementation for NSMutableCopying protocol.

This is part of iOS Basics series.

We look here at code examples and results of such actions.

For reference we use the code over here. We have a AddressBook and ContactCard classes. For sake of simplicity we have only one contact card in the address book.

Our reference ab1 object is an object of type AddressBook.

AssignWhen we assign one object to another, we essentially create a new reference pointer to same data.

For eg:

We look at lines 35 -42 in main.m

We can see both ab1 and ab2 point to essentially same data. Hence output of both ab1 & ab2 is same. So any change in either one results in change of data for both objects.

Shallow Copy

We introduce a "copyme" function to create a copy of AddressBook. But this is essentially a shallow copy. Even though we now have seperate copies of Addressbook, any change in contactcard for one (ab1) still reflects on another object (ab3).

This problem occurs because both ab1 and ab3 point to same ContactCard  object.

Reference Code is between lines 46 - 63 in main.m

This is part of iOS Basics series

Copying Objects is not a trivial assignment problem.

When we assign one object to another, in iOS we are merely linking references. This results in erroneous conditions.

iOS provides rich set of options to handle these situations.

Here are the options -

copy attribute for Properties [we saw this in previous post]

NSCopying & NSMutableCopying protocols

Before we jump to NSCopying & NSMutableCopying protocols, we would first need to understand concepts of 

Deep & shallow copy

Mutable & Immutable copy

This is part of iOS Basics series.

Preprocessor in Objective C is something that is inherited from C Language.

Preprocessor statements are identified by the presence of pound sign (#)

We look at only two things --

# -- It is used to stringify the data.

For eg: #define str(x) #x

results in #x == “x”

## -- It is used to join two tokens in the macro.

For eg: #define printx(n) print(“Octal number is %i\n”,x##n)

This is part of iOS Basics Series

We already looked at Protocols. When we mention Protocols, it is necessary to mention delegates as well.

Dictionary defines delegate as someone who has authority to represent some other person.

In our case delegate is a class/object who knows which is the class that conforms to protocol.

This is a popular Delegate Design Pattern, where a class is delegated task to carry on behalf of originating class. This way to external world it appears the job is done by delegated class, which in reality is done by someone else.

Lets look at our protocol example.

//Protocols.h

@interface MyProtocol

-(void) implicitRequiredMethod

@required

-(void) explicitRequiredMethod

@optional

-(void) explicitOptionalMethod

@end

//ProtocolConformer.h

@interface ProtocolConformer<MyProtocol>

-(void) implicitRequiredMethod

-(void) explicitRequiredMethod

@end

// BroadCaster.h

@interface BroadCaster

{

-id<MyProtocol> protocolHandle;

}

-id initWithProtocolHandle:id<MyProtocol> pH;

-(void) broadcastNow;

@end

Here the BroadCaster is the one who is acting as a Delegate Class. It holds the handle to ProtocolConformer where the actual magic is supposed to happen.

But to external world all actions for the events happens on Broadcaster class.

This is part of iOS basics series.

In previous post we have seen What is Protocol.One can extend existing already declared Protocol just like we extend existing classes albeit with different syntax.

Here is our original Protocol declaration

//Protocols.h

@interface MyProtocol

-(void) implicitRequiredMethod

@required

-(void) explicitRequiredMethod

@optional

-(void) explicitOptionalMethod

@end

So imagine we want to add new Protocol say "AdvancedProtocol" which adds one more method to existing protocol. Here is how you achieve that

@interface AdvancedProtocol <MyProtocol>

-(void) moreImplicitRequiredMethod;

@end

This is part of Objective C / iOS basics series

Dictionary defines Protocol as a set of rules governing exchange of data between two devices.

Protocols in Objective C tries to achieve same. It sets rules(methods) inorder to exchange data between two classes.

Classes conforming to Protocol implement the method(s).

Class which wants to exchange data stores reference to the class conforming to the protocol.

Here is how whole thing in terms of code works

//Protocols.h

@interface MyProtocol

-(void) implicitRequiredMethod

@required

-(void) explicitRequiredMethod

@optional

-(void) explicitOptionalMethod

@end

//ProtocolConformer.h

@interface ProtocolConformer<MyProtocol>

-(void) implicitRequiredMethod

-(void) explicitRequiredMethod

@end

// BroadCaster.h

@interface BroadCaster

{

-id<MyProtocol> protocolHandle;

}

-id initWithProtocolHandle:id<MyProtocol> pH;

-(void) broadcastNow;

@end

This is part of iOS Basics series.

Categories is a very unique and useful feature of Objective C.

Category provides an easy way to modularize definition of a class into groups or categories of related methods.

Categories can be useful in following cases --

Extending an existing class definition without access to its original source code or without subclassing.

Distributed Incremental development of Code. This is possible as one doesnot need to implement all the methods declared in the interface section.

Extending using Categories differs from subclassing in following ways --

One can override methods in original class, but unlike subclasses, it cannot access original method implementation. It is for this reason it is not recommended to override methods inside Category.

Although category has access to instance variables of original class, it cannot add its own instance variables.

Here is an example of Categories.

Use Case: We get URL in string format and we need to parse it. Also this url parsing might be required across various classes.

There could be two approaches in my opinion -

Write a separate Class which provides for parsing method.

We can use Category to extend NSString class and introduce Parsing method.

Which one to choose depends on context of use case. Here we see second case as a demonstration of Category implementation.

@interface NSString ( containsCategory ) - (NSDictionary*) getURLParameters; @end

Now you can use this method to parse URL Parameters from NSString that was received.

Eg: NSDictionary* mydict = [mystring getURLParameters];

This is part of iOS basics series.

[ Heads up this is very long post, so get a cup of coffee before you start on this :) ]

Understanding Memory management for any platform is central part of work for a programmer. Wrong choices and your program can break and result in unhappy customer.

iOS / Objective C provides nice wrapper to reduce basic memory handling issues by programmer.

It does by using Automatic Reference Counting(ARC).

In ARC rule is simple, as long as there is a pointer referencing the memory, the memory is not released

All this happens at compile time. Compiler checks what are the attributes of Properties and based on that does decisions, when to send request for reclaiming the memory.

strong --  By default all Properties have strong attribute. It essentially says, property is owned and hence do not release till the end of scope.

For eg:

@interface Engine

@property NSString* manufacturer

@end

@interface Car

@property BOOL running;

@property(strong) Engine make; // you dont need to explicitly mention strong although we are doing it here for clarity.

@end

And our main file looks like this --

int main(int argc, const char * argv[]) {     @autoreleasepool {         Engine* eng = [[Engine alloc]init]; // reference cnt 1         eng.manufacturer = @"Ford";         Car* nano = [[Car alloc]init];         nano.make = eng; // reference cnt 1     }     return 0; }

Now compiler knows unless "nano" object's make gets dereferenced, it cannot release "eng" object.

weak -- This exists essentially to avoid retain cycles . We saw with strong attribute, every pointer reference causes increment in reference counting to the given memory.

This is not desirable in all cases especially with parent-child relationships. This is because it causes retain cycles, where parent is pointing to child and child is pointing back to parent resulting in either of them not being released. Essentially retain cycles result in memory leak and hence we need to avoid them.

By having weak reference we can avoid these retain cycles.

For eg:

If we needed reference to all Cars using a Particular Engine, we might have reference to Car object as well. In this case we would end up with retain cycle . So the declaration of Engine class would look like as following --

@class Car //forward declaration of Car class

@interface Engine

@property NSString* manufacturer;

@property(weak) List<Car*> cars;

@end

This way now there are retain cycles between Car(Parent) and Engine (child) class.

copy -- By specifying the attribute, we are saying we would need a copy of the memory instead of the same reference.

This is very useful in cases where referencing to same value can result in unexpected behavior.

Its very practical to have engines from same manufacturer. So when there are two cars with engine from same manufacturer our pointer references can look as follows.

Can you see a problem here, If something changes in engine, information captured about engine in both the cars would be lost. This can be a serious issue in a larger project.

Also in practice every engine of car would be independant of each other, so it would be wise to create seperate copies of engines for each car instance/object.

This is exactly what copy attribute does, creates independent copies.

Here is the Class definition --

@interface Car

@property BOOL running;

@property(copy) Engine* make; //create seperate copy of engine.

@end

Now it is the responsibility of each instance to destroy the created instances of engine which was not the case earlier.

You can override dealloc method of NSObject.

(Note: Copying objects is not a trivial task it involves lot of deeper understanding. We cover all that in subsequent posts)

Migration Trivia:

If you are late entrant to iOS / Objective C world like me, you wont even notice this.

But in case you come across these terms, it here for completeness

assign in manual memory handling == weak in ARC

retain in manual memory handling == strong in ARC

We look at shallow / deep copy in next section.

This is part of iOS Basics Series

In the previous post we looked at Properties under the hood.

We look at customisation and issues with default generation.

There could be following three issues ---

The names of getters / setters are designed to be with default naming convention

Not always one would want to have both setters and getters generated.

Not all getters / setters would be run in multithreaded programs.

We look at each case --

Customised Names to Getters / Setters --

Objective C provides attributes with @property directive so that one can have custom names for their getters / setters.

Here is how you achieve this -

@interface Car

@property (getter=isRunning) BOOL running;

@end

Now the method generated for getter would be as follows

-(BOOL) isRunning

{

return _running;

}

Preventing Setters from generating (readonly) --

Since Running is a state of car which can only be influenced by its internal operations, it would be wise to hide setter from other external objects.

We can achieve this by use of readonly attribute.

It is used as follows --

@interface Car

@property (getter=isRunning, readonly) BOOL running;

@end

Single Threaded or Nonatomic use cases

@property directive by default makes setters and getters atomic operations. This is very useful in multithreaded environment. But it comes at the cost of overhead to maintain synchronisation.

Not every application needs to deal in threads if for example you are making stop watch application you dont need threads. In such case one can conserve the overheads by using nonatomic attribute.

Here is how you use this --

@interface Car

@property (getter=isRunning, nonatomic) BOOL running;

@end

This is part of iOS Basics Series

Properties are convenient way to create getters/setters for the declared member variable(s) or properties  of the class.

We cover three aspects in our Properties Discussion --

Declaration

Custom naming of getters & setters

Memory Management & Properties

We look at Declaration in this post and other two in subsequent posts.

Here is how you do it

// Car.h

@interface Car

@property BOOL running; // With XCode 4.4 you dont need to explicitly declare the variable before @property directive

@end

This will result in getters & setters with default naming convention & instance variable with underscore( _running)

//Car.m

@implementation Car

@synthesize BOOL running;

@end

Note: @synthesize directive is not mandatory we can access "running" variable with "_running".

The resulting methods would look like this

-(BOOL) running{

return _running;

}

-(void) setRunning:(BOOL)newValue{

_running = newValue;

}

You can now use these setters & getters like this

Car* myCar = [[Car alloc] init];

myCar.running = YES;

if (myCar.running)

   NSLog(@"Car is running");

else

  NSLog(@"Car is not running");

One can even call the getters & setters like any other method of class like this

[myCar running]; // Calling getter

One can even override getters/setters to create custom getters/setters.

By doing this @synthesize directive becomes mandatory.

This is part of iOS basics series.

We observed in our previous posting on class in iOS that we need to declare and define getter and setters everytime.

iOS makes it simple to reduce this pain by offering two directives namely @Property and @Synthesize. But using these properties is not so straight forward. If we donot know what we are doing, we can end up in a pointer mess and might have program doing funny things.

We will look at intricacies in another post, which will be split in two parts --

Under The Hood Properties in Objective C (Links would be added later)

Custom naming of getters & setters.

Memory Management & Properties.

Copying in Objective C (Links would be added later)

For now lets look at basic declaration of @property and @synthesize pair.

// Car.h

@interface Car

{

Engine e;

}

@property Color c;

...

@end

//Car.m

@implementation Car

@synthesize Color c

.....

@end

This is part of iOS Basics Series

Class is a programmatic representation of real world object.

For Eg: If you had to design a program for Automated Car Parking system, you might need to represent real objects of Car, People, Parking Hall in some form. These all real Objects can be represented as Class in Object Oriented World.

So essentially Class will contain data to store state of the object and methods/functions which would be used to attain the states.

Lets say we want to represent Car object.

Car would have Engine, Colour of its own and other parts which we choose to ignore.

Car can start, stop at minimum

Thus data here would be Engine, Colour

& Operations would be Start, Stop

Declaring a Car Class would be as follows --

@interface Car

{

  Engine engine;

  Color color;

}

-(void) setColor:Color c;

-(void) getColor;

-(void) setEngine:Engine e;

-(void) start;

-(void) stop;

@end

If you have to write the implementation of the class, you can write in separate file with actual function definitions between @implementation... @end directives.

The (-) sign tells that the compiler that methods are instance methods. It also means that they can be operated only on instance of a class or Object of the class.

We can have (+) sign as well in front of method. It means the method is a class method and you can call it without creating an instance.

Class methods are not static methods though. They differ in following ways --

To call class methods, one needs instance of the metaclass that describes the class object being invoked.

Also unlike static methods, one can inherit class methods, making it easier to share one single implementation like +alloc of NSObject class.