Whether you're a PHP or a .NET developer it's becoming increasingly likely that you will at some point want to adapt your web application or site into a native mobile application that people can carry around with them. The transition to a new language isn't always easy especially in the case of Cocoa if you've not dealt with a language like it before. This article aims to help by demonstrating how you would achieve some of the tasks you'd normally do in PHP.
For the latest PHPEM talk it was my turn to take the floor and talk about how a PHP developer might tackle taking on a different, stricter language than what they might be used to. The aim of this session was to explain the differences between how PHP and Cocoa utilise the MVC design pattern so that a simple application could be created that is easy to follow and understand.
What is Cocoa?
When people talk about Apple and Cocoa they're not talking about the seed that chocolate is made, but the programming language. The Cocoa programming language is a form of objective-C and was developed by Apple for creating their Mac OS X and iPhone OS applications. The Cocoa language is primarily split into two frameworks: the Foundation Kit, and the Application Kit. The foundation kit contains all the generally used functions and objects that are applicable to all applications, whilst the application kit contains code that allows interactions with user-created GUIs. It is normal that when developing applications for Mac OS X or iPhone OS that Xcode is used so that the interfaces adhere to Apple's design guidelines with their pre-made components and controllers.
Introduction to Xcode
Xcode is the IDE created by Apple to be used in the creation of desktop applications for Mac OS X, and touch applications for devices running iPhone OS (the iPhone and iPod Touch). The primary function of Xcode is to provide an environment where you can code your applications with the help it provides through it's debugging tools and the contextual help that will help auto-complete function names and defined object names. It also has some handy syntax highlighting that makes it easier to read your code at a glance.
A typical project is divided by Xcode into Classes (the models and controllers), Other Sources (main method, etc.), Resources (images, XIBs, and other media), Frameworks (shows the contents of the included frameworks), and Products. You'll notice under this same tree view that it provides handy shortcuts to breakpoints within your code, and also to SCM.
When you're ready to start designing interfaces you have the choice of creating them either programatically or using the Interface Builder which is a drag and drop application where you can drop in the pieces to make up your application and then "wire up" the functions and properties to the various components from what you've already coded in class files.
When it comes to testing your application you can create a build using any of the versions of the iPhone SDK you have installed, but if you're using Snow Leopard then you have to use the later 3.1 build. Most of the time you will be testing your application with the built-in iPhone simulator, but eventually you'll want to test on an actual device as well. It should be noted that in order to put your application onto a Touch based device you will need to register with the Apple Developer Connection at a cost of either $99 or $199 depending on your needs. You can then authorise a phone to be used with that account and will need to follow an intricate process in order to allow Xcode to use this authorised device.
Cocoa and the Model-View-Controller pattern
When it comes to the MVC model most PHP developers should notice that it follows this design pattern a lot closer than many of the PHP frameworks that are currently available. For those who are not familiar with the MVC design pattern, it is a way of splitting out the different parts of the code out into presentation, logic, and user-interaction so that the code is easier to maintain. In Cocoa it is cleanly divided into the 3 categories with two-way interactions taking place between the models and views with the controller.
Models
For Cocoa's implementation of MVC the Model component is normally either an NSObject (named as such due to it's development from NextStep) or an NSManagedObject (which is usually used with CoreData). One of these models is an equivalent to what you'd create as a class in PHP - it is used to encapsulate data and contains methods that interacts with the data - it does not directly output anything to a view, as is also good practice with PHP classes.
The model will send notifications to the controller when there is an update to the data, and will receive updates via the controller also - this means the view has no direct interaction with the model, nor the model with it. The best way to see how a model is created in Cocoa is to actually implement and use an example. For the examples over the next few sections we'll gradually put together code which can be used to create your own "Coin Counter" application which can be used to display the value of coins based upon the weight of them - similar to how a bank counts coins.
To start with we'll create a model that describes a single coin, and we'll include member functions to aid in it's use. If we did this in PHP we might end up with:
<?php
class Coin {
var $weight;
var $value;
function Coin ($weight = '', $value = '')
{
$this->weight = $weight;
$this->value = $value;
}
}
function getCoins ()
{
}
?>So as you can see that's a fairly straightforward piece of code that any experienced PHP developer would understand.
