iPhone fetch data dictionary from keychain - iphone

So I'm trying to convert an old project to Automatic Reference Counting. I'm trying to use the conversion tool that xCode has but it says to fix a couple things before it can convert. I have no idea how to fix this error. It's in the implementation of the keychain file. This method is the one that returns the error, specifically the line with the SecItemCopyMatching. The error I am getting says: " Cast of an indirect pointer to an Objective-C pointer to 'CFTypeRef*' (aka 'const void**') is disallowed with ARC. I've been looking all over google, apple docs, and a bunch of other crap and can't find a better way to fetch an existing data dictionary in the keychain. Any help appreciated. Thanks!
-(NSMutableDictionary*)fetchDictionary {
NSMutableDictionary *genericPasswordQuery = [self buildSearchQuery];
NSMutableDictionary *outDictionary = nil;
OSStatus status = SecItemCopyMatching((__bridge_retained CFDictionaryRef)genericPasswordQuery, (CFTypeRef*)&outDictionary);
if (DEBUG) printf("FETCH: %s\n", [[self fetchStatus:status] UTF8String]);
if (status == errSecItemNotFound) return NULL;
return outDictionary;
}

You don't need to disable ARC for this; you just need to declare the query's result as a CFDictionaryRef, then cast it to an NSDictionary after the call.
/*1*/ CFDictionaryRef cfquery = (__bridge_retained CFDictionaryRef)genericPasswordQuery;
/*2*/ CFDictionaryRef cfresult = NULL;
/*3*/ OSStatus status = SecItemCopyMatching(cfquery, (CFTypeRef *)&cfresult);
/*4*/ CFRelease(cfquery);
/*5*/ NSDictionary *result = (__bridge_transfer NSDictionary *)cfresult;
Couple of remarks:
In line 1, we convert the query from Cocoa land to Core Foundation country. We use __bridge_retained to make sure ARC does not release and deallocate the object while we are working with it. This kind of bridging cast retains the object, so to prevent leaks, it must be followed with a corresponding CFRelease somewhere. SecItemCopyMatching definitely will not release the query for us, so if we use a retained bridge, then we need to release the resulting Core Foundation object ourself. (Which we do in line 4.)
Lines 2, 3, and 4 are pure C code using Core Foundation types, so ARC will have nothing to do or complain about them.
In line 5, we tell ARC that SecItemCopyMatching has created its result with a retain count of 1, which we are responsible for releasing. (We know this because it has "Copy" in its name.) __bridge_transfer lets ARC know about this responsibility, so it will be able to do it for us automatically.
Don't cast the immutable Core Foundation dictionary returned by SecItemCopyMatching to NSMutableDictionary; that's just wrong. Also, it is against general Cocoa style conventions that buildSearchQuery returns an NSMutableDictionary. Simple NSDictionarys would work fine in both cases.
The rule of thumb here is that __bridge_retained needs to be followed by a CFRelease, while the result from a "Copy" or "Create" function must be cast into Cocoa-land using __bridge_transfer.

Method 3: Let ARC do the heavy lifting (or a combination of method 1 and method 2):
NSMutableDictionary* query = [NSMutableDictionary dictionaryWithDictionary:
#{
(__bridge id) kSecClass : (__bridge id) kSecClassGenericPassword,
(__bridge id) kSecAttrService : nssService,
#if ! TARGET_IPHONE_SIMULATOR
(__bridge id) kSecAttrAccessGroup : #"PRODUCT.com.COMPANY.GenericKeychainSuite",
#endif
(__bridge id) kSecMatchLimit : (__bridge id) kSecMatchLimitOne,
(__bridge id) kSecReturnAttributes : (__bridge id) kCFBooleanTrue,
}];
if ( [nssAccount length] != 0 )
[query setObject:nssAccount forKey:(__bridge id) kSecAttrAccount];
CFDictionaryRef cfresult;
auto err = ::SecItemCopyMatching((__bridge CFDictionaryRef)query,
(CFTypeRef*)&cfresult);
if ( err == errSecItemNotFound )
return std::wstring();
else if ( err != noErr)
throw std::exception();
NSDictionary* result = (__bridge_transfer NSDictionary*) cfresult;
SecItemCopyMatching doesn't need to own the incoming dictionary, so __bridge is
adequate and then ARC continues to manage the lifetime of query.
And by transferring ownership of the result to arc, it will manage the lifetime
of result as well and free us of the need to remember to CFRelease it on all code
paths.

Method 2: When you use it once, why need a retaining or transfering? example from bottom work at glance for me, testing, debuging(memleaks) all pass :) Only one thing did leak unreleased autoretained variable when key will be found (1)
CFDictionaryRef keyAttributes = NULL; /* variable for store attributes */
NSMutableDictionary *credQuery = [NSMutableDictionary dictionary]; // credential Query
/* Here you add some options for search your key */
OSStatus errGather = SecItemCopyMatching(
(__bridge CFDictionaryRef)credQuery,
(CFTypeRef *)&keyAttributes
);
if (errGather == errSecSuccess) {
// Gather stored key
NSDictionary *keychainDict = (__bridge NSDictionary *)keyAttributes;
NSData *passData = keychainDict[(__bridge id<NSCopying>)kSecValueData]; // password
...
/* work with gathered data :) */
...
CFRelease(keyAttributes); // (1) HERE. Release when CFType is retained really :)
credQuery = nil;
keychainDict = nil;
passData = nil;
}

Related

Use casting instead of CFStringRef getting contact information

I've got a doubt about using "CFStringRef". I've seen several examples of managing iPhone contacts and in most of them they use:
...
ABMultiValueRef emails = ABRecordCopyValue(person, kABPersonEmailProperty);
CFStringRef emailRef = ABMultiValueCopyValueAtIndex(emails, 0);
...
NSString *email = (NSString *)emailRef;
I don't know why CFStringRef is used instead of using casting:
...
ABMultiValueRef emails = ABRecordCopyValue(person, kABPersonEmailProperty);
NSString *email = (NSString *)ABMultiValueCopyValueAtIndex(emails, 0);
...
Is it conventional to use CFStringRef? Is it correct to use direct casting?
CFString is “toll-free bridged” with its Cocoa Foundation counterpart,
NSString. This means that the Core Foundation type is interchangeable
in function or method calls with the bridged Foundation object.
Therefore, in a method where you see an NSString * parameter, you can
pass in a CFStringRef, and in a function where you see a CFStringRef
parameter, you can pass in an NSString instance. This also applies to
concrete subclasses of NSString.
Both are same.
There is no difference, the first example just uses an extra temporary variable. Performing a straight cast is perfectly OK, although you should pay attention to the memory management aspect. It sounds like ABMultiValueCopyValueAtIndex returns a retained object although the documentation isn't clear.

Memory leak when declaring NSString from ABRecordCopyValue

I am using the following line of code...
NSString *clientFirstName = (NSString *)ABRecordCopyValue(person, kABPersonFirstNameProperty);
The 'analyse' feature on Xcode is saying that this giving rise to a potential memory leak. I am not releasing clientFirstName at all as I have neither alloc or retain'd it.
However, I am conscious that ABRecordCopyValue may not be returning an object as say a command like [NSMutableArray arrayWithArray:someArray] would which might mean I am indeed creating a new object that I control and must release.
Keen to hear thoughts...
Any sort of copy returns an object with a retainCount of 1, so you need to release it via CFRelease().
See the doc:
You are responsible for releasing this object.
Refer to this link. It has same as yours:
NSString potential leak
Refer to answer of KennyTM:
ABMultiValueCopyValueAtIndex is a "Copy" function, which follows
the "Create
Rule".
You need to call CFRelease to release it after finish using it.
NSString *contactEmail = (NSString *)ABMultiValueCopyValueAtIndex(emailInfo, 0);
...
if (contactEmail != nil)
CFRelease((CFTypeRef) contactEmail);
Release your object clientFirstName using CFRelease.
Add the code below:
if(clientFirstName != nil)
{
CFRelease((CFTypeRef) clientFirstName);
}
NOTE: Do not forget to check if clientFirstName is not nil. It is better to have a practice of checking that object is not nil before executing any function on it as it saves us from potential crashes though not in this case, but in many cases
EDIT:
Also as #Dondragmer says in one of the comments below:
I think even
[clientFirstName release];
should solve the problem.
Let me know if you need more help.
Hope this helps you.
I don't fully understand how ObjectiveC reference counting works, but a small update in code fixed the Analyze warning:
Before:
NSString *firstName = (__bridge NSString*) ABRecordCopyValue(person, kABPersonFirstNameProperty);
After
NSString *firstName = (__bridge_transfer NSString*) ABRecordCopyValue(person, kABPersonFirstNameProperty);

NSMakeCollectable and ARC doesn't work

I'm trying to convert my old project to ARC. I have a function which creates UUIDs, but apparently this is no longer supported when using ARC:
NSString *uuid = nil;
CFUUIDRef theUUID = CFUUIDCreate(kCFAllocatorDefault);
if (theUUID) {
uuid = NSMakeCollectable(CFUUIDCreateString(kCFAllocatorDefault, theUUID));
//[uuid autorelease];
CFRelease(theUUID);
}
I get the compiler error (when trying to convert): 'NSMakeCollectable' is unavailable: not available in automatic reference counting mode.
So my question is: how do I create UUIDs when using ARC? Is there another way which I should now use?
NSMakeCollectable() is for the benefit of the (essentially deprecated) Objective-C garbage collector. ARC knows nothing about it.
You must use a special casting attribute, usually __bridge_transfer, to ensure that the memory is not leaked. __bridge_transfer is used like so:
id MakeUUID(void) {
id result = nil;
CFUUIDRef uuid = CFUUIDCreate(NULL);
if (uuid) {
result = (__bridge_transfer id)uuid; // this "transfers" a retain from CF's control to ARC's control.
}
return result;
}
Edit: As other answers have mentioned, CFBridgingRelease() does this for you. So instead of using (__bridge_transfer id)uuid, it may be cleaner to write CFBridgingRelease(uuid). They are equivalent though, so it's up to you which you find more readable.
When you transfer the object from CFString to NSString, you need to let ARC know how you want to handle memory management. In this case I would suggest:
uuid = CFBridgingRelease(CFUUIDCreateString(kCFAllocatorDefault, theUUID));
This instructs CoreFoundation to release the object (as is required to balance Create). Cocoa will ARC-retain the object when it is assigned to uuid.
CFUUIDRef theUUID = CFUUIDCreate(NULL);
NSString *s2ndUuid = (__bridge_transfer NSString*)CFUUIDCreateString(kCFAllocatorDefault, theUUID);
To have a single UUID across whole app, I think the best way to achieve that would be to have it run once in the whole application lifecycle.
static NSString *uuid;
- (NSString *)theCurrentDeviceUniqueIdentifier {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
CFUUIDRef theUUID = CFUUIDCreate(kCFAllocatorDefault);
if (theUUID) {
uuid = CFBridgingRelease(CFUUIDCreateString(kCFAllocatorDefault, theUUID));
CFRelease(theUUID);
}
});
return uuid;
}
it's definition of NSMakeCollectable
NS_INLINE id NSMakeCollectable(CFTypeRef cf) {
return cf ? (id)CFMakeCollectable(cf) : nil;
}
I think this should work
uuid =CFUUIDCreateString(kCFAllocatorDefault, theUUID);

release ABMultiValueRef object

In my app, static analyser points a leak in the following code:
ABMultiValueRef phone = (NSString *)ABRecordCopyValue(person, kABPersonPhoneProperty);
NSString *mobilephone= (NSString*)ABMultiValueCopyValueAtIndex (phone,0);
similarly whenever i use this function ABRecordCopyValue it points a leak
I tried to release it by [phone release]; method, however I am getting a compiler warning "invalid receiver type 'abmultivalueref'". What is the proper way to release this ?
It looks like you are confusing the NS data types with the CF data types. The address book methods typically return core foundation (CF) objects. These objects are toll-free bridged, which means they can be used interchangeably with NS types.
When using core foundation objects, any method with 'copy' in its name will return an object that you later need to release using CFRelease. Only if you cast it to its NS equivalent can you use - release.
So your code could be written as either of the following:
ABMultiValueRef phone = ABRecordCopyValue(person, kABPersonPhoneProperty);
NSString *mobilephone = (NSString *)ABMultiValueCopyValueAtIndex(phone, 0);
// other code
[mobilephone release];
or
ABMultiValueRef phone = ABRecordCopyValue(person, kABPersonPhoneProperty);
CFStringRef mobilephone = ABMultiValueCopyValueAtIndex(phone, 0);
// other code
CFRelease(mobilephone);
Have you tried with CFRelease(phone); ?
Because ABMultiValueCopyValueAtIndex is not a NSString, it's a CFStringRef
Using __bridge_transfer ensures that ARC will release the object for you.
Using __bridge means you must release the returned object manually.

Can't put a NSString into a NSMutableArray and store it in NSUserDefaults

I am receiving this error: '-[__NSCFArray insertObject:atIndex:]: mutating method sent to immutable object'
In the ViewDidLoad I initialized my array:
id object = [[NSUserDefaults standardUserDefaults] objectForKey:#"array"];
if (object)
{
locationArray = object;
NSLog(#"retrieved", object);
}
else
{
locationArray = [[NSMutableArray alloc] init];
NSLog(#"init");
}
Then, I am trying to add the data to locationArray:
ABMultiValueRef multi = ABRecordCopyValue(person, property);
NSUserDefaults *locatie = [NSUserDefaults standardUserDefaults];
// Set up an NSArray and copy the values in.
NSArray *theArray = [(id)ABMultiValueCopyArrayOfAllValues(multi) autorelease];
//everything goes fine the first time, but the second time i receive an error after at this code:
[locationArray addObject:theArray];
[locatie setObject:locationArray forKey:#"array"];
Every first time I select an address everything is fine. But every second time I am receiving that error.
What did I do wrong?
NSString *fname = (NSString *)ABRecordCopyValue(person, kABPersonFirstNameProperty);
NSMutableString *lname = (NSMutableString *)ABRecordCopyValue(person, kABPersonLastNameProperty);
What makes you think ABRecordCopyValue is going to return a mutable string here?
Just telling the compiler that it will return a mutable string (which is all “(NSMutableString *)” does) doesn't mean it will. If the Address Book documentation doesn't specify that this will return a mutable string, assume it won't and create a mutable string yourself.
Speaking of which…
NSMutableString *name = [[NSMutableString alloc] init];
Here's the string you should be appending to. You don't need lname to be mutable, because this string is mutable.
NSMutableString *space = #" ";
fname = [fname stringByAppendingFormat:space];
fname = [fname stringByAppendingFormat:lname];
By doing this, you waste the mutable string you created. You are creating two intermediate immutable strings here, not appending to the mutable string.
name = fname;
And here, you throw away the mutable string entirely (and thereby leak it since you never released it), replacing it with the immutable string you got from your series of stringByAppendingFormat: messages.
What you should do is send the name mutable string an appendFormat: message, passing both the first and last name strings. You don't need the space string; you can include that in the format string.
See also the NSMutableString docs.
[nameArray addObject:fname];
At no point prior to this statement have you created an NSMutableArray object and stored its pointer in the nameArray variable. Not in any code you've shown, anyway.
Until you do that, this variable holds nil, the pointer to no object. The addObject: message does nothing because that's what messages to nil do: Nothing. Logging the array you don't have produces “(null)” because that's the description of nil.
if (nameArray == nil) {
NSLog(#"NO DATA TO RETRIEVE FROM USERDEFAULTS");
You aren't showing any code that retrieves from user defaults. Even if you did, it would return an immutable array as Sven said; you would have to make a mutable copy.
This is the best I can do without a description of the problem. We may be able to provide more and better suggestions if you edit your question to tell us what happens when you run the above code, and not just what doesn't happen.
The problem occures when you get the locationArray from the NSUserDefaults and try to insert some object ([locationArray addObject:theArray];). The object you get from the NSUserDefaults is not mutable, so you have to create a mutable copy:
NSMutableArray* locationArray = [[NSUserDefaults standardUserDefaults] objectForKey:#"array"];
if (locationArray != nil)
locationArray = [[locationArray mutableCopy] autorelease];
else
locationArray = [NSMutableArray array];
And don't forget to check if fname is not nil before adding it to array