UIBarButtonItem
はサブクラス化されていないためUIView
、のような通常の特性を取得することは不可能frame
です。
これを行う1つの方法は[barButtonItem valueForKey:@"view"]
これは完全に機能し、GestureRecognizer(たとえば)を基になるに追加することができますUIView
。
ただし、これはプライベートUIKit
API違反ですか?
UIBarButtonItem
はサブクラス化されていないためUIView
、のような通常の特性を取得することは不可能frame
です。
これを行う1つの方法は[barButtonItem valueForKey:@"view"]
これは完全に機能し、GestureRecognizer(たとえば)を基になるに追加することができますUIView
。
ただし、これはプライベートUIKit
API違反ですか?
これは、検証時に即座に拒否されるという点では非公開ではありませんが、脆弱であると見なされるほど非公開です(つまり、新しいiOSバージョンは、コードを使用しているアプリストアの既存のアプリを壊す可能性があります)。
同様のコード(KVCを介してUIToolbarのbackgroundView ivarをフェッチする)がアプリストアの検証に合格し、本番環境で使用されていると言えます。
悪い可能性がある場合は、メソッドをでラップする必要があり@try { ... } @catch
ます。これにより、新しいiOSリリースで失敗する可能性のあるKVCをインターセプトできます。
「それは私的ではない」ための5つの証拠
それはあなたが他の方法で得ることができる特性です。これを試してみてください。これらのビューの1つは、実際、問題の_view
ivarですUIBarButtonItem
。これは、これへのアクセスUIView
自体が禁止されていないことを示していますが、KVOの方法は疑わしいかもしれません(しかし、私はそれを疑っています)。
NSArray *array = self.toolBar.subviews;
for (UIView *view in array) {
view.backgroundColor = UIColor.greenColor;
}
これらは実際にこのプロパティのKVOをトリガーします。ivarsはKVOAPIをトリガーする必要はありませんよね?
@Farcallerは、AppStoreで販売されている同様のケースについて言及しています。彼/彼女は質問がそこにある最初の20分以内に答えたので、これを行うアプリがApp Storeに何千もあるかもしれないと仮定するのは合理的です(しかし安全ではありません!)。
このUIViewは、ボタンが押されるたびに下塗りされるため、たとえば、ジェスチャーレコグナイザーを設定して実行することはできません。view
ただし、が置き換えられるたびに同じジェスチャレコグナイザを設定し続けることができます。私にとって、これは実際にはそれがプライベートAPIのものではないというより多くの証拠ですが、それを使用するときは非常に注意する必要があります(そして、KVOを使用して最新のものがあることを確認してください)。
私のアプリはAppStoreで販売されており、これを行っています。