どろあそび (4)

「Android Kotlin の基礎」もレッスン4になりました。

レッスン4ではログ機能とアクティビティとフラグメントのライフサイクルを扱います。

アクティビティおよびフラグメントは初期化されている、表示されている、フォーカスされているの3状態があり、状態が遷移するごとにシステムから対応するコールバックが呼ばれます。

このレッスンではどのような条件で状態が遷移するかを確認するとともに、状態遷移に関連した対応を扱っています。

最初の項目「Lifecycles and logging」はログ機能を使用してアプリ操作と状態遷移の関係を確認しています。

ログ機能にはAndroidが標準で提供するログ機能とTimberによるログが説明されています。Timberはログを生成したオブジェクトのクラス名をログに自動的に出力する機能が追加されているそうです。

ところで、このページは一時的にかもしれませんが正しく表示されないようで次の項目への移行ができなくなっています。

このため、次の項目はAndroid Codelabsからそれらしいのを持ってきています。

次の項目「Complex Lifecycle Situations」はバックグラウンドタスクと強制終了、画面の回転について扱っています。

Androidでは電池の持ちやフォアグラウンドで実行している別アプリのパフォーマンスに影響を与えないよう、自分のアプリがフォアグラウンド動作している時にだけバックグラウンドタスクを実行することを推奨しています (もちろん、音楽を演奏するなどのようにバックグラウンドでも継続して実行することが必要なアプリもありますので、強制ではありません)。

これを実現するためにライフサイクルの状態遷移コールバックを使用することができます。

また、スマートフォンは電話ですので、電話がかかってきた時にはできるだけ早く受ける必要があります。このため、自分のアプリが画面に表示されなくなった時の状態遷移に関わる処理はできるだけ小さくする必要があるとのことです。

ところで、他のアプリの実行などによりアプリが画面表示されていない条件でメモリなどのリソースが不足するとアプリは状態遷移コールバックを行わずに強制終了される場合があります。

このような場合、アプリを再起動させると直前の状態が失われているために初期状態からの起動となってしまいます。

これを避けるための施策として、アプリが画面表示されなくなる時点で再起動時に必要となるデータをシステムに記録し、再起動時にシステムから受け取って再開できる仕組みが導入されています。ただしこの仕組みはRAM上に再開用のデータを保存するため、保存できるのは単純データ型のみで総量も限定されている (その上機種依存) ので、アプリケーションは再開を考慮した設計が必要と思われます。

また、状態遷移に関連する問題として、デバイスを回転させた際に表示の縦横が変わるとき、アプリは一旦終了して再起動させられるため、表示の縦横変換に対応するためには再開用データの保存が必須となります。

普通に考えると画面の縦横変換で再起動が必要になるのはどうかと思うけど、縦横の表示で操作メニューの配置が変わるなど凝った作りができるようにという配慮なのでしょう。

ということで、今回は以上です。