What may cause all UIView animations to finish instantly? - objective-c

I have an iOS app where I use a lot of UIView animations. They'll all work perfectly for a very long time, then suddenly all animations finish instantly instead of using the specified duration. No errors and the app still functions, but the animations don't work properly.
The app will do a lot of downloading small graphic files in the background then call a selector on the main thread to present the graphics.
Does anyone know what may cause this kind of behavior?

I know it's not okay to handle UIKit in backgrounnd threads but thought it was limited to all drawing, like adding subviews etc. It seems creating and changing views (without adding them as subviews) is not okay either. My problem in particular was creating UIImageViews in a background thread. I changed the code to load into UIImages and create the UIImageViews in the presentation code, which is run in the main thread and now it's completely stable.

Related

iCarousel disables any other animation done in the background

I am using Nick Lockwood's iCarousel to display images, and I need to make a transition between backgrounds behind the carousel when the carousel stops at an image.
I am using UIView's animateWithDuration, and the problem is that the animation completion happens instantly because iCarousel is calling [CATransaction setDisableActions:YES];
I deleted the call to disableAnimation and enableAnimation in Step method of iCarousel, and now my transition animation works fine, but I'm afraid some functionality will be missing or strange bugs will occur now.
can anybody concur or suggest a different approach for this?
The [CATransaction setDisableActions:YES] is partly for Mac support and partly to prevent weird resizing effects when item views are loaded. If you aren't seeing any problems then it's probably safe to disable those lines, but you're generally better off not modifying the library if you don't have to as it makes it more difficult to upgrade to a new release later.
When are you triggering your animation? If you only want it to happen when the carousel comes to a stop, the correct place to do it is probably in the
- (void)carouselDidEndScrollingAnimation:(iCarousel *)carousel;
Delegate method. If you do it there you shouldn't have problems with the animation being stopped. If you are already doing it there, and you are still seeing problems then a workaround is to delay your animation until the next runloop update, which you can do using GCD, like this:
dispatch_async(dispatch_get_main_queue(), ^{
//perform your animation code
});

Can I build UIView elements on a separate thread?

I have an app that has to load and render a fair amount of content onto screen (mostly loading from a database).
I won't post all the code here but in effect it simply builds up a set of UIView objects that are added to a UIScrollView object. Nothing too complicated, just loaded quite a lot of stuff. This currently takes a second or so render everything (running on the main thread).
I want to show an activity indicator whilst the loading is happening, and I think the best way to do this is to have the method that takes a long time happen on a background thread and "report back" when it is complete.
The question is this. I know all the actual drawing is done by the main thread, so is it possible to create a new thread and have that build up a set of UIView objects that are then drawn on screen?
there is a great WWDC2012 session video, that deals exactly with your use case:
WWDC2012 Building Concurrent User Interfaces in iOS
Basically the trick is to prepare and draw the views on another queue and ship it over to the main queue.
You are correct. All the UI work should be done on the main thread. In your case I would suggest you to add the UIView object which are visible to the scrollview and add rest of them only when scrollview starts moving to that point. You can keep on adding views once they are about to be visible and remove any views which are not needed from the scrollview. This normally helps in better memory management.

View with a lot of UIButtons are slowing switch animation between views

I have UIViewController with many UIButtons (>30). But my animation between previous and next views is slow and with spurts. If I commented all of buttons - animation is going to work correctly. How can I fix this problem? My project use ARC mode (in this I think couldn't be memory leaks)

UIView's drawRect Calls When Backgrounded

I am working a multitasking app which continues for a while after being sent to the background. I noticed that the drawRect methods in one of the UIView gets called constantly when the app is in the background. This drawRect method is responsible for updating the user interface while the app works.
What is the best practice for this? I don't want to be wasting CPU cycles drawing something that the user won't see.
Maybe the answer to this question might help you out:
Check if iOS app is in background
Check if the app is running in the background, and if so... don't draw anything.

UIViewController - mysteriously slow to load

I'm writing a tab-based universal app where one of the tabs takes considerably much longer to load than the rest (approximately 5s), and it locks down the main thread while doing it.
Now, this specific tab is an image gallery, so it could be expected to take a little while to load and display the images, however, the delay occurs before I instantiate any of my variables... (The image loading is done on a separate thread anyway...)
I create my subviews etc. in the viewDidLoad method, but the delay occurs somewhere after the init method and before the viewDidLoad method.
(The delay is present even if I comment out everything in the viewDidLoad method.)
The View Controller is initialized with a nib containing nothing but a UIScrollView and a UIImagePickerController...
Does anyone know what's being loaded/processed before the viewDidLoad method?
This is a problem with loading UIImagePickerController on the phone while being attached to the xcode harness. This creates a longer than normal delay. Try testing on the device without being connected to the xcode debugger.