9

私は、1 つのアクティビティ ( BaseGameActivityを拡張する) だけを持つアプリに取り組んでおり、複数のフラグメントを切り替えます (Google のサンプル コードの状態のように)。

現在、2 台のデバイスでマルチプレイヤー ゲームをテストしています。両方のユーザーが正常にログインしたり、メッセージを相互に送信したりできます。ただし、一方のユーザーがデバイスを回転させた瞬間、部屋から追い出されます。

アクティビティが破壊されて再作成されているため、これは理にかなっていると思います。しかし、私が理解できないのは、ユーザーがデバイスを回転させ、ゲームの状態 (ログイン、ルームへの参加など) をそのまま維持できるようにするために何をする必要があるかということです。

  • 1 つの考え: android:configChanged="orientation|screenSize" - しかし、Android はそれを思いとどまらせます (ほとんどの場合、正当な理由から) - しかし、これは、デバイスの向きが変わっても部屋にとどまるために Google Play ゲーム サービスで行かなければならない方法ですか? ?

  • 「onRetainNonConfigurationInstance()」を使用して GameHelper インスタンスを保存し、アクティビティが再作成されたときに再度使用するのはどうですか?

  • または、何らかの形でゲーム接続 (サインイン、ルームへの参加など) をサービスに実装しますか?

それとも、私はこれについてすべて間違った方法で考えていますか?! ご意見とご協力ありがとうございます。可能であれば、コード例も大歓迎です。

4

3 に答える 3

1

これがアイデアです。でもその前にちょっとイラスト。

Android アプリは、メモリまたはそれが決定する何らかの理由により、いつでも Android Resource Manager によって強制終了される可能性があります。したがって、「常時オン」の永続的なデーモンを保持するために、サービスを使用します。

アプリはその状態をサービスに伝えることができるため、サービスはここにあると便利です。サービスはすべての実際のデータ (接続されている、どのサーバーに接続されているか、サーバー接続など) を保持し、サービスに再接続するだけです。

このサービスを使用すると、リモート クライアントが切断されたこと (サービスがアプリにバインドされていない場合、ユーザー定義が切断されていること) を通知する可能性があるという追加の利点が追加され、サービスがクライアント間の仲介を行うため、きめ細かな接続に役立つ可能性があります。サーバーと GUI クライアント。すべての意図と目的において、サービスはゲームをプレイする実際のクライアントであり、サービスに何をしようとすべきかを伝える gui クライアントによって駆動されているだけです。このようにして、サービスはユーザーには見えず、プレイステートは常に保持されます。

しかし、最初に、AndroidManifest を介してアプリをシングルトンにして、アプリケーションの 1 つのインスタンス (singleTop) のみを使用するか、常に同じプロセスを使用します (sameProcess ですが、それが少しでも役立つかどうかは不明です)。

それが失敗した場合は、サービスが進むべき道であることが最終的にわかるまで、痛みの少ない良いルートをたどります。そのため、問題の軽量な修正があるかもしれません。単純なデーモン サービスが必要なだけで、1 日で済むかもしれません。

于 2013-07-11T13:54:20.710 に答える
1

私はまったく同じ問題に遭遇し、現在これの修正に取り組んでいます。

最初に私はちょうど使用して実装しました

    android:configChanges="keyboardHidden|orientation|screenSize"
    android:screenOrientation="portrait"

私のゲームも、ゲーム サービスのフラグメント ベースの実装も、向きの変更を正しくサポートしていなかったためです。つまり、欠点は Google が提供するものではなく、自分のコードにあると確信しています。

私の場合、プレイヤーのいずれかが「回転」すると、フラグメントが正しく再起動されないため、ユーザーはゲームから追い出されます。次に onLeftRoom コールバックを受け取り、この時点で終了することを選択します。

この機会に、ゲーム サービスのフラグメント ベースの実装を改善し、簡素化します。これが私の基本的な計画です。

以下を含むフラグメント アクティビティ (ABS):

  • 「Quick Game」、「Leaderboards」などのいくつかのシンプルな UI フラグメント タブ。

  • 「BaseGameActivity」サンプルに相当する「ヘッドレス」(UI なし) setRetainInstance(true) フラグメントであり、GameHelper へのすべての呼び出しを実行します。

  • GameHelper - 変更されていない提供バージョン。

このアプローチの利点は、「ヘッドレス」フラグメントを使用することで、現時点で見られるトリッキーな問題のいくつかを回避できることです。たとえば、いくつかのフラグメントを再起動した後でも、 getActivity() null エラーが発生し、このような単純な小さなゲームには複雑すぎると思われる問題を解決しようとしていることに気づきます。

ちなみに、ゲーム（少なくとも私のようなばかげたもの）が私の電話/タブでサービスとして実行されていたら、私は満足しません-しかし、それは私の意見です. 親アクティビティで死ぬ setRetainInstance(true) フラグメントは完全に適切だと思います。

これについて他の人の考えを聞くことに興味があります。

知らない人のために（ソースhttp://www.vogella.com/articles/AndroidFragments/article.html#headlessfragments1）：

8.2. 構成変更を処理するための保持されたヘッドレス フラグメント ヘッドレス フラグメントは、通常、構成変更全体またはバックグラウンド処理タスクで何らかの状態をカプセル化するために使用されます。この目的のために、ヘッドレス フラグメントを保持するように設定します。保持されたフラグメントは、構成の変更中に破棄されません。

于 2013-07-12T00:00:26.103 に答える