Activityの概要

9286 ワード

Activitiesの概要
Activityクラスはandroidアプリケーションの重要なコンポーネントであり、activityオブジェクトの組織と起動方法はandroidプラットフォームアプリケーションモデルの基礎である.プログラムがmain()関数を使用してアプリケーションを起動するのとは異なり、androidシステムはActivity実列で現在のActivityライフサイクルに合致するコールバックメソッドを呼び出すことでコードを実行します.
このドキュメントでは、activitiesの基本概念について説明し、activitiesを使用する軽量レベルのガイドラインを提供します.Appベストプラクティスの詳細については、Guide to App Architectureを参照してください.
activitiesの概念
モバイルアプリケーションの体験はデスクトップアプリケーションとは異なり、ユーザーとアプリケーションのインタラクションは常に同じ場所で開始されません.プログラムのオープンは常に不確定である.たとえば、メイン画面でEmail appを開くと、emailリストが表示されるかもしれませんが、ソーシャルメディアappを使用する途中でemail appを開くと、直接emailの編集ページに向かう可能性があります.
Activityクラスは、以上の問題を解決するために設計されています.1つのappが別のappを呼び出すと、実際に呼び出されるのは、呼び出されたapp全体ではなく、appのactivityです.Activityはこのようにappとユーザが対話するエントリポイントとして機能する.Activityクラスを継承することでactivityを実現できます.
Activityは、appがUIを描画するウィンドウを提供します.このウィンドウは通常、画面全体を塗りつぶしますが、画面よりも小さく、他のウィンドウの上に浮動する可能性があります.通常、activityは画面を実現します.例えば、1つのappのアクティビティはオプション画面を実現し、もう1つのactivityはピクチャ選択画面を実現する.
ほとんどのアプリケーションには複数のスクリーンが含まれています.これは、複数のactivityがあることを意味します.通常、アプリケーションにはmain activityがあり、ユーザーがappを起動すると、acitvityが実装する画面が最初にユーザーの前に表示されます.その後、各activityは、異なる操作を実行するために他のactivityを開くことができる.たとえば、簡単なメールappのmain activityでは、受信ボックスを表示する画面が提供される場合があります.受信ボックス画面からmain activityは、メール編集や個人メール画面の開くなどの他のactivityを起動することができる.
app中のactivityは互いに協力することによって粘性のあるユーザ体験を形成するが、各activityは他のactivityに緩やかにバインドされるだけであり、app中のアクティビティは通常最小の依存関係を有する.実際、activityは他のアプリケーションのactivityを起動することが多い.たとえば、ブラウザappは、ソーシャルメディアappの共有activityを起動する可能性があります.
appでactivityを使用するには、appのmanifestファイルにactivityの情報を登録し、activityのライフサイクルを正しく管理する必要があります.このドキュメントの他のセクションでは、これらの内容について説明します.
manifestファイルの構成
appでactivityを使用するには、activityを定義し、manifestファイルにactivityのプロパティを表示する必要があります.
定義activity
manifestファイルを開き、要素のサブ要素として要素を追加してactivityを定義します.たとえば、
<manifest ... >
  <application ... >
      <activity android:name=".ExampleActivity" />
      ...
  application ... >
  ...
manifest >

要素に必要な唯一の属性はandroid:nameであり、activityのクラス名を指します.ラベル、アイコン、UIトピックなどのactivityフィーチャーを定義するプロパティを追加することもできます.これらのアトリビュートおよびその他のアトリビュートの詳細については、要素リファレンスドキュメントを参照してください.
注意:アプリケーションをパブリッシュした後、activity名を変更する必要はありません.このようにすると、アプリケーションショートカットなどの機能が破壊される可能性があります.パブリッシュ後の変更回避の詳細については、変更できない内容を参照してください.
intent filtersの定義
intent filtersはandroidプラットフォーム上の非常に強力な特性です.これらはactivityを起動する能力を提供し、明確な要求だけでなく、不明確な要求にも基づいています.たとえば、明確なリクエストが「Gmail appの送信メールactivityを開く」とシステムに通知されます.それに比べて、不明なリクエストは「メールを送信できるactivityを開く」ことをシステムに伝えます.このintent filtersは、ユーザがタスクを実行するときにどのアプリケーションを使用するかをユーザに尋ねるときに機能する.
このプロパティは、要素にプロパティを定義することで使用できます.要素の定義には、要素とオプションの要素と要素が含まれます.これらの要素を組み合わせると、activityが応答できるintentタイプを指定できます.たとえば、次のコードフラグメントでは、テキストデータを送信するactivityを構成し、他のactivityからのリクエストを受信する方法を示します.
 
<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
        <data android:mimeType="text/plain" />
    intent-filter>
activity>

この例では、要素は、このactivity送信データを指定します.要素をdefaultに設定してactivityが起動要求を受信できるようにします.要素は、activityが送信できるデータ型を指定します.次のコード・クリップは、上記のactivityを呼び出す方法を示しています.
val sendIntent = Intent().apply {
    action = Intent.ACTION_SEND
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, textMessage)
}
startActivity(sendIntent)

自分のappを「自給自足」し、他のappがあなたのappのactivityをトリガーすることを許可しない場合は、他のintent filtersを使用する必要はありません.他のプログラムで取得したくないactivityにはintent filtersがあるべきではありません.これらのactivityは、appの範囲内で明示的なintentで起動できます.Activityがintentにどのように応答するかについては、ntents and Intent Filtersを参照してください.
Permissionsの定義
指定したactivityはmanifestファイルのラベルのappで起動できます.親activityは、manifestファイルで同じ権限が定義されていない限り、サブactivityを起動できません.activityに要素を定義した場合は、呼び出されたactivityに対応する要素が必要です.
たとえば、SocialAppという名前のappを使用してソーシャルメディア上でメールを共有したい場合は、SocialApp自身が呼び出したappにも必要なpermissionを定義する必要があります.
<manifest>
<activity android:name="...."
   android:permission=”com.google.socialapp.permission.SHARE_POST”/>

SocialAppを呼び出すには、適切なSocialAppのpermission設定が必要です.
<manifest>
   <uses-permission android:name="com.google.socialapp.permission.SHARE_POST" />
manifest>

アクセス権とセキュリティの詳細については、Security and Permissionsを参照してください.
Activityのライフサイクルの管理
activityのライフサイクルでは、activityは多くの状態を経験します.これらのステータス間の変換は、一連のコールバックメソッドで処理できます.次のセクションでは、これらのコールバック方法について説明します.
onCreate()
システムがactivityを作成するときに作成されるコールバックメソッドを実装する必要があります.この方法の実装は、作成したactivityの基本コンポーネントを初期化する必要があります.たとえば、appで作成されたviewsとリストにバインドされたデータは、ここで完了する必要があります.最も重要なのは、
このメソッド内でsetContentView()メソッドを呼び出してactivityのユーザーインタフェースのlayoutを定義する必要があります.
onCreate()メソッドの実行が完了すると、次のコールバックメソッドはonStart()です.
onStart()
onCreate()メソッドの実行が完了すると、activityはstarted状態に入り、ユーザーが表示されます.このコールバックメソッドには、現在のactivityをユーザと対話可能なフロントactivityにする最後の準備が含まれている.
onResume()
システムは、activityがユーザーと対話を開始する前にこのメソッドを呼び出すだけで、activityがactivityスタックの上部にあり、すべてのユーザー入力を取得します.1つのappのほとんどのコア機能はonResumeメソッドで実現される.
onPause()メソッドは、常にonResumeメソッドの後に呼び出されます.
onPause()
activityがフォーカスを失い、一時停止状態になったときにonPause()メソッドが呼び出されます.例えば、ユーザが「戻る」または「最近」ボタンをクリックすると、このような状態になる.システムがactivityのためにonPasuse()メソッドを呼び出す場合、技術的にはactivityは依然として部分的に見られるが、通常、ユーザがactivityを離れており、activityはすぐにstopped状態またはresumed状態に入ることを示す.
ユーザがUIの更新を望む場合、一時停止状態のactivityはUIの更新を継続することができる.例えば、地図ナビゲーションまたはメディアプレーヤーを含むactivity.これらのactivityが焦点を失っても、ユーザーはUIの更新を継続することを望んでいる.
onPause()メソッドにプログラムまたはユーザーデータを保存したり、ネットワークを呼び出したり、データベーストランザクションを実行したりするべきではありません.データ保存の詳細については、Saving and restoring activity stateを参照してください.
onStop()
システムは、activityがユーザーに表示されなくなったときにonStop()メソッドを呼び出します.これは、activityが破棄されているか、新しいactivityが開始しているか、既存のactivityがリカバリ状態に入っており、停止したactivityを上書きしている可能性があります.これらの場合、停止したactivityは表示されません.
activityがユーザと対話する状態を返す場合、システム呼び出しの次のコールバック方法はonRestart()であり、アクティビティが完全に終了するとonDestroy()が呼び出される.
onRestart()
停止状態のactivityが再起動すると、このコールバックが呼び出されます.onRestart()はactivityをこのactivity stoppedの状態に戻します.このメソッドの後ろには常にonStart()メソッドが付いています.
onDestroy()
システムはactivityが破棄される前にこのメソッドを呼び出します.
このコールバックはactivityが受信した最後のコールバック方法であり、onDesty()の実装は、通常、activityまたはactivityを含むプロセスが破棄されたときにすべてのリソースが解放されることを保証するためである.このセクションではactivityのライフサイクルについてのみ説明します.アクティブライフサイクルとそのコールバックの詳細については、アクティブライフサイクルを参照してください.
 
転載先:https://www.cnblogs.com/Shadowplay/p/9453435.html