I have a callback handler registered that listens to changes in the iOS Address Book.This is how I register the callback
ABAddressBookRegisterExternalChangeCallback(address_book, adressBookChanged,self);
What I want is to perform all the commutation in background thread when callback method is called.This is how I structured my callback :
void adressBookChanged(ABAddressBookRef ab, CFDictionaryRef info, void
*context)
{
//Perform all commutation in background thread
}
As we can not use one addressbook ref in multiple threads .How can I perform this.Please help me out what I am doing wrong?
Related
The iOS ATT Alert needs to be shown on startup before an app starts, so the remaining app code needs to be run in the completion handler (eg initialising advert code and starting the main game).
However, this crashes because the completion handler callback is not on the main thread (after the alert is actually shown and Allow or Ask App Not to Track is selected).
In iOS (Xamarin C# code):
public override void OnActivated(UIApplication application) // RequestTrackingAuthorization must be called when app is Active
{
if (!this.shownAlert)
{
this.shownAlert=true;
Debug.WriteLine("1) ThreadId={0}", Environment.CurrentManagedThreadId); // ThreadId=1
ATTrackingManager.RequestTrackingAuthorization(delegate (ATTrackingManagerAuthorizationStatus trackingManagerAuthorizationStatus)
{
Debug.WriteLine("2) ThreadId={0}", Environment.CurrentManagedThreadId); // ThreadId=7
});
}
}
Prints:
1) ThreadId=1
2) ThreadId=7
And the similarly in Unity:
Debug.WriteLine("1) ThreadId={0}", Environment.CurrentManagedThreadId); // ThreadId=1
ATTrackingStatusBinding.RequestAuthorizationTracking(delegate (int status)
{
Debug.WriteLine("2) ThreadId={0}", Environment.CurrentManagedThreadId); // ThreadId=4
});
This seems like a bug to me. So how do all the apps and games out there get this to work? Somehow switch to the main thread in the callback? I don’t see any examples of this.
I am creating an NSAsynchronousFetchRequest which has a completion block inside it.
I have seen various examples where some include using dispatch queue on the main thread and others don't. For example the Ray Wenderlich core data book doesn't call the result on the main thread.
Should I go back on the main thread when executing the result. Initially I thought I had to but now I don't. Some definitive clarity would be great.
fun exampleFetch(_ completionHandler: #escaping () -> () {
let fetchRequest = NSFetchRequest<NSDictionary>(entityName: "Example")
let asyncFetchRequest = NSAsynchronousFetchRequest<NSDictionary>(fetchRequest: fetchRequest) { result in
// DispatchQueue.main.async { // is this needed
completion()
//}
}
managedContext.performChanges {
do {
try self.managedContext.execute(asyncFetchRequest)
} catch let error {
print("error trying to fetch saving objects:", error.localizedDescription)
}
}
}
You should not explicitly call the completion handler on the main queue. Let the caller decide how to handle it. If anything, document that the completion handler will be called on an arbitrary queue. Then the client calling your exampleFetch method knows that it is their responsibility to be sure that process the result on whatever queue it needs.
This gives the client more control.
This also prevents a lot of needless thread switching. A client may call exampleFetch from a background queue and it may want to process the results in the background. If you explicitly put the completion on the main queue, the client then needs to explicitly switch back to a background queue to process the result. That's two needless queue switches and it's wasted effort on the main queue.
I need to perform periodic updates of the data I persist with Core Data. I get such data from asynchronous calls to REST services. To firstly retrieve all the data, I create a full core data stack in a private queue and then I do this:
- (void)updateDataFromServices
{
[[UIApplication sharedApplication] setNetworkActivityIndicatorVisible:YES];
self.dataUpdatePrivateContext = [MyCoreDataStackHelper getPrivateContext];
if (self.dataUpdatePrivateContext != nil) {
[self.dataUpdatePrivateContext performBlockAndWait: ^{
// Asynchronous operations
[self callService1];
[self callService2];
[self callService3];
}];
}
}
In the callback of each service that is called, I check that the rest of services have already finished too, and if all have finished I call a method (manageInfoUpdate) to handle updates between the data I have in my main context (in main thread) and the data I now have in the private context (in the private queue):
- (void)manageInfoUpdate
{
const char* UpdateInfoQueue = "com.comp.myapp.updateinfo";
dispatch_queue_t queue = dispatch_queue_create(UpdateInfoQueue, NULL);
dispatch_async(queue,^{
// Handle updates from private context:
// Here I compare objects in the main context with the objects
// in the private context and I delete objects from both
// by calling:
[mainContext deleteObject:object];
[self.dataUpdatePrivateContext deleteObject:object];
// This seems to work...
// Save and clear private context
[self saveContext:self.dataUpdatePrivateContext];
[self clearContext:self.dataUpdatePrivateContext];
dispatch_async(dispatch_get_main_queue(), ^{
// Re-fetch from main context to get
// the updated data
// Save main context
[self saveContext:mainContext];
// Notify end of updates
});
});
}
I try to perform the manageInfoUpdate operations in another async thread. I'm getting EXEC_BAD_ACCESS exceptions when trying to clear / save the contexts... Could somebody help me to find why?
Thanks in advance
You won't get an outright "error" for using Core Data in a multi-threaded environment incorrectly. The app just will crash, sometimes.
To confirm you are using it correctly, turn on the debug flag com.apple.CoreData.ConcurrencyDebug 1 in your runtime arguments. Then it will crash EVERY time you touch a MOC or MO from the wrong queue.
As it stands you code is not correct at all with regard to threading. A MO that is created on one queue can only be accessed from that queue. Likewise, a MOC that is configured for the main queue must be accessed on the main queue and a MOC configured as a private queue must be accessed on ITS private queue.
Your "UpdateInfoQueue" is violating the threading rules completely.
Turn on the debug flag, correct the errors it shows you and your save issue will be corrected.
I am developing a bluetooth app using the EADemo example. Whenever there is data in the bluetooth inputStream, the following event is invoked:
- (void)stream:(NSStream *)aStream handleEvent:(NSStreamEvent)eventCode
{
switch (eventCode) {
case 1:
//here I want to start two tasks
break;
}
And I have a common queue to which I have to write and read parallely.
The queue is actually a NSMutuableArray. In the write part, I use addobject:
and in the read part, I use objectAtIndex:0.
Any one has any idea how to move about this?
As you are using same array you will need to make it safe to access otherwise it may crash app
APPROACH A: (Using Grand Central Dispatch)
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0);//set priority as per requirement
//Read
dispatch_async(queue, ^{
while (//condition to stop)
{
//Perform read operation
}
});
//Write
dispatch_async(queue, ^{
while (//condition to stop)
{
//Perform write operation
}
});
//As operations are performed on same queue your array is safely accessed
APPROACH B: (Using threads)
Create two thread
Read Thread
Write tread
But access your array in synchronised manner.
I am new to multithreading in iOS. I need to do three things: get information from the api, parse the information and save to my database. I have these three things in a different files(getAPI,parseAPI and savetoDB). getAPI will call parseAPI and it will in return call savetoDB. I want all three of them to work in background thread.
My question is when I call getAPI, will parseAPI and savetoDB run in the background thread as well? How do I ensure that all three of them run in the background? How do I return the call back to main thread after savetoDB?
Example:
dispatch_queue_t backgroundQueue;
backgroundQueue = dispatch_queue_create("lakesh", NULL);
- (void)startprocess {
dispatch_async(backgroundQueue, ^(void) {
[self getAPI];
});
}
Need some guidance.. Thanks...
If you issue a function on a background thread, all execution will continue on that thread until it finishes or you call back another function on the main thread. I had worries like you in the beginning, so I made myself the following macros:
/// Stick this in code you want to assert if run on the main UI thread.
#define DONT_BLOCK_UI() \
NSAssert(![NSThread isMainThread], #"Don't block the UI thread please!")
/// Stick this in code you want to assert if run on a background thread.
#define BLOCK_UI() \
NSAssert([NSThread isMainThread], #"You aren't running in the UI thread!")
As you can see by the comments, I tend to use these macros at the beginning of methods I want to make sure I'm not using by error in the wrong thread. I've put these macros and more random stuff at https://github.com/gradha/ELHASO-iOS-snippets which you may find useful.
With regards to your question on returning to the main thread, since you are using GCD the best would be to call dispatch_get_main_queue() at the end of your savetoDB with the code you want to run there. If savetoDB is a library function, its entry point should allow passing in the success block you want to run on the main thread when everything finished. This is the pattern used by libraries like https://github.com/AFNetworking/AFNetworking. Note how their examples provide an API where stuff runs in the background and then your code gets called back (usually in the main thread).
Yes, parseAPI and savetoDB will run in the new queue you have created. If you need to modify the UI when the operations are finished, that code must run in the main thread. To do that, get a reference to the main queue and send it some code. For example:
- (void)startprocess {
dispatch_async(backgroundQueue, ^(void) {
[self getAPI];
dispatch_async(dispatch_get_main_queue(), ^{
// Refresh the UI with the new information
});
});
}
Don't forget to dispatch_release your new queue when you're done with it.
Another pattern, used by Cocoa itself in many parts of the framework, is to add callback block to the signatures of your API functions that is invoked when the background operation has ended. This Stack Overflow thread explains how to do that.
Yes of course if getAPI calls parseAPI, the code of parseAPI will execute on the same thread than the one getAPI was executed, so in your example on a background queue.
To return the callback to the main thread at the end, use the same techniques as Apple uses with their completionBlock you can see on multiple Apple APIs : simply pass a block (e.g. dispatch_block_t or void(^)(NSError*) or whatever fits your needs) as a parameter to your getAPI: method which will pass it to parseAPI: which will in turn pass it to savetoDB: and at the end savetoDB: can simply use dipatch_async(dispatch_get_main_queue, completionBlock); to call this block of code (passed from method to method) on the main thread.
Note: for your getAPI you can use Apple's sendAsynchronousRequest:queue:completionHandler: method, that will automatically execute the request in the background then call the completion block on the indicated NSOperationQueue (NSOperationQueue uses GCD's dispatch_queue internally). See documentation on NSOperationQueue, GCD and the Concurrency Programming Guide and all the great detailed guide in Apple doc for more info.
-(void)getAPI:( void(^)(NSError*) )completionBlock
{
NSURLRequest* req = ...
NSOperationQueue* queue = [[NSOperationQueue alloc] init]; // the completionHandler will execute on this background queue once the network request is done
[NSURLConnection sendAsynchronousRequest:req queue:queue completionHandler:^(NSURLResponse* resp, NSData* data, NSError* error)
{
if (error) {
// Error occurred, call completionBlock with error on main thread
dispatch_async(dispatch_get_main_queue(), ^{ completionBlock(error); });
} else {
[... parseAPI:data completion:completionBlock];
}
}];
}
-(void)parseAPI:(NSData*)dataToParse completion:( void(^)(NSError*) )completionBlock
{
... parse datatToParse ...
if (parsingError) {
dispatch_async(dispatch_get_main_queue(), ^{ completionBlock(error); });
} else {
[... savetoDB:dataToSave completion:completionBlock];
}
}
-(void)savetoDB:(id)dataToSave completion:( void(^)(NSError*) )completionBlock
{
... save to your DB ...
// Then call the completionBlock on main queue / main thread
dispatch_async(dispatch_get_main_queue(), ^{ completionBlock(dbError); }); // dbError may be nil if no error occurred of course, that will tell you everything worked fine
}
-(void)test
{
[... getAPI:^(NSError* err)
{
// this code will be called on the main queue (main thread)
// err will be nil if everythg went OK and vontain the error otherwise
}];
}