From the Apple documentation on animating property changes in a view,
In order to animate changes to a property of the UIView class, you
must wrap those changes inside an animation block. The term animation
block is used in the generic sense to refer to any code that
designates animatable changes. In iOS 4 and later, you create an
animation block using block objects. In earlier versions of iOS, you
mark the beginning and end of an animation block using special class
methods of the UIView class. Both techniques support the same
configuration options and offer the same amount of control over the
animation execution. However, the block-based methods are preferred
whenever possible.
Other than the confusing terminology between an animation block and an objective-c block object, I am wondering what are some good resources and examples for using block objects to do animations with the UIView class? I have looked through the Apple documentation and also googled for some examples and could not find very many helpful resources. Also, what can we do to make sure that it is backwards compatible with devices earlier than iOS 4? I read somewhere that using a block object in earlier versions will cause a crash?
Here are some pointers to the Apple Documentation
Core Animation Programming Guide
Core Animation Cook Book
Animation Types and Timing Programming Guide
A Short practical Guide to Blocks (which contains a code sample to animate an UIView, see Listing 1-1)
Blocks Programming Topics
HTH
Related
I'm trying to get to grips with using Chipmunk (not the Obj-C version) with UIKit components on iOS, and still struggling immensely.
I'm trying to establish how, in the ChipmunkColorMatch example in the documentation, the UIButton instances are actually hooked up to any of the physics calculations. I see that the UIButtons are created inside the Ball class, and some of their properties are set, (type, image, etc.), but I'm not understanding where the cpBody or cpShape or whichever it is is actually attached to that UIButton. I assume it needs to be, else none of the physics will be reflected in the UI.
I've looked in the SimpleObjectiveChipmunk tutorial on the website too, but due to the fact that it uses libraries unavailable to me (the Obj-C libraries), I can't establish how it works there, either. Again, I see a UIButton being created and positioned on-screen, but I don't see how the cpBody (or in that case, ChipmunkBody) is linked to the button in any way.
Could anyone shed some light on how this works? Effectively what I'm going to need are some UIButton instances which can be flicked around, but I've not even got as far as working out how to create forces yet, since I can't get the bodies hooked up to the buttons.
Much obliged, thanks in advance.
EDIT: Should also point out that I am not, and do not want to use cocos2d in this project at all. I've seen tutorials using that, but that's a third layer of confusion to add in. Thanks!
Assuming this source is the project you're asking about, it looks like the magic happens in Ball's sync method -- it creates a CGAffineTransform representing the translation and rotation determined by the physics engine, and applies that to the button.
In turn, that method is called by the view controller's draw: method, which is timed to occur on every frame using CADisplayLink, and updates the physics engine before telling each Ball to sync.
Since iOS 5.1 was released, the default for showing the Master view controller in split views is a slide in type of thing. In order to present a popover it seems like you have to enable it using a UIPopover controller instead. Does this mean that the popover is going to going out of style?
When it comes to Apple's API's, deprecated means that Apple has specifically stated that something is in the process of going away. It's usually accompanied by advice regarding a new way to accomplish the same thing. So, if Apple ever deprecates UIPopoverController, you'll know it just from reading the documentation.
That said, it's also a good idea to read the release notes for each new version of iOS that comes along. In the iOS 5.1 release notes you'll find a note that explains what you're seeing:
In 5.1 the UISplitViewController class adopts the sliding presentation
style when presenting the left view (previously only seen in Mail).
This style is used when presentation is initiated either by the
existing bar button item provided by the delegate methods or by a
swipe gesture within the right view. No additional API adoption is
required to obtain this behavior, and all existing API, including that
of the UIPopoverController instance provided by the delegate, will
continue to work as before.
Lately I've been running into some subtle layout issues in my iOS app. For example displaying a viewController from one part of the app causes the layout of some subviews to be altered (the z-axis ordering changes). Another subtle issue is the navigation bar flickering slightly.
What are some techniques for debugging these issues?
I'm especially interested in printing/logging properties of objects. For example I'd like to just dump/print/log all properties of the viewController referenced above to see exactly what changes. Then perhaps one can use symbolic breakpoints to pin-point the cause.
Check out DCIntrospect. It's a tool that can be very helpful for looking at view's info conveniently.
You can use KVO to observe frames changing, so you know what changes when, from and to what values. You can even use it to fix properties to some contant value. (See Prevent indentation of UITableViewCell (contentView) while editing)
You can use reflection to loop through all properties of an object. I don't know how such a broad approach would help you, but it is possible. (See Loop through all object properties at runtime)
Another technique to use is to subclass a UIView with override methods for re-positioning a view, or other aspects - then you can set breakpoints or log when the frame changes, or other attributes.
To use the UIView debugging class you can just change the type of a View in InterfaceBuilder to be your custom view type instead of UIView.
Use iOS App layout Debugging tool
revealapp.com
Just integrate revealapp SDK in your app and work as firebug
In the new GLKit GLView reference, there is this warning that is emphasized:
Important: Your drawing method should only modify the contents of the framebuffer object. Never attempt to read the pixel information from the underlying framebuffer object, modify or dispose of the framebuffer object, or read its other properties by calling OpenGL ES functions. Instead, rely on the properties and methods provided by the GLKView class
Previously, with EAGLView the best practice published all over was for hit testing which included the use of glReadPixels using a framebuffer which was rendered but not presented.
With GLKView the only thing that seems to come close is a "-snapshot" call to make a UIImage object from the render. Then dig out the pixels. This seems very inefficient.
Is there a "best practice" for hit testing with the new GLKit funcitons? It seems that binding and rebinding of a seperate framebuffer are possible but then I'm not sure of what the dramatic warning in the GLKView reference means.
Any ideas on the best approach for hit testing when using GLKit?
Check out this very informative SO post which includes sample code. I believe it is exactly what you're looking for- it worked great for me.
I want a UIButton to pulse, and I plan to do this by fading slowly between two color arrays on a CAGradientLayer. Is there a way to repeat an animation back and forth?
Yes. In Core Animation you create an explicit animation to do the fade and then you must also set two other properties for the animation object: autoReverses and repeatCount (number of repetitions to perform, each 2 repetitions will take you through your animation and back again). In your case you’d add the following lines to your code that sets up the animation object (I’ll call the object anim):
anim.repeatCount = HUGE_VALF;
anim.autoReverses = YES;
HUGE_VALF causes the animation to repeat forever though you could specify a number larger than any amount of repetitions that might occur.
These properties aren’t shown in the documentation of the CAAnimation object or it’s subclasses since it is defined in the CAMediaTiming Protocol which is adopted by CAAnimation and it's subclasses. But you can see examples and discussion of the CAMediaTiming protocol as it applies to CAAnimation objects in the Timing, Timespaces, and CAAnimation section of the Animation Types and Timing Programming Guide either on Apple’s Developer site or in the documentation provided through XCode.
(Many people seem to find Apple's Core Animation documentation to be particularly hard to understand until you get a good overall grasp of the disparate parts. I basically knew what you had to do but still found it hard to remember exactly where to find the actual information as to the properties involved.)