I am currently testing my app, and when I switch tab views I notice that my allocation of memory goes up, and stays up. From this I have to assume it has to do with loading new information from the new view and not unloading the old view. So essentially I have two views loaded. I would liked to know how I can remove the prior view from memory, or if that is even necessary. I am currently running at about 50mb of allocation (yeh it is a small app). I don't have any leaks.
Also, I created my tabview by "embedding" my existing views in one, so I don't have any code currently to support it.
#rdelmar speaks truth. A tab bar controller keeps the child view controllers in it's tabs for the life of the tab bar controller.
A view controllers views don't get loaded until the first time it is displayed. The views can use a substantial amount of memory.
All that is perfectly normal, and you should not try to change it.
Related
I have a TabBarView and I noticed that when I'm changing views the memory that it has remains and the new view memory add it to to old.
I've tried to reduce it (the memory in every view) by changing all my variables to lazy and it worked for each view separately and now I don't have very high as I had to energy impact section. But the problem with views still remains (I get memory warning after a little navigation to the views)
I have 4 tabs:
First with tableView
Second with collectionView
Third with a Map
And The last one 3 collectionViews
From my search I understood that I have to do something with viewDidDisappear or Unload
I am subclassing UIApplication to intercept and display touches in my TouchDisplay view. I would like to extend the Application, Window, Delegate or Main ViewController in order to keep my TouchDisplay view on top of all other views. As my and most other applications work, views and controllers are added and removed all the time. I figure the correct answer will be able to deal with these additions and removals and stil keep the TouchDisplay view on top.
Thanks for your help,
Joe
Here are a few approaches you could take for this:
If you're targeting iOS 5+ and iPad only, you can make a top-level view controller which has two contained view controllers. The first would be a view controller for your "TouchDisplay" view. The second would be the application's normal root view controller. (i.e. your existing main view controller; you'll need to set definesPresentationContext to YES on this view controller) Since you're writing the container view controller, you can order those two subviews however you like. There is a WWDC 2011 Talk on view controller containment that goes into great detail about this. This is the most "correct" approach IMHO, because it gives you a view controller for your TouchDisplay view, handles rotation and generally plays nice with others. (This only works on iPad, because on iPhone a new modal view always covers the full screen.)
A more straight-forward approach is to simply add your TouchView to your existing top-level UIWindow as a subview with addSubview:. Most applications don't actually remove the top-level view controller or add new top-level ones; they just present other view controllers from it. A view you add in the top-level window will stay above those. Of course, your app may not follow this rule, in which case you might try option #3 instead. This has rotation gotchas (your view will not auto-rotate when the device rotates, so you need to do this yourself.) You could also force your view back to top, say, on a 1-second timer, if you are having issues with other things covering it. This is also not as nice as option #1 because you don't get a UIViewController, just a UIView.
The most extreme approach is that you can create another UIWindow and give it a higher window level, such as UIWindowLevelAlert and put your TouchDisplay view in that. You can then make the window background transparent, and it will stay above your normal app content. There are lots of gotchas here, especially about auto-rotation and which window is the keyWindow (which is why you should use #1 or #2 instead if you can).
After some time I was able to get my app working. I have made an easy to use overlay that shows touch feedback over your existing application.
You can download the project here:
https://github.com/megaplow/FingerTracks/tree/master/FingerTracks
Happy coding,
Joe
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 am pushing and popping from one view to the other within my App. The view is being retained in the memory so when you hit the "Back" button after pushing a view, the same screen that was before you pushed the view is retained.
For some reason, I will need to reload the parent view after popping from a child view. I need to display different content based on the actions the user taken when they were redirected to the child view.
I am using UINavigationController to navigate from one view to the other. I need it so I can easily go back and forth within the different views of the App.
The correct way to do this would be to perform your actions in viewDidAppear. Initialisation code that you write in viewDidLoad is called only once. But in viewDidAppear you can refresh your view's content every time the view is added to the window. The controller is retained in the memory for performance reasons. Removing it would hamper that factor.
Here is a stack overflow post that explains the different view* callbacks in good detail.
I am trying to have the ability to switch views in and out. The screens are generated on the fly and there may be anywhere from 30-100 of them that will be presented sequentially. A NavigationController may work, but I may be creating a hundred or so screens so I am worried it will run out of memory if I push that many views. Maybe this could work if I only ever added one screen at a time to the NavigationController, and when a new one is added remove all screens and then add the new one. But this may cause strange animations.
I tried creating a custom View Switcher that could load each of the views on the fly following the chapter 6 example in the apress book. The problem is that on rotations the events do not make it to the View Controller for the currently visible view. So it ends up doing weird things on screen rotations.
Another approach that I am thinking may work is to use a tab bar controller and make the tabs invisible. Then I can just use tabs 1 and 2 to hold the current view, and the last view and ping pong back and forth. Then memory is not as much of an issue as using a NavigationController.
Does anyone have any other ideas? I feel like there should be an easier way to do this that I am just not seeing.
How about creating a singleton "ScreenManager" that loads, adds and removes your views on your root view controller? This way you can make sure that the view hierarchy isn't convoluted and out of your control. It's also a good idea design-wise and should be very easy and efficient with memory management.