I have recently used one of the most useful framework in iPhone 3.0 – CoreData.

There are many guides on using CoreData, such as from cocoadevcentral or Apple’s guide. But what I found lacking is that there was no discussion on the pitfalls of using CoreData, or its view controller, NSFetchedResultsController.

I learnt the pitfalls along the way, and there are 3 particular pitfalls that I would like to share with developers while developing txeet for iPhone.

1. Performance hit with predicate using one-to-many relationship

When using NSFetchedResultsController, we would often form our predicate (like SQL) to retrieve some table rows.

If you were to use a predicate that involves transversing a one-to-many relationship, the performance could be slowed down tremendously (as slow as 30 sec to run, or even crash!). Take for example a Template model that has a one-to-many relationship tags to Tag model:

The predicate above would require transversing to each Tag to find ‘love’. This is computationally very expensive.

The solution to this is to avoid transversing relationship. A faster way that CoreData could execute is to access the properties/attributes. For the above example, what I did is to add another attribute tagsAsAttribute to Template model. This property would store the tag names in a delimited format such as “;love;jokes;quotes;”. The predicate would then be changed to:

Note: This is not the best way to design the data model, as tagsAsAttribute has a dependency and is redundant.

2. User-driven updates

If you read the Apple’s guide to NSFetchedResultsControllerDelegate, please note of the section User-Driven Updates.

In short, if you have user-driven updates, you should write the following as the first line in every (only one is shown below) of the NSFetchedResultsControllerDelegate delegate methods:

And when there is a user-driven update, set the isStillUpdating boolean to true, and set false when the update is completed.

User-driven updates could be re-ordering of table rows, or inserting of objects.

3. abort() should NEVER be used in release

If you have used the sample code for CodeData, there is a line of code which is there only for testing environment. In the comments, it warned developers that abort() should not be used in shipping application..

But I didn’t read the comments..

Apparently, certain devices will occasionally have error when running certain CoreData methods. Eg. NSManagedObjectContext’s save. When there is an error, we could optionally handle the error, but we should NEVER abort and exit the app.

There is no easy way to obfuscate Java classes of an Android app. This is no Eclipse plugin, nor even a working ant script.

Maybe there are working ant scripts. But for Android SDK 1.5, it seems like no one has supplied a proper one, yet. And hence, I spent half a day hacking out a script that works. There are more effort and hurdles than what are presented here.. but for a simple working script, here it is how I did it:

1 Create a Project

From the Terminal, in /android-sdk/tools/, run:

./android create project –target 2 –path /PATH/TO/ObfuscatedApp –activity MyActivity –package com.just2me.obfapp

2 Edit build.xml

Replace the build.xml with my modified build.xml, which is the most important item in this tutorial. The obfuscation work is in the optimize target as seen below.

Some points to note in the build.xml ant script:

• Edit the properties for the path to your Android SDK and Proguard
• If you use any libraries, copy them to /lib and add -libraryjars ${library-jar}/some_lib_used.jar accordingly
• -dontoptimize is needed for Android
• For all classes that are declared in AndroidManifest.xml Application nodes (Activities, Receviers, etc), add an arg to tell proguard not to obfuscate. Exampe: "-keep public class com.just2me.obfapp.activity.*"

3 Run ant

The last step is to simply run the ant script!

To package a debug version that is signed with a debug key, run "ant debug-obf".

To package a release version that is unsigned, run "ant release-obf".

If all is well, then you will find the products in /bin. ObfuscatedApp-debug.apk would be the debug package that could be installed on simulator/devices.

If you want to build multiple versions of an application from a single Xcode project, you would want to cerate multiple targets. For example, when you want to release a free version and also a paid version, you should create 2 targets in that Xcode project.

This tutorial will cover the how-to and the pitfalls in creating multiple targets.

1 Create a New Target

Lets assume we have an application call "Flowers", which is a paid version. And we would want to create a lite version that has some reduced functionality but is free. It is to note that both the paid version and lite version would share the same code, with only some differences.

Firstly, create a new target. Under Groups & Files, right click on Targets > Add > New Target  (Figure 1 below).

Select Application as the new target template.

Enter "FlowersLite" as the target’s name.

Pitfall: When a new target is added, it would not copy over any resources, compiled sources or libraries from the original target! You would need to copy them over manually (drag and drop from Flowers to FlowersLite). If you copy all correctly, you would see figure 2 below. The numbers in brackets indicate number of files, hence they should be the same for both the targets.

2 Info.plist

We could define properties, such as application name and icon files, for each of the target. Figure 3 below shows "Flowers-Info.plist" for the full version.

For the lite version, the "FlowersLite-Info.plist" could be changed as necessary. For example, the bundle identifier for the lite version could be "com.just2me.flowerslite" and the Icon file could be "Icon-lite.png" instead (as in figure 4 below).

3 Writing Preprocessor Codes

Preprocessor codes are used to determine which code would be used during compile time. You may want different targets to run different section of the codes using preprocessor codes. For illustration, we will add a LITE_VERSION definition to the lite version.

Under Targets, right click FlowersLite > Get Info.

Change Configuration to "All Configurations" (this is important).

In the Preprocessor Macros field, add the flag LITE_VERSION (see figure 5 below). Note: If you don’t see the section "GCC 4.2 – Preprocessing", change the active SDK to base SDK and try again.

With the flag LITE_VERSION defined, we could now write codes that will be compiled for the different targets. An example is shown in figure 6 below.

When the active target is selected and being run, it will work and print correctly.

4 Managing Resources

You could copy different resources (having same name but different) to the targets. Resource could refer to xib files, images, etc.

For example, if the lite version has a different default loading screen, you could create another Default.png for the lite version. Note: To make it work, you have to copy the correct Default.png to that target’s "Copy Bundle Resources", and also to remove the incorrect Default.png.

5 Build for Distribution

When you are ready to compile the application for submission to iTunesconnect (release distribution), there is one last important thing worth checking.

It was pointed out in section 3 (Writing Preprocessor Code), that you have to change the configuration to "All Configurations" before you make any changes to the target properties (in this tutorial is adding the LITE_VERSION flag). That is important as the same flag is needed for all configurations, including distribution.

PS: I am stressing this last step as I had made this mistake.. and it resulted in my lite version being released as a paid version because the LITE_VERSION flag was only set for Debug, and not for Distribution!! I did not realize this mistake when compiling for Distribution, as I could only compile the app but not run it on simulator/device..