私はAndroid <3.0で使用されているメニューボタンのファンです。これは、ゲームアプリにとって非常に便利だったためです。重要であるが、ゲームプレイに関係のない機能(ゲームの保存、参照情報リンク)、メインゲームインターフェースを煩雑にしない場所に配置しますが、それでも簡単にアクセスできます(オプションメニュー)。
このキーの使用は、メニューボタンを削除してアクションバーに置き換えたため、3.0で問題になりました。アクションバーは、フルスクリーンで実行するのが好きなゲームには本当に適していません。アクションバーなし-オプションメニューにアクセスできません。ただし、タブレットにはそれほど多くのユーザーがいなかったため、これをテストする時間がなかったため、しばらく無視することができました。
ただし、ICSは、MENUボタンが明らかに戻ってこないため、これは深刻な問題になります。今ではタブレットだけでなく電話でもこの問題に対処する必要はありません。
この問題に対する私の最初の解決策は、GUIにソフトボタンを配置して、ハードメニューボタンを置き換えることです。
this.openOptionsMenu();
そして、すべてがICSで完全に機能するようになりました。
ただし、これはハニカムでは機能しません。 ActionBarが表示されていない場合、openOptionsMenuを呼び出しても何も起こりません。
これに対処する方法についての考えはありますか?
私はいつでもTargetSDK <11を使用することに戻ることができると思います(それにより、ActionBarをタブレットに表示するように強制します)が、これを見る限り、これは単に問題を未来に押し込んでいるだけで、これはしたくないと思います。
オプションメニューを完全にドロップし、コンテキストメニューのみを使用しますか? [明確化:これにより、オプションメニューを開くのではなく、コンテキストメニューのみを使用するようになりました-少なくとも今のところ-これらはすべてのデバイスで動作します]。
オプションメニュー/アクションバーの混乱全体で同様の問題を抱えている他の人がやることに決めたことを聞いてみたい。
メニューボタンがゲームでなくても重要になる別のシナリオを共有しましょう。
ActionBarのようにある程度動作する独自のツールバーをアプリに実装します。私のアプリは1.5 SDKでリリースされたので、そうしました。当時はそのような概念はありません。そして、ツールバーに対応するために、デフォルトのタイトルバーを非表示にします。ただし、一部のアクションはメニュー機能を介して実行されます。
Galaxy Nexusでは、ActionBarを使用していない場合はメニューボタンがなく、アプリがまだ1.5をサポートしているため、それが痛いので。
さまざまな回避策がありますが、簡単なものはありません。
とは言うものの、私が思いつく唯一の回避策は、ツールバーのすべてのオプションをユーザーに提供することです。したがって、メニューはまったく必要ありません。ツールバーの一部ではない2つのアクションしか持っていないため、これを行うことができます。
あなたの状況では、ボタンのコンテキストメニューは、すべてのアイテムが異なるコンテキストであるリストアイテムのコンテキストメニューを持つのと比較して、ゲームには実行中のコンテキストが1つしかないため、ゲームの悪い解決策ではありません。
ところでopenOptionsMenu
がICSで動作し、しばらくしてHoneyCombを捨てることができる場合(今でもユーザーベースが低すぎる場合)、両方のメニューを提供してみてください バージョンに基づいて 。
編集:さて、下のナビゲーションバーにあるメニューs/wボタンを取得する別の方法もあります。 targetSdkVersion
を11未満に設定するだけです。詳細については、 plsはsoln全体を読み取ります
ただし、ICSは、MENUボタンが明らかに戻ってこないため、これを深刻な問題にします。
より正確には、メニューのようなもののためにオフスクリーンボタンを使用するかどうかは、デバイスのメーカー次第です。 Android 4.0の互換性定義ドキュメントを引用:
ホーム、メニュー、および戻る機能は、Androidナビゲーションパラダイムに不可欠です。デバイスの実装は、アプリケーションの実行時にこれらの機能をユーザーが常に利用できるようにする必要があります。これらの機能は、専用の物理ボタン(機械式または静電容量式のタッチボタンなど)、または専用のソフトウェアキー、ジェスチャー、タッチパネルなどを使用して実装できます。
そのため、オフスクリーンMENUボタンがあることを期待することはできません。
これに対処する方法についての考えはありますか?
ゲームUIの一部として独自の「メニュー」を作成します。私は、オプションメニューを使用するためにフルスクリーンが必要だと思うゲームを期待しません-実際、それをしたゲームを見たことを覚えていません(確かに、私は大物のゲームプレーヤーではありません) 。私がプレイしたすべてのゲームは、MENUプレスでは何もしません。むしろ、「メニュー」と見なされる可能性のあるものはすべて、ゲームUIに直接実装されます(たとえば、ゲームUIのルックアンドフィールでフォーマットされ、実行するための選択肢を提供する画面につながるボタン)。
オプションメニューを完全にドロップし、コンテキストメニューのみを使用しますか?
ユーザーはメニューを表示するためにどこを長押しすればよいかわからないので、それはひどいでしょう。
そして、メニューボタンのことわざに最後のスパイクを置くために、Googleは最後の別れを量ります。
http://Android-developers.blogspot.com/2012/01/say-goodbye-to-menu-button.html
マイケル、私はまったく同じ状況にあり、カスタムダイアログを使用してオプションメニューを実装することで解決しました。 ICSの方が下のレガシーオプションメニューよりも見栄えがいい。このように構成されている
minSdkVersion = 8 targetSdkVersion = 14 SDKビルドバージョン8(Eclipseのsettings.cで14に設定できますが、タイプセーフが提供されます)
API <10のユーザーはハードメニューボタンを使用し、標準オプションメニューを表示します。 APIが10以上のユーザーには、アプリに3つのドットのアイコン(オーバーフローメニュー)が表示され、クリックするとカスタムダイアログメニューが表示されます。また、新しいICS [設定]などを参照してください。
メニューボタンが戻ってくるようには見えないため、ICSを使用しているユーザーは1%未満ですが、レガシーの壁を破りたかったのです。
最近のブログ投稿に応えて、彼らは開発者にメニューよりもアクションバーの使用を開始してほしいと思っているようですが、API => 3.0およびAPI <3.0をサポートしたい場合、これは苦痛になります。したがって、API <3.0と互換性のあるカスタムアクションバーを作成するか(SDKで例を見つけることができます)、または...先週試しました:
メニューボタンが私のICSタブレットに表示されないという問題もありました。 ActionBarとメニューオーバーフローボタンの両方が表示されたので、これが現在の回避策です(少なくとも私が取り組んでいるプロジェクトでは)。