UILongPressGesture minimumPressDuration - objective-c

So I am relatively new to Objective-C and there is a definite possibility I am missing something fairly obvious, so feel free to throw tomatoes at me if so. Here is my problem:
I have an iPhone single-view application consisting of one MapView. I included a long-press gesture recognizer on that MapView in order to annotate/drop a pin. It appears that this will work if I do not specify a minimumPressDuration...
- (void)viewWillAppear:(BOOL)animated {
UILongPressGestureRecognizer * longPressRecognizer = [[UILongPressGestureRecognizer alloc] initWithTarget:self action:#selector(handleLongPress:)];
[mapView addGestureRecognizer:longPressRecognizer]; // Actual map view handler is added to
...
}
-(void) handleLongPress:(UILongPressGestureRecognizer *)gestureRecognizer {
NSLog (#"Did it work?!");
// Some code here to make pins appear; omitted for simplicity in this question
}
As expected, when I long press the map, after 0.5 seconds (the default time) I will have 1 pin on the map. If I move around my finger, I have a crapload of pins. The log also prints out "Did it work?!" many times over and over. Again, expected. However, when I add one little line to the viewWillappear method (right before messaging mapView's addGestureRecognizer):
longPressRecognizer.minimumPressDuration = 1.0;
...the gesture no longer works. In that I hold press for 1 second and nothing appears on the log. Let go, try for longer than one second... nothing. No pins are dropped, and nothing prints out to the log. Why is this occurring? I can't understand why setting a minimum duration would break this. My expectation is that this should function the same as before - no custom-set minimum press duration - with the only difference being I need to hold down for 1 full second instead of half of one.
Update: it appears that if I choose values between 0.1 and 0.5 inclusive it works. But once I go to 0.6 or greater it does not work. Something going on under the hood in Obj-C I don't know about?
Also, I know I should be checking state in my handler function, so unless that will fix that problem don't pile on me for it. I just want to get the bare bones working first before I delve into the details.
Thanks!
P.S., using OS X 10.8.2 and Xcode 4.5.1 (4G1004).

I encountered the same issue. After set recognizer's delegate and turn simultaneous recognition on, this issue is solved. Following is my code for your reference:
- (void)init
{
UILongPressGestureRecognizer *longPressGestureRecognizer = [[UILongPressGestureRecognizer alloc] initWithTarget:self action:#selector(lockLongPress:)];
longPressGestureRecognizer.minimumPressDuration = 1.0;
longPressGestureRecognizer.delegate = self;
[targetView addGestureRecognizer:longPressGestureRecognizer];
}
- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer
{
return YES;
}

Related

NSScrubber pan animation end notification

The touchbar-specific NSScrubber control scrolls with inertia on a pan gesture. I want to be notified of this animation's end to perform some function.
Try 1
The NSScrubberDelegate has a - didFinishInteractingWithScrubber: method which I implemented. However, soon after I stop manipulating the scrubber directly -- lifts the finger off the touchbar -- I get a callback, but the scroll continues to happen due to inertia. The final item that gets selected is NOT the one when this delegate method was called back.
Try 2
Digging further, I came across NSAnimation. Though it isn't documented clearly, I gather that scrubber is also a NSAnimatablePropertyContainer, as its selectedIndex property documentation says one can animate the selection through the animator proxy thus: scrubber.animator.selectedIndex = i. By that virtue, assuming that the animated property for the smooth panning is the boundsOrigin, I tried querying it.
I was able to get a CAAnimation by doing this
CAAnimation* a = [NSScrubber defaultAnimationForKey:#"boundsOrigin"];
// returns the same pointer value as above
// a = [myScrubber animationForKey:#"boundsOrigin"];
a.delegate = self;
...
- (void)animationDidStop:(CAAnimation *)anim
finished:(BOOL)flag {
if (flag == YES)
NSLog(#"Animation ended!\n");
}
I get a valid pointer value for a. However, I get numerous calls to animationDidStop with all of them having flag = YES; as the scrubber scrolls I keep getting these calls and when the scroll stops the calls stop. This feels closest to what I want but I dunno why so many calls come instead of just one when the animation ends.
Since NSScrubber's NSView or NSScrollView aren't exposed, I'm not sure if I'm querying the right object to get to the right NSAnimation.
Try 3
I also tried the hacky route of doing this on manipulation end code in vain
-(void)didFinishInteractingWithScrubber:(NSScrubber *)scrubber {
NSLog(#"Manipulation ended\n");
NSAnimationContext*c = NSAnimationContext.currentContext;
[c setCompletionHandler:^{
NSLog(#"Inertial scrolling stopped!\n");
}];
}
The completion handler is called almost immediately, before the inertial scroll stops :(
Ask
Is there anyway to know when the scrubber's pan gesture inertial animation ends?
I finally found a way to register a callback for the pan gesture's inertial scroll animation end.
Like any other scroll view, this also has the NSScrollViewDidEndLiveScrollNotification. Use the notification centre to register for the callback!
NSScrollView *sv = myScrubber.enclosingScrollView;
// register for NSScrollViewWillStartLiveScrollNotification if start is also needed
[[NSNotificationCenter defaultCenter] addObserverForName:NSScrollViewDidEndLiveScrollNotification
object:sv
queue:nil
usingBlock:^(NSNotification * _Nonnull note) {
NSLog(#"Scroll complete");
}];
Thanks to this answer for showing this approach.

Disable double tap zoom in MKMapView (iOS 6)

in ios 5 i was able to disable the double tap zoom by just overriding it with a new double tap gesture. But it seems that the double tap gesture is no longer in the gesturerecognizer array that comes with the mkmapview.
NSArray *gestureRecognizers = [_mapView gestureRecognizers];
for (UIGestureRecognizer *recognizer in gestureRecognizers) {
NSLog(#"%#", recognizer);
}
returns nothing in ios 6, where in ios 5 it would return 2 recognizers, one for single tap and one for double tap.
I'd look through the gesture recognizers of MKMapView's subviews. It's probably still there somewhere.
Of course, messing around with another view's GRs is slightly dubious and will likely break the next time Apple changes something about MKMapView...
EDIT: For the benefit of anyone else reading this, please check that it's a UITapGestureRecognizer and that numberOfTapsRequired == 2 and numberOfTouchesRequired == 1.
Also, instead of disabling double-taps on the map entirely, consider adding a double-tap GR on the annotation and then do [mapDoubleTapGR requireGestureRecognizerToFail:annotationDoubleTapGR]. Again, hacky — don't blame me if it breaks on the next OS update!
This worked for me:
[_mapView.subviews[0] addGestureRecognizer:MyDoubleTapOverrider];
Do you want to let the user do anything with the view? If not, it sufficient to set userInteractionEnabled to NO. If so, what specific interactions do you need to allow? Everything but double-tapping? Why disable that one interaction?
The more we know about your use case, the better the answers we can provide.
This works for me:
//INIT the MKMapView
-(id) init{
...
[self getGesturesRecursive:mapView];
...
}
And then let the recursive function loop through the subviews and find the GR:s.
-(void)getGesturesRecursive:(UIView*)v{
NSArray *gestureRecognizers = [v gestureRecognizers];
for (UIGestureRecognizer *recognizer in gestureRecognizers) {
if ([recognizer isKindOfClass:[UITapGestureRecognizer class]]) {
[v removeGestureRecognizer:recognizer];
}
}
for (UIView *v1 in v.subviews){
[self getGesturesRecursive:v1];
}
}
This example removes all tap-GR:s. But I guess you can specify to remove whatever you'd like.
You can use a long tap gesture instead, that works.

Mouse Enter/Exit events on partially hidden NSViews

I have a problem that I think is solvable with some hackery, but I'm very curious if there is an easier way to get the job done without having to do all of that.
I have a stack of NSViews (layer-backed, if that somehow helps provides some better solution), as shown below:
The thing here is that this is essentially a menu, but is hover-sensitive. If the user hovers over one of the exposed parts of the lower-level views, I need to perform an action depending on what that view is. It is a dynamic system so the number of stacked menu items like this may change, making static calculations more difficult. As you can see, they are basically all a copy (shape-wise) of the first item, but then rotated a bit the further you go down the stack via simple transform rotation.
My question to the SO community is what do you all think the best approach to getting mouseEntered: and mouseExited: events for just the literally visible portions of these views?
What I have attempted to do is use an NSTrackingArea on the visibleRect portion of these views, which sounds much more handy than it really is in this situation. In reality, the visibleRect seems to be "visible" for all of them, all the time. Nothing is explicitly blocked or hidden by anything more than just a partially overlapping NSView. All that happens is I get a spammed console from all of the views screaming out at once that a mouse entered their rect.
Something I am considering is making sub-NSView's of each menu item and having each of those be responsible for the tracking area... each menu item having a "strip" view along the right and bottom sides that could report, but that's still a bit of a hack and is icky.
Does anyone have a better idea? Perhaps one from experience?
Thanks!
I know you already have a solution, but I thought I would try a different approach, that didn't require getting tons of mouseMoved events. I created 3 custom views in code, added tracking rects for them and sent all mouseEntered and mouseExited messages to the same method that does a hitTest to determine which view is top most. This is the code for the content view of the window.
#implementation MainView
#synthesize oldView;
-(void)awakeFromNib {
oldView = nil;
Card *card1 = [[Card alloc]initWithFrame:NSMakeRect(150, 150, 200, 150) color:[NSColor redColor] name:#"Red Box"];
NSTrackingArea *area1 = [[NSTrackingArea alloc]initWithRect:card1.frame options:NSTrackingMouseEnteredAndExited|NSTrackingActiveInActiveApp owner:self userInfo:nil];
[self addTrackingArea:area1];
[self addSubview:card1];
Card *card2 = [[Card alloc]initWithFrame:NSMakeRect(180, 120, 200, 150) color:[NSColor yellowColor] name:#"Yellow Box"];
NSTrackingArea *area2 = [[NSTrackingArea alloc]initWithRect:card2.frame options:NSTrackingMouseEnteredAndExited|NSTrackingActiveInActiveApp owner:self userInfo:nil];
[self addTrackingArea:area2];
[self addSubview:card2];
Card *card3 = [[Card alloc]initWithFrame:NSMakeRect(210, 90, 200, 150) color:[NSColor greenColor] name:#"Green Box"];
NSTrackingArea *area3 = [[NSTrackingArea alloc]initWithRect:card3.frame options:NSTrackingMouseEnteredAndExited|NSTrackingActiveInActiveApp owner:self userInfo:nil];
[self addTrackingArea:area3];
[self addSubview:card3];
}
-(void)mouseEntered:(NSEvent *)theEvent {
[self reportTopView:theEvent];
}
-(void)mouseExited:(NSEvent *)theEvent {
[self reportTopView:theEvent];
}
-(void)reportTopView:(NSEvent *)theEvent {
id topView = [self hitTest:[theEvent locationInWindow]];
if (![topView isEqual:oldView]) {
oldView = topView;
([topView isKindOfClass:[Card class]])? NSLog(#"%#",[(Card *)topView name]):NULL;
}
}
This is the code for what I called cards (colored rectangles):
#implementation Card
#synthesize name,fillColor;
- (id)initWithFrame:(NSRect)frame color:(NSColor *)color name:(NSString *)aName{
self = [super initWithFrame:frame];
if (self) {
self.fillColor = color;
self.name = aName;
}
return self;
}
- (void)drawRect:(NSRect)rect {
[self.fillColor drawSwatchInRect:rect];
}
I finally came to a solution on Twitter via Steven Troughton-Smith. Here's how it works:
In each menu item, I am disregarding anything related to NSTrackingArea or direct mouse position interpretation. Instead, the parent controller view is handling all of the tracking and receiving mouse movement events.
Each menu item has an overridden hitTest: method that does the point conversion and returns whether or not the point being tested is within the background image (there are shadows and stuff in there, making it more difficult than the vanilla implementation).
I then setup a sort of "hover menu item changed" callback in the controller so that I can handle hover menu changes.
This was a pretty straightforward solution. Very glad I decided to stop and ask, rather than hack something together with my previous idea.
Thanks Steven!
Overlapping tracking-areas:
All you have to do is hitTest from view you are in. if this is true:
window.view.hitTest(window.mousePos) === self/*sudo code*/
What this code does is that it returns the view under the mouse position. Now all you have to do is setup a few "if" and "else" clauses to verify that your mouse is off or on the view.
Full code example:
https://gist.github.com/eonist/537ae53b86d5fc332fd3
Full description of the concept here: (perma link)
http://stylekit.org/blog/2015/12/20/Overlapping-tracking-areas/
VS the default enter and exit behaviour:
I had to add another answer to this question as this is another approach to solve the problem. This approach now also includes path assertion (think rects with round edges or other custom paths)
The answer is long winded but it works:
http://stylekit.org/blog/2016/01/28/Hit-testing-sub-views/
it involves using the apple provided method: CGPathContainsPoint(path,transform,point)
If you follow the link to that blog post and then from there check the styleKit repo on github. You will find the code need to achieve the gif animation example given above. Im providing this as a pointer to the answer as it may take you significantly less time than trying to research this on your own. I use this technique in all my UI elements and it works flawlessly.

The exact moment iOS takes the view snapshot when entering background?

I have a problem when putting my iPhone app to background by pushing the exit button, and then relaunching by tapping the launch icon on the home screen: the app's view does return to its initial state like I want it to, but before that it flashes the earlier, wrong view state onscreen briefly.
Background
My main view consists basically of a sequence of interlinked UIAnimateWithDuration calls. The behavior I want whenever any interruption occurs, is to reset the animation to its initial state (unless the animations have all finished and the app has entered the static final phase), and start over from there whenever the app returns to active and visible state.
After studying the subject I learned I need two types of interruption handling code to provide good ux: "instant" and "smooth". I have the method resetAnimation that resets the view properties to the initial state instantly, and the method pauseAnimation that animates quickly to the same state, with an additional label stating "paused" fading in on the top of the view.
Double clicking exit button
The reason for this is the "double clicking exit button" use case, that actually does not hide your view or put you in the background state, it just scrolls up a bit to show the multitasking menu at the bottom. So, resetting the view state instantly in this case just looked very ugly. The animated transition and telling the user you're paused seemed like a better idea.
This case works nice and smootly by implementing the applicationWillResignActive delegate method in my App Delegate and calling pauseAnimation from there. I handle returning from that multitasking menu by implementing the applicationDidBecomeActive delegate method and calling from there my resumeAnimation method, that fades out the "paused" label if its there, and starts my animation sequence from the initial state.
This all works fine, no flickering anywhere.
Visiting flipside
My app's built over the Xcode "utility" template, so it has a flipside view to show info/settings. I handle visiting the flipside and returning back to the main view by implementing these two delegate methods in my main view controller:
(void)viewDidDisappear:(BOOL)animated
(void)viewDidAppear:(BOOL)animated
I call my resetAnimation in the viewDidDisappear method and resumeAnimation in viewDidAppear. This all works fine, the main view is its initial state from the very beginning of the transition to visible state - no unexpected flashing of wrong animation states of anything. But:
Pushing exit button and relaunching from my app icon (the buggy part!)
This is where the trouble starts. When I push exit button once and my app begins its transition to background, two things happen. First, applicationWillResignActive gets called here too, so my pauseAnimation method launches also. It wouldn't need to, since the transition doesn't need to be smooth here – the view just goes static, and "zooms out" to reveal the home screen – but what can you do? Well, it wouldn't do any harm either if I just could call resetAnimation before the exact moment that the system takes the snapshot of the view.
Anyways, secondly, applicationDidEnterBackground in the App Delegate gets called. I tried to call resetAnimation from there so that the view would be in the right state when the app returns, but this doesn't seem to work. It seems the "snapshot" has been taken already and so, when I tap my app launch icon and relauch, the wrong view state does flash briefly on the screen before the correct, initial state shows. After that, it works fine, the animations go about like they're supposed to, but that ugly flicker at that relaunch moment won't go away, no matter what I try.
Fundamentally, what I'm after is, what exact moment does the system take this snapshot? And consequently, what would be the correct delegate method or notification handler to prepare my view for taking the "souvenir photo"?
PS. Then there's the default.png, which doesn't seem to only show at first launch, but also whenever the processor's having a hard time or returning to the app is delayed briefly for some other reason. It's a bit ugly, especially if you're returning to your flipside view that looks totally different from your default view. But this is such a core iOS feature, I'm guessing I shouldn't even try to figure out or control that one :)
Edit: since people were asking for actual code, and my app has already been released after asking this question, I'll post some here. ( The app's called Sweetest Kid, and if you want to see how it actually works, it's here: http://itunes.apple.com/app/sweetest-kid/id476637106?mt=8 )
Here's my pauseAnimation method – resetAnimation is almost identical, except its animation call has zero duration and delay, and it doesn't show the 'Paused' label. One reason I'm using UIAnimation to reset the values instead of just assigning the new values is that for some reason, the animations just didn't stop if I didn't use UIAnimation. Anyway, here's the pauseAnimation method:
- (void)pauseAnimation {
if (currentAnimationPhase < 6 || currentAnimationPhase == 255) {
// 6 means finished, 255 is a short initial animation only showing at first launch
self.paused = YES;
[UIView animateWithDuration:0.3
delay:0
options:UIViewAnimationOptionAllowUserInteraction |
UIViewAnimationOptionBeginFromCurrentState |
UIViewAnimationOptionCurveEaseInOut |
UIViewAnimationOptionOverrideInheritedCurve |
UIViewAnimationOptionOverrideInheritedDuration
animations:^{
pausedView.alpha = 1.0;
cameraImageView.alpha = 0;
mirrorGlowView.alpha = 0;
infoButton.alpha = 1.0;
chantView.alpha = 0;
verseOneLabel.alpha = 1.0;
verseTwoLabel.alpha = 0;
verseThreeLabel.alpha = 0;
shine1View.alpha = stars1View.alpha = stars2View.alpha = 0;
shine1View.transform = CGAffineTransformIdentity;
stars1View.transform = CGAffineTransformIdentity;
stars2View.transform = CGAffineTransformIdentity;
finishedMenuView.alpha = 0;
preparingMagicView.alpha = 0;}
completion:^(BOOL finished){
pausedView.alpha = 1.0;
cameraImageView.alpha = 0;
mirrorGlowView.alpha = 0;
infoButton.alpha = 1.0;
chantView.alpha = 0;
verseOneLabel.alpha = 1.0;
verseTwoLabel.alpha = 0;
verseThreeLabel.alpha = 0;
shine1View.alpha = stars1View.alpha = stars2View.alpha = 0;
shine1View.transform = CGAffineTransformIdentity;
stars1View.transform = CGAffineTransformIdentity;
stars2View.transform = CGAffineTransformIdentity;
finishedMenuView.alpha = 0;
preparingMagicView.alpha = 0;
}];
askTheMirrorButton.enabled = YES;
againButton.enabled = NO;
shareOnFacebookButton.enabled = NO;
emailButton.enabled = NO;
saveButton.enabled = NO;
currentAnimationPhase = 0;
[[cameraImageView subviews] makeObjectsPerformSelector:#selector(removeFromSuperview)]; // To remove the video preview layer
}
}
The screenshot is taken immediately after this method returns. I guess your -resetAnimation method completes in the next runloop cycle and not immediately.
I've not tried this, but you could try to let the runloop run and then return a little bit later:
- (void) applicationDidEnterBackground:(UIApplication *)application {
// YOUR CODE HERE
// Let the runloop run for a brief moment
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.01]];
}
I hope this helps,
Fabian
Update: -pauseAnimation and -resetAnimation distinction
Approach: Delay the animation happening in -applicationWillResignActive: and cancel the delayed animation in -applicationDidEnterBackground:
- (void) applicationWillResignActive:(UIApplication *)application {
// Measure the time between -applicationWillResignActive: and -applicationDidEnterBackground first!
[self performSelector:#selector(pauseAnimation) withObject:nil afterDelay:0.1];
// OTHER CODE HERE
}
- (void) applicationDidEnterBackground:(UIApplication *)application {
[NSObject cancelPreviousPerformRequestsWithTarget:self selector:#selector(pauseAnimation) object:nil];
// OTHER CODE HERE
}
I've now run some tests, and eliminated the problem, thanks to #Fabian Kreiser.
To conclude: Kreiser had it right: iOS takes the screenshot immediately after the method applicationDidEnterBackground: returns -- immediately meaning, before the end of the current runloop.
What this means is, if you launch any scheduled tasks in the didEnterBackground method you want to finish before leaving, you will have to let the current runloop run for as long as the tasks might take to finish.
In my case, the scheduled task was an UIAnimateWithDuration method call -- I let myself be confused by the fact that both its delay and duration was 0 -- the call was nonetheless scheduled to run in another thread, and thus wasn't able to finish before the end of applicationDidEnterBackground method. Result: the screenshot was indeed taken before the display was updated to the state I wanted -- and, when relaunching, this screenshot flashed briefly onscreen, causing the unwanted flickering.
Furthermore, to provide the "smooth" vs. "instant" transition behavior explained in my question, Kreiser's suggestion to delay the "smooth" transition call in applicationWillResignActive: and cancel the call in applicationDidEnterBackground: works fine. I noticed the delay between the two delegate methods was around 0.005-0.019 seconds in my case, so I applied a generous margin and used a delay of 0.05 seconds.
My bounty, the correct answer tick, and my thanks go to Fabian. Hopefully this helps others in similar situation, too.
The runloop solution actually results in some problems with the app.
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.01]];
If you go to the background and immediately open the app again, the app will turn into a black screen. When you reopen the app for the second time, everything is back to normal.
A better way is to use
[CATransaction flush]
This forces all current transactions to be immediately applied and does not have the problem resulting in a black screen.
Depending on how hardcore important it is to you to have this transition run smoothly, you could kill off multi-tasking for your app entirely w/ UIApplicationExitsOnSuspend. Then, you would be guaranteed your Default.png and a clean visual state.
Of course, you'd have to save/restore state on exit/startup, and without more info on the nature of your app, it's tough to say whether this would be worth the trouble.
In iOS 7, there is [[UIApplication sharedApplication] ignoreSnapshotOnNextApplicationLaunch] call that does exactly what you needed.

MPMoviePlayerController adding UIButton to view that fades with controls

I am trying to add a UIButton to the view of a MPMoviePlayerController along with the standard controls. The button appears over the video and works as expected receiving touch events, but I would like to have it fade in and out with the standard controls in response to user touches.
I know I could accomplish this by rolling my own custom player controls, but it seems silly since I am just trying to add one button.
EDIT
If you recursively traverse the view hierarchy of the MPMoviePlayerController's view eventually you will come to a view class called MPInlineVideoOverlay. You can add any additional controls easily to this view to achieve the auto fade in/out behavior.
There are a few gotchas though, it can sometimes take awhile (up to a second in my experience) after you have created the MPMoviePlayerController and added it to a view before it has initialized fully and created it's MPInlineVideoOverlay layer. Because of this I had to create an instance variable called controlView in the code below because sometimes it doesn't exist when this code runs. This is why I have the last bit of code where the function calls itself again in 0.1 seconds if it isn't found. I couldn't notice any delay in the button appearing on my interface despite this delay.
-(void)setupAdditionalControls {
//Call after you have initialized your MPMoviePlayerController (probably viewDidLoad)
controlView = nil;
[self recursiveViewTraversal:movie.view counter:0];
//check to see if we found it, if we didn't we need to do it again in 0.1 seconds
if(controlView) {
UIButton *backButton = [UIButton buttonWithType:UIButtonTypeCustom];
[controlView addSubview:backButton];
} else {
[self performSelector:#selector(setupAdditionalControls) withObject:nil afterDelay:0.1];
}
}
-(void)recursiveViewTraversal:(UIView*)view counter:(int)counter {
NSLog(#"Depth %d - %#", counter, view); //For debug
if([view isKindOfClass:NSClassFromString(#"MPInlineVideoOverlay")]) {
//Add any additional controls you want to have fade with the standard controls here
controlView = view;
} else {
for(UIView *child in [view subviews]) {
[self recursiveViewTraversal:child counter:counter+1];
}
}
}
It isn't the best solution, but I am posting it in case someone else is trying to do the same thing. If Apple was to change the view structure or class names internal to the control overlay it would break. I am also assuming you aren't playing the video full screen (although you can play it fullscreen with embeded controls). I also had to disable the fullscreen button using the technique described here because the MPInlineVideoOverlay view gets removed and released when it is pressed: iPad MPMoviePlayerController - Disable Fullscreen
Calling setupAdditionalControls when you receive the fullscreen notifications described above will re-add your additional controls to the UI.
Would love a more elegant solution if anyone can suggest something other than this hackery I have come up with.
My solution to the same problem was:
Add the button as a child of the MPMoviePlayerController's view;
fade the button in and out using animation of its alpha property, with the proper durations;
handle the player controller's touchesBegan, and use that to toggle the button's visibility (using its alpha);
use a timer to determine when to hide the button again.
By trial-and-error, I determined that the durations that matched the (current) iOS ones are:
fade in: 0.1s
fade out: 0.2s
duration on screen: 5.0s (extend that each time the view is touched)
Of course this is still fragile; if the built-in delays change, mine will look wrong, but the code will still run.