I have an iPad SplitViewController application with the following features:
master (left hand) view controller is hidden in both portrait and landscape by returning YES in the shouldHideViewController delegate method
master view controller contains a tab bar controller
I utilise a multiple master detail manager to manage swapping the detail view controller based upon the selection made by the user in the master tab bar
I have a problem that only occurs after a memory warning is received by the application. When the master view slides in (either via a swipe or tapping the left bar button) the view appears effectively empty i.e. it does not contain any table view, just the semi-transparent background where the table view should be. If I tap the other view in my tab bar it loads it's master view correctly. If I then tap back to the problem view it now appears correctly.
Originally I had another problem in that not only was the view empty but it was also sized for full screen. I was able to fix the size problem via the solution proposed in this SO question - it is noted in the solution that "Apparently when a memory warning is received, the view controller gets released, so when it presents itself again, it gets it's size from it's parent view, which is full screen. So you just have to reset the frame every time it gets loaded."
By putting break points in my code I can verify that when I first try to access the master view after a memory warning the ViewDidLoad event is called (this does not occur if there has not been a memory warning), however the ViewDidAppear & ViewWillAppear events are not called. So the app is aware that it needs to reload the master view after a memory warning, but for some reason it does not seem to show the master view.
I'm struggling to work out how to correctly make the view appear again after a memory warning. Or is there something I should be doing to prevent the master view from being unloaded when a memory warning is received?
UPDATE: I have also observed that if the master view is showing at the time of the memory warning then this problem does not occur.
I raised this issue with Apple technical support. Their reply was as follows:
A search of radar shows that this is a known problem in iOS 5.1 and
that engineering is aware of it. At the moment there does not seem to be
a workaround for this problem other than making sure that you don't
get memory warnings.
If you'd like you can file an additional bug at:
http://bugreporter.apple.com/. Additionally I'd suggest that you try
this and see if it is still an issue in iOS 6. If it is please file a
bug and send me the radar number so that I can keep track of it.
I did as they suggested and tried it out in iOS 6. I found that the problem did not occur and therefore seems to be fixed in iOS 6. Apple did not offer a solution for iOS 5.1.
Related
I've noticed that as I navigate across my iOS app memory stack grows with each opened viewController.
My navigation is based on segues and I do self.dismiss() before performing each segue. Still, it looks like viewControllers stack in memory.
How can I avoid this?
In Android finish() kills the Activity (in most cases), so I need an alternative in the iOs.
The memory issue can have several causes and not necessarily a UIViewController. In order to find and solve the issue you have to reduce the scope of the issue from "app" to a certain screen or even class. Then you can check the code and try to figure out where's the suspicious code.
Solving this issue is not a straight up task and there's no "how to fix memory issue for my app" tutorial, you'll have to check your code and compare with potential causes of memory leaks.
Also you'll have to be careful for false positives of memory leaks. Here are some steps I follow when I suspect a memory issue.
Navigate trough the app "till the end", then go back to "home screen", if the memory drops, all good.
If the memory doesn't drop, I do the same navigation several times, if the memory increases with the same step (more or less but close) then there's an issue. If the memory doesn't increase (maybe just a bit, several kb) then it's ok, it means there are some assets cached in memory (images, files, etc). But you will need a way to test this scenario too.
Now we are back to the "memory increased again almost the same as first time", now I do a clean run, and take each screen at a time, I just open the screen go back (dismiss/pop the controller) and observe, if the memory drops then that's not the screen that leaks. When I find the screen that increases the memory and never goes back:
check if the controller is passed as a reference to other objects that won't be deallocated (singleton classes or other, depends on the app).
check if the controller is sent as "delegate" to any other classes and if those delegates are correctly defined (strong delegates are a biiiiig issue).
if all of the above are ok, then I'll simply comment all the code that performs any work and try again. If commenting the code doesn't drop the memory(this happens rarely) then the screen is not the right one.
if the memory drops after commenting the code, I start de-commenting bits of the code and run again, until you'll find the piece of code that creates you issues.
One thing to keep in mind, you have to be patient while investigating memory issues, and to be honest, sometimes you have to be lucky too.
Per documentation on UIViewController.dismiss:
Dismisses the view controller that was presented modally by the view controller.
So calling this would dismiss any view controller shown modally. Based on your question, I have to assume that your segues are push segues and not modal, otherwise you'd be seeing your view controllers disappear.
Your 'view controller stack' might be with regards to the navigation stack on a UINavigationController. If so, then those view controllers remain in memory, as when a view controller is popped off the stack (ie: user swipes from left edge of screen, or hits "Back" in the nav bar), the previous view controller appears.
Without more information on how you're presenting your view controllers or building your navigation, I don't think you'll be able to get more answers.
I'm facing a very weird bug. I have a button and I'm pushing a view controller normally, using segues. However, when I push the view controller the whole app layout messes up: it sometimes works, sometimes glitches such as leaving me with a blank view with nothing but the tabbar, or previous view controller still being seen but transformed to somewhere else in the screen etc. If I manage to go back, it always works fine after the first try. Here are some observations:
Problem is specific to device (iPhone X). Simulator (even the same model and same OS version) works perfectly.
Switching to modal doesn't matter. The "glitchy look" animates a bit different, but the problem is still there.
Turning off animation in transition doesn't matter. It presents me a glitchy screen instantly, just without animation.
Pushing/presenting the view controller from code (as opposed to storyboard segue) doesn't matter. Exactly same.
Giving a delay (e.g. half second) after tapping the button before presenting the view controller doesn't change anything. Just wanted to try this to see if some race condition is present on tap, for whatever reason.
The problem is specific to one view controller. Presenting anything else at the same segue/state doesn't cause any problem.
The problematic view controller doesn't have anything special at all: It's actually just a wrapper with three child view controllers, something I commonly do:
When I'm trying to present the problematic controller, I'm always getting this weird log: [Render] CoreAnimation: failed to allocate 1223558576 bytes
My application is definitely not out of memory. It's using ~50MB on iPhone X at the time of problem. It's a media app and can allocate ~500MB with no issues or crashes when shooting/filtering video etc.
The problem occurs if a specific embedded view controller (the second one of three) is present. For example, if I remove the embed segue to that, it seems to run perfectly.
That embedded view controller is a simple UIViewController subclass that just has a table view and some cells.
What might be going on?
I've been dealing with this (somewhat) random bug for a while and can't figure out the problem. The context: I'm creating an UISplitView iPad app that have a UINavigationController inside the Master view:
Main menu in red, submenu in green and main content in purple.
This UINavigationController does not fill the entire Master view because I need some space to have a vertical menu. When a user select a button on the vertical side menu, it sets something new to the UINavigationController to show a UITableView with options. What I'm doing on every menu selection is:
[self.subMenu setViewControllers:#[subMenuViewController] animated:YES];
What happens is that I don't need to keep the menu history, so what I do is I set a new root view controller to the subMenu every time.
The issue is when I start messing with the device orientation. It doesn't have a clear pattern, but sometimes, when rotating, my app crashes. Now when I run it with Instruments, this is what I get:
167 Zombie -1 00:32.101.527 UIKit -[UITableView _spacingForExtraSeparators]
And the interesting thing is that the bad access happens on the previous root view controller of the subMenu. So if I tap "Events" and then after that I tap "Podcasts", the bad access happens on trying to access "EventsViewController".
So I'm guessing something is not right on my way of replacing the root view controller of the subMenu UINavigationController, but I'm not sure what it is. Maybe I need to make sure the current root view controller is released before setting a new one?
Any help is much appreciated. :)
It's not uncommon to crash in system library code due to something you didn't set up quite right. This might be that your UIWindow, UIApplicationMain or its content view or your view controller instance was not retained or got released somehow.
That shouldrotate method won't help if your controller isn't still around.
This is to identify which object got released.
For particularly thorny problems, you could add release, retain, and dealloc methods (that log and call super) to a suspect class of yours and see what's releasing it. Log the -retaincount to keep track (I only use this for diagnostic purposes,)
Or you can try this, set a breakpoint on -[UIDevice setOrientation:] and step through your code in the debugger.
To make debugging easier, you can type call (void)instrumentObjcMessageSends(YES) right in the debugger console to begin logging objc_msgSends to /tmp/, then continue execution and it will trace all the messages that are sent right up until the crash.
So first, you should implement the methods willRotateToInterfaceOrientation, willAnimateToInterfaceOrientation and didRotateToInterfaceOrientation (check the actual signature of these methods) in your view controllers that contain a UITableView.
In each of these methods check the your table view dataSource and delegate. I think this crash is caused by a release of the delegate or table view's datasource.
Also you should check what table view delgate/datasource methods are called during rotation.
And the last thing, make sure you discard the old instances of subMenuViewController and they are properly removed from the parent view controller.
I'm making an interactive book for the iPad and am using UINavigationController to implement the navigation between a page and the next. When a user turns the page, the next page is pushed on top of the navigation stack.
I'm now 15 pages into the app, and the app crashes when I try to go from page 14 to page 15. No error message in the console, nothing in the device's crash logs neither.
Each view controller's scene in the storyboard has UIImageViews displaying images that are between 5MB and 20MB. The view controllers' viewDidLoad method is called just once. The total size of all the app's assets is below 200B. I'm using ARC.
I've ran the app using Instruments' Memory Monitor. The app's Real Memory consumption increases by about 80MB every time a new page is turned, and crashes when it reaches 800MB (the device is an iPad 3).
Why such an enormous memory consumption? Is this because the UIImageView in the Storyboard's scenes cache the images?
What would be the best way to free up memory when you use a
UINavigationController and ARC?
I tried adding setting all the view controller's subviews to nil in the view controllers' viewDidDisappear: method, but memory consumption stayed the same.
When you use a UINavigationController, each ViewController you push stays in memory forever (well, until your app exits) unless your user presses the back button on that particular ViewController. It keeps a stack of ViewControllers - with the visible one at the top.
So the simple answer is don't use a UINavigationController for this.
I'd suggest building your own ViewController that 'knows' which is the next and previous pages and manually loads and removes them as and when required. This way you can ensure that you only have one page in memory at once (except for during the transitions - maybe you could use this animation for the transitions http://cocoacontrols.com/platforms/ios/controls/xbpagecurl).
You probably don't want to use a UINavigationController for this purpose. You really want one view controller to manage all your pages and render the new page on the same view while removing the old.
How do I make a curled-up view update live as the user interacts with view being presented with presentModalViewController: under it?
The behaviour I want:
User taps a view settings button.
User taps controls in the view settings screen. Rather than dismissing view settings, the view automatically updates in the background.
User taps something to dismiss view settings.
Imagine if in Maps tapping Map, Satellite, Hybrid didn't uncurl automatically but just updated the display.
I'm able to get notification that something's changed from the settings controller back to the main view controller. The main view controller can update and signal that it should redraw parts of itself, but actually updating the screen is intermittent. It will work 5 times in a row, then not work a couple times, then work another 5 times in a row. Dismissing the modal view always catches up the view underneath, however, so I assume the rendered image of my view is sometimes being cached or not being redrawn despite my request. But I can't think of a way to verify this.
This happens on both the device and the simulator.
While there might be multiple root causes of this behavior, here's a common issue I've seen that causes 'delayed' or 'intermittent' updates to UIKit views.
If the statements that update your presenting view (or the presented view) are running in a dispatch queue other than the main queue, UIKit may produce inconsistent results and timing in the actual UI update. You can usually tell by putting a breakpoint on the statements that update the UI and examining the name of the 'queue' displayed in Xcode's left-side debugger view. It should be 'com.apple.main-thread'. If it's not, that could be your issue. This can happen in quite a few delegate methods such as the network APIs.
Try wrapping your UI updates in:
dispatch_async(dispatch_get_main_queue(), ^() { ... }); and see if that helps! You should only do this when needed and take care to use block-safe techniques as always.
I tested this in a brand new Universal app for iOS 7.0.3 using the iPad simulator with a view controller presented using the partial curl transition. I was able to replicate the original issue, including the intermittent update and the 'snap' update when dismissing the presented view by using a background queue in the code I provided above. Once I switched to the main queue, everything worked A-OK.
Let me know if this helps or if there was some other issue :)