Not Getting Success/Fail Callbacks for Share Extension using AFNetworking
Asked Answered
S

3

10

I'm having a bit of a problem with AFNetworking in a share extension. In the didSelectPost, I'm calling:

[[AuthClient sharedClient] POST: @"/v1/events"
    parameters: params success: ^ (AFHTTPRequestOperation * operation, id responseObject) {
        [self.extensionContext completeRequestReturningItems: nil completionHandler: nil];
    }
    failure: ^ (AFHTTPRequestOperation * operation, NSError * error) {
        NSLog(@"error: %@", error);
        [self.extensionContext cancelRequestWithError: error];
    }
];

[AuthClient sharedClient] uses the singleton pattern to get an instance of AFHTTPSessionManager with NSURLSessionConfiguration set with a background identifier.

However, neither the success or failure callbacks are invoked and it just hangs indefinitely until the extension gets killed. Interestingly, the HTTP request finishes fine on the server side; the completion just never gets invoked.

Sowell answered 25/2, 2016 at 6:11 Comment(2)
why you not try new AFN class?Anadiplosis
can you pause in the debugger and look at all your stacks? see if 2 of them are trying to take the same lock. (or either others' locks)Hermetic
L
4

I guess, the problem isn't with AFNetworking but problem is with that singleton class. You have not specified your app's architecture, but I'm assuming that, you may calling multiple APIs in different view controllers using the same [AuthClient sharedClient] singleton at the same time. Hence, you're actually receiving a success call but not for the above call but some where else in your controller. I have faced the exact issue in my UITabbarController based application where I was making API calls in viewDidLoad of different view controllers and my tester was continuously changing all tabs. Thus, I tried to get response for first view controller (1st tab) and used to get response in second view controller (2nd tab), which was wrong!

Lebanon answered 2/3, 2016 at 5:23 Comment(2)
Agree... Maybe stick an NSLog() line in the success block to verify they aren't getting called. Since you're using an instance variable on a singleton there can only ever be 1 extension context, so if it's possible that a call could be in flight when another one gets fired; then there will only be one thing receiving callbacks.Shaver
Logging didn't help, but the issue was with the singleton. Won't go into app-specific details, but this put me on right trackSowell
M
1

1) Try to execute this request in Postman, for check the right way and parameters, if ok -> 2.

2) Try to use session configuration like this

NSURLSessionConfiguration *sessionConfiguration = [NSURLSessionConfiguration defaultSessionConfiguration];

// Initialize Session Manager
AFURLSessionManager *manager = [[AFURLSessionManager alloc] initWithSessionConfiguration:sessionConfiguration];

at this point we can assume that your singletone was initialised for another request with different configuration.

3) similar problem

4) about AFNetworking background

P.S. Try to use simple asynchronous on main thread, with spinner while waiting response

Mayfield answered 4/3, 2016 at 12:28 Comment(0)
R
1

Some things I'd try:

  • Do a sanity check with a network trace; and ensure that the data you expect is reaching the client.
  • Set a breakpoint and look for any blocked threads or anomalies (even consider breaking on the Apple networking APIs themselves ie. CFNetworking or NSURLSession etc.).
  • Check that the lambda/completion blocks are being properly set/retained by your singleton object / try to write a simple test routine without using the singleton to see if it makes a difference (such as by manually instantiating the class and using it).
  • It's not clear from the snippet if the 'success' completion handler prints out a debug message - consider adding an NSLog there too, if one's not already in the handler.

Hopefully some of this can bring you closer to an idea of what's causing the problem.

Rerun answered 8/3, 2016 at 6:18 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.