I have a storyboard with 6 View Controllers and their respective views. I do NOT have any navigation controllers associated with these 6 View Controllers.
To go from one view controller to another, the swipe gesture recognizer is used alongside a modal segue. All view controllers have alteast 1, and sometimes even two swipe gesture based modal segues to other view controllers.
My question is, do I need to worry about memory? When I swipe are these viewcontrollers going to be infinitely added to memory eventually causing the app to crash?
An example could be: Say I am in the first VC and I swipe Right to the second VC, then swipe once again to Right to Third VC, then swipe left twice to get back to the First VC will the memory contain this:
Memory: First VC, Second VC, Third VC, Another Copy of Second VC, Another copy of First VC?
I know it seems like a stupid question but since I have only started programming a couple days ago I am very worried I will be having memory issues.
I would appreciate your thoughts and any potentially helpful links to places that dicusses this issue.
you have a good question and it depends on how you are creating and dismissing your view controllers. Normally a design like you mentioned would be built using a built in controller like UINavigationController or UIPageViewController or maybe using a scrollview.
If you are "presenting" new view controllers, then you need to dismiss to remove them. If your not dismissing, then you view controllers will stick around.
If you are using segue's, remember that each segue creates a new instance.
If your logic generally says - swipe right: new modal segue, swipe left: dismiss, then you will be cleaning up as you go. This works if its ok that each right swipe creates a new instance.
If you need the six view controllers to stay in memory all the time, you may want to look at using a pageViewController or roll you own solution. I have seen some nice solutions like you describe using a scroll view.
If you wanted to use a scroll view, basically you would crete an array, load the array with the six instances of your view controllers, then load the scroll view for horizontal scrolling. Add the gesture recognizers and logic for left/right swipes and you have a nice horizontal page scroller.
Here is a very nice reference and tutorial that seems to solve the solution you are describing. http://www.wannabegeek.com/?p=168
good luck and happy new year.
As long as you dont keep strong references to the view (or its subviews, like buttons...), they will be deallocated if needed.
Related
I'm planning a game app where a series of views are presented, one after the other, sequentially, in a loop.
I'm having a hard time figuring out the segue I should use for this (using the storyboard). It seems to me, that using the 'show' segue will result in a stack of views. In my app, you never go back from where you came, so does that mean that I could end up with dozens of views, one on top of each other?
Is there a way so that once you go into a segue, one view replaces the previous view?
Unfortunately you are not going to be able to do this with Storyboard segues as the "Replace" segue is only for SplitViewController (which sounds like wouldn't be right for what you are trying to do). Instead handle transitions through code. Have a base navigation controller and keep setting the new view controllers as the navigation controller's root view controller
My apps "short" description:
Basically an interactive storybook, I have a class that sets up a audio session and audio player which every other class(ViewControllers) in my app imports and calls a function or two to set the right sound to be played each time something happens(for instance.. user reads the story). Each ViewController has it's own .m and .h classes and uses them for animations and action handling. My app is only about 60 mb's in size (audio/images/code).
Now these ViewControllers are set up in a storyboard (they are 13 now) and are modal segued from one to the next one and then programmatically dismissed to go back.
When I run my app on my iPad now, I'm starting to get memory warnings and yes Instruments is showing me that my app is adding roughly about 40 Mb's for every ViewController that I segue to.
My questions are:
Do they reside in real memory no matter what I do? (I thought I wasn't holding any strong pointers to these view controllers).
Is there an easy way for me to dismiss one controller and still use a modal segue to get to the next one?(ran into troubles trying this)
Modal Segues are probably not the way I should be doing things in my App are they?!. They looked so nice and easy for my "storybook", but now they are giving me a very rough time.
Any other tips you can give me from what I described are appreciated.
Thank you.
Yes, as long as you present it modally. The presenter view controller keeps a strong pointer to the presented view controller. What you could do here is in the viewWillDisappear: release all the images and other views that might use memory !
You could instantiate your view controller using the method instantiateViewControllerWithIdentifier: and then presentViewController:animated:completion: like you would do with any view controller
It's up to you to decide. But you could easily mimic the animation if you wanted to.
If I understood everything correctly I would go with a singleton class kinda like 'AudioEngine' which is accessible from anywhere in any class. Then I would design all my viewcontrollers in my storyboard like you did. When I need to present modally another view controller, I'll do it using the answer of your 2nd question. If I still had a memory issue, I would try to cheat and keeps always 3 view controllers (like we do with the UIScrollView's infinite scroll) that I would reuse and I'll mimic the modal presentation using UIView's animation blocks.
I have two subviews that load. One is a tabbar thats inside a viewcontroller which gets loaded fairly early on and the second is a view that appears when a tab bar item is pressed.
however when this subview is added it loads over the tabbar subview.. is there a way to bring to front or something along those lines?
There is a whole plethora of methods to choose from...see the section Managing the View Hierarchy in the UIView docs
The root question is "how many UIViewControllers can you push on the navigation stack?" without causing memory warnings or earning a watchdog termination.
Suppose I have an application that is basically a database for three entities where each can have a relationship with some other entity, and the relationship is shown on a UIViewController. Users can follow those relationships and each one brings up a new controller - If the entities are A, B and C and A->B->C->B->C->A then each kind of view is on the stack twice. I understand how to push and pop, how to push back to a particular controller, and I think rather than just extend the navigation stack indefinitely it might be best to reuse a view controller in the navigation stack.
To do this, every time I wanted a FirstEntityViewController I could scan the navigation stack to find an object where [self isKindOfClass:[FirstEntityViewController class]]; and then call methods designed to rejig that view for what I currently want to see - just refreshing the data in the same way you do when reusing a UITableViewCell.
This is fine except for the effect it might have on the NavigationController. If I use UINavigationController:popToViewController:animated: I think it is going to discard everything above the view I'm popping to, including the view which the user expects to find on tapping "Back" in the navigation bar. So user taps a relationship, taps back and goes "huh?"
If I remove the matching controller from the navigation stack and then pop it on to the top of the stack the back behavior remains OK as long as the user doesn't go back as far as the instance of FirstEntityViewController that was moved or else again navigation will seem inconsistent.
Is the right solution to remove the controller from the stack, and somehow hold a place in the stack so that when the reused controller is popped it can be replaced back where it came from? Should I maintain my own list of view kind and data display so that when popping I can replace the view below the view about to pop to, staying one step ahead of back navigation?
Or is that just getting too complicated? Is there no need to even worry about this situation because the OS reuses much of the view controllers in the same way as UITableViewCells are reused, and there is no real memory or performance impact in having a 50-deep navigation stack?
ViewController instances remain in the UINavigationController's stack, but any view except for the top view may be unloaded at any time (the view controller is notified via the viewDidUnload message).
In other words, the views underneath the top view do not hang around and will eventually be unloaded in low-memory conditions, so there's no need for you to attempt to re-use your view controllers.
Last I checked you can't push a viewcontroller that's already on a navcontroller stack back onto it again. You'll have to create a fresh viewcontroller and push it onto the stack and each back button will pop that one off the stack. The best you can do is make a cache of viewcontrollers and dole them out as-needed -- as long as they're popped off the navcontroller stack. But it probably won't buy you much by way of memory savings.
UITableViews are a bit different in that there's only a relatively small number of cells in view at any given time and as soon as the cell goes offscreen it's removed and returned back into the pool. If you can guarantee that the maxdepth of your chain is fixed, then you can pull a similar windowing scheme. If not, you may have to stick with going deep and be vigilant about releasing memory as soon as you can.
I've involved myself so much in NavigationControllers that I've become kinda ignorant with other options.
Here's what I want to accomplish, I've built Subclassed ViewControllers to Push via NavigationController that works pretty fine.
However, to avoid the Idea of going back and getting to a new view doesn't fit for quick access since this is about calculator, I came up with using SegmentedControl.
I added UISegmentControl to the NavigationBar.
What I want to accomplish, is on tapping of a segment, The Calculator1ViewController Loads below the NavigationBar. And on tapping another Segment, the previous ViewController is unloaded and a different "Calculator2ViewController" is loaded.
I'm not quite sure how to do it, loadFromNib may not work too well, because I'm using custom ViewControllers.
Any suggestions would be great help.
You might be better off making it a single view controller, and just swapping out the views.