At the beginning of my app, I am initializing a UIViewController with a NIB.
At some point, I am removing the view from the screen, then releasing it, so it no longer takes up memory. (At this point I am also saving the state of the view in the UIViewController)
At a later point, I want to recreate the view and bring it back on screen. I will then restore its state. (Using the same UIViewController, not a new one, since it saved the state)
My question, is when I recreate the view, how do I do so from the NIB, or is this not possible?
To me, the obvious remedies are:
Don't save state in the UIViewcontroller (Where does convention dictate that I do save state?)
Don't release the view (maybe just release all of its subviews?)
Don't load my view from a NIB, create programmatically (seems to go against using IB for everything)
Note:
I am not using a UINavigationController, I am handling the swapping of the views myself, since thee are only 2 of them.
If you need that level of control, you dont really want to use IB. Because, as you noted, if remove the view and then later recreate it, you would have to do it in code then anyway. Just design most of the views in IB, then write some code that generates just this view. Then you can call that same method again later to recreate that view when you need it.
You may be able to archive it and later turn it back into an object, but that seems like an inelgant solution. IB does not allow for dynamic creation of controls at runtime, even if they used to exist but don't anymore. There is no shame in leaving IB out of loop for this. In fact it's probably a good idea.
OR
If its a complicated view with a lot of pieces, put the view in it's own nib, and make a view controller for it. Then you can simply instatiate the view controller with the nib name, and add the controllers view as a subview to you main view. Then your view controller handles loading of the nib, and you get to design it in IB. Nothing says the view of a view controller has to take up the entire screen either.
self.otherController = [[OtherController alloc] initWithNibName:#"Other" bundle:nil];
[self.view addSubview:otherController.view];
Don't create the view controller and the view in the same nib file; either create the controller in code or put the view in a separate nib file. If you later nil out your controller's view property, the controller should recreate the view.
But why are you so worried about this? There's already a mechanism to automatically free up the view if you're low on memory: the low memory warning. It will only destroy and recreate the view if you actually need to do so, and it's built in to the system so you don't have to do anything. Remember the saying about premature optimization?
Related
I have created Storyboard with several views calling each other, now I need to create the code
I notice that XCode didn't created .h and .m controller files for each View from storyboard.
Should I create them manually?
Should I keep only one controller? (or few depending of separation of concerns on MVC)
Is there a pattern for developing this?
thanks
The usual approach is one view controller pr. screen full of content. You can imagine having one view controller for a tableview, with any sort of content, and then another view controller that presents that content in a new screen full of content if a row is pressed.
Normally when you have subviews inside of your view controllers, you wire them up in interfacebuilder. Then for instance if you want to populate a view that has a uiimageview and a uiactivityindicatorview inside it, you can control their behavior and how their populated from the view controllers code. You could also if you want something very generic and you feel that one view will probably take up a lot of code in your view controller, create a uiview subclass for it, and then set the class in interface builder.
Did this help? Please let me know if you need more clarification.
It's entirely up to you whether you have a ViewController for each view. If you have many views I would recommend it. Even if you have 2 or 3 views you probably still should. Things can get really confusing when each view has a different task but all have similar IBOutlets.
TLDR; Personally, I would say it was good practice to have a ViewController for each view if each view has a separate task.
Is it possible to reload the main view of a view controller from its XIB file in its viewWillAppear method? The method make significant changes to the view, which would be difficult to reverse. When the view controller gets pushed off the navigation stack, the method has to deal with a changed view. It would be much easier if I could just relax the view from the XIB. It seems that the Apple implementation assumes that the view will remain static, and can therefore be reused.
You can update large portions of your view in the -viewWillAppear. There is no stipulation what you can or can't update there.
Just make sure you account for everything, when you do. I have used -viewWillAppear to refresh my view with information, so you can use that to load an initialize what you need rather than -viewDidLoad.
Suppose I have 2 views. In the first view, I allocate memory to displaying many UI components such as an UILabel, UIImages, etc.
Suppose the user navigates to the next view (via UINavigationController)
Is it OK to deallocate memory assigned to displaying UI components in the first view and then initialize them again once the user goes back to the first view (in viewFirstLoad or the appropriate function)?
It seems to me if you don't do this, then memory will keep on increasing the longer the user uses your app in that particular session.
Is this not allowed? frowned upon? impossible?
It is perfectly normal and in fact, that functionality is built in standard UIViewController - when controller is not displayed its view may be released from memory and you can release all its subviews (e.g. retained through IBOutlet references) in controller's -viewDidUnload method.
When controller needs to display again it reloads its view again.
It depends. Generally, the rule of thumb is that you should free objects that you don't need. If your view is just a view, then yes, I'd release it and all of its subviews. If your view has data that was obtained through a lengthy retrieval process (e.g. a web service call), I'd probably hold onto the data somewhere so that I don't have to go back out and retrieve it when the user goes back to the first view.
To clarify a little: Apple recommends you display data specific to a view in it's -viewDidLoad method, such as setting text on labels. Then, in -viewDidUnload you should release (or nil outlets of) the view objects you setup in -viewDidLoad. It's critical you implement -viewDidLoad, as the base UIViewController code checks that it's subclass actually implements -viewDidLoad before it assumes it can unload the view (and therefore call -viewDidUnload). Failing to implement -viewDidLoad results in the controller thinking it can't recreate your view at a later time, and so it doesn't unload the view from memory. A developer I know experienced this same problem, took forever to track down.
I'm making a custom UIViewController, which is similar to a UITabBarController, as there are some buttons which switch between views. However I'm unsure whats the best way to switch the views:
Have a UIView in the nib file, and add/remove the viewController's views as subviews, as they are needed.
Have a UIView in the nib file (as an IBOutlet), and replace the UIView with the viewController's view so that they are subviews of the myTabBarController's view directly.
Don't have a UIView in the nib, and programmatically set the frame of the viewControllers as they are added, so they are subviews of the myTabBarController's view directly
I had to do something similar once, and in my case it was simpler to have my master
"switching" view (for lack of a better term) maintain a list of UIViewControllers. That way, I was able to maintain the state of the child view controllers even when the corresponding view was not visible or had even been destroyed (to save memory, for example), which made it simpler to keep track of the info on each "page". In my approach, I simply programmatically added each UIViewController to the switch view. Basically your approach #3.
That said, there's nothing wrong with your approaches #1 and #2. They'll do the job. The only thing I don't particularly like about #1 is that it doesn't scale as easily, since you've statically set which views are the children of your switcher at compile time, and cannot easily change that at runtime.
I'm using this approach from Red Artisan's Marcus Crafter. It works remarkably well.
My main view controller (representing the Main Menu in my app) has a simple UIView with a few sub views. I am using a modal-type design pattern and switch to multiple other view controllers before finally returning to the main menu. The problem is, in my other view controllers (not the main menu one), I often load data-heavy images and the like which sometimes causes the main menu (which is not currently on-screen) to unload its view to in response to memory warnings. The problem is, when I ultimately switch back to my main menu, the screen is all black and all but a few UILabels have been dispensed of. At this point, I would like to re-load my view and start fresh. But in the documentation, it says that you should never call -loadView directly. How can I re-load my view?
In this situation, check the isViewLoaded property — it should be returning NO. If the view has been unloaded correctly, isViewLoaded will return NO and calling view on your view controller will automatically load in the view again.
Check your custom view unloading code — you should be removing everything from the view hierarchy ([[self view] removeFromSuperview]) that belongs to you.
If you haven't got any unloading code, make sure you're not over-retaining some of your views, which will cause problems when unloading.