I am an iOS application developer. I am implementing NSURLConnection in iOS to handle webservices calls.
In my application I want to implement the multiple network connection simultaneously. And also I want full control over stopping the network call manually.
For example , I am navigating to table view which fills data from server using connection on background thread so in this case the UI is responsive. But lets say I want to navigate back from this tableView in this case the connection is not stopped. I want to stop it.
Please help me with this scenario. I want my UI responsive anyway. Thanks a lot. It will be really helpful.
Thanks,
Ganesh
You could use NSOperation/NSOperationQueue to manage the states of your operations, which includes suspending and canceling operations.
NSOperationQueue
NSOperation
use a property to store the NSURLConnection. For your ViewController override dealloc, or ViewWillDisapper (depending on your design) call the cancel method on the NSURLConnection
Related
I am using dispatch_async and a block to retrieve server data every 3 seconds or so. What is the method of handling the view either disappearing or the user shutting the program down?
Would it be a boolean flag that the async block checks every now and then? If so, what if the view exits while the async block is sleeping?
You cannot easily cancel a dispatch call, so your best bet is to move to an NSOperation instead. There is a highly relevent video from WWDC 2012, Session 211 - Building Concurrent User Interfaces on iOS which covers precisely the kind of problem you describe. I definitely suggest you watch it.
The basic approach is to create an NSBlockOperation which can check the -isCancelled property on itself to return early if it gets cancelled. Then you can cancel the operation in viewDidDisappear.
An alternative approach would be to use NSTimer which can also be easily invalidated/cancelled. This might actually be the simplest solution for you given the description of what your code is doing.
I'm a beginning iOS developer and in my first app I want to load data for my view controller, but the problem is that the data comes over from three different web services. I use NSMutableRequest in an attempt to implement this functionality.
What I want to do is issue three requests to load data at the same time and when the last one finishes, remove the activity indicator.
I tried using an NSOperationQueue, but with async it doesn't execute the didReceiveData or didFailWithError methods. Please do comment if you need more detail or explanation (my English is not very good).
Thanks.
I would look at GCD, and create 1 synchronous request that contains your 3 asynchronous requests to your web services. This way you let GCD do the work of waiting for each of the async operations to complete. There are a few really good videos on itunes from WWDC (Apple's developer conference) that are incredibly informative with regard to GCD.
I've just been wondering for a while now how exactly asynchrounous requests work with NSURLConnection.
For example, suppose you have several upload processes running in your application, all initialized using different instances of NSURLConnection. As uploading processes, your wrapper objects gets the NSURLConnection delegate methods called, like:
-(void)connectionDidFinishLoading:(NSURLConnection*)connection;
Suppose that in all your NSURLConnection wrapper objects share the same delegate object which have a list of all active uploads in an array, and that when the connectionDidFinishLoading gets called for all your connections, they go in and remove themself from that list in the shared delegate object.
The question then is, do you have to worry about thread-safety when those connection objects can access the same array? Or does all those delegate methods go back to the main-thread in such a way that you are not supposed to worry about thread-safety?
The trick is that the delegate methods are called on the thread on which you created your NSURLConnection, which unless you specifically change it will be the main thread. The OS uses one of the threading Queueing APIs to call the delegate method over and over on that thread in the order each connection finishes.
With NSURLConnection its only really the transfer that needs to be threaded. If the transfer happened on the main thread then during the transfer the User wouldn't be able to interact with your iOS application. Doing stuff with the result takes a relatively short time, but if it takes a long time whether you choose to do that processing in the background (on a different thread) or not is then up to you.
From the web service delay the data how can o do that the same process.When data came from the web service I want the write to the db .But data a little delaying .How can ı solve this problem.
Not sure I understood your question completely. It looks there are two parts.
You can use multithreading for your web service call so it won't block your current UI. Grand Central Dispatch can be used to manage such process for you. Here is a tutorial on GCD.
If you are using NSURLConnection, there are delegates that you can implement to wait for those callbacks. Here is one document from Apple.
I am currently thinking about the data-model for my iOS App. The app does only receive Information from a server and therefore, the "model" itself generally does all the web-requests, ...
However, these network requests have to be performed in the background - I mean another task, not the iOS background state - and after the request has finished, the information in the Application has to be updated.
Would it make more sense to write a delegate to inform the controller or could I also use NSNotificationCenter? I think an NSNotification-based solution could make the model more universal, e.g. in a desktop application.
And maybe, I should add: the model (since it saves some session Information) is a singleton, so a regular delegate based method would not work...
I don't think that it would be a good idea to use a separate thread to handle the communication. Apart from being complex, it is not necessary since NSURLConnection/NSURLRequest do allow you to handle communication asynchronously, i.e., without blocking.
In detail, you can create an NSURLRequest executing:
NSURLRequest* yourReq = [NSURLRequest requestWithURL:yourURL];
then create an NSURLConnection with:
NSURLConnection* yourConnection = [NSURLConnection connectionWithRequest:yourReq delegate:yourDelegate];
and start it with:
[yourConnection start];
When the data is ready, one of the methods for your delegate (connectionDidFinishLoading:, or connection:didFailWithError:) will be called so that you can update your UI.
All this without blocking.
An even better alternative to using NSURLConnection/NSURLRequest, is using ASIHTTPRequest, which seems to be more resilient as to memory management and also offers a great caching mechanism.
EDIT: if your concern is that being your model a singleton, you cannot have a delegate, let me suggest that you look further into the matter.
Your model may be a singleton and the delegate to your request may have nothing to do with the model, apart from knowing how to access it (which is pretty trivial being the model a singleton).
This is possible by several mechanisms with NSURLConnection, but if you use ASIHTTPRequest, it will become really easy, because each ASIHTTRequest can have its own delegate.
A delegate solution does work and is recommended. It looks something like:
[[DataLayer sharedInstance] fetchDataWithDelegate:self];
That method can spawn a background thread and respond to the delegate on the main thread.