I've dug through a lot of topics regarding didReceiveData: method not being called - the solution is to set appropriate cachePolicy and implement willCacheResponse delegate method.
So I did, now I get didReceiveData message each time anything comes from the server.
Unfortunately I don't get didReceiveData the very first time the server responds.
In other words, the first time I get "didReceiveData" message there are 2 response objects in the "data" parameter. Every response from the server following that moment is OK.
Any help?
Just needed a clarification; Are you using any threading in your application?
If Yes, then the thread which creates the connection should receive the response from the server. The other threads will not identify the response which is returned for some other thread.
Related
Is there any way to send out two httpresponses for a single httprequest in play framework.
As as per the RFC of http we can send out two messages for a single request although as I am really novice in Play framework, can this be done.
If not what might be the best approach to solve this scenario
Little note: This solution does not use chucnked, and use the xmlHttp request instead. And also, there is no magic: two requests and two responses. So if you have a constraint on the front-end framework; this might not be the best answer.
You also commented this:
not at once , need to send ok response as an handshake then followed with the actual response which is calculated after extensive mathematical operations
So, if you don't have any constraints on your front-end framework; I would simply use the advantage of Javascript to send the second request, in the background, and get the second response back. Here how I would do it:
Update my views file to take a parameter, handShake of type Boolean. So when to user goes the page for the first time, the controller method response is false. After the first hand shake, the controller method, sends true with Ok response to the user. Only then when it is true the app itself sends another request, as an xmlhttp request via the javascript code, to the controller, and then the corresponding controller method, calculates what it needs to calculate and sends the response back.
This way you send two requests, and get back two responses, but you don't reload the whole page for the second request.
Here is what I need:
call post api
if success: do nothing
if failed(no internet available): put the request on to a stack
monitor if the network has come back
if network available: retry everything on that stack
even if the user close the app, I still need to have the stack available. I need to store the stack onto the disk
Here's what I plan to do:
have a class called apiRequest, it contains
parameters
url
have a class called apiRequestManager, it contains
array of apiRequest
the apiRequest array is stored onto the disk. Every time, when user want to call the api, I call Alamofire.request first and if failed, put it onto the apiRequest array.
use NetworkReachabilityManager to listen if user can reach the server. If true, then retry everything in apiRequest. Everytime a request succeed, remove it from the array. else keep it as is.
The reason I ask this question is because I am new to the Alamofire framework. I don't know if this is a good way to go or if this case is already been handled in Alamofire.
Also, there is a RequestRetrier protocol. But I don't want to retry every single request again and again, I want to retry it all at the same time and if not succeed I do want to store the request on to the disk for future retry so I guess that is not what I want to use?
Any suggestions?
Thanks.
Hi in my application I am using NSURLConnection delegate metods to get a response from the server.Here what is happening is when ever I send a request to the server for the first time I am getting response immediately.After that first request if I send same request to the server again immediately I am getting the response as null. But if i leave the ipad aside after sometime I am getting the response can you please let me know is there any time limit needed between the requests while sending to the server using NSURLConnection delegate methods.Please help me to resolve this issue.
Thanks in advance.
I'm using HttpWebRequest in a VB.Net WinForms app to get data from an inhouse webservice. The code I'm using works for both GET and POST when run while Fiddler is not running. If I have Fiddler running the GETs work and are captured but a POST doesn't complete. In this case Fiddler captures the initial request but never gets the response and the application doesn't get a response.
The code builds a HttpWebRequest for the POST setting the appropriate properties, encodes the data to be sent into JSON and then does this.
Using postStream As Stream = webrequestobj.GetRequestStream()
postStream.Write(WebServiceByteData, 0, WebServiceByteData.Length)
End Using
I used WireShark to capture the generated network packets and noticed that when a POST is sent without going through Fiddler the following happens.
When "postStream As Stream = webrequestobj.GetRequestStream()" is executed a packet with all of the header info is sent that includes a "Expect: 100-continue" header but doesn't have the request data.
When the postStrean.Write call is executed an additional packet is sent that has the request data.
With Fiddler running nothing is put on the wire until after the postStream.Write is executed. At that point both the header packet with the "Expect: 100-continue" header and the request data packet are sent back to back before the service has responded with the "100 Continue". I'm guessing that this confuses the webservice as it doesn't expect to get the request data packet yet. It doesn't respond with the requested data.
I used Composer to manually create the request without the "Expect: 100-continue" header. When this is executed the same two packets are generated and the service responds with the expected data.
So, in order to be able to use Fiddler to capture the POST traffic it looks like I need to either be able to tell HttpWebRequest to not issue the "Expect: 100-continue" header (I've looked but haven't found a way to do this) or for Fiddler to handle the packets differently, maybe not sending the second packet until it sees the "100 Continue" response or by stripping out the "Expect: 100-continue" header.
It's possible that I've missed a setup option in Fiddler but nothing I've tried so far makes any difference.
Thanks,
Dave
Old question, but the short answer is that the lack of a 100/Continue response shouldn't have mattered at all.
To learn more about Expect: Continue, including how to remove this header if you like, see http://blogs.msdn.com/b/fiddler/archive/2011/11/05/http-expect-continue-delays-transmitting-post-bodies-by-up-to-350-milliseconds.aspx
Background: During the handshake process, my iOS app learns the server capabilities by
Checking its header information in didReceiveResponse
AND
Parsing its response XML in connectionDidFinishLoading
Problem statement: Since callback #1 precedes #2, I am storing the version string in didReceiveResponse and checking it later in connectionDidFinishLoading when the response is available.
This fortunately works fine so far because #1 preceeds #2. But is that order always guaranteed by network / iOS?
From NSURLCOnnection Reference:
Zero or more connection:didReceiveResponse: messages will be sent
to the delegate before receiving a connection:didReceiveData: message.
The only case where connection:didReceiveResponse: is not sent to a
delegate is when the protocol implementation encounters an error
before a response could be created.
Zero or more connection:didReceiveData: messages will be sent
before any of the following messages are sent to the delegate:
connection:willCacheResponse:, connectionDidFinishLoading:,
connection:didFailWithError:.
Zero or one connection:willCacheResponse: messages will be sent to
the delegate after connection:didReceiveData: is sent but before a
connectionDidFinishLoading: message is sent.
So, it will not happen ONLY if there is an error before creating the response.
According to the documentation:
Zero or more connection:didReceiveResponse: messages will be sent to the delegate before receiving a connection:didReceiveData: message. The only case where connection:didReceiveResponse: is not sent to a delegate is when the protocol implementation encounters an error before a response could be created.
Zero or more connection:didReceiveData: messages will be sent before any of the following messages are sent to the delegate: connection:willCacheResponse:, connectionDidFinishLoading:, connection:didFailWithError:.
So unless there's an error, you can guarantee that you'll get a didReceiveResponse before getting a connectionDidFinishLoading.
Yes, of course. In didReceiveResponse you could check NSURLResponse and if something will be incorrect you can just stop downloading. So connectionDidFinishLoading will be called only after you've checked the response.