Good bye, EXC_BAD_ACCESS!

August 28th, 2011

The EXC_BAD_ACCESS error means that a message was sent to a point in the memory where there’s no instance of a class to execute it. Thus “bad access”. Most of the times, the message was sent to an abject that has been already released or was never initialised.

In the over released objects situations, zombies are very handy… When you enable this feature, a dummy object (a zombie) is kept on the place of every released object, allowing to debug objects which were released already. To enable the zombies, edit the scheme: in “Run”, open “Arguments” tab and add NSZombieEnabled with value YES in the “Environment Variables” section. Voila!

Important: remind not to leave the zombies enabled when you submit your app to the App store. Also, it’s a good practice to disable them if you don’t really need them.

No comments »

Posted in Articles, Tutorials

Tags: debug iOS Objective-C

Conditional Compilation

June 16th, 2011

Sometimes you need different settings for different purposes (for example, when you’re testing your app). You could use a server for development and another for production, try to do something hard code when you are testing In App Purchases or something else…

Conditional compilation is very useful in these scenarios. While blocks of “if” from programming languages are part from the binary file but only one block is executed at time (but both could be, in different moments), the conditional “if” is executed during compilation and so the negated block won’t be part of te binary file.

You need to add a compilation flag in your project settings. In the example below, the flag -DDEBUG_BUILD was added to the target settings.

#ifdef DEBUG_BUILD
    #define SERVER_URL_STRING @"http://development.server.com"
#else
    #define SERVER_URL_STRING @"http://production.server.com"
#endif

No comments »

Posted in Articles, Tutorials

Tags: conditional compilation debug macros

NSLog(“Hello world!”)

May 27th, 2011

Everybody knows logging is an import step during any software development, specially in the debug phase. However, its removal can be very tricky after the debug phase is finished and logging is no longer needed and you might need to get rid of it. That’s when macros are very helpful…

#ifdef DEBUG
#   define DLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
#else
#   define DLog(...)
#endif
 
// ALog always displays output regardless of the DEBUG setting
#define ALog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

With the code above, you can use DLog to log only while debugging and ALog to log always.

You can put this code to your .pch file or creat a new file (for example, Log.h) that you can reuse among various projects and import it whenever you need or in the .pch file again.

#import “Log.h”

For this to work you need to add the -DDEBUG flag in the “Other C Flags” option in your project’s configuration.

Another simpler way would be:

#ifdef DEBUG
#	define DLog(...) NSLog(__VA_ARGS__)
#else
#	define DLog(...) /* */
#endif
#define ALog(...) NSLog(__VA_ARGS__)