I am using TabBarKit, and I want to execute a request to pull a new peice of content from a webservice each time a user goes back to a tab.
I can't put the request code in viewDidLoad as its not fired when coming back to the tab. With that said, I've noticed viewWillAppear / viewDidAppear are called multiple times when returning back to a tabs view controller.
If I put the requesting code in there, it is fired multiple times resulting in the webservice being pinged needlessly.
How can I solve this problem? Which method should I place my HTTP request call in so it executes once per view?
You could try setting/checking a downloadInProgress flag before submitting the asynchronous download, then resetting that flag when the request completes.
If you're using something like the ASIHTTPRequest, that calls a delegate method when the request completes or fails, which is the point where you could reset the flag. It allows you to tag each request individually so you can track the success or failure of each one, so this wouldn't restrict you from running one background request at a time.
Turn's out there was an extra call to viewWillAppear in the controller code. If you're interested in following the changes, there is a thread on the issues section of the Git project.
Related
I am a beginner developer in Objective-C/iOS and I have this simple question.
My program interact with a server side and I use GCDAsyncSocket for asynchronous communication.
I wonder, suppose the use is opening my status view controller which causes a request for server, but before the response arrives he has already moved to a different view!
What is the right way the handle this situation??
Thank you!
Ideally you should not move to the next view controller until you get the response in didReceiveData callback, because your GCDAsyncSocket delegate will have to be set to some controller, and probably you would have by default set it to the status view controller.
So you have to wait for the callBack response and upon receiving it you can move to the next view controller.
While the delegate can be set to the next view controller, you can skip it for now as you a beginner in iOS.
This is key.
asynchronous
You're using an asynchronous request to get your data. You'll have to use callbacks to let the view controllers know that the request has ended. I've never used that library but a quick glance at the readme says:
Classic delegate-style support.
All of the following result in calls to your delegate method: connections, accepts, read completions, write completions, progress,
https://github.com/robbiehanson/CocoaAsyncSocket/blob/master/README.markdown
https://github.com/robbiehanson/CocoaAsyncSocket/wiki/Reference_GCDAsyncSocket
Here's the scenario:
-A UIViewController (A) is pushed onto the navigation stack
-On viewDidLoad an async GET is called using AFNetworking (a singleton AFHTTPClient shared throughout the application) to populate various user elements on the view (say a UILabel).
-The user presses the back button before the request returns
-Assume other active view controllers may be making requests so you can't cancel all open operations
So question #1 is, should you track the open requests made by UIViewController A and cancel the outstanding ones when the user leaves that view, or should you let them finish up and ignore them? Since AFNetworking uses blocks, the user elements being updated are retained inside the block and therefore won't cause a crash when the success/fail block is executed after the view has been popped. However the downside to ignoring them seems to be unnecessary network traffic.
Question #2 is, where would you execute the code to cancel the operations made by UIViewController A? viewDidDisappear doesn't seem right because the user may have gone forward (pushed a new view onto the stack) instead of back (popped the current view), in which case you don't want to cancel the open requests because the user may come back to the current view and it won't load again. However, I don't think dealloc or viewDidUnload will be called while the request is executing since the block will keep a retain on the user elements so I don't think it can go there.
Would appreciate thoughts on this. What do you think is best practice?
Generally speaking, you don't really need to cancel requests when a user leaves a view controller. In terms of memory management, a reference to block self will prevent any crashes caused by sending messages to deallocated instances, so no worries there.
As far as user experience, I would say that you shouldn't really worry about it until it's a problem (we developers have a knack for guessing completely wrong on what will be slow in our applications). If you are making large GET requests, though, and it's creating noticeable sluggishness, my suggestion would be to have the controller do HTTPClient -cancelAllHTTPOperationsWithMethod:path: in -viewDidUnload: (any other callback would be premature).
Maybe you could have a singleton which manages all the network stuff, and just set its delegate to the current vc (in viewDidLoad) so you get any incoming data, and send it a cancel message when the vc disappears (or else let a different vc become its delegate). Or the singleton could keep the data for access by any vc at some later stage. I tend not to put async code into my VCs for this reason.
I am using the UIApplicationDidBecomeActiveNotification to refresh my tableview when the app becomes active. My problem is that in my ViewWillAppear, I am also calling a method to refresh this table's data.
This is causing the table to be refreshed twice upon application launch. How can I get one of them not to fire when the app is initially launched? Refreshing the table has some intensive processing of network and local data.. so I would really like o only perform this action once.
Thanks.
You need to use UIApplicationWillEnterForegroundNotification instead of UIApplicationDidBecomeActiveNotification.
The latter is posted every time your app becomes active (initial launch, back to app after call/sms interruption, etc.). But the former is posted only in case of wake up from background. Note that in this case viewWillAppear is not called (as it should seems to be at the first sight).
One way to do it would be with a flag, that you can set up in didFinishLaunching, since that is only executed once per launch.
I am using three20 and implement the model like the example of TTRemoteExamples. Now problem is: when I click and open a page, the TTURLRequest sent out, during fetch data from remote, I click to open another page. But the previous network request is still there messed my loaded data. So I want to know the way to cancel previous network request when I switch to another page. Or when I click button to do a new request in the same page.
Thanks~
To cancel a TTURLRequest, keep a reference to it (typically in an instance variable) then send it a "cancel" message. Like so:
[self.myRequest cancel];
If you don't want the delegate to be notified of the request being cancelled, do:
// I'm assuming self is the delegate here, that may not be true
[[self.myRequest delegates] removeObject:self];
[self.myRequest cancel];
You'll typically also want to do this in your view controller dealloc method. If a request continues after the viewController has been deallocated, it will try to send delegate messages to it, and you'll get a bad access crash.
As for the timing of when you cancel it, that's up to you. If you need it to stop when a user leaves your view controller, then implement UIViewController's viewWillDisappear: or viewDidDisappear: methods (don't forget to call super!).
When the return button on the keyboard for a textfield is tapped I want to add a UIView, then connect to a website with NSURlConnection sendsynchronousrequest and I have the code in that order
But when I run in the simulator (I can't run on device) the connection is run first then the subview is added (ie the opposite of the order of the code)
Why is this and how can stop it, because I want the view to added, then the connection done and then the view removed.
The subview is being added, but views are drawn by the runloop. By making a synchronous request on the main thread, you are blocking the runloop, so the view won't be drawn until after the request completes. Do the request asynchronously, either by using the async API or by doing a synchronous request in a background thread.
Many actions happen on the run loop, rather than in the order you code. If you really want to code the way you have, then performSelector:withObject:afterDelay: with a delay of 0 might work to trigger your NSURlConnection (you will need to move that code to a method).
As JK suggests, an asynchronous request might solve it anyway, and improve the UI. I'm a great fan of ASIHPPTRequest library, which makes async trivial.