I have a button press that fires off an animation, and upon completion of the animation, changes the text of a label. I'd like to write a test verifies that when the button gets pressed, eventually the text of the label changes properly.
The implementation of the button press IBAction will use [UIView animateWithDuration:animations:completion:]. I obviously don't want my unit test to actually wait 0.5 seconds for an animation to complete.
I thought about mocking UIView, but it seems odd to inject UIView as a dependency to a view controller. Further, the mocking framework I'm using (OCMockito) doesn't seem to work well with mocking class methods.
I also thought about method swizzling or writing a testing category for UIView, and using an implementation that does nothing but invoke the animations: block followed by the completion: block. That seems a bit broken to me; I worry that overriding the implementation of a class method on UIView may have unintended consequences down the road.
Being new to TDD, I'm not sure what best practice is here. Is this one of those pieces of code that should be considered "UI twiddling" and therefore it's acceptable to leave untested? Or is there some more obvious way to test this that I am missing?
I would simply make a property that determines the length of the animation and have it default to 0.5 seconds.
That way, your test can set the animation duration to 0 and observe that the label's text is updated without waiting.
This is dependency injection, and it's wildly useful if you just starting with TDD. It also has the nice side-effect of make your code more modular and less coupled.
Related
If a Single View app is created, with a FooView that subclasses UIView, and do a
NSLog(#"hello");
in drawRect, then it is printed.
And if I create a subclass of CALayer called CoolLayer, and add this method to FooView.m:
+(Class) layerClass {
return [CoolLayer class];
}
and at the end of FooView.m's drawRect, do a
NSLog(#"layer's class is %#", self.layer.class);
then CoolLayer is printed. So now the view's underlaying layer is CoolLayer.
But when the following is added to CoolLayer.m:
-(void) display {
}
which is the method that is automatically called to redraw the layer (similar to drawRect), then no NSLog whatsoever was printed. It might be that the app went into an infinite loop. (even my touchesBegan that prints out NSLog messages is not printing). If a breakpoint is set at display, it will stop there once but when I continue the program, it will never arrive at display again. What is wrong with this and how can it be fixed?
The layer's display method will not be called again unless the layer is dirty, i.e. set to need a redisplay. This is usually a good thing, and is why you don't see the method being called more than once.
Also, the normal implementation of display will call the drawInContext: method. Since you override this in your subclass, the drawRect: method of the view is never called. You need to either replicate the standard behavior of CALayer, or call the superclass' display method in your own implementation.
That does not sound like an infinite loop. If you were in an infinite loop your app would freeze, and after a few seconds the springboard app would kill it for being unresponsive.
Call setNeedsDisplay or setNeedsDisplayInRect on your layer to make it "dirty" and require drawing again. Note that you don't want to call setNeedsDisplay any more than you have to, because it takes a lot of work to re-render the layer and push it's contents onto the screen. Only display when something has changed
You're not seeing an infinite loop here. If you were, as Duncan points out, you'd eventually crash either due to the watchdog timer or from an infinite recursion that would be immediately obvious in the stack trace you'd see in the debugger.
If you put an NSLog into your UIView's -drawRect: method, then override its default layer class with your own custom CALayer that does its own drawing, your UIView's -drawRect: would no longer be called. Drawing would now be handled by your custom backing layer.
As described in the "Providing CALayer Content by Subclassing" subsection of the Core Animation Programming Guide, you typically override -display in your CALayer if you want to somehow customize the contents CGImageRef for your layer. Normally, you'll be overriding -drawInContext: if you want to render custom Quartz drawing within your CALayer. Making your overridden -display method totally blank, and not writing anything to the contents property, is not standard behavior, so I'm not surprised that you're seeing odd results from doing that.
Based on your series of recent questions, I highly recommend you stop and spend some time reading the Core Animation Programming Guide and looking at some sample code involving CALayers before proceeding further.
Is there any significant difference in performance when you call
[someObject performSelector:#selector(testMethod:) withObject:anotherObject];
vs
[someObject testMethod:anotherObject];
?
The first causes an extra call to objc_msgSend() that isn't necessary in the second case.
The performance difference is unlikely to remotely matter unless you are calling said method as quickly as you possibly can many 10s of thousands of times and you aren't doing any significant work in testMethod:.
I.e. don't worry about it unless you measure an actual performance problem.
Interesting fact, performing a selector with a delay of 0 causes that method to be called at the top of the next run loop of the app. You can use that to delay certain events that occur frequently (used a lot in optimizations of UI, like images that get reloaded in a UIScrollView)
No there isn't any performance hit that I am aware of, and if there is any it is not significant.
I’ve come across an important difference when passing data to another view controller in prepareForSegue.
using:
[viewController performSelector:#selector(aMethod:) withObject:anObject];
aMethod is called AFTER viewDidLoad and viewWillAppear of the destination viewController.
using:
[viewController aMethod: anObject] ;
aMethod is called BEFORE viewDidLoad and viewWillAppear of the destination viewController.
So if you’re sending data important for the setup of the destination viewController, use the second way.
There is a lot difference in above both methods. I was trying to get animation of Two buttons coming from right side and stops at center but the second button was coming with 0.3 second delay. Now the main point comes here. I was using one animation method for both of 2 buttons. Now i wanted that when I click Finish button, then both buttons should go to left and again New buttons come. This was fine till reading.
Now when i was writing method for Finish button click. I was performing going out of buttons Animation first and then coming in buttons, but when I used the Above second method i.e. [someObject testMethod:anotherObject]; then what happens is I was not able to see the Going out Animation and directly coming in animation of buttons was shown.
Here actually comes the use of first method i.e. [someObject performSelector:#selector(testMethod:) withObject:anotherObject withDelay:delay];
The reason I found was when I click the Finish button the animation runs in different thread and the other code runs in different thread so the going out action was performed in another thread and coming in was performed in another thread. So first thread was not shown.
After using first method with Delay time of total animation. I achieved my goal. So both methods have their own significance.
For my experience,there are two differences:
The first one can add afterDelay:(CGFloat)seconds, and this is the only case I use the first one.
[someObject performSelector:#selector(testMethod:) withObject:anotherObject afterDelay:1.0];
The second one, you need to define it in someObject.h. Otherwise, you will get a compile warning.
The answer is that they are exactly the same.
There are two really good articles one from Mike Ash, where he explains the objc_msgSend():
http://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-build-objc_msgsend.html
And an another one from Tom Dalling who is explaining that perform selector is calling objc_msgSend().
http://tomdalling.com/blog/cocoa/why-performselector-is-more-dangerous-than-i-thought/
I am trying to create an intro animation for my iOS app and am having issues with timing. In particular I would like to change screens after the intro animation plays. I currently use a UIImageView and there does not appear to be a way to do this. Many stackoverflow questions say to use an NSTimer or performSelector:afterDelay but these are not accurate timers and in my case are completely wrong. Here is what I am doing.
Set UILaunchImageFile to LaunchImage.png
AppDelegate allocs an IntroViewController
IntroViewController.LoadView allocs IntroView
IntroView.initWithFrame performs the following
UIImageView* iv =
iv.animationImages =
iv.animationDuration = 2.0
iv.animationRepeatCount = 1
[iv startAnimating]
Set NSTimer/performSelector:afterDelay?
When timer triggers change from IntroViewController to something else.
If I perform either step 5 or 6 it does not work correctly. It does correctly play the animation and it will correctly change the view/view controller, but the timing is horribly horribly wrong. When you call startAnimating in this manner it may not actually start the animation for a full second or two. I presume because the app is still loading in resources somehow. This time however is not consistent across the simulator or all devices. Infact several runs on the same device may have different results. Thus I can not hard code some delay.
All I want to do is detect that a UIImageView animation has played the last frame and do something. That's it. The best solution I've found so far is to set a timer in some manner and then do something, but in my situation a timer is not a solution.
Any ideas?
The long delay you observe is due to reading and decoding the images, which UIImageView does before the animation begins.
Core Animation performs the animation for you, and it does its drawing in the render server, which is in a separate process. Remember that what you see on the screen doesn't necessarily represent your app's instantaneous picture of your layer tree: Core Animation Rendering Architecture.
UIImageView doesn't provide facilities to give you accurate results here. I'd suggest:
Make a UIView of your own.
Create a CAKeyframeAnimation with discrete calculation mode and your images' CGImageRefs as its values.
Set the animation's delegate to your IntroViewController.
Add the animation to your view's layer for the "contents" key.
Your IntroViewController will get animationDidStop:finished: when it's done.
Two things to consider, though:
First, you'll get better results using a movie rather than a series of images, since the movie can be streamed from storage.
Second, and more importantly, this solution will improve the timing situation but will not totally mitigate it. animationDidStop:finished: is called when your app thinks the animation is done… which is not necessarily exactly when it appears to finish.
You'll do better if you don't rely on delegate callbacks for media timing: instead, add this animation and the animation transitioning your views (using a CAAnimationGroup if necessary) in the same turn of the run loop. Delay the latter with a beginTime of the first animation's duration. Depending on what you're doing, you may have to set the second animation's fill mode as well to get the correct behavior during the first.
I've been using CALayer animations in my program, primarily to move around CALayers with animation on my screen. My problem is that I don't want to exit the layer-moving (card dealing, as it happens) method until all of the cards are done dealing. How can this be done cleanly?
Presume that my layer-moving method is called by different methods at different times, so it's better to let the normal flow of the program bring me back to the starting place, rather than trying to go back and forth with delegation.
Trying something simple like udelay() didn't work because it appears to block the display of the animation too.
Any ideas? Bonus if it's something I could use to pause for the completion of a built animation too (specifically, the animated dismissal of a modalViewController in what I'm working on now, but it'd be nice to have mechanisms that would regular pause, then continue on when various Animated: things occur).
CAAnimation has a delegate method animationDidStop:finished: and UIView has setAnimationDidStopSelector:. You can pause what you are doing at the beginning of the animation, and use these to resume. For example, if you want to pause a timer, set timerRunning = NO right at the animation code, then timerRunning = YES in the didStop method.
I have a CABasicAnimation that animating a property of a CALayer e.g. bounds.origin. I want to be able to observe the property changing over time, but haven't really found a method that works 100%.
I tried using KVO (key-value observation) on the presentationLayer's bounds.origin keypath. The system complains that the object is freed before its observers are freed, leading me to think that the presentation layer is only temporary. Observing presentationLayer.bounds.origin as a keypath doesn't work.
I tried creating a property on another layer and animating that e.g. by declaring the #property and making it #dynamic on that layer. However this new property only gets changed when the presentation layer is accessed (e.g. at the end of the animation), it doesn't seem to update while the animation is running.
I used needsDisplayForKey on the property in #2, which does trigger updates during the animation, but for these issues:
it only works if the CALayer has non-zero frame. Since this layer might be a CAShapeLayer or subclass, it may have a zero frame.
it looks like it triggers setNeedsDisplay for that layer, but since I'm not actually drawing that layer only monitoring the property change, I don't want to cause it to redraw.
I tried scheduling an NSTimer, and within the timer callback sample the presentationLayer. This also works but for these issues:
The timer would probably be slightly out of sync with the animation update.
Since occasionally the original animation gets pre-empted by another animation, it's difficult to actually get the timer to fire when the animation is running and only when the animation is running.
Any suggestions? All this would be on iPhoneOS 3.0/3.1.
Try using CADisplayLink, which is designed to stay in sync with the animation loop. More info: https://ashfurrow.com/blog/animating-views-with-cadisplaylink/
I think you've named all of the possibilities. In fact, I wasn't even aware of #2 and #3 and I wrote the book on Core Animation. ;-)
KVO is not available for these properties. Would be nice if it were, but I believe the reason for this has to do with the overhead it would take. The value would update very frequently and have to call back to any observers.
Anyhow, I've found the NSTimer to be the most reliable approach, but now I'm not sure from what you've said. What makes you think that the timer is out of sync? Why is it difficult get the timer only to fire when the animation is running? Can't you just check for the condition you want in the timer callback and then do nothing if the condition is not met?
Best Regards.
The best solution for me is using both: CABasicAnimation and CADisplayLink together. You can start observing changes on start animation and finish on it's finish. You also can calculate each step, but pay attention of timing logic. It will be working when you use linear timing. Or you have to prepare similar logic on your class based on CADisplayLink (transformation aligns to time changes).