Objective-C Mobile Development
Objective-C Mobile Development
Best Practices based on pure Object Oriented Design
Post 1 of a Series
Written by Pablo Elustondo
The increasing importance of iOS apps for almost all business user-centric applications leads to the need of properly using Objective C and the XCode development environment. Even when some cross-platform mobile development tools like PhoneGap are starting to emerge, Objective C and Xcode are still the best way to develop high quality and high performance apps for iOS.
Unfortunately, Objective is not familiar to most programmers and the good practices can be confusing. It is a relatively old language based on C and ‘inspired’ by Smalltalk. At first glance it looks like a mix of two beautiful but radically different languages with a controversial conceptual integrity. Some old but existing practices like declaring internal variables in the interface are somehow inconsistent with the object oriented concept of encapsulation. Objective-C has evolved over the years and has various different options to implement almost similar things; some of them are rooted in C which should be avoided in the first place unless we really need to optimize performance. In areas like memory allocation, for example, various strategies as presented and some of them are already changing in iOS 5. Discussions around Objective-C in internet forums like StackOverflow are very popular.
Objective-C and Xcode are effective languages and a powerful development environment when used properly. In this series we will try to discuss the most simple and conceptual ways to look at Objective-C focusing on clarity before optimizing performance. We will look at Objective-C from the most purist object oriented view trying to capture the best practices and patterns while keeping it conceptual and overlooking the rough edges. Of course comments are very welcomed and may steer the direction of the blog series.
We will also introduce some of the latest advancement such as Objective-C automatic reference counting and Xcode UI storyboarding that make life easier. We want these posts to be useful to those who never used Objective-C before but understand programming and want to write new code; all concepts are introduced are assuming no previous knowledge of Objective-C.
To illustrate concepts we will use the well know object ‘bank account’. So, we want an iPhone app to access some basic aspects of our bank account remotely. Let assume all security and access aspect has been solved for simplicity.
First thing we will need is being able to manipulate and communicate with objects of type “BankAccount”. Objective-C is primarily, a statically typed language so we will write our variable with the statement BankAccount *bankAccount. We could also declare variables without a static type, but we would try to avoid that until is necessary. To tell our bank account that we need more cheques, we can say something like: [bankAccount orderCheques]. This is called in Objective-C “sending a message” (in other languages would be called a function call). If we want our bank account to deposit a cheque we have, we can write something like [bankAccount deposit: cheque];
Sometimes when we send a message to an object and we expect something in return. For example, the message “withdraw cash amount” would yield some form of cash (real or electronic). We could put that resulting money in the variable with the statement: Cash *cash = [bankAccount withdraw: amount];
The object can accept ‘messages’ and can also have ‘properties’. If we want to know the account balance, we can get his balance amount in the variable bankAccountBalance with a statement such as: float bankAccountBalance = bankAccount.balance. This is called the ‘dot’ notation, very popular in other OO languages but in Objective-C, this is only available on properties. We could also have written the same thing as float bankAccountBalance = [bankAccount balance] but for longer nested sequences the dot notation is more handy.
In Objective-C, as in other OO languages, classes are objects themselves and we can also send them messages. So, for example, one thing we can do with an object of class “BankAccount” is to create instances; create new account instances. If we want to create a new account instance, we can just do something like newBankAccount = [BankAccount new];
Much of object-oriented programming consists of writing the code for new objects and defining new classes. In Objective-C, following C style, classes are defined in two separated text files. A file with extension “.h” defines the interface and declares the methods, properties and super class. An implementation file with extension “.m” defines the class implementation. Most declarations in Objective-C start with the “@” symbol to differentiate this from the underlying C code. We use the following directives:
@interface to declare the class interface
@property to declare properties inside that interface
@class to import or include other classes that we have already defined.
To round up this post, this is how the interface for our BankAccount class will look like for now.
#import <Foundation/Foundation.h> //Includes necessary basic classes to make an app
@class Cash, Cheque; //We declare intention to use the classes we wrote
before
@interface BankAccount : NSObject //BankAccount just inherits from the generic Object
@property float balance;
- (void) orderCheques;
- (Cash *) withdraw: (float) amount;
- (void) depositCheque:(Cheque *) cheque;
@end
If we just want to use this object in our program, and somebody else is actually implementing it, this is the only thing we need to know. Of course, some documentation will help. But this is what we need from a compiler point of view. In the next post we go deeper showing how to implement and use this ATM sample app.
The opinions expressed on this discussion room are writer's and don't necessarily represent NTT DATA Canada's positions, strategies or opinions.