检测iOS 10.3应用程序评级对话框显示的机制？ [英] Mechanism to detect display of iOS 10.3 app rating dialog?

问题描述

TL; DR：iOS上是否有某种方法可以检测iOS 10.3中添加的Storekit App Rating对话框的存在/显示？

TL;DR: Is there some way on iOS to detect the presence/display of the Storekit App Rating dialog added in iOS 10.3?

我最近添加了支持我的应用程序的新应用评级对话框使用：

I've recently added support for the new app rating dialog to my apps using:

[SKStoreReviewController requestReview];

但是，我知道有一些使用注意事项（如此处记录），即在调用上述功能时可能会或可能不会显示对话框，不包括客户的情况已经对应用程序进行了评级，或者客户已经对对话框进行了3次调整。

However, I'm aware there's some caveats of usage (as documented here), namely that the dialog may or may not be presented on calling the above function, the not cases including if the customer has already rated the app or the customer has dimissed the dialog 3 times.

我也知道Apple不希望对话框的呈现由a直接调用用户操作，因此存在要报告的对话框：

I'm also aware that Apple doesn't expect presentation of the dialog to be directly invoked by a user action and therefore the presence of the dialog to be reported:

虽然在用户体验流程中有意义时应调用此方法在您的应用中，评级/评论请求视图的实际显示受App Store政策的约束。由于此方法可能会或可能不会显示警报，因此响应按钮点击或其他用户操作来调用它是不合适的。

Although you should call this method when it makes sense in the user experience flow of your app, the actual display of a rating/review request view is governed by App Store policy. Because this method may or may not present an alert, it's not appropriate to call it in response to a button tap or other user action.

但这并不能阻止UX团队将这些按钮放在图形设计中并询问我们能否知道对话框是否显示？

But that doesn't stop the UX team putting these buttons in the graphic designs and asking "can we know if the dialog was shown"?

所以，我的问题是是否有其他间接方式可以确定此对话框的显示？

So, my question is, is there some other indirect way that the presentation of this dialog can be determined?

我最近使用Appium对Android和iOS应用程序进行了一些自动测试使用Xpaths查找本机UI元素，所以只是想知道是否可以在iOS应用程序的上下文中实现相同的功能。

I've recently been doing some automated testing of both Android and iOS apps using Appium and using Xpaths to find the native UI elements, so just wondering if the same can be achieved from within the context of an iOS app.

推荐答案

你的问题让我思考，这比我想象的要容易。

Your question got me thinking, and it is easier than I would have thought.

我的第一个想法是检查 UIWindow 相关内容 - 快速查看文档显示，有 UIWindow 相关通知 - 太棒了！我做了一个快速的项目，订阅了所有这些并提交了审查控制器。这会弹出日志：

My first thought was to check UIWindow related things - a quick look at the documentation revealed, that there are UIWindow related notifications - great! I made a quick project, subscribed to all of them and presented the review controller. This popped up in the logs :

method : windowDidBecomeVisibleNotification:  
object -> <SKStoreReviewPresentationWindow: 0x7fe14bc03670; baseClass = UIApplicationRotationFollowingWindow; frame = (0 0; 414 736); opaque = NO; gestureRecognizers = <NSArray: 0x61800004de30>; layer = <UIWindowLayer: 0x61800003baa0>>

因此，为了检测审核控制器是否已显示，您需要订阅通知并检查它的 object 属性以找出它的类：

So in order to detect if the review controller was shown, you'd need to subscribe to a notification and inspect it's object property to find out its class :

- (void)viewDidLoad {
    [super viewDidLoad];

    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(windowDidBecomeVisibleNotification:)
                                                 name:UIWindowDidBecomeVisibleNotification
                                               object:nil];
}

- (void)windowDidBecomeVisibleNotification:(NSNotification *)notification {
    if ([notification.object isKindOfClass:NSClassFromString(@"SKStoreReviewPresentationWindow")]) {
        NSLog(@"the review request was shown!");
    }
}

现在请记住 SKStoreReviewPresentationWindow 不可公开访问 - 因此您不能简单地编写 [SKStoreReviewPresentationWindow类] ，并使用欺骗系统NSClassFromString 就是这样 - 欺骗系统。不幸的是，另一个最有趣的通知， UIWindowDidResignKey ，没有发出 - 我希望主窗口会辞职，但不幸的是没有。一些进一步的调试也表明主窗口仍然是关键而不是隐藏。您当然可以尝试将 notification.object 与 [UIApplication sharedApplication] .window 进行比较，但也有其他窗口正在显示 - UITextEffectsWindow 和 UIRemoteKeyboardWindow ，尤其是首次显示警报时，两者都不公开。

Now bear in mind that SKStoreReviewPresentationWindow is not publicly accessible - so you can't simply write [SKStoreReviewPresentationWindow class], and tricking the system by using NSClassFromString is just that - tricking the system. Unfortunately the other most interesting notification, UIWindowDidResignKey, was not issued - I hoped that the main window would resign, but unfortunately not. Some further debugging also showed that the main window remains key and not hidden. You could of course try comparing the notification.object to [UIApplication sharedApplication].window, but there were also other windows being shown - UITextEffectsWindow and UIRemoteKeyboardWindow, especially when the alert was first shown, and both of them are also not public.

我认为这个解决方案是一个黑客攻击 - 苹果公司很容易改变这个解决方案。但最重要的是，这可能是审查期间拒绝的理由，因此请自担风险。我在iPhone 7+模拟器上测试了这个，iOS 10.3，Xcode 8.3.2

I'd consider this solution a hack - it is prone to changes by Apple that will break it. But most importantly, this could be grounds for rejection during review, so use at your own risk. I tested this on iPhone 7+ Simulator, iOS 10.3, Xcode 8.3.2

现在，因为我们现在知道它了有点可以检测审核控制器是否显示，更有趣的问题是如何检测到 NOT 显示。您需要引入一些超时，之后您会执行某些操作，因为警报未显示。这可能会让您的应用感觉被挂起，因此对您的用户来说这将是一次糟糕的体验。此外，我注意到审查控制器没有立即显示，因此更有意义的是为什么Apple不建议在按下按钮后显示它。

Now, since we now know that it is kinda possible to detect if the review controller was shown, a more interesting problem is how to detect that it was NOT shown. You'd need to introduce some timeout after which you'd do something because the alert was not shown. This can feel like your app hanged, so it would be a bad experience for your users. Also, I noticed that the review controller is not shown immediately, so it even makes more sense why Apple doesn't recommend showing it after pressing a button.

这篇关于检测iOS 10.3应用程序评级对话框显示的机制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！