A couple adjustments to prevent flickering on Drop style ... #5
Conversation
…le when dismiss is called too soon
|
Is this only happening with the "drop" animation? |
|
Hi, just had another go at fixing this. the issues come when the dismiss action is queued (fired before the show completes). Logically, you don't want to fire the UIView animation to hide the gradient and window before the beginning of the dismiss action. There is no showActionCompletion property so I hooked the UIView animation into the dismissActionCompletion block which seems fine visual as it's quite quick anyway. This seems to work... Great lib by the way...good code :) |
| } else { | ||
| void (^oldCompletion)(void) = [self.dismissAnimationCompletion copy]; | ||
| self.dismissAnimationCompletion = ^{ | ||
| MMProgressHUD *self = weakSelf; |
There was a problem hiding this comment.
Let's go ahead and omit this line altogether and just use weakSelf below since you're only referencing it a single time. Something feels dirty to me about assigning to a variable named self outside of init.
|
I like your second approach much better 😃 |
…mpletion blocks not being nil'ed. Still doesnt solve problem which is: On my iPhone4 device (not simulator) if the drop animation is dismissed before finished showing (and therefore queued), the hud pops back to the center before being removed by the completion block. I've tried: - disabling the CATransaction begin/end when it's queue (as the queue block is contained in the showAnimation's transaction) - setting removedOnCompletion to NO in _dropAnimationOut - hud.layer.removeAllAnimations before adding the dismiss animations - breaking in the dismiss completion block. The hud is already been moved back to centre so it's not the cleanupAfter method or anything happening in completion. - Subtracting 0.15 from the BG fade animation duration (which == *Long for drop animation) which is the only thing that works but is a total hack and very timing sensitive. I've commented this out in the committed code. Would love to fix this but I need to move on with my project. Can't figure out why this would only happen when queued. Must be the showAnimation taking precedent somehow... Side note: For the completion block(s), I've added code to nil them after they are called as was specified in the comments for dismissAnimationCompletion.
|
Hi, see that last commit. I've changed the self back to blockSelf, but the technique is kosher I believe. I learned it from digging around the @weakify / @strongify macros in ReactiveCocoa. Worth a look! |
|
Yeah it's the same principle as the weakify/strongify macros, just simpler. Not reusing |
A couple adjustments to prevent flickering on Drop style ...
...when dismiss is called too soon.
There are two issues that occur when dismiss is called before show is complete. The first is the setting of the hud's position and transform immediately on calling dismiss which causes it to disappear for a moment until the dismiss animation kicks in.
The second is the completion block for the background fade which cleans up and hides the UIWindow containing the HUD causing it to disappear before it's off screen. I've put in a delay if progress < 0. It's a touch hack-ish but it's quite a sophisticated system and I'm hoping you might have a better solution :)
Love the drop-style by the way - perfect for my client project! I'll let you know the app when it's out of NDA :)