如何阻止 iOS 7 控制中心控制音乐应用程序? [英] How to block iOS 7 control centre from controlling music app?

查看:29
本文介绍了如何阻止 iOS 7 控制中心控制音乐应用程序?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的应用程序通过成为远程控制事件的第一响应者,使用远程控制明确阻止用户表单,例如来自 iOS7 之前的旧跳板、耳塞.但是,在 iOS7 上,同样的代码无法绕过控制中心音乐控件.

Our app explicitly blocks user form using remote-control, e.g., old springboard from pre-iOS7, earbud, by becoming the first responder to the remote-control events. However, on iOS7, the same code fails to bypass the control centre music controls.

从测试来看,控制中心似乎绕过了所有音乐控制事件,包括 UIEventSubtypeRemoteControlPause 和 UIEventSubtypeRemoteControlPlay,以及 UIEventSubtypeRemoteControlTogglePlayPause.

From out tests, control centre seems to have bypassed ALL music control events including UIEventSubtypeRemoteControlPause and UIEventSubtypeRemoteControlPlay, and UIEventSubtypeRemoteControlTogglePlayPause.

是控制中心有自己的远程控制协议还是iOS7中拦截远程控制事件的方式发生了变化?

Is it that control centre has its own protocol for remote control or that the way to intercept remote-control events has changed in iOS7?

相同的阻塞代码在 iOS6 设备上仍然可以完美运行.这是我们要做的:

The same blocking code still works perfectly with iOS6 devices. Here is what we do:

  1. 在我们的 appDelegate 中添加了一个方法:

  1. Added a method in our appDelegate:

(BOOL)canBecomeFirstResponder {返回是;}

(BOOL)canBecomeFirstResponder { return YES; }

在 applicationDidBecomeActive 中调用:

Call this in applicationDidBecomeActive:

[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];

[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];

//将自己设置为第一响应者[自己成为FirstResponder];

// Set itself as the first responder [self becomeFirstResponder];

在 applicationWillResignActive 中调用这个

Call this in applicationWillResignActive

//关闭远程控制事件传递[[UIApplication sharedApplication] endReceivingRemoteControlEvents];

// Turn off remote control event delivery [[UIApplication sharedApplication] endReceivingRemoteControlEvents];

//辞去第一响应者的职务[self resignFirstResponder];

// Resign as first responder [self resignFirstResponder];

终于添加了

(void)remoteControlReceivedWithEvent:(UIEvent *)receivedEvent {

(void)remoteControlReceivedWithEvent:(UIEvent *)receivedEvent {

    if (receivedEvent.type == UIEventTypeRemoteControl) {
        
        switch (receivedEvent.subtype) {
                
            case UIEventSubtypeRemoteControlTogglePlayPause:
                NSLog(@"Received: UIEventSubtypeRemoteControlTogglePlayPause\n");
                break;
                
            case UIEventSubtypeRemoteControlPreviousTrack:
                NSLog(@"Received: UIEventSubtypeRemoteControlPreviousTrack\n");
                break;
                
            case UIEventSubtypeRemoteControlNextTrack:
                NSLog(@"Received: UIEventSubtypeRemoteControlNextTrack\n");
                break;
                
            case UIEventSubtypeRemoteControlPlay:
                NSLog(@"Received: UIEventSubtypeRemoteControlPlay\n");
                break;

            case UIEventSubtypeRemoteControlPause:
                NSLog(@"Received: UIEventSubtypeRemoteControlPause\n");
                break;

            case UIEventSubtypeRemoteControlStop:
                NSLog(@"Received: UIEventSubtypeRemoteControlStop\n");
                break;
                
            default:
                NSLog(@"Received: Some remove control events\n");
                break;
        }
    }
}

任何指针将不胜感激.

推荐答案

我想我对发生的事情有了更好的了解,至少在 CoreAudio 级别.

I think I have a better idea of what happened, at least at the CoreAudio level.

当应用的音频会话类别为单独环境时,音乐应用的播放事件会触发音频会话中断,类似于闹钟或电话.这个将触发应用程序的音频会话中断侦听器回调,并具有进入中断"状态.

When the app's audio session category is solo-ambient, the music app's play event triggers an audio session interruption similar to an alarm clock or a phone call. This will trigger app's audio session interruption listener callback with the "enter-interruption" state.

然而,音乐应用程序的暂停事件并没有像人们预期的那样触发具有退出中断"状态的侦听器回调.这个缺少的退出调用有效地冻结了我们应用程序的音频会话.退出控制中心也不会触发它.同样的事情适用于物理遥控器,除了可以使用我在上一封电子邮件中所说的 firstResponder 技巧来阻止物理遥控器.它不适用于控制中心.

However, the music app's pause event does not trigger the listener callback with the "exit-interruption" state, as one would expect. This missing exit call effectively freezes our app's audio session. Quitting the control centre does not trigger it either. Same thing applies to a physical remote-control, except that the physical remote-control can be blocked using the firstResponder trick said in my last email. It does not work with Control Centre.

除非我遗漏了一些明显的东西,否则我更确信 CoreAudio 或命令链中的其他框架存在两个错误.

Unless I'm missing something obvious, I am more convinced that there are two bugs in either CoreAudio or other frameworks in the chain of command.

Bug 1:音频会话中断听众的退出呼叫如果在那里先进行了入口呼叫,则无法从音乐遥控器进行.

Bug 1: Audio session interruption listener's exit call cannot be made from music remote control if the entrance call is made first there.

Bug 2:控制中心的音乐遥控器不符合遥控器事件机制.

Bug 2: Control Centre's music remote control does not conform to remote-control event mechanism.

我很惊讶从来没有人报告过这个.

I'm just surprised that no one ever reported this.

除非有人提出不同的建议,否则我想我会提交错误报告.

I think I'm going to file a bug report unless someone suggests differently.

更新错误 2 是误报.在 iOS7 SDK 上干净重建所有东西几次后,我们发现问题消失了.错误 1 ​​仍然存在.

UPDATE Bug 2 was a false alarm. After clean rebuilding everything over iOS7 SDK for a couple times, we found that the problem went away. Bug 1 still holds.

这篇关于如何阻止 iOS 7 控制中心控制音乐应用程序?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆