Brains! Delicious Zombie Brains!!

iOS | Wednesday February 2 2011 16:04 | Comments (0)

When developing for the iPhone, you have to be aware of its memory limitations. For example, the original iPhone had 128mb of RAM, the iPhone 3GS has 256mb RAM and the iPhone 4 has 512mb RAM. Its all well and good to develop solely for the iPhone4 and use a lot of memory, but then that excludes anyone with an older handset.

Also, take into account that the iOS (iPhone Operating System) itself will use up a sizeable chunk of that memory too, and then you’re left with about the same amount of RAM that, say for example,  a Windows 98 PC would have had! iPhone4 specs are 1Ghz, 512mb RAM so maybe a high end Win98 machine! FYI, the iPad is similar specced to the iPhone4, eg same CPU but only 25mb RAM!!

So, what I’m trying to say is, Memory Management is important. Even more so with the limited resources found on mobile devices, like the above Apple products, and also Android phones and the new Windows Phone 7.

We saw in a previous chapter on Memory, Constructors, Destructors, new, alloc and init how to create objects, allocate space in memory, and initialise them, so you should be familiar with that concept.

Now, thats all well and good, but what the hell has that got to do with Zombie Brains???

When debugging, we can use a feature of XCode called “Zombies”. If we allocate space and release it, as we should since we’re such good programmers, then if we have a momentary lapse of concentration and continue coding somewhere else and try make a function call on this object, which has already been released, then we should expect and error. The problem here is, XCode will only give a very general error, eg “objc[123]: FREED(id): message release sent to freed object=0x213d2” or something similarly cryptic. If you are developing a large program with a lot of code, its pretty hard to pinpoint the exact object that you released earlier and subsequently made a call to.

With Zombies enabled, you will be able to find out what type the object was, so that will narrow down the search to a smaller area of code. It will tell you this with an error message similar to this:

NSInvocation: warning: object 0x1234f of class ‘_NSZombie_myClass1‘ does not implement….blah blah blah

The bolded part is the important part. You can focus your search on objects of that type only. It might not make a big difference on small apps, but on large ones, it will save a good chunk of searching!!

So, how do you enable Zombie mode?

On the left pane in XCode under “Groups & Files”, scroll down to “Executables” and expand. Double click on your app name (or right click-> Get Info) and when the new windows pops up, make sure you’re in the “Arguments” tab. Now, in the bottom box where it says “Variables to be set in the environment”, click the “+” button to add a new entry. Type in “NSZombieEnabled” and give it the uppercase value of “YES”.

Congratulations, you now have Zombie Brains in your code!!

Memory, Constructors, Destructors, new, alloc and init

iOS | Wednesday December 22 2010 13:44 | Comments (1)

Quite the catchy title, eh??

I have been looking into some memory management techniques in Objective-C. I’m used to the way C/C++ and many other languages do it, by using the “new” keyword.
In Objective-C, this is done differently.

While you CAN declare a class variable like this:

myClass *object = new myClass;

it is not the most common way. Instead, its more commonly seen like this:

myClass *object = [[myClass alloc] init];

The “new” keyword allocates a space in memory to hold the object. It then initialises it, probably with a constructor and can give variables a default value. So thats 2 things it does. Allocates and initialises. In Objective-C, these are done independantly.

Also, note the nesting of the square brackets. Its making 2 calls, but just doing it in a more readable way.

I mentioned constructors above, and I’ll show you now how to pass a variable to the “constructor”.  Note, I don’t think they’re actually called constructors and destructors outside C++, but just go with it anyway…. 😉

So, in C++, you would create an object and initilise some string/variable like so:

myClass *myObj = new myClass(“Hello World”);

In Objective-C:

myClass *myObj = [[myClass alloc] initWithString:@”Hello World”];

See how we are initialising with a string? This can also be done with contents of a file or URL, as well as many other options (In XCode, press ESC to see a list when it prompts for auto-completion). For example,

myClass *object = [[myClass alloc] initWithFormat:@”Hello, my name is %@ and I am %d years old”,name, age];

Obviously you also need the back-end to handle these initialisations.

Autorelease Pools

Lets say you create an object that contains a method which in turn creates a new object called myAddress, assigns it a value, then return this value, eg “return myAddress”. You will obviously have to release this object to obey proper memory management rules. Since you need to do your tidy up before calling the “return”, how can you destroy the object but still use it on the next code line without getting a compile error? In Objective-C, we use [myObject release] instead of “delete myObject” like in C++. For example, in C++ pseudocode:

myClass *obj1;
myClass *obj2 = obj1.returnAddress();

myClass obj1::returnAddress
myClass *myAddress = new myClass("123 City Road");
delete myAddress;
return myAddress;   // Will cause error

So, instead of delete myAddress, Objective-C would read [myAddress release]. Now, stay with me here for a minute while I explain the answer to this problem! Objective-C has the “Pool”, which is like a queue of objects that need to be deleted. When you release an object, it gets deleted straight awat. Now, if you use the “autorelease” keyword in place of “release“, you’ll see some magic happening. You see, autorelease puts the object into the pool for deletion but indicates that its still needed for the moment. The Pool will simply wait a few milliseconds and then just go ahead and delete it. The thing here that I am uncertain about is if it just takes a guess and deletes it whenever, or if it watches the object to wait until it goes out of scope. I’d imagine the latter is how it happens, but I’ll need to look into it. Here’s the corrected code in Objective-C(note the return type in the brackets):

-(myClass) returnAddress
myClass *myAddress = [[myClass alloc] initWithString:@"123 City Road"];
//[myAddress release];    // Will cause the return statement to crash
[myAddress autorelease];  // Works fine
return myAddress;


We saw above how to initialise data types in constructors, using the initi keyword. Now I want to quickly show you destructors.

The default destructor is always called “dealloc” and is also always predefined, in case you don’t supply your own. Since its already defined in the header file “Foundation.h”, in Objective-C we need to tell the compiler which one we want to use, so it doesnt get confused. This is done with the “super” keyword. See below:

-(void) dealloc {

// Clean up

[super dealloc];


And there you go!

So now you’ve got a Mac, what are you gonna do with it?

iOS | Wednesday December 15 2010 12:17 | Comments (0)

Finally, we can now get onto the reason I created this blog! Learning Objective-C!

I’m doing some online tutorials to get the basics right. Since I’m coming from a C and C++  background, I was expecting a lot of similarities. However, there seems to be some fundamentals differences in syntax.

For example, lets take Hello World in a few languages:

printf(“Hello World”);  // C

cout << “Hello World”; // C++

NSLog(@”Hello World”); // Objective-C

First thing,  why the hell is there an @ symbol there??? Secondly,what the hell is NSLog???

Well, the @ symbol is there to tell Objective-C to expect a string. Thats just how it works.

Secondly, NSLog comes from back in the 80’s before Steve Jobs took over Apple. He was working on the NextStep language (NextStep => NS, see?) so when he did become boss in Apple, he rather biasedly (is that a word???) used the NextStep platform to build Mac OSX. So even though its evolved to use Objective-C, they still use the foundation classes from NextStep. FYI, don’t mind the capitalisation of NextStep. It can be written as any of NeXTSTEP, NeXTstep, NeXTStep, or NEXTSTEP.

So anyway, from my first lesson in Objective-C, I have spotted another oddity. This time to do with calling methods in classes. See below:

myClass.doFunction(); // C++

myClass.doFunction(myValue); // C++

[myClass doFunction]; // Objective-C

[myClass doFuction:myValue]; // Objective-C

Thats for calling methods with zero or one parameters. I’m currently trying to get my head around sending 2 parameters in Objective-C! I need to find some example code….

Further research, and alternatives to writing apps on MAC OSX

iOS | Wednesday December 8 2010 18:54 | Comments (1)

After writing the previous post, I decided to do some research to see if there was other ways, on a student budget, to write iPhone apps without a Mac and Apple developer account.

Well, the good news is that its possible to write the apps without going over budget. The bad news is, theres no other way to submit them to the app store without purchasing the $99 subscription. Sure, you can give them to someone else to submit, but then they get the credit…and we don’t want that! 😉

With regards the actual coding, this bits a bit tricky.

Now, while it is definitely possible to actually write code, and compile it on Windows, it is not exactly ideal. The reasons behind this are as follows:

  1. Some IDEs actually facilitate HTML5/javascript coding. This is then “wrapped” in an app and the built in browser is used to render it. While it works, its still not native code so you may suffer from a performance hit. I did find an IDE that lets you write your own Objective-C, but you then have to upload your code to their own server, which is Mac based. It then compiles, converts to an app, and provides a download link to the compiled app. If you’re worried about people stealing your source code, you may want to avoid these!
  2. The compilers that natively compile Objective-C do not support the Foundation classes, which give the iPhone its look and feel. Remember, Objective-C was around long before the iPhone, and even Mac OSX. You can perhaps somehow copy over the foundation classes from XCode and compile a fully-fledged iPhone app, but then you get this problem….
  3. Testing. There are 2 ways to test an iPhone app. 1: Copy it via USB directly to the iPhone, or 2: Use the iPhone simulator/emulator. First of all, to transfer the app to the iPhone, you need the developer account, and you also need the iPhone SDK…on a Mac. Secondly, the simulator/emulator only works on the iPhone SDK…on a Mac.

If you are interested, I’ll list the software I came across and you can test them yourselves. Note, I havent tested any of these myself as I am only at the early stages myself!

  • AirPlay (probably the closest you’ll get, compiles to Obj-C)
  • Appcelerator Titanium (HTML/javascript)
  • Flash CS5 (HTML/javascript)
  • Unity 3D (for games, needs Mac to compile)
  • StoneStrip S3D (for games, needs Mac to compile)
  • Genuitec MobiOne (HTML/Javascript)
  • Dragonfire SDK (code in Obj-C, upload to THEIR server, which compiles your code.  Then you download the app)

Also, I should point out that you still need to have the Apple Developer Account for these pieces of software, like Adobe CS5, since you will need to transfer the app to the iPhone, and this is only done by provisioning it with your Developer Code!!

So there you have it. Not the greatest of options on Windows, for a change. Although I hear Mac Minis are going for about €800/$600 these days…;)

So, you wanna be an iPhone developer

iOS | Monday December 6 2010 12:56 | Comments (0)

OK, lets start this off. If you want to make an iPhone app, here’s what you’re gonna need:

1. A Mac, with Mac OSX Snow Leopard
Yes, you’re gonna have to go out and splash the cash on a Mac. These cost about a grand for a new one so it can all be a bit pricey. Though you can also maybe try and find a second hand Mac online somewhere. Also, you will preferable have Snow Leopard included for latest compatibility with iPhones (see below).

2. XCode and the iPhone SDK
YoThe latest version of the iPhone Software Development Kit (SDK) will only run on Snow Leopard. You can always run an older version on Leopard I suppose, but it just won’t have the latest features and support for the new iPhone, iTouch and iPad.

3. Apple Developer account – To download the iPhone SDK, you will need to be registered as an Apple Developer. Additionally, to submit apps to the appstore, you will also need to join the iOS Developer program, which costs $99 per year. FYI, the “iOS” is the “iPhone Operating System”.

4. The ability to learn Objective-C
Objective-C is the language all Apple software is written in. You will use this language to write the app code in XCode.
Try get yourself a good book:
-Objective-C for Dummies
-iPhone in Action:- Introduction to Web and SDK Development

or online resource:

5. An Apple device
You might need an actual handset, like an iPhone, iTouch or iPad to test your software on. The SDK comes with an emulator, which can run the apps, but is missing some key features like GPS, camera and the shake function. If you’re coding apps to take advantage of these features, then yes, you’ll need an iPhone/iTouch/iPad.


Once you’re registered as an Apple Developer on the iOS program, they will provide you with an authentication key that you will use to transfer the apps to your device over USB cable, but we’ll worry about that later.

If you have the majority of items in that checklist, then you’re doing well. At the moment, all I have is a book on iPhone programming, and the internet! Not the greatest of starts, but I suppose thats the whole point of this project…to acquire the necessary instruments I’ll need to develop apps!

Have I missed anything? Let me know…