Alex Francois

There are few things in this world that i hate, tourists in Oxford Circus, White van drivers and Provisioning Profiles.

I recently had an upset with one of my applications failing to launch on my device because of:

Error from Debugger: Error launching remote program: Security policy Error 

Showing up in the console when the application was about to launch. Luckily for me this problem was pretty easy to fix after some googling.

Simply delete all the expired provisioning profiles from the device, for some reason Apple doesn't take too kindly to expired profiles hanging around on the device, even if they are completely unrelated to the app your trying to load into the debugger.

I'm constantly searching the internet for somewhere that simply lists out all of the categories available in the app store, so here it is:

Book

Business

Education

Entertainment

Finance

Games

Healthcare & Fitness

Lifestyle

Medical

Music

Navigation

News

Photography

Productivity

Reference

Social Networking

Sports

Travel

Utilities

So i may have lied about posting a question every week, turns out i don't post regulary enough so my entire blog would have turned into a question of the week. But do not fear, it's more of a math question of the month, but we'll stick with the name because it sounds better.

Here is another question to get your teeth into, again use any language you like:

Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

Sometimes crashes in iOS can be very cryptic, if an object is being over released nine times out of ten, the debugger will die a silent death. Luckily for us, Apple thought of this problem and built a nice little flesh eating minion to spit some information out everytime an object is over released. Here are the very simple steps needed to enable NSZombie and start catching these silent errors in your debugger:

Double-click an executable in the Executables group of your Xcode project.

Click the Arguments tab.

In the "Variables to be set in the environment:" section, make a variable called "NSZombieEnabled" and set its value to "YES".

Here's a screengrab from one of my projects of NSZombieEnabled, enabled:

JSON is a great little format for grabbing data from your favourite API's, it's clean, compact and easy to extract data from.

The only problem with JSON is that in essence it's just a giant text file filled with data you want to grab. Which is pretty inconvenient if you only want to grab a tiny piece of data from a large file as you have to parse the whole file to access a part of it. 

I'm slowly begging to fall in love with Core Data on the iPhone, once you get your head around how to set it up and utilize it's tools it's well worth the time invesment of learning how to implement it in your iPhone apps. Here's a great quote from Stack Overflow explaining the benifits of Core Data:

In summary, Core Data can greatly simplify your code, particularly for complex object models. You get undo / redo support almost for free with it. It also provides some very significant performance benefits, particularly on the iPhone. Even though it seems counterintuitive, given how much overhead you'd think the framework has, in most cases you can beat the performance of hand-tuned SQLite using Core Data. On the iPhone, it does a great job of batching fetches to minimize memory usage.

This handy snippet of code is great for grabbing data directly from JSON, for example pulled from the Twitter API for your Twitter client iPhone app. All you are required to do is to set the properties for your entity to match those in the JSON feed and pass a dictionary of object properties to the funtion.

For this example i'm using the JSON framework, we simply need to create a dictionary of each object in the JSON feed and pass it to our function to store it in Core Data:

NSArray *results = [jsonString JSONValue]; for (NSDictionary *place in results) { Place *cdOject = [self cdObjectFromDictionary:place]; }

Here is the function which stores the dictionary into Core Data:

- (NSManagedObject *)cdObjectFromDictionary:(NSDictionary *)dict if (managedObjectContext == nil) { managedObjectContext = [(AppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext]; } NSManagedObject *object = [NSEntityDescription insertNewObjectForEntityForName:@"Your Entity Name" inManagedObjectContext:managedObjectContext]; NSDictionary *attributes = [[NSEntityDescription entityForName:@"Your Entity Name" inManagedObjectContext:managedObjectContext] attributesByName]; for (NSString *attr in attributes) { [object setValue:[dict valueForKey:attr] forKey:attr]; } return object; }

In recent light of the events over at Gawker and Lifehacker, I thought i would explain further the importance of salting passwords. If what happened over at Gawker isn't enough motivation for you to implement salting, i hope this illustrates the importance for you. You may also want to head over to the Fusion Table to check if your password has been compromised so that you can change your passwords and keep yourself safe.  

You may think simply using a md5 hash on your passwords is more than enough encryption to keep your users data secure if your database is hacked. But thanks to rainbow tables your passwords are pretty easy to crack, especially if they are 8 characters or less your entire user base could be exposed with relative ease.

This quote from earlyonetoo over on reddit, explains how rainbow tables work rather well:

Salting is mainly a way for defeating rainbow tables. A rainbow table is a pre-computed database of the hashed values of common passwords, uncommon passwords, and even all possible passwords up to a certain character length. If the hashes of users' passwords is unsalted, all someone has to do is look up the hash value in the pre-computed database of hashes and, possibly, instantly find the original password. Salting a hash means attaching an additional random character string to the user's password before hashing it. For example, when calculating the hash of a password, you can first generate a random 16 character salt, say "h47489k4hf83hfjg". Then, instead of hashing the password "boobies", you hash the string "h47489k4hf83hfjgboobies". The resulting hash is impossible to look up in a rainbow table, but if you store the salt you used along with the hash value, you will still be able to login authentication in pretty much the same way as if you had hashed the password without a salt.