I have an odd UI bug I am tracking down, where my UI in a particular UIViewController subclass shows up mostly ok and then animates itself to be totally ok.
I have tracked down where the "shift" is occurring, but have not yet completely solved the issue. While attempting to track down and fix the bug, I had a very, very odd thing happen.
I set and hit a breakpoint in -(void)viewDidAppear:(BOOL)animated for the UIViewController in question. When the breakpoint was hit, the UI on the attached phone was wrong. Then, while still on the breakpoint, without me taking any action, the UI performed the "shift" to correct the out-of-position frames.
How is this possible? Shouldn't -(void)viewDidAppear:(BOOL)animated fire on the main/UI thread? If so, how is any adjustment being made to the UI while paused?
Related
I'm having an annoying issue with a custom transition using UIViewControllerContextTransitioning when triggering the animation from a tableView
I followed many tutorials out there, to name a few :
- http://www.brightec.co.uk/blog/ios-7-custom-view-controller-transitions-and-rotation-making-it-all-work
- http://objectivetoast.com/2014/03/17/custom-transitions-on-ios/
This is the exact problem I have (but no solution :/ ): Custom transition animation unknown delay between animationControllerForPresentedController and animateTransition
Sometimes it works, sometimes it's just to slow.
I don't know what happens behind the scenes between animationControllerForPresentedController and animateTransition. If you have an idea on how to debug that I'd like to hear it.
Even without seeing your code I'm pretty sure you having a main thread issue. (see http://www.raywenderlich.com/31166/25-ios-app-performance-tips-tricks#mainthread - understand that, both about not blocking the main thread and always doing UI on the main thread.
I have a strange issue both on mobile device and in simulator.
After a while spent in the application, animations on UIView are disabled (like if animated was set to NO), notably on :
pushViewController in a UINavigationController (also true for popTo)
displaying a UIActionSheet
switching between views with IIDeckViewController
This is quite strange as all transition are usually animated, and in a non predictable way, they all become non-animated
Everything was working well a few days agos, and as far as I can remind, I did not make any changes that should lead to such a behavior.
Any ideas ?
Thanks
Cheers
We recently had some trouble like this, the culprit was initiating some animations from a non-main thread (perhaps you are initiating a transition). This caused some trouble with animations transactions getting rolled back and this broke animations until the transaction was rolled back. There were some entries on the console pointing to CA transactions. Setting CA_DEBUG_TRANSACTIONS=1 on the environment quickly revealed the stack of where the the transactions were started.
The fix was to not do anything that would create transactions from a non-main thread.
I'm having an issue where my app is crashing on sleep, and sometimes on home. I'm getting a BAD_ACCESS error in a thread called gpus_ReturnNotPermittedKillClient, which tells me that my app is making UI changes in the background, which to my understanding is a no-go. Therefore, I'm stepping through my code to see what happens on home / sleep, and I find that my breakpoint in my VC's -viewWillLayoutSubviews method is getting hit AFTER the breakpoints in the -applicationWillResignActive and -appplicationDidEnterBackground notifications (in which I'm attempting to stop all updates from an asynchronous callback function).
That doesn't seem to make any sense. From the application's perspective, if it's not cool to do UI updates in the background, why call viewWillLayoutSubviews after you're in the background?
EDIT: It appears to do this even when my app doesn't crash. Could it just be lldb getting things out of order?
I think you simply need to be tolerant of this. Per this tech note, you can't do any GLES rendering in the background. My recommendation would be for your app to set a flag when applicationWillResignActive is called, and then before doing any rendering work you check that flag and don't do the work (and perhaps just call -setNeedsDisplay on the view so that if your app becomes active again it will know to draw that view). You seem troubled by the fact that viewWillLayoutSubviews is getting called "late", but I don't see how that really matters. (i.e. layout != rendering) I would be surprised if your view's -drawRect: method were getting called after applicationDidEnterBackground but I would still say that it would be your responsibility to check a flag and not render if your app is in the background.
My app runs fine in iOS6, but in an unspecified upcoming version of iOS that I cannot name for NDA reasons, all UIViewController transition animations stop working. New views just pop into place instantly. I am not sure if this unspecified future version of iOS is the cause, as I've seen this happen occasionally in iOS6.
Sometimes animations start working for a while and then stop shortly after, making me think it's some sort of memory warning issue, but my app is using a fairly reasonable ~125MB of RAM at most times. Can anyone offer any advice or things to investigate?
The described behavior has always existed: if you do work on background threads and then call and UIKit methods then more often than not the update will be delayed in a weird way.
Because of this you should always dispatch_async onto the main queue to update the UI.
Those bugs are very hard to catch since they do not always occur predictably.
To catch them I built a method that swizzles some UIKit methods to check if they are called on the main thread. This allows you to stop on a symbolic breakpoint, whenever you have forgotten to dispatch back onto main queue.
https://github.com/Cocoanetics/DTFoundation/blob/develop/Core/Source/iOS/Debug/UIView%2BDTDebug.m
A good workaround from the Apple dev forums on this issue:
Do this:
[UIView setAnimationsEnabled:YES]
And animations start working again. I suspect that this is either a straight up iOS7 bug, or somewhere in my code an animation or UIViewController launch is happening on a background thread, causing animations to stop. Probably unrelated to the unspecified future version of iOS.
This issue appears to be caused by doing UIKit stuff in background threads. I have a pre-render cache full of NSOperations that renders complex UIViews to UIImages to cache the output. This seemed to work fine in iOS6, but probably does cross the line somewhat. I'll need to replace this functionality with something that renders images and text to a graphics buffer rather than using UIViews and UILabels at all.
All you have to do is catch hold of main queue while updating UI on receiving response from an API.Ios uses main queue by default for updating UI but it is not 100 percent efficient.Hence you have to make sure that the UI gets updated on main thread only and the way to do that is as below:
DispatchQueue.main.async{
//UI related code eg:
self.label.text = "abc"
self.button.setTitle("xyz",.normal)
self.tableView.reloadData()
}
If you are not catching hold of main thread animations may or may not work.
But if you are using main thread animations will definetely work.
Correct Code while updating UI on api response:
Alamofire.getApiCall(paramaters: parameters, completion:{
response in
// UI related code.
DispatchQueue.main.async{
self.label.text = "abc"
self.button.setTitle("xyz",.normal)
self.tableView.reloadData()
}
})
Incorrect Code which may cause animations to stop and lead to weird crashes:
Alamofire.getApiCall(paramaters: parameters, completion:{
response in
// UI related code.
self.label.text = "abc"
self.button.setTitle("xyz",.normal)
self.tableView.reloadData()
})
I've seen some other solutions, but none of them are working for me.
My app is suddenly returning to a black screen after I use the home button to leave and then return to the program. It briefly shows the screen and then goes black.
There's nothing inside my appDelegate methods related to foreground and background, and I don't know if there's another bit of code that I should be looking for to solve this issue.
What can cause this to happen?
update:
Upon re-entering the foreground I've checked to make sure that all of the views, subviews, layers and sublayers still exist. Calling setNeedsDisplay to all of them from the WillEnterForeground notification does no good.
Looking at the notifications sent out, there is one called
_UIWindowWillDestroyWindowContextNotification
which looks menacing, but I can't find any information about that.
Any pointers about where to look are much appreciated, I've tried everything that seems possibly relevant. Thanks!!
The most probable cause is you're doing something on the main thread. When the app goes black just click pause on the debugger and check the main thread. If you're not doing something on the main thread please tell us what is your app doing when you click pause.