問題タブ [android-lifecycle]

Android の初心者として、アクティビティのライフサイクルについて疑問に思い始めました。人のリストを読み込んで表示するアクティビティがあります。人をクリックすると、その人の詳細を表示する別のアクティビティを開きたいです。私は現在、「PersonDetailActivity」にインテントを作成してこれを行っています。ここまでは順調ですね。PersonDetail ページで、Person リストに戻るためのメニュー アクションが必要です。私は再び同じ手法を適用しました。つまり、PersonListActivity に戻るインテントを意味します。

ここで、PersonListActivity に戻ることが何を意味するのか疑問に思い始めました。新しいインスタンスが作成され、リストに表示される人物をリロードする必要がありますか? リストを再度リロードせずに、同じインスタンスに戻ることができますか? 次に、他のアクティビティへのインテントを介して自分自身へのポインターを渡す必要がありますか?

したがって、いつ意志とアクティビティが再インスタンス化され、いつ再インスタンス化されないか。ヒントや提案は大歓迎です。おそらく、私がまだ気づいていないこれらの前後のメニュー アクションに適用されるいくつかのパターンがあるでしょう。

ありがとう、

ヴィンセント

アクティビティを開いたときに、スケール アニメーションをアクティビティに適用しました。黒い背景に色を付けることができます。前の活動が一時停止しているので、何か可能ですか?

タブレットで連携する 2 つのアプリケーションがあります。ユーザーが1つのアプリケーションからバックアウトし、次にアプリを開いたときに oncreate が呼び出されますが、ホームに戻ってから戻った場合は oncreate が呼び出されないことに気付きました.. onPause、onStop、onResume は決してありません。呼び出されています..ユーザーが家に帰ったときにアプリが終了することを確認する方法が必要です..

または別のオプションは、他のアプリがアプリが開いているかどうかを確認して閉じることができるかどうかです..

助けてください

私はAndroidを初めて使用し、簡単なゲームを開発したいと思っています。

公式のAndroidサイトとstackoverflowでアクティビティのライフサイクルについて読んだことがありますが、ゲームの一時停止/再開について少しサポートが必要です：-/

ライフサイクル図に似たシーンを期待していましたが、画面をロックするとメソッドActivity.onDestroy()も呼び出されますが、onCreate()再度呼び出されます。呼ばれていないので混乱してonRestart()います！

画面の向きの問題について知っており、android:screenOrientation="landscape"役立つはずだったものを追加しました。

インターネットでよく説明されているアニメーションや衝突などの他のゲームの仕組みには満足していますが、一時停止/再開を管理することはできません。

誰かが包括的なチュートリアルを推奨したり、コード例を挙げたりできますか？一時停止、保存などが可能な単純なゲームのスケルトンを構築する方法をカバーするものは何でもありがたいです。

どうもありがとう

アクティビティがスタックに既に存在するかどうかをプログラムで確認し、再作成する代わりに再利用する方法はありますか?

ユーザーが複数のルートを介してアクティビティに入り、複数のルートを介して先に進むことができる状況が発生します。ただし、他のアクティビティを数回クリックすると、同じアクティビティに再びアクセスできます。スタックに既に存在することがわかっているときに、アプリが新しいアクティビティを作成するのを避けたいです。

これは私の設計が悪いだけかもしれません (これは私の最初のアプリです)。しかし、これをどのように管理できるのか疑問に思っていましたか? これに対する解決策はありますか？

ご存知のように、すべての Android アクティビティは、作成、開始、再開、実行、一時停止、停止、破棄します。このプロセスは、Android のマニュアルによく示されています。

このライフサイクルでは、アクティビティがどのように作成されるかを理解する可能性はありますか? つまり、アクティビティが直接呼び出されたのか、アクティビティが一度作成されて Android OS によって強制終了され、ユーザーが戻った後に再作成されたのかをどのように理解できますか?

より基本的には、アクティビティがセカンドライフかファーストライフかをどのように理解できますか?

編集：なぜこれが必要なのですか？
私のデザインでは、データがネットから読み込まれるメイン ページがあります。ユーザーが詳細をクリックすると、Web のセッションと同じように、データが静的オブジェクトに配置されます。これは正常に動作します。

しかし、ユーザーがセカンド ライフで詳細アクティビティを開始すると、静的オブジェクトのデータが強制終了され、nullpointer 例外が発生しました。

同じアーキテクチャのプロジェクトが 4 つあるので、この問題を解決したいと考えています。

こんにちは、
私のアプリでは、スレッドを一時停止するためにThread.sleep（100）を使用しようとしていますが、CPUの使用量を減らすためにバックグラウンドで使用していますが、再度開くとフリーズします。アプリを再度開いたときに、それが呼び出されていないこと
に気付きました。onResume

なぜ何かアイデアはありますか？

まず第一に、アクティビティの開始、一時停止、再開、停止についてのすばらしい説明を読みました。それは問題ありませんが、別の問題があります。

Android リファレンスのアクティビティ ライフサイクル図は、別のアクティビティを呼び出すと、呼び出し元のアクティビティに対して onPause() が呼び出され、後で他のアクティビティが終了すると、呼び出し元が onResume() を介して再開することを示しています。

したがって、最初のアクティビティが Main で、もう 1 つのアクティビティが Other である場合、サイクルは次のようになります (疑似コード)。

これは図が教えてくれることです。しかし、私の Main は最初に onStart() を取得し、次に onResume() を取得します。

何故ですか？私は何かを誤解していますか？

私のアプリケーションは、現在の画像データをファイルに保存しonPause()て、セッション間で保持します。ただし、アプリがフォアグラウンドにあるときにデバイスの電源を切ると、アプリが一時停止して何度も再起動され、ファイルへの書き込み中に最後に強制終了されることに気付きましたonPause()。

では、 を呼び出してから を呼び出すことでonPause()、 のレンダラー スレッドに画像データを要求して待機します。次に、データを取得したら、呼び出して、データを外部ストレージのファイルに書き込みます。その後、私は電話します。GLSurfaceViewgLSurfaceView.queueEvent()FutureTaskfutureTask.get()gLSurfaceView.onPause()super.onPause()

ただし、onPause()外部ストレージへの書き込み中に中断されたようで、次にアプリを再起動したjava.io.EOFExceptionときに、保存されたデータを読み込もうとすると報告されます。

デバイスの電源を切るとどうなるかを記録しました。トレースは次のとおりです。

その後、デバイスがシャットダウンするか、少なくともロギングが停止します。

おそらく、データは最初の 2 回は正しく保存されますが、アプリがファイルへの書き込みを完了していないため、3 回目にはスラッシングされます。

データを書き込むバッファを交互に使用し、正常に書き込んだ後に最新のデータを含むバッファへの参照を保存するダブルバッファソリューションを実装することを考えています。しかし、もっと簡単な方法があるに違いないと思います。

この問題を回避/回避する方法について何かアドバイスはありますか?

注: onPause() 全体で 1 秒近くかかるため、バックグラウンド スレッドで [GLSurfaceView から読み取り、GLSurfaceView を一時停止してファイルに保存] というシーケンスも試してみましたが、onCreate() がバックグラウンドスレッドがまだ画像データを書き込んでいる間に画像データを読み取ると、明らかにエラーが発生します。

パーセルのアンマーシャリング中に奇妙なクラッシュに遭遇し、onCreateそれを修正する方法にさらに混乱しました.

TrackEntity私のアプリは次のようなオブジェクトを保存します:

そしてそれに応じてロードします：

STATE_TRACKとして定義されTRACKます。

このコードは画面の回転の変更には問題なく機能しますが、アクティビティがバックグラウンドで破棄され (私はこれを Android Dev Tools で強制しました)、後で再起動するとクラッシュします。エラーは次のようになります。

私がそれを修正したように見える方法は、 の値をSTATE_TRACKからTRACKに変更することでしたappname:TRACK。

インスタンス状態バンドルのタグの命名に関する公式ドキュメントのメモは見つかりませんでした。誰かがそこで何が起こったのか説明してもらえますか?