Hi guys,
Do you know if you can "restart" an RKObjectRequestOperation with a new authentication in RestKit 0.20.3?
If the first one fails, I want to change the authentication of the RKObjectRequestOperation and start it from the beginning.
It isn't documented as reusable so even if it did work now you couldn't guarantee that it will continue to work in the future. The request and the response descriptors you use to create the operation are immutable so you can easily extract those to create a new operation instance and set your new auth details.
As an aside, the operation contains a state machine and internally utilises several other asynchronous operations. Don't rely on reusability.
Related
We're making calls to an API to get JSON data using AFHTTPRequestOperationManager.
Currently, we are instantiating a new AFHTTPRequestOperationManager for each request. We're considering instantiating just a single AFHTTPRequestOperationManager and reusing it across requests.
What are the trade-offs?
There are several reasons why AFHTTPRequestOperationManager per domain is a handy pattern:
1) You save the resources of creating a new manager for each request which can create significant memory pressure
2) Having just one reference to a manager allows you to easily manage all the network requests in your app. For example, when a user logs out you may want to cancel all requests. With just one manager you can easily access the operation queue and cancel them all at once.
3) Related to #2, having one instance allows you to manage the configuration for all your requests at once. For instance adding authorization headers or configuring custom parsers. These could of course be done before every request but it adds unnecessary complexity.
I'm developing some iOS apps and I'm downloading/uploading data which are very sensitive.
I'm using AFNetworking to do that requests and my question is simple:
I reach only 3 different certificates in all the app, can I custom AFNetworking's layer to accept only these 3 certificates?
The aim of this manipulation will be to avoid "Man To the Middle" attacks and so avoid injection and/or retrieval of any additional information during the HTTP exchanges.
All AFNetworking operations inherit from AFURLConnectionOperation, which defines a block called authenticationChallenge. Setting this block on your operations will define how AFNetworking responds to the NSURLConnectionDelegate method connection:didReceiveAuthenticationChallenge:. Specifically, you will want to inspect challenge.proposedCredential.
If you don't want to set this block on every operation, you could also subclass the operation type you're using (like AFJSONRequestOperation, for example), and override connection:
willSendRequestForAuthenticationChallenge: with the behavior you want.
I discovered today Servlet 3.0 asynchronous facility. I have read about it and think I understood the concept.
I was wondering: would that make any difference on "standard" controller's actions, or should it be saved for the use of web services, or extensive computational processes ?
In other words, is it a bad idea to use it on all one's controller's actions, without considering the computational time of the actions method beforehand?
If it is, could you explained to me why ?
Thank you in advance.
No, this would be a bad idea.
On a controller action, you get a request and you want to serve a response as soon as possible. You can use the asynchronous only for thing that can be delayed.
If a user is requesting a page on your website, you can't respond with empty page, then do a push back to update his page. I would use this feature only for AJAX requests and even not for all of them. You have to decide what makes sense to run be run asynchronously and what not.
You should read the Grails documentation for Asynchronous Request Handling
In general for controller actions that execute quickly there is little benefit in handling requests asynchronously. However, for long running controller actions it is extremely beneficial.
The reason being that with an asynchronous / non-blocking response, the one thread == one request == one response relationship is broken. The container can keep a client response open and active, and at the same time return the thread back to the container to deal with another request, improving scalability.
Hopefully this should be clear enough, but please ask if something is not clear.
I've just started to try out RestKit for an iOS app i'm building. I normally use ASIHttpRequest, but I want to test out RestKit mostly for its object mapping between JSON and CoreData. There are some great things about RestKit, but I've run into an issue that really makes it feel deficient, unless I'm doing something wrong or have missed something. I hope someone here can guide me on that.
I'm using RKObjectLoader to make async & sync calls to a REST API. My service is designed to send back proper HTTP status codes, along with some sort of description, a 401 being an example of when the API needs an authenticated user.
My problem is that RestKit stops acting normally if i get a 401 error back. The RKResponse object has a status code of 0, even though it has a payload in it. I'm pretty sure this comes down to NSURLConnection's poor handling of HTTP statuses, but I would expect RestKit to wrap around this somehow. Especially since the RKResponse class has quite a few wrapper functions to determine the status code of the response (isOK, isCreated, isForbidden, isUnauthorized, etc.).
In comparison, ASIHttpRequest doesn't use NSURLConnection, but instead uses the lower level CFNetwork code. ASIHttpRequest allows me to see exactly what came back over HTTP without sending out errors left & right.
Question is, am I doing something wrong, or is this the expected behavior out of RestKit? Has anyone successfully been able to make a calls to [RKResponse isAuthenticated]? Although its inconclusive to me, is there any difference between running in async and sync mode in this regard. I did read somewhere that NSURLConnection run in sync mode will act a bit differently, even though the underlying code is just calling the async operations. Does this have more to do with me using RKObjectLoader as opposed to just RKRequest? Perhaps the fact that the payload can't map to a model causes anger, but it seems that the code is breaking earlier within RKRequest.sendSynchronously, prior to when mapping actually takes place.
Bottom line is my code needs to be able to freely read HTTP status codes. Any guidance would be most appreciated.
Haider
The common way for RestKit 0.20.x is to subclass RKObjectRequestOperation.
I wrote a blog article about this problem which can be found here:
http://blog.higgsboson.tk/2013/09/03/global-request-management-with-restkit/
See http://groups.google.com/group/restkit/msg/839b84452f4b3e26
"... when authentication fails, the authentication challenge gets cancelled and that effectively voids the request."
UPDATE:
RestKit already includes a delegate method for this:
(void)request:(RKRequest *)request didFailAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;
Triggers before
(void)objectLoader:(RKObjectLoader *)objectLoader didFailWithError:(NSError *)error
When HTTP Basic authentication fails, so we can use this instead.
As a novice iOS developer, I am trying to understand some concepts related to the callback mechanisms in iOS.
My model makes HTTP requests through NSURLRequest to a backend rest service. The model has several methods which corresponds to the methods in the service. NSURLRequest is based on the delegate pattern, which means that I receive a common callback for all of the service calls. Then, my model has to find out which service call the callback is related to, so that I can send an appropriate update event to the controller. This is awkward since I have to maintain som state in the model to remember which call I made the last time (which is very impractical in the case of concurrency), or interpret the payload in the HTTP response.
I would wish that NSURLRequest would support the target-action pattern, so that each of the requests could decide which callback method to use. Is that possible? Am I missing something here?
If target-action is not available in the framework, what are the best practices to solve this?
The way to do this is to use NSURLRequest with NSURLConnection. If you check out the docs for NSURLConnection, they will tell you that you need to implement the callback methods in the NSURLConnectionDelegate protocol, and will give you details.
That page also points to several examples, with sample code.
You can also check out the URL Loading System Programming Guide at developer.apple.com, which will give you additional information on how these classes are intended to be used.