iPhone：我想出了一个有趣的方法来绕过 API 限制。这行得通吗？
我试图解决的问题是：
当使用 UIImagePicker 时，它会随着设备旋转而自行调整。我不希望它这样做，而是应该始终保持纵向。我用谷歌搜索了很多，但没有找到任何解决方案（只是其他人有同样的未解决问题）。唯一的答案是使用私有 API 调用，我宁愿不冒险这样做。
-
但是，我遇到了“method swizzling” - 一种在运行时交换方法名称的方法。我打算做什么：
向 UIViewController 添加一个类别，该类别定义了“customShouldRotate”等方法，定义了不允许旋转的自定义行为。
在运行时将这些方法与 UIViewController 的默认旋转方法混合。
——
不过仔细一想，事情可能没那么简单。这就是原因 - 对于以下问题的任何答案将不胜感激。
我正在调整的方法是在 UIViewController 中，而不是 UIImagePickerController 中。我无法直接在图像选择器中进行混合，我已经尝试过通过子类化，它似乎是处理旋转的子视图的控制器而不是 UIImagePickerController 本身。调配的方法是否会传递给子类，如果没有，那么是否有解决方法可以做到这一点？
它可能不是 UIImagePickerController 中使用的 UIViewController 的正常旋转方法。有什么方法可以判断吗？
Apple 会同意方法调配吗？我没有使用私有 API 调用，但话又说回来，如果他们拒绝了我也不会太惊讶。
-
这整个想法是否可行/值得尝试 - 或者，如果有人实际上以不同的方式解决了原始问题，那么那就更好了。
The problem that I'm trying to solve is this:
When using a UIImagePicker, it adjusts itself as the device is rotated. I don't want it to do this, rather it should constantly stay in the portrait orientation. I've googled aplenty and haven't found any solution (just others with the same unsolved problem). The only answer was to use a private API call, I would rather not risk doing this.
-
However, I came across 'method swizzling' - a way of swapping method names at runtime. What I'm planning to do:
Add a category to UIViewController that defines a methods such as 'customShouldRotate' defining custom behavior that won't allow rotation.
Swizzle these methods with the default rotation methods of UIViewController at runtime.
-
After a bit of thought though, it might not be that simple. Here's why - any answers to the following would be much appreciated.
The method I'm swizzling is in UIViewController, not UIImagePickerController. I can't swizzle in the image picker directly, I've already tried via subclassing and it appears to be a subview's controller that's handling the rotation rather than UIImagePickerController itself. Will swizzled methods pass down to subclasses, if not then is there a workaround to do this?
It may not be a normal rotation method from UIViewController that is being used in UIImagePickerController. Is there any way to tell?
Will Apple be OK with method swizzling? I'm not using a private API call, but then again I wouldn't be overly surprised if they rejected it anyway.
-
Is this whole idea feasible/worth trying - or, if someone's actually solved the original problem in a different manner then that would be even better.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
方法调配很好：Apple 使用静态分析器检查私有 API。如果您可以重载、混合或执行任何操作来实现相同的效果，而无需调用私有 API，则分析器不会识别该效果。
苹果可能拒绝你的唯一原因是修改“标准”行为 - 但我怀疑这种情况不会发生。最糟糕的是你的应用程序被踢回给你，你必须恢复原来的行为。
Method swizzling is fine: Apple check for private APIs using a static analyzer. If you can overload, swizzle, or do what you will to achieve the same effect without calling a private API it won't be picked up by the analyzer.
The only reason Apple may reject you for is for modifying 'standard' behaviour - but I suspect this won't happen. The worst thing is your app gets kicked back to you and you have to reinstate the original behaviour.