Re: Work with AddressBook without blocking the main thread
Re: Work with AddressBook without blocking the main thread
- Subject: Re: Work with AddressBook without blocking the main thread
- From: Peter Tomaselli <email@hidden>
- Date: Sat, 25 Apr 2015 23:13:29 -0400
Ha, great link! It was fun reading about the possible pitfalls here. Database corruption simply by reading improperly? Yikes!
Also, the post served to bring dispatch_get_current_queue() to my attention, which seems quite handy.
This fella does not mention how he handles the whole “the [authorization request] completion handler is called on an arbitrary queue” issue, but probably the ‘solution’ there is for me to make a strategic retreat and prompt for access slightly before, instead of exactly at the moment that, I need access to the AB.
Thanks for all the help, Quincey and Roland. I may still try this with a private thread and a runloop, just for fun. :)
Peter
> On Apr 25, 2015, at 10:27 PM, Roland King <email@hidden> wrote:
>
> I had trouble believing there was an API left which was really thread-tied - until I convinced myself that this one really is. I wonder why, underlying SQL implementation perhaps?
>
> In the course of hunting around I found a blog entry here http://adrian.schoenig.me/blog/2012/05/05/ios-addressbook-framework-and-gcd/ <http://adrian.schoenig.me/blog/2012/05/05/ios-addressbook-framework-and-gcd/>. It ended with this update which is interesting if not authoritative
>
> "After having had a chat with Apple engineers, the recommended way is the following: Create address book references on the fly whenever you need them. Do not bother keeping them around since they are lightweight and fast to create. The performance issue that I experienced was due to doing the initial search and the cache for the address book not yet being warmed up. You could just create a fake query at first to warm it up, but it is not recommended.”
>
> if you don’t need to keep a long-running persistent reference to the address book, you may well be able to create them when you need them, use them immediately and then throw them away again. You may be able to create lots of them in different blocks on possibly different background queues at the same time and effectively parallelise the whole thing.
>
> You could, again if you don’t just need one true ABAddressBookRef, squirrel created ones away in thread local storage, then they’re guaranteed to be per-thread, but I’d only even try that rather dubious solution if analysis showed that creating and destroying them was causing performance issues.
>
>> On 26 Apr 2015, at 09:51, Peter Tomaselli <email@hidden <mailto:email@hidden>> wrote:
>>
>> Thanks for the reply. Well, now you’ve got me doubting myself. This is for iOS. Isn’t the C API the only option on that platform?
>>
>> I am planning on doing some work with the address book that doesn’t seem to be directly supported in the API (basically, I want to display all the email addresses in the address book that meet certain criteria). For this, I was assuming I’d have to grab pretty much all the email addresses from the book and iterate through them, bucketing as I go.
>>
>> This is all in my head so far, but if my ABAddressBookRef must live on the main thread forevermore, doesn’t that mean my “filtering” code must also run on the main thread? This is the reason I am concerned about blocking.
>>
>> Instead, my hope was to build a small wrapper class for the ’book that would accept blocks, run them off away from the main thread, and call back to the UI when done.
>>
>> It sounds like that’s maybe what is available on OS X already? But this is an iPhone app. I’ll check out the threading stuff; sounds like that might be fun to try anyway.
>>
>> Appreciate the help,
>>
>> Peter
>>
>>> On Apr 25, 2015, at 9:23 PM, Quincey Morris <email@hidden <mailto:email@hidden>> wrote:
>>>
>>> On Apr 25, 2015, at 17:54 , Peter Tomaselli <email@hidden <mailto:email@hidden> <mailto:email@hidden <mailto:email@hidden>>> wrote:
>>>>
>>>> I don’t have a real good reason for not using the main thread at the moment—it seems fine, performance-wise, for what I am doing.
>>>
>>> The point of these restrictions on ABAddressBook is that it’s *already* an asynchronous API. There’s no synchronous waiting that would block the main thread, and the fact that the completion handler is called on an “arbitrary” thread suggests that all the heavy lifting is already done on a background thread, outside of your control. For that reason, I can’t think of a reason why you’d ever want to start from a background thread.
>>>
>>> Also, do you have a good reason for sticking with the C API? What about using the Cocoa API? [ABAddressBook sharedAddressBook] doesn’t seem to have the same-thread requirement, though [ABAddress addressBook] does.
>>>
>>> (Note that in the current state of OS X or iOS, it’s a mistake to assume that the C version of an API is more performant than the Obj-C version. It’s almost always better just to use the one that’s easier to use, and that’s almost always the Obj-C version.)
>>>
>>>> But I was interested in hearing if there was a more performant approach I might be missing, if only to satisfy my curiosity. Most of the info on the web about this is tons of GCD contortions that, from what I can tell, are missing the point.
>>>>
>>>> So with respect to spinning up a thread to “keep around”, just point me in the right direction here (this would be new stuff for me): is it NSThread I should look at?
>>>
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html> <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html>>
>>>
>>> However, there’s no reason to believe that using a background thread is going to perform better. All you’d be moving to the background thread, I think, is the creation of the ABAddressBookRef data structure itself, which isn’t going to make any difference to anything.
>>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden <mailto:email@hidden>)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com <http://lists.apple.com/>
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden