I am looking to to develop an app where there will be "n" number of views created based on the user's interaction. If each of these views are created dynamically with autorelease, when will the view actually be released?
Lets say there are 10 views, all being dynamically created views with autorelease:
View 1 is created and added to a navigation stack, user is shown view 1
User moves to another view "View 2", View 1 is pushed off the stack and View 2 is added. Will View 1 be released here? I would not want it to be released, so should i retain it?
The problem is, i might not know how many views i am creating, so deallocating them manually might be problem, or is there a way?
I am a little confused soul here.
Thanks
You don't add views to navigation stack, you add view controllers.
When you push view controller 2, the 1st one will not get released, no. Navigation controller will always keep all it's view controllers retained until they are popped off the stack. It will only call -unloadView on non-displayed view controllers to free up some memory, but if you are creating your views inside view controllers' loadView method, everything will get recreated automatically.
You don't dealloc anything manually, you can only release it. Since navigation controller will retain any view controller you add on it's stack, you are free to release it yourself.
From the way you ask your questions, I've noticed you are missing some very basic knowledge about iOS SDK, MVC and OOP in general. I would honestly suggest you try creating a much simpler app than that chat app of yours first to learn some basics.
It will help if you post key segments of your code so we can see what you are doing. In short, if a view controller is in the navigation stack, it will be retained by the navigation controller. If it is popped off but you want to keep it, you'll need to retain it from another controller, probably the one that presents it.
Related
For now I have a single login view controller that hide and adds subviews dynamically based on user interaction. Is it better to have multiple UIViews with one view controller, or multiple view controllers?
The benefit of having children UIViewControllers would be if you needed to care about the view lifecycle in any of the children. For instance, if in some of your subviews (child views) you needed to know if it appeared to trigger some logic, then it would be good to use children UIViewControllers.
Another reason might be, if you wanted to use view controller transitions within your custom container, as described by Apple in the UIViewController class reference:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/index.html#//apple_ref/occ/instm/UIViewController/transitionFromViewController:toViewController:duration:options:animations:completion:
But, to me it doesn't sound like you would need this, it sounds like you would just show/hide your views, or otherwise animate them.
But if your views don't care about any of that, and just need to render UI elements, I'd say using children UIViewControllers adds additional complexity without much benefit.
This is under the assumption that either way, all your views are living on the single UIViewController's view. If you are pushing and popping view controllers inside a UINavigationController, or presenting ViewControllers modally, you definitely should use UIViewControllers for that.
Also, you definitely shouldn't put all your view code inside that single view controller. You should use subclasses of UIView, or some other mechanism of making sure you separate your components.
For example you might have:
LoginViewController - organizes and hides and shows the individual views
SignInView - shows the sign in form
RegisterView - shows the register form
...etc
Of course its better to have multiple view controllers for many reasons:
Each view controller has its own code/logic/functionality.
Better for memory management. Once you're done from a view controller, system will automatically deallocates it from memory. Using multiple views will be overload in your system when some views are not used.
Better organisation for your project. You will just present/dismiss/push/pop view controllers and pass data between each other. Instead you will deal with horrible logic for hiding and showing UIViews.
Using one view controller will have a massive amount of code which in long term the project will be an impossible mission to manage.
Having multiple view controllers is better in the sense that you would have more ease at coding them individually. Also Navigation will be good which is good for User Experience.
Memory Management will be efficient.
The MVC architecture(Model View Controller) will instead become Massive View Controller which will be a headache while debugging.
Check out this answer for more clarity. I think you are confused between ViewController and View.
Check out the accepted answer of this question in the link. Hope it helps.
About viewController's "viewDidLoad" and "viewWillAppear" methods
I currently have my first app, which uses a storyboard. From the first view, I can be 8 model views deep before returning back to the start.
I think using XIBs (not storyboards) is better for my application. I would like to learn how to do all the views in code but all the books and tutorials treat code as a black plague. Hard to learn if no one teaches anymore.
My concern with my 8 deep modal string of views is that memory is consumed by each view and not released until I fall back to the start - releasing each one as I fall back.
My application is a state machine (so I want to simple move from one view to another), releasing all aspects of the view just being left. As I move from one state to the next, I release the current view as I move to the next one.
Can someone point me in the right direction?
Thanks.
You have a couple of choices. You could create a custom container controller (which would exist for the life of the run), and switch out which controller is embedded in it. As long as you have nothing pointing to the one that you replace, it will be deallocated.
A simpler solution, but one I don't really like to use, is to replace the window's root view controller with the next controller you want to go to, which will also cause the replaced one to be deallocated.
I have an application where the user can push infinitely deep into views (pushing onto nav stack). At some point, there will be a memory warning. I'd like to remove view controllers from the navigation controller and dealloc them. If the user goes back to those view controllers, I'd like to recreate the view controllers and push them back into the correct position in the stack.
Is this the right way to be thinking about this problem?
Is there an open source project that does this? It doesn't seem like an uncommon issue and I'd rather not reinvent the wheel.
There was a time where you needed to make sure that calls to viewDidLoad and viewDidUnload matched properly so that memory warnings could be handled this way. Since iOS 6 this is no longer necessary.
As it says in the documentation for viewDidUnload:
In iOS 5 and earlier, when a low-memory condition occurred and the
current view controller’s views were not needed, the system could opt
to call this method after the view controller’s view had been
released. This method was your chance to perform any final cleanup. If
your view controller stored separate references to the view or its
subviews, you could use this method to release those references. You
could also use this method to remove references to any objects that
you created to support the view but that are no longer needed now that
the view is gone. You would not use this method to release user data
or any other information that cannot be easily recreated.
In iOS 6 and later, clearing references to views and other objects in
your view controller is unnecessary.
If you're manually keeping large objects in memory, such as image or video data, then you can override didReceiveMemoryWarning to release those objects where necessary.
I'm just getting back into iOS development after a year or so away and am looking for a way to have a single view above or below a UITabViewController view. The idea is to have one ad view that is used throughout the app instead of one on each tab. The constant reinitializing of the ad view seems like it would be a lot of overhead so having one persist throughout would seem to be more effective.
I've searched for this but not found much of anything so even a useful link would be appreciated.
Thanks in advance,
Jason
I see several approaches here:
Since you are setting up your view hierarchy in your application's delegate, I'd suggest creating a separate UIViewController and managing it from your app delegate. That way you can show/hide it in the main UIWindow, without having to do much work.
You can subclass UITabBarController and show the ad in the visible view controller. This is more work, but your app architecture is arguably cleaner, because your app delegate doesn't get cluttered with ad-related code.
Another option is to look into a UIViewController category, where you can manage add related code. Not necessarily the cleanest, but it keeps the ads out of both your app delegate, and your tab bar controller. (You'd add the ad view as a category property via runtime level calls and associate objects, but that gets messy.)
I'd probably go with the first approach if it were me, but I could argue for either of the other two approaches, since an ad view doesn't really necessitate it's own view controller.
How about create a parent view controller and each view controller inherits from that parent view controller? Parent view controller has a ad view or table view, so every child view controller will has those two view as well.
Okay, after spending some time trying to create and manage a customer view controller for this I stumbled on the Container View Controller capability Apple added in iOS 5. I have no need to support iOS 4 or earlier so this works good for me. There's a good description of it here (unfortunately the author never wrote part 2 with a tutorial):
Container View Controller description
And a decent tutorial is available here:
Container View Controller tutorial
Between the two of these I was able to create a good setup with an AdViewController and BodyViewController (TabBarController) contained in a Container View Controller. This gives me all the capabilities I need (at least so far).
I'm executing a segue like so;
[self performSegueWithIdentifier:#"showSecondView" sender:self];
But the behavior is that it will always "load" the new view rather than show the existing view if it was already loaded.
My question is, how can I keep a view in memory once I've loaded it, so that future segue calls will simply "show" the existing view?
Thanks
EDIT:
Here is my user interface design. It's essentially a custom side tabbar view controller with a UIView (the big gray block) where all of the subviews are placed.
The short answer is that iOS isn't well suited for that, but you might be able to do so. It depends.
The question is how is that view's controller represented in the view controller hierarchy. The standard options are pushViewController (a push segue) or presentViewController (a modal segue). You might be able to do a custom segue that takes advantage of view controller containment (see WWDC 2011 session 102), but I'd be surprised if that would be something you'd want to pursue. Usually when you hear people talking about the frustration of creating new views is a result of their wanting to return to some main view, but neglecting to popToRootViewController and instead having a segue back to that root scene.
A wholly theoretical (and probably impractical) answer that might come up is to use a singleton and do some slight of hand to transition views, but after watching WWDC 2011 session 102 on view controller containment in which they belabor the importance of keeping one's view hierarchy synchronized with the view controller hierarchy, so I don't think that makes sense.
I might be able to make a more meaningful suggestion if I understood your desired user interface. For 99% of apps, they are geared around pushing/popping views, presenting/dismissing modal views, or using some container (e.g. a tab bar container or some custom container) for jumping between sibling views. What is your user interface flow?