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 > <quinceymor...@rivergatesoftware.com> wrote: > > On Apr 25, 2015, at 17:54 , Peter Tomaselli <peter.tomase...@icloud.com > <mailto:peter.tomase...@icloud.com>> 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> > > 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
