バックグラウンド
通知の発火にこの不一致が見られる理由に関しては、おそらくKVOの動作に関係しています。プロパティの値を観察します。この場合、statusBarHidden
。ただし、通知を受け取るには、そのプロパティが存在するセッターを介して変更されている必要があります。
通知は魔法のように発生することはないため、セッターの副作用として効果的にコーディングする必要があります。(これは、プロパティをコーディングするときに自動的に行われることがよくあります)ただし、そのプロパティを持つクラスは、ivarを直接変更することもできます。この場合、次のようUIApplication
な内部構造体_applicationFlags
があります。
unsigned int statusBarHidden:1;
したがって、setStatusBarHidden:withAnimation:
基礎となるデータメンバーを直接変更するだけで、オブザーバーをコールバックするために必要なセッターをバイパスすることは完全に可能です。
解決?
回避策として、このアプリがアプリストア用であるかどうかについては言及していません(個人/趣味の目的であるか、エンタープライズアプリであるか、脱獄アプリである可能性があります)。
オプションになる可能性のあることの1つは、メソッドswizzlingを使用して、のデフォルトの実装をsetStatusBarHidden:withAnimation:
独自の実装に置き換えることです。独自の実装ではsetStatusBarHidden:
、を呼び出すだけで、KVOが再度有効になります。または、アニメーションを保持したい場合は、GCDを使用して、アニメーションの終了setStatusBarHidden:
にかかる時間の後に実行するようにスケジュールすることができますsetStatusBarHidden:withAnimation:
。そうすれば、アニメーションを取得でき、を呼び出すことでKVOをトリガーすることもできますsetStatusBarHidden:
。
メソッドのスウィズリングがAppStoreアプリで常に拒否されるかどうかは私にはわかりません。私はそれが(少なくともiOSフレームワークのメソッドをスウィズリングするとき)そうだと思ったが、これによれば、それは許可されているか、すり抜けることができる。
次の質問は、 「メソッドのスウィズリングが、パブリックAPIに含まれているにもかかわらず、Appleが本当に避けてほしいものである場合、それを回避する方法はありますか?」です。
私がリンクしたStackOverflowの質問の人々が嘘をついていない限り、それはレビューを通過しているように見えます(少なくとも時々)。したがって、自動化された方法でテストされていない可能性があります。たぶんそれは、標準機能が異なって機能しているのを見る人間のテスターによって視覚的に認識されることがあります。彼らが推測する方法は、メソッドのスウィズリングの結果であるに違いありません。この場合、ステータスバーのUIの動作を変更するために実際に使用するのではなく、通知をラッチするだけなので、気にしないでください。
または、既知のiOS API(スウィズリングで使用)のセレクターを検索している可能性があります。その場合、文字列から構築されたセレクターは、検出を回避するために、非常に簡単に難読化できます。
とにかく、いくつかのオプション...