I'm testing out in app purchases for my mac app, and I've noticed that the selectors productsRequest:didReceiveResponse: and paymentQueue:updatedTransactions: are getting called on a background thread (not the main/ui thread) when I request products or try to make a purchase.
I haven't seen any documentation warning about this, since that would mean updating UI from within these methods should not be done.
Has anyone else run into this? Should I just be calling performSelectorOnMainThread: within these methods to update the UI?
Ran into the same issue as it appears to behave just like an asynch call using NSURLConnection. I solved my particular issue by using the NSObject method call "performSelectorOnMainThread:withObject:waitUnitlDone:" Probably setting up NSNotification to be caught on the main thread of ViewController or WindowController would work as well.
Related
I'm a windows developer and I'm having a hard time understanding the right way to run code in the
NSApplication's main thread.
Most of my code is running in a cvdisplaylink thread (it's an opengl app)
THe problem is that I can't call things like NSOpenPanel from it - it crashes the app and warns about only running stuff like this from the main thread.
It's fine, but the main thread is completely opaque as far as I understand, and I can only make it do things with events. The NSApp sendAction method sounded promising - because I could explicitly specify which method to call. But it didn't 'send' any thing, it just called this method directly from the same thread.
Am I understanding this right? Do I have to push some sort of a custom event (perhaps NSEventTypeApplicationDefined) to the main thread queue for this to work properly?
And if so, how to I respond to custom events like that?
Like this:
dispatch_async(dispatch_get_main_queue(), ^{
// do whatever
});
If what you want to do is to call a method of an Obj C object, the old school Cocoa way (which still works) is to use performSelectorOnMainThread:withObject:waitUntilDone:
E.g. to hide a window by calling its "orderOut:" method you would do this.
[theWindow performSelectorOnMainThread:#selector(orderOut:)
withObject:nil
waitUntilDone:NO];
My situation is that every time when my app becomes active I need to sync some data from Facebook. This sync should be made in the background and should not lock the GUI (thus it should not run on the main queue).
So in my - applicationDidBecomeActive: method I have this code:
dispatch_async(dispatch_get_global_queue(0,0), ^{
[[FacebookHelper sharedInstance] syncData];
});
FacebookHelper is a singleton class that takes care of all Facebook handling. In the FacebookHelper class I have implemented the Facebook delegate methods. But for some reason when I run the above code the Facebook delegate method - request:didLoad: (when the Facebook data is finished downloading) is never called. Although if I run the same code with dispatch_sync it will finish (but then the GUI will be blocked).
Edit: Facebook SDK v2
Actually after analyzing the code I noticed it was an internal processing method that was done in the - request:didLoad: delegate method. So I just put that internal processing method inside a dispatch_async block and it performed nicely in the background.
Thanks for your help!
I have a window that displays some data in an NSTableView. This data is loaded in the background. The data-loading-thread is started in the windowDidLoad: method. If the window is closed before loading has finished, the background thread should be cancelled. I do this by signalling the thread in the windowWillClose: delegate method and waiting for the background thread to finish.
Now this all works perfectly. But I have one problem: How can I update the data in the table view? I have tried calling reloadData via performSelectorOnMainThread: but this leads to a race condition: The reloadData call is sometimes queued on the main thread after the window close command, and will execute after the window has closed, and everything goes up in flames.
What's the best way to control and communicate with a background thread?
Well, you know, this is exactly what makes the use of threading complex: you always face synchronization issues.
What I suggest is, instead of calling [tableView reloadData] from your thread, simply signal your controller (by calling a method controllerShouldReloadTable) and let your controller do the check if windowWillClose has been called or not. There might be a chance that your controller has been also released by the time controllerShouldReloadTable, and to fix this you will definitely need to retain the controller from the secondary thread.
On a side note, I would cancel the thread in viewDidUnload (for symmetry).
Most important: I would use asynchronous calls and a delegate class so that the whole multithreading issue is solved at its root.
EDIT: Sending asynchronously a request will not block the sending thread waiting for the response. Instead, asynchronous send (for NSURLConnection is called start) immediately returns (so, no blocking) and when the response is received, a delegate method will be called (i.e., connectionDidFinishLoading:) so that you can updated the model and the UI. Take a look at NSURLConnection docs, but as usual, I strongly suggest using [ASIHTTPRequest][2], which has many advantages.
i'm seeing a weird issue trying to add custom URL support to my Mac app. i've defined the URL(s) in Info.plist, and when i navigate to them my app gets launched (or, if running, activated), but then, regardless of whether my app delegate implements handleGetURLEvent:withReplyEvent: or not, i see a couple of the following messages in the debug output:
+[NSKVONotifying_MyAppDelegate handleGetURLEvent:withReplyEvent:]: unrecognized selector sent to class 0x1d096e0
Apparently, NSKVONotifying_MyAppDelegate is a wrapper created by KVO for my real delegate (called MyAppDelegate), and that seems to obscure my implementation of handleGetURLEvent:withReplyEvent:, which never gets called. AFAICT, nothing in my app uses KVO on the delegate, and i'm running out of ideas as to what could be causing this.
any suggestions?
turns out the KVO thing was a red herring. the method needs to be static, as careful reading of the error message (or docs) would have made clear, while i had an instance method (as one would expect, for delegate methods? weird API design choice).
I'm working on a simple proof-of-concept for an iPhone app (and important bit of info, I'm pretty new to Mac OSX development all around). I created a view based app with a timer. I declared my NSTimer in the interface of my app's controller, used #property and #synthesize, and I initialize it in the controller's viewDidLoad method with scheduledTimerWithTimeInterval method. My selector is a method with the signature -(void)someMethod:(NSTimer *)timer which is declared in the interface and defined in the implementation file of the controller as well. I can step past the line where I assign the timer and see that it points to a valid object, but my program goes no further than the end of the viewDidLoad method and never reaches the breakpoint at the first line of my method that is called by the timer. Also, I see GDB: Program received bad signal: "EXC_BAD_ACCESS" in the status bar of xcode at this point (viewDidLoad end is reached). I didn't do anything in IB but add a view and a picker just so I'd see if the UI actually loads...it never does.
So, am I doing something wrong with the NSTimer, or are my troubles elsewhere? How can I use the debugging tools in xcode to get more information?
EXC_BAD_ACCESS usually indicates a memory management error, without seeing the code probably from somewhere else in your app. It's a very common error for beginners, but an important subject to fully understand, so I'd suggest looking through some of the questions on memory management here and find a few guides or tutorials to look through. It's actually pretty easy to learn.
Also, it shouldn't hurt but unless you need to access the timer in between fire events, you don't actually need to store it as an instance variable. Once you create and start a timer it's added to and retained by the application's run loop.
Have you got NSZombieEnabled?
Might be useful if this is failing on an over released object.