I am having an issue with UIWebviews and a couple of custom NSURLProtocols that I have in my app.
All my non web view request are invoked with NSURLSession, so in order for those request to go through the protocols I need to set the setProtocolClasses array on my sessionconfig, at this point everything works as expected.
For my web views, I do a registration on the didFinishLaunchingWithOptions: method in the AppDelegate with the [NSURLProtocol register class[MyProtocol Class]]. If i don't re-register before the execution of the web view request, that web view request won't go through the protocol.
Do you guys have any idea why I have to re-register to my custom protocol every time I try to load a web view request?
What is the request URL? Is it possible that there's another protocol class that gets registered after you? Does canInitWithRequest get called on your class at webview request time?
Related
So I have implemented my own NSURLProtocol sub class. I registered it when app launches.
I tried to print all requests in canInitWithRequest:, however while running, it's not getting all the requests, just a few domains.
Is there anything I should notice or be careful? Any possible reasons? What did I miss? Thank in advance.
It kind of depends on how you registered it. You can register it for use with NSURLConnection (and, IIRC, the shared NSURLSession), or you can register it for use with other NSURLSessions individually. If a request happens in a session that your protocol isn't registered in, your protocol won't see it.
I have a WatchOS2 app which displays data on the watch after calling NSURLSession. Since response takes some time, if the user opens another interface controller another call goes to
- (void)session:(WCSession *)session didReceiveMessageData:(NSData *)messageData replyHandler:(void(^)(NSData *replyMessageData))replyHandler
But if previous api output comes then it returns data through reply. Again the second data output should also be send. So this is giving a crash and my app hangs.
Is there a way to stop the previous reply from being sent by closing the request?
No, there is no way to cancel the previous request. It sounds like you are making the "currently visible interface controller" be the delegate of the WCSession, which would be mixing a lot of responsibilities. Instead I'd suggest adding something like a singleton class that is the permanent delegate of WCSession; and it persists and notifies, or dispatches incoming data to the right place.
I have been developing a weather application in iOS 8 . I need to display the parsed JSON when the view displays. I am not sure in which delegate methods do i need to request the api. i know it should be requested in the background thread. which are the delegate methods run on background thread?
you can call your api in every where!
for example call in : AppDelegate or in initialize viewController.
but remember : your request is async so if the request going to fail or getting timed out you should handle it or notify toy first View Controller.
SFSafariViewController is compelling, but has a very simple API that doesn't allow setting any fields on the request it initiates when presented. Are there any clever ways to set the HTTP referer header on requests initiated from SFSafariViewController?
There is no API for that, unfortunately.
You can check SFSafariViewControllerDelegate page - all of the delegate methods is post-load handlers.
WKWebView and WKNavigationDelegate is one of possible replacements (iOS 8.0+).
The only way I could think to do this would be to bounce the request off of a web service that you control.
Sadly you can't use anything other than http or https URLs, so a local file URL won't work (short of listening on a socket on the device).
I am building an app in swift which interacts with an API. There a two ways a user can be logged out, by clicking a logout button or by receiving a 401 response when calling the API.
I plan on using NSNotificationCenter in my API class to broadcast an event when an unsuccessfully response is received so generic handling of things like 401, 400, 500 can be handled in one place outside of the API class.
To prevent duplicating the logic involved with logging out in multiple places I have created a Class which will clear any existing tokens and present the login view controller. This class can then be used when the logout button is clicked in the view controller or when a 401 response is picked up by the response observer.
My problem is, since the logic is not inside a view controller I am unsure how I can present the login view controller as I do not have access to the method self.presentViewController
You're going to need to pass that responsibility to a view controller.
How I've handled this in the past is using a key-value observer (or RAC) to monitor the active token. When that token goes away, I swap out the root controller.
Where you do this depends on how you've structured things. The app delegate is a reasonable spot.