A Simple Alternative to UDID’s on iOS

Photo courtesy of http://www.talkandroid.com

The fact that Apple deprecated the use of UDID’s as an identifier for developers in iOS 5 is nothing new. There have been many privacy concerns related to the use of a users UDID by developers, but I won’t get into that. Till now, developers could still access a users UDID, since the API is only deprecated and not fully removed. After the recent Path privacy fiasco, Apple has felt the heat and required app developers to ask for user permission before accessing just about any user data, including UDID.

The good news is there is a very simple alternative to using a users UDID and it’s called UUID (Universally Unique Identifier). UUID was standardized by the Open Software Foundation (OSF) and is said to be “practially unique” rather than “guaranteed unique”. But that’s not something you need to worry about. The Wikipedia page for UUID states:

“… one’s annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%.”

The even better news is generating a UUID in iOS is extremely simple thanks to Core Foundations CFUUID class. Here’s how:


- (NSString *)uuid
{
  // Creates a Universally Unique Identifier (UUID) object.
  CFUUIDRef uuidObject = CFUUIDCreate(kCFAllocatorDefault);

  // Returns the string representation of a specified CFUUID object.
  NSString *uuid = (NSString *)CFUUIDCreateString(kCFAllocatorDefault, uuidObject);
  CFRelease(uuidObject);

  return [uuid autorelease];
}

Note: With ARC you need to use __bridge when casting from CFStringRef to NSString *.

That’s all the code you need to replace your use of UDID’s.

Please share any comments or suggestions below!

@farhadnoorzay

Tips for improving performance of your iOS application

Great post on iOS performance by Ankit Gupta, co-founder @ Pulse News!

http://eng.pulse.me/tips-for-improving-performance-of-your-ios-application/

Objective-C: How to Add Delegate Methods in a Subclass

I love design patterns. When understood and used properly they can make your life as a developer so much easier. One of my favorites is the delegate pattern which is used all over the place in Cocoa Touch. Delegation is a design pattern which allows an object to “delegate” work to another helper object. This design pattern is great because it allows you to provide custom behavior without having to subclass.

But there are times when you need to subclass a class that has already implemented a delegate and add additional delegate methods. As a matter of fact, one of the most used classes in iOS does this… UITableView. We’ll take a look at UITableView and see how it adds delegate methods.

UITableView is a subclass of UIScrollView as you can see from its header file.

UIKIT_CLASS_AVAILABLE(2_0) @interface UITableView : UIScrollView <NSCoding>

If we look at the UIScrollView header we’ll see

UIKIT_CLASS_AVAILABLE(2_0) @interface UIScrollView : UIView <NSCoding> {
id           _delegate; // A delegate instance variable is declared of type id
}
// The delegate will be required to conform to the UIScrollViewDelegate protocol
@property(nonatomic,assign) id<UIScrollViewDelegate> delegate;
@end

You can see that the “delegate” instance variable should conform to the UIScrollViewDelegate protocol. So as a subclass, UITableView wants to also use the delegate pattern and has to add the additional methods it needs. It’s actually pretty simple to do so.

Step 1) Create your delegate protocol and extend the parent classes delegate protocol (in your .h)

// This is the syntax to extend another protocol
@protocol UITableViewDelegate<NSObject, UIScrollViewDelegate>

// Your delegate methods go here...

@optional
// Display customization
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath;
@end
Step 2) Redefine the “delegate” instance variable to conform to your delegate protocol (in your .h)
@property(nonatomic,assign)   id <UITableViewDelegate>   delegate;

Step 3) Tell the compiler that the delegate property will be provided at runtime (by the superclass in our case) (in your .m)

@dynamic delegate;

That’s all there really is to it. Other classes can now conform to the delegate protocol, set themselves as the delegate, and receive delegate calls from UITableView and UIScrollView. So if you ever need to add delegate methods in a subclass, remember UITableView is a great example.

*You can learn more about design patterns in iOS in Apples documentation.

Follow

Get every new post delivered to your Inbox.