I've been asked to help fix a bug for a client, who is an inexperienced developer. However, I'm absolutely stumped by this one.
The problem is that after a string of opening and closing a view controller, which is being pushed onto a navigation controller, all of the subviews will disappear (including the navigation bar items) and show straight through to the window. After this happens, I can still press the buttons on the navigation bar, but they will immediately disappear on touch-up, and restoring a stable UI state is impossible without a quit & relaunch. Another obscure side effect is that after closing the app, Springboard will flash as I swipe between screens. My initial thoughts were that this was a memory issue (e.g. subviews getting released on memory warning), but I have since cleaned all the leaks & checked all the viewDidLoad/viewDidUnload handling of outlets and the problem is still happening. So now I think that with the Springboard effect, that the code is somehow messing up the state of core animation entirely.
Has anyone seen anything like this before? Or have any idea how it would be possible to make this much of a mess? I would attach some screenshots, but trying to take a screenshot with the phone when the app is in this state causes a system crash.
I've not experienced this, but maybe a memory warning is eating some of your views?
I know that iOS is free to unload view controllers that aren't visible.
I'd stick a breakpoint in viewdidunload or similar and see if that triggers.
As it turned out, this bug was caused by a UIView being deallocated while it had a superview.
Related
I'm running into a very strange issue with 3D Touch previewing in my app. As you press into a cell to show a preview, a view seems to grow out of the top left corner, until it's about to show the preview view controller, at which point it's the full size of the view controller.
Here's a video of the behavior
I haven't been able to replicate in any apps I've created from scratch; however, creating a new tableview and view controller in the same app it still does it:
Video
I know this isn't a lot to go on, but I've exhausted my debugging knowledge. I'm not getting auto layout errors, when I debug the view hierarchy the view just isn't there. I'm hoping someone has experienced this and knows how to fix it.
Thanks!
It took me a while to hunt this bug down. Turns out it's caused (in my case) by https://github.com/icanzilb/EasyAnimation. When I remove the library the bug is gone.
Cheers!
Edit: As it happens it's documented here: https://github.com/icanzilb/EasyAnimation/issues/14
I`ve searched a lot about this problem but I didn´t find anything, hoping someone does it, here is my question:
Ive tested the app in the simulator a lot of times. I have ARC and all the outlets released in the viewDidUnload (Ive quite a lot of images). When I run it on the simulator, the memory continues rising again and again, when changing between views.
For example, I have a button in a view. And right clicking it, I drag it to another view, connecting them. Do I need to release anything relating in this way the views? If so, where I put the code? (I have a .h and .m for each view).I have read a lot of questions like this, but all off them referred to views related by code, not using the drag option
(Style - modal)
Please I would thank a lot any clue or help, as I have to solve this problem in a short period of time,
Thanks in advance :)
viewDidUnload is not called anymore starting with iOS6. That might explain what is happening.
Called when the controller’s view is released from memory. (Deprecated in iOS 6.0. Views are no longer purged under low-memory conditions and so this method is never called.)
Furthermore, viewDidUnload was usually called when the view was unloaded due to memory pressure, so you were anyway expected to call it from your dealloc method.
Try doing your niling in dealloc or viewDidDisappear.
You should also be aware, if you use UIImage's imageNamed to load your images, that this method will cache the images. So even when you remove them from your views they remain in the system's cache.
Without seeing your code it is not possible to say more than this.
Run a app with tabs using iOS 5 simulator or device
Bring up a modal dialog
Simulate memory warning (for devices go to some apps that are memory intensive)
Switch to another app (if you have not done so already)
Come back to the app
Dismiss the dialog
You will see a blank screen (the window). Test project to demonstrate this bug / issue: http://github.com/chetanpungaliya/iOS-5-TestModal
I ran into this myself today and can't find any explanation other than it's an iOS 5 bug. After a bit of hacking, I found a workaround. Before you dismiss the modal view controller, change tabBarController.selectedIndex to a different view controller index and then back again.
You can see this in a clone of your project at https://github.com/xjones/iOS-5-TestModal. I also submitted this to you as a pull request.
EDIT: added openradar report
Someone has also posted this on openradar: http://openradar.appspot.com/10529236
I too had the same issue and fixed it. The problem is that the outlets that we connect via xib are set to nil in viewDidUnload method. This method is called on all views that are not currently visible, when memory warning occurs. When we come back to those views, their viewDidLoad method is called again. The only way to fix this is to remove setNil methods from viewDIdUnload to dealloc method and everything will work fine.
I have an iOS app that, in one view, makes a toolbar in code. Nothing fancy here; just a bunch of standard UIBarButtonItems (initialized with initWithImage, and each one invoking a different selector), added (along with spacers) to the toolbar using UIToolbar setItems:animated (with no animation).
This works fine most of the time... but sometimes, after going to another view and back to this one many times, the toolbar's touch-handling appears to be off. It highlights and invokes the wrong button. It's not always the same wrong button, either; sometimes it's one right next to the one I actually tapped, but other times it is further away, even clear over on the other side of the toolbar.
There is no pattern to it, but if you try long enough (switching to another view and then back to this one), it always happens. It seems to happen more often when the other view is at a different screen orientation (forced by its shouldAutorotateToInterfaceOrientation implementation), but even when all views have the same orientation, it still happens now and then. When it happens, my selector gets invoked with a sender that matches the button that was actually highlighted, rather than the one I touched. So it really seems to be a matter of something in iOS not processing the touch correctly.
My google-fu has utterly failed to turn up any other reports of this issue... seems like it must be an Apple bug, since none of my code is involved in the toolbar touch handling. This happens both in the simulator and on the device, under iOS 4.3 (haven't tried other versions yet).
Has anyone else run into this issue? Any suggestions on how to avoid it?
OK, I found the problem. It wasn't the code that creates the toolbar itself; it was where (and how often!) it was being called.
This was legacy code, and we hadn't noticed that the create-the-toolbar code was being called from the view's didRotateFromInterfaceOrientation method (for reasons we can't imagine). That method gets invoked quite frequently, and the old toolbar wasn't being torn down, so it was creating toolbars on top of toolbars. Not too surprising that the touch handling went wonky in that situation.
Deleting the call there (and putting it in viewDidLoad like one would expect) solved the problem. Sorry for wasting everybody's time... but maybe the next person to stumble across screwy toolbar behavior will find this helpful.
I have a program based on UITableView (the user can edit the contents of the cells). After a long time open (mostly in the background) it will sometimes suddenly stop allowing you to fully scroll to the bottom of the list. The scroll is set to bounce, so it will bounce up and you can see the last few rows, but it will bounce right back down and hide them again.
I am using the navigation controller's toolbar, so in some ways it seems like the toolbar hides the last few items, but I think that's not really what's going on. (I think the last item or two would be off the screen anyway.)
Again, there is no problem scrolling most of the time.
It happens so rarely that I haven't been able to get very close to identifying the cause. It seems like it might happen after rotating to landscape mode, but many many rotations can occur without causing the problem. It also seems to show up after my phone has gone well below 10% battery before being recharged (I notice the problem after the battery is back to full, but it could be it starts before that, or that the battery status is totally unrelated).
Since it happens after the program has been running for days (mostly in the background) and is fixed by restarting the phone, I have suspected a memory leak, but I don't get any memory warnings and the program runs normally otherwise, even when the scrolling stops behaving correctly.
I have run Leaks a few times, and only once found a 16 byte leak on exiting the program, which I haven't been able to reproduce.
Any thoughts would be deeply appreciated.
Leaks wouldn't cause such problems by themselves. Sounds like your table gets resized, either automatically with UIViewAutoresizingFlexibleBottomMargin/UIViewAutoresizingFlexibleHeight resizing mask or manually.