アクティビティライフサイクルメソッド：onPostResumeの重要性
Activity に関する公式ドキュメントには、7つのライフサイクルメソッドがリストされています。
onPostResume()は、ライフサイクルメソッドとして引用されませんでした。
しかし、この方法は重要な方法だと思います。
ライフサイクル中に、アクティビティが非表示から表示状態に見える場合、
_onRestart()
onStart()
onResume()
onPostResume()
_順番に呼び出されています。
私のコードスニペット：
_package ravindra.projects.my_app_1;
import Android.content.Intent;
import Android.content.IntentFilter;
import Android.os.PersistableBundle;
import Android.support.v7.app.AppCompatActivity;
import Android.os.Bundle;
import Android.util.Log;
import Android.view.View;
import Android.widget.Button;
import Android.widget.EditText;
import Android.widget.TextView;
public class MainActivity extends AppCompatActivity implements View.OnClickListener{
private EditText txtUserName;
private EditText txtPassword;
Button loginButton;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.d("Ravi","Main OnCreate");
txtUserName=(EditText) findViewById(R.id.username);
txtPassword=(EditText) findViewById(R.id.password);
loginButton = (Button) findViewById(R.id.login);
loginButton.setOnClickListener(this);
}
@Override
public void onClick(View view) {
Log.d("Ravi", "Login processing initiated");
Intent intent = new Intent(this,LoginActivity.class);
Bundle bundle = new Bundle();
bundle.putString("userName",txtUserName.getText().toString());
bundle.putString("password",txtPassword.getText().toString());
intent.putExtras(bundle);
startActivityForResult(intent,1);
// IntentFilter
}
public void onActivityResult(int requestCode, int resultCode, Intent resIntent){
Log.d("Ravi back result:", "start");
String result = resIntent.getStringExtra("result");
Log.d("Ravi back result:", result);
TextView txtView = (TextView)findViewById(R.id.txtView);
txtView.setText(result);
}
@Override
protected void onStart() {
super.onStart();
Log.d("Ravi","Main Start");
}
@Override
protected void onRestart() {
super.onRestart();
Log.d("Ravi","Main ReStart");
}
@Override
protected void onPause() {
super.onPause();
Log.d("Ravi","Main Pause");
}
@Override
protected void onResume() {
super.onResume();
Log.d("Ravi","Main Resume");
}
@Override
protected void onStop() {
super.onStop();
Log.d("Ravi","Main Stop");
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.d("Ravi","Main OnDestroy");
}
@Override
protected void onPostResume() {
super.onPostResume();
Log.d("Ravi","Main PostResume");
}
@Override
public void onSaveInstanceState(Bundle outState, PersistableBundle outPersistentState) {
super.onSaveInstanceState(outState, outPersistentState);
}
@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
}
}
_以下のメソッドをスキップしてonPostResume()を実装することは目的を果たしませんか？
_onRestart(), onStart(), onResume()
_onPostResume()を実装する場合、これら3つのメソッドを実装する利点は何ですか？
_onRestart(), onStart(), onResume()
_onPostResume：
アクティビティの再開が完了すると呼び出されます（アクティビティの{@link #onResume}が呼び出された後）。通常、アプリケーションはこのメソッドを実装しません。システムクラスがアプリケーション再開コードの実行後に最終セットアップを行うことを目的としています。
次のことを行います
画面がユーザーに見えるようにし、アクティビティの最終設定を行います。
メッセージキューにあるコード「what」を持つメッセージの保留中の投稿を削除します。
すべてのフラグメントが再開されることを確認し、コントローラーのFragmentManagerによって管理されるすべてのフラグメントを再開状態に移動します。
コントローラーのFragmentManagerによって管理されるFragmentsの保留中のアクションを実行します。
ライフサイクルバイスをチェックすると、次のように機能しました
onResume（）-アクティビティ
onResume（）-フラグメント
check third point as explained aboveonPostResume（）-アクティビティ
onPostResumeは主に、サブクラスの再開が完了した後に何らかのセットアップを完了したいシステムアクション用に予約されています。
それが良い2つのことは、それが重要だと感じるかもしれませんが、アクションを行うためですafterネストされたフラグメントも再開されますandアプリケーションが保証ユーザーに見えるようにします（onResume中にまだ見えないかもしれません）。
Sourcesを見るときにメソッド名から少し混乱するかもしれませんが、フローをログに記録すると、何が起こるかわかります
- アクティビティの再開
- フラグメントの再開
- onPostResumeはActivityで呼び出されます
将来の読者に注意の言葉を追加します-onPostResumeを使用してフラグメントを待機し、たとえばgetメソッドを呼び出すと、悪い、信頼性の低いデザインになります。代わりに、フラグメントからコールバックパターンを取得し、準備ができたらフラグメントにアクティビティにデータを「送信」させる必要があります。
あなたの質問に答える前に、AndroidによるonPostResume()について話しましょう
onPostResume()
APIレベル1に追加
void onPostResume ()
activity再開が完了したときに呼び出されます（after onResume() has been called）。 アプリケーションは通常、このメソッドを実装しません。システムクラスがアプリケーションの再開コードが実行された後に最終セットアップを行うことを目的としています。
彼らが言ったように活動が再開されると、それが呼び出されます。あなたが活動した後に何かをしたいのであれば、あなたがこの方法を使用することができます再開されます。しかし、ほとんどの場合、onResume()でアニメーションの開始、排他的アクセスデバイス（カメラなど）のオープンなどを行うため、アクティビティが再開されるとonPostResumed()が呼び出されます。だから、それは履歴書に異なり思いませんか？ onPostResume（）ではosのアクティビティに応じて既に再開されているため、onPauseとonStop（）の場合は異なります。これらは、アクティビティがバックグラウンドに移行しているときに（まだ）殺されておらず、ユーザーに表示されなくなったときに呼び出されている場合です。したがって、それらはonResume()およびonPostResume()とは異なります。
OnPostResume（）に依存する前に、developers.Android 1-アプリケーションは通常このメソッドを実装しません。アプリケーションの再開コードが実行された後、最終的な設定を行うには、システムのクラスを対象としています。 （しかし、私たちはどんな本の意図我々の目的のためにそれを使用することはできません）。 2 - この リンクを を確認してください。彼はonPostResume（）がないことを言った[〜＃〜]は常に[〜＃〜]と呼ばれます。そして、彼の場合は、（もちろん、彼らは活動の男の上にある）の断片のためでした。ここで回答は、「FragmentActivity.onResumeFragments()」を使用しなければならない問題は完全にAPIレベル16で解決し、ライブラリREV 9.新しいメソッドをサポートしている、です。
それはあなたの知っている次第ですので、それらのいくつかは、この方法に頼るの課題を持つようにします。
ログを使用し、アクティビティライフサイクルのメソッドをオーバーライドした後、次の結論に達しました：このメソッドは、フラグメントをロードした後、フラグメントを再開した後に親アクティビティで特定のタスクを実行したい場合に非常に役立ちます。
私が使用した/この結論に到達するためにコードスニペットを次試してみました：
親のアクティビティで：
//postResumemethod
@Override
protected void onPostResume() {
super.onPostResume();
Log.v("testPostResume","reached_postResume") ;
}
In called Fragment :
//On ResumeMethod
@Override
public void onResume() {
super.onResume();
Log.v("testStartFragment","reached_Startfragment") ;
}
これは私のログです：V/testStartFragment：reached_Startfragment V/testPostResume：reached_postResume
我々は明らかに断片のonResumeメソッドが実行された後、ポストレジュームが呼び出され見ることができます。そのため、アクティビティでコードを実行する場合は、フラグメントを呼び出し/ロードした後（フラグメントをロードした後、アクティビティを介して任意のタスク）、それを行うことができます
これでクエリが明確になることを願っています
onPostResume()はライフサイクルメソッドとして引用されていません。しかし、この方法は重要な方法だと思います。
おそらくあなたの気持ちは間違っています。そして、それがなぜそうなのかについての私の答えは、少し長く、一種の抽象的なものです。
抽象的な（しかし重要な）部分
通常、さまざまなonPreXyzおよびonPostXyz（別名onBeforeXyzおよびonAfterXyz）メソッドは、サブクラスによる拡張に対して基本クラスを開かせようとする試みですが、いくつかの重要な動作の側面を保持します。独自の基本クラスを設計しており、ライフサイクルイベント「Xyz」があり、デフォルトの処理動作は次のとおりであると仮定します。
- 他の処理の前に初期化を行います
- カスタマイズ可能なロジックを含むイベントの実際の処理を行う
- すべてのカスタマイズ可能な処理が完了したら、いくつかの仕上げロジックを実行します
ここで、Activityクラスのようなものを作成していると仮定します。これは、いくつかのロジックと、おそらく深い継承階層を持つ、大きく継承されるベースクラスです。ここで、基本クラスのロジックに関して、サブクラスロジックがどこで（いつ）実行されるかを考える必要があります。ここで重要なトリッキーな部分は、サブクラスに追加のロジックをステップ＃2の周りに配置することです（つまり＃1の後と＃3の前）。サブクラスは、＃3の後にあるsuperの呼び出し後、または（まれに）superの呼び出しの前に、つまり＃1の前に、ロジックを配置できるため、単純な仮想メソッドではこの目標を簡単に達成できません。それで、あなたは何をしますか？ テンプレートメソッドパターン が役立ちます。次の方法でコードを整理します
class Activity {
public final void performXyz(XyzEventData eventData) {
onPreXyz(eventData);
onXyz(eventData);
onPostXyz(eventData);
}
protected void onPreXyz(XyzEventData eventData) {
// put you logic from step #1 here
}
protected void onXyz(XyzEventData eventData) {
// put you logic from step #2 here
}
protected void onPostXyz(XyzEventData eventData) {
// put you logic from step #3 here
}
}
したがって、単一の外部エントリポイントperformXyzがあり、Xyzイベントが発生するとライフサイクルイベントを生成するコンテキストによって呼び出され、実行シーケンスを強制する3つの異なるメソッドにイベントを内部的にディスパッチします。通常、すべてのコードを「main」onXyzメソッド内のサブクラスに配置します。ただし、他の2つのうちの1つに配置する正当な理由がない限り、つまり、クラスもサブクラス化され、いくつかの実行順序。
注目に値するポイントがいくつかあります。
エントリポイントメソッド
performXyzはfinal（つまり、非仮想）です。このようにして、誰もそれを上書きして実行順序の強制ロジックを破ることができないようにします。基本クラスは、ステップ＃1および＃3ロジックを
onPreXyzに直接配置することにより、onPostXyzおよびperformXyzメソッドを空のままにすることさえできます。ただし、基本クラスの設計者が、いくつかの中間サブクラス（他の多くのより深いサブクラス（ Layer supertype など）の基本クラスとなる）が可能な深い継承階層を期待している場合、同じ実行が必要になることがあります順序強制機能では、とにかく基本クラスでそのようなメソッドを提供することは理にかなっています。ケースが3ステップ実行の分離を必要とせず、2ステップで十分な場合は、
onPreXyzまたはonPostXyzメソッドのいずれかが完全に省略される場合があります。これはAndroidでよく起こることです：onPostXyzよりもはるかに多くのonPreXyzメソッドがありますが、AsyncTaskは両方の機能を備えた顕著な例外のようです。
Androidの詳細（およびonPostResume）
この長い紹介の後、どのようにAndroidがonPostResumeにこのアプローチを使用しますか？ Activity.onPostResume のコードを見ると、基本クラスとUIの要素に密接に関連し、おそらくすべてのデータ構造が完全に準備されていることを期待しているものはほとんどありませんが、これはもちろん驚くべきことではありません。
さらに興味深いのは、サブクラスでどのように使用されるかです。非常に少ないオーバーライドの1つは、古いデバイス用のバックポートされた「フラグメント」機能を提供するv4サポートライブラリのFragmentActivityにあります。 FragmentActivity.onPostResume には、子フラグメントを再開するロジックが含まれています。標準のActivityクラスでは、フラグメントを再開する同様のロジックがmInstrumentation.callActivityOnResume(this);呼び出しとonPostResume();呼び出しの間の performResume メソッドに直接配置されているため、ステップ＃の一部であるように見えることがあります私の以前の抽象的な説明の3は、呼び出し元のコードに入れただけです。明らかに、FragmentActivityはActivity.performResumeに新しいコードを追加して、アクティビティの再開後に確実に実行されるようにすることはできません。したがって、オーバーライドされたFragmentActivity.onPostResumeにロジックを配置し、この方法で、アクティビティが既に再開された後にフラグメントを再開するのと同じセマンティクスを保持します。また、このセマンティクスがActivityクラスとFragmentActivityクラスの両方で明示的に保持されているという事実は、これがより良い方法であることを示唆していることに注意してください。コードが実際にフラグメントを使用している場合、not putonPostResumeに拡張ロジックを追加するか、何か悪いことが起こるかもしれません（不明）正確には）。