Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

RossOliver

macrumors regular
Original poster
Nov 6, 2006
157
0
Hey,

I'm looking to copy the effect used for when you change the volume on your iPhone. I have a UIImageView which I set to hidden, then show it at certain times during my application for a second or two at a time. Rather than it abruptly appearing and then disappearing, I would like it to fade out in a similar fashion to the iphone volume icon.

I took a look at the ViewTransitions sample code but that just seems to handle fading from one view into another - what's the best approach to fade out a single view so it is hidden?

Thanks for your time,

-Ross
 

Enuratique

macrumors 6502
Apr 28, 2008
276
0
The only thing I can think of is handling UIView's various animation methods (haven't done animation transitions, sorry otherwise I'd be more specific) and basically increment the alpha value of the view you wish to fade in from 0 (invisible) to 1 (opaque) during the course of the animation. The documentation for the alpha property even alludes to using the alpha property in just this way:

Discussion

Changes to this property can be animated. Use the beginAnimations:context: class method to begin and the commitAnimations class method to end an animation block.
 

RossOliver

macrumors regular
Original poster
Nov 6, 2006
157
0
The only thing I can think of is handling UIView's various animation methods (haven't done animation transitions, sorry otherwise I'd be more specific) and basically increment the alpha value of the view you wish to fade in from 0 (invisible) to 1 (opaque) during the course of the animation. The documentation for the alpha property even alludes to using the alpha property in just this way:

Discussion

Changes to this property can be animated. Use the beginAnimations:context: class method to begin and the commitAnimations class method to end an animation block.

Thanks for the reference - I'll see if I can patch it into one of the View Transition samples to get the effect I'm after...
 

RossOliver

macrumors regular
Original poster
Nov 6, 2006
157
0
Turns out it couldn't have been much simpler :rolleyes:

Code:
[UIView beginAnimations:nil context:NULL];
[UIView setAnimationDuration:0.5];
[myImageView setAlpha:0];
[UIView commitAnimations];
 

Enuratique

macrumors 6502
Apr 28, 2008
276
0
Sweet! Good to know! Does this code fade the view in or out?

[EDIT] Upon further reading, it appears that this code fades the view out.

But why are you using nil for one parameter and NULL for the other? I think at the end of the day, they both compile to the value 0, so it would still work - I'm just curious.
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
http://developer.apple.com/iphone/l...e_ref/occ/clm/UIView/beginAnimations:context:

From that documentation it looks like the context parameter is a void *, while the first parameter is an NSString *. It seems to be a convention to refer to null object pointers as nil, while pointers to primitives are simply NULL. I'm pretty confident that they can be used interchangeably, it's just a matter of convention. Someone out there may need to correct me, but this is my understanding.

-Lee
 

Enuratique

macrumors 6502
Apr 28, 2008
276
0
http://developer.apple.com/iphone/l...e_ref/occ/clm/UIView/beginAnimations:context:

From that documentation it looks like the context parameter is a void *, while the first parameter is an NSString *. It seems to be a convention to refer to null object pointers as nil, while pointers to primitives are simply NULL. I'm pretty confident that they can be used interchangeably, it's just a matter of convention. Someone out there may need to correct me, but this is my understanding.

-Lee

Makes sense to me :)
 

RossOliver

macrumors regular
Original poster
Nov 6, 2006
157
0
It seems to be a convention to refer to null object pointers as nil, while pointers to primitives are simply NULL.

That's the impression I was under...

I've ran into a bit of a snag with this now. My problem is that the view I want to animate starts out with an alpha of 0 (invisible). So before the animation I want to set it to 100 (fully visible) and I thought I would get away with this:

Code:
[myImageView setAlpha:100.0];
	
[UIView beginAnimations:nil context:NULL];
[UIView setAnimationDuration:0.5];
[myImageView setAlpha:0.0];
[UIView commitAnimations];

However, doing this stops the animation from working - the image simply appears immediately, stays fully visible for 500ms and then disappears immediately. Can anyone explain why doing operations before (and after) an animation has unexpected results (I've also tried setting it to hidden to start with, then visible for the animation and hidden again when it finishes)?

Cheers,

-Ross
 

Enuratique

macrumors 6502
Apr 28, 2008
276
0
That's the impression I was under...

I've ran into a bit of a snag with this now. My problem is that the view I want to animate starts out with an alpha of 0 (invisible). So before the animation I want to set it to 100 (fully visible) and I thought I would get away with this:

Code:
[myImageView setAlpha:100.0];
	
[UIView beginAnimations:nil context:NULL];
[UIView setAnimationDuration:0.5];
[myImageView setAlpha:0.0];
[UIView commitAnimations];

However, doing this stops the animation from working - the image simply appears immediately, stays fully visible for 500ms and then disappears immediately. Can anyone explain why doing operations before (and after) an animation has unexpected results (I've also tried setting it to hidden to start with, then visible for the animation and hidden again when it finishes)?

Cheers,

-Ross

Now I could be wrong but typically alpha values range from 0 (invisible) to 1 (opaque) not 100. There's a mathematical reason for this in the graphics processing - if the alpha value is 0.5, that means half the pixel colors from one view are added to half the value of the other view being faded upon to get the composite resultant color. Try changing that first as it may be performing this computation with 100 instead of 1, giving whacky values that when interpreted by the graphics engine either crashes the app or gives undefined behavior (such as an image being visible when it shouldn't be). There shouldn't be any need to muck with visibility properties.

Also, animation schemes like the one Apple has implemented will take the animation duration and multiply it by 30 (30 frames in a second, as detectable by the human eye) to figure out the total delta value to change the selector property (in this case, the alpha property) by. Since you've defined the animation to be 0.5 seconds, that means there will be a total of 15 frames of animation, so it must increment or decrement the alpha value by abs(1-0)/15 each frame [translate that as absolute_value(starting alpha value - ending alpha value)/(30*duration) or changing the alpha value by roughly .066667 each frame. Using this math with an alpha value of 100, it changes by 6.6667 each time - but until the last frame, the alpha value is always above 1, which if the graphics processor simply truncates any value above 1 to 1 (they often do this), this would have the same effect as the view being fully visible until the last frame, when it drops to 0 becoming immediately invisible.

Hope I'm right and that this is the quick fix,

Enuratique
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.