Do I need to cancel the opened connections (NSURLConnection) when I leave the view?
I'd do that in viewWillDisappear or viewDidDisappear but I don't know whether I actually need to do that.
If you're using ARC, there's a good chance your NSURLConnection objects (assuming they are instance variables or that you're holding onto them in memory somehow) will get magically released when the view controller goes away.
But to be sure, and to be nice, you should cancel the open connections. Doing the NSURLConnection object "cancel" in either "viewWillDisappear" or "viewDidDisappear" should work well.
Related
Kind of a newbie question, so forgive me if I'm missing some basic concepts...
I have a view controller within a window, which contains multiple NSTableViews, each of which having a variety of associated observers added via addObserver. These work fine and as expected, with notifications going to each of the correct table views. However, if I close the window, then open a new window (of the same type), posted notifications are being sent to the table views of the window that was previously closed.
I was under the impression that as of macOS 10.11 observers did not have to be explicitly removed, which I would assume would happen when the original window is closed... UNLESS I'm missing something fundamental about closing windows. At the moment, I don't do anything special when the user closes a window, and the window just vanished from the screen. Do the views created in my viewDidLoad method live on even after the window is closed? Or no I need to explicitly dispose of these views in a method such as viewWIllDisappear?
Thanks!
Even when object you added as observer is disposed the observer is not. According to official documentation you have to pair each addObserver with corresponding removeObserver. This is true and for NotificationCenter and for KVO. By the way adding object as observer does not increase its owners, so under correct memory management left observer result in run-time crash - that is why needed paired removeObserver (if there is no crash in such situation it means there is leak).
The place where to do this depends on usage. If you add observer in viewWillAppear then it is better to remove it in viewWillDisappear, if you add on creation then remove should be done in deinit
Lets say I have multiple View controller classes using the same UIAlertView *alertView. *alertView's delegate is set to a centralized delegate.
I do this because would like to use the .tag to do different things based on it.
The question is every time I invoke an alert view or dismiss it, what do i have to do to prevent a memory leak?
Should I not release every time? Or is this a very bad idea?
Thanks.
A UIAlertView may be "shown" from anywhere in your app. I have an app that the main UIViewController has a timer that every so often brings up a UIAlertView. When that timer goes off, even if my main view being shown is from a completely different UIViewController (and thus view) the Alert will come to front.
If you really want to "actively" bring up the UIAlertView from any of your UIViewControllers (lets say based upon a user action), then I would do one of two things.
1) setup my Application Delegate Object with the UIAlertView implemented there, with accessor methods for invoking (showing) the Alert view, and thus freeing it from there also, or
2) Generate a singleton like object with the AlertView implemented there!!!
In either case then you can simply dealloc your UIAlertView once within the dealloc routine you write for either of those placements, and alloc it only once when the object is initialized.
Just treat it like you would any other object. If you want to keep it around, assign it to a retained property like: self.myAlert. You still need to release it like you normally would when creating it. The retained property will take care of keeping it around for you.
Always keep your retains(alloc's, copy's, etc...) and releases balanced.
I want to make sure that all my initializations for my views and stuff are handled every time my application starts, even when it is called back after being sent to the background, such as with multitasking.
What's the best way to do this? should i use applicationDidBecomeActive to call viewDidLoad on my viewcontroller directly? I'm guessing this is not wise. I just want to make sure that stuff gets done on load every time the user calls up the app, no matter what state it is in at the time.
I have several apps published that do just that - call viewDidLoad on one or several UIViewControllers from applicationDidBecomeActive.
It works just fine. Apple doesn't object to it either.
However, be aware that if you have allocations in your viewDidLoad you need to either check for already allocated instances or release the instances you allocate in viewDidLoad when your app suspends. The same goes for DB connections that need to be closed, notification listeners, and so on.
As long as you watch for these elements and handle them correctly, the approach is valid and very usable.
I set the view controller to be the delegate of a local variable ASIHTTPFormDataRequest request.
But, tapping "Back" before the request has finished, pops and deallocates the view controller. So, when the request completes and sends the message -requestDidFinish: to the now nonexistent delegate, the app crashes with an EXEC_BAD_ACECESS exception.
How do I fix this crash?
One way I could think of solving this is to set the delegate to nil immediately after the navigation controller pops it. But, if that's the solution, how do I do that? (ARC's weak references would be sweet right now.)
Another way I can think of is to make request an instance variable of the view controller and call [request clearDelegatesAndCancel]; [request release]; in the view controller's dealloc method. This approach is outlined in ASIHTTPRequest Example Code, but I've been advised it's best to make requests local variables instead of instance variables. And, this particular view controller is a settings table view controller and has 13 switches. For automatic saving to the server, each switch creates & sends a new request each time it's toggled. If I made ivars, I'd have to make 13. That's a lot of code!
Thoughts? Ideas?
I think the first question is: What do you want to happen if the user presses back after pressing a switch? ie. Should the http request be cancelled, or is it important that the request does get to the server? I'll assume for now that you do want to cancel them, as that seems to be implied in your question.
I've been advised it's best to make
requests local variables instead of
instance variables
I'm not sure if that was good advice - you almost always want requests to not be local variables so you can cope with cases like this.
For your case, you could consider using an NSOperationQueue.
Rough steps to do this would be:
Create an NSOperationQueue in your view controller init.
When you want to make a http request, add it to the ASIHTTPRequest queue instead of call startAsynchronous
In dealloc, iterate the objects in the queue, calling [request clearDelegatesAndCancel]; for each one, and then release the queue.
That should solve the crash without needing 13 ivars!
I solved this by retaining the request delegate like NSURLConnection retains its delegate.
I know that dealloc is called when an object's retain count reaches zero and that iVars should be released therein, but I am wondering if it is also an appropriate spot to delete temporary files or close database connections.
Specifically, I have a subclass of UIViewController that creates a database connection in -viewDidLoad and through user interaction, temporary files can be created. I would like to close the DB connection and delete the temporary files (if they exist) when the aforementioned controller gets popped of the navigation stack. Should I do so in dealloc?
My first thought was to do this DB and file clean up in -viewDidUnload, but I now know that this method is only called when a memory warning is issued by the OS. Another thought was to put it in -viewDidDisappear:animated but the issue with that approach is that the another view may go on top of the one controlled by my view controller. In that scenario, I do not want to close the DB connection or clean up the temp files.
If dealloc is not the appropriate spot (this is my gut feeling), where should this type of clean up be done? I would kind of hate to force the parent of my view controller to have to call a method in response to its child getting popped off the navigation stack.
The Apple guide to memory management says, No.
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html#//apple_ref/doc/uid/TP40004447-SW13
In short, don't use dealloc to manage resources.
You can do so in dealloc, or if you need the files around during app lifecycle, on your app delegate's applicationWillTerminate:. YMMV.
Do not try to do this in the dealloc method of your view controller.
What would happen if the view controller gets retained somewhere you're not expecting it? The dealloc method may not get fired, and you clean up never occurs. Maybe that's not the case in the code you're writing now, but something could change in the future.
Is there any specific reason you want to tie the deletion of files and closing of the DB connection to popping off the view controller? If not, perhaps you could do this immediately your query has completed, or it may make sense to open the DB connection on startup/foreground, and then close it on termination/backgrounding.
If you must tie it to view controller being popped off the nav stack, then you could call your clean-up method from viewDidDisappear: