未调用iOS9 Safari内容拦截器扩展

Pav*_*nek 7 safari safari-extension ios ios9 safari-content-blocker

我正在玩XCode7测试版,试图测试闪亮的新" 内容拦截器扩展 ".示例类采用与NSExtensionRequestHandling(已知)共享扩展相同的协议.从共享扩展的本质区别在于该类是一个普通的NSObject,而不是一个*ViewController子类,因为,你知道,一个阻挡延伸不应该被显示任何UI反馈.这至少是我的理解.无论如何,beginRequestWithExtensionContext应该将阻塞声明JSON提供给扩展点的关键方法不会被调用.该扩展程序确实具有TRUEPREDICATE其功能,NSExtensionActivationRule并且Safari确认在新的Safari配置"内容拦截器"中存在我的主机应用程序.但仍然没有雪茄.

有人知道它是否应该在测试的早期就已经开始工作了,还是只是一个新闻稿?

而且,哦,虽然我们在这里,是否有任何关于声明JSON格式的文档,或者只是我的Google-Fu让我失望了?:)

Chr*_*nes 5

你怎么知道扩展没有被调用?

我构建了一个非常快速的测试应用程序并NSLog()beginRequestWithExtensionContext方法中做了一个简单的操作,并且在扩展程序打开时调用它.

此外,fwiw,+[SFContentBlockerManager reloadContentBlockerWithIdentifier:completionHandler:]可让您随意触发主应用程序的更新.

  • 没有日志,也没有断点给我.看到你的帖子,我甚至愚蠢地尝试在ObjC中制作一个新应用而不是Swift.扩展正在播放负鼠.你能在某个地方发布你的主机应用程序仓库吗? (2认同)
  • 我分叉你的repo,构建它并且*不*WFM :(`reloadContentBlockerWithIdentifier`甚至没有在XCode7b3中调用完成处理程序,并在最新的XCode7b5中使用`ContentBlockerErrorDomain Code = 3`调用它.阻塞程序扩展不均匀实例化,执行得越少`beginRequestWithExtensionContext`.你能检查一下吗?确实,我没有`reloadContentBlockerWithIdentifier`调用,但是如果你使用较旧的XCode7 beta进行测试,它现在可能也会被打破.如果没有. ..我要吓坏了. (2认同)
  • 所以我接受你的回答.它没有给出我想要的银弹,但基本上它就是你所说的:它应该起作用.现在有了iOS9,它显然可行:)在我这边,它足以放弃我在XCode7b1中创建的测试项目,并在XCode7 GM中重新制作它.完全相同的裸骨代码.我永远不会知道这是什么问题,但我不在乎了. (2认同)