Activity x Compose Lifecycle: The Complete Visual Guide 🚀

 

👨‍💻 Activity Lifecycle


Activity.onCreate() <- Activity is created

↓

Activity.onStart() <- Preparing to become visible on screen

↓

Activity.onResume() <- Foreground state (interactive)

↓

Activity.onPause() <- Partially visible

↓

Activity.onStop() <- No longer visible

↓

Activity.onDestroy() <- Activity is destroyed

 

👨‍💻 Compose Lifecycle


[First Composition]
  - Composable is evaluated, Compose tree is built
  - LaunchedEffect -> Runs once after the commit
  - SideEffect -> Runs after every commit
  - DisposableEffect -> onDispose is called upon disposal

↓

[Recomposition]
  - UI is re-evaluated in response to state or data changes
  - Only the necessary parts are recomposed (efficient update)
  - SideEffect and DisposableEffect are also re-evaluated during recomposition

↓

[Dispose]
  - Depends on the ComposeView's disposal condition
  - DisposableEffect's onDispose is executed
  - Disposal timing is determined by the ViewCompositionStrategy

 

👨‍💻 Activity x Compose Lifecycle


Activity.onCreate() setContent { ... } <- Sets the ComposeView

↓

[First Composition]
  - Evaluates Composables and builds the UI
  - LaunchedEffect -> Runs once after commit
  - SideEffect -> Runs after each commit
  - DisposableEffect -> Defines onDispose

↓

Activity.onStart()

↓

Activity.onResume()

↓

[Recomposition]
  - Re-evaluates necessary parts in response to state changes
  - LaunchedEffect is not re-executed (only if its key changes)
  - SideEffect / DisposableEffect are re-evaluated

↓

Activity.onPause()

↓

(ComposeView is retained)
  - UI becomes partially obscured
  - State is maintained within the Composition

↓

Activity.onStop()

↓

[Preparing for Dispose (Detection)]
  - ViewCompositionStrategy monitors disposal conditions

↓

Activity.onDestroy()

↓

[Dispose]
  - ComposeView is destroyed
  - DisposableEffect.onDispose() is executed

This is the general flow.

Here are the notes for each item:

Activity.onCreate() A lifecycle method called when an Android app's Activity is created.

    setContent { ... }: Sets the UI using Jetpack Compose. This sets a ComposeView as the Activity's content view. The Compose lifecycle begins.

  • First Composition The Composable functions set in setContent are evaluated for the first time, and the UI is built.

LaunchedEffect: An Effect used for asynchronous processing. Runs only once after the first composition.

SideEffect: Runs after every composition commit (the timing when UI changes are applied).

DisposableEffect: An Effect used for resource cleanup. The logic defined in onDispose is executed when the Composition is disposed.

Activity.onStart() A lifecycle method called just before the Activity becomes visible to the user.

Activity.onResume() The Activity moves to the foreground and becomes fully interactive with the user.

  • Recomposition Only the necessary Composable functions are re-evaluated in response to changes in State.

LaunchedEffect: It is not re-executed during recomposition. However, it will be re-executed if its key changes.

SideEffect: It is re-evaluated on every recomposition.

DisposableEffect: It is re-evaluated on recomposition, and the cleanup logic (onDispose) from the old Effect is called.

Activity.onPause() The Activity enters a paused state and becomes partially obscured.

ComposeView Retention: The UI is not destroyed; it is retained. The state is also maintained within the Composition, allowing it to be reused upon re-display.

Activity.onStop() The Activity is no longer visible. A time to prepare for cleaning up state and resources.

Preparing for Dispose (Detection) ViewCompositionStrategy: A mechanism that monitors the conditions under which the ComposeView should be disposed. It triggers the Composition's disposal based on the View's lifecycle.

Activity.onDestroy() The timing when the Activity is completely destroyed.

  • Dispose The ComposeView is destroyed: The UI and state are completely released.
  • DisposableEffect.onDispose(): The resource cleanup logic is called.

 

👨‍💻 Summary

The Jetpack Compose and Activity lifecycles are closely linked, with specific processes occurring at each stage, from UI initialization (setContent) to disposal (Dispose).

It is especially important to understand the differences between effects like LaunchedEffect, SideEffect, and DisposableEffect, and to manage them appropriately.

Furthermore, by efficiently reusing the UI in response to Activity state changes (like onResume or onPause) and cleaning up resources as needed, you can achieve stable application behavior.


【Android Studio Flamingo】dependencies をバージョンアップデートするときに確認するべき3つの相性

ソフトウェアの開発において、依存関係は重要な要素の一つです。一つのライブラリが別のライブラリに依存している場合、最新バージョンのアップデートを行う際には、注意が必要です。

今回は、依存関係をアップデートする際に留意しておくべきことについて解説します。

で、[File] - [Project Structure] からのこの画面。

This project uses Gradle Version Catalogs. There are some limitations. Learn more.

【Android Studio Flamingo】dependencies をアップデートするときに確認しておくべきこと

[Suggestions] 画面だけで完全に更新できませんよね。

「プラグイン、ライブラリ同士の互換性は考慮されていないものがある。」

「提案されない表示されないライブラリがある。」

ということで、どこに注意しながら新しいものに更新していくとスムーズに進むか、という話です。

 

🔗 Android Studio と Android Gradle Plugin

Android Studio は、Android アプリ開発に必要な開発環境を提供する統合開発環境です。

Android Gradle Plugin (AGP) は、Android Studio のビルドシステムに使用されるツールであり、ビルドプロセスを自動化するために必要です。

Android Studio と Android Gradle Plugin
👉 Android Gradle plugin and Android Studio compatibility - Android Studio Flamingo | 2022.2.1  |  Android Developers hatena-bookmark

Android Studio で使用している Android Gradle Plugin のバージョンを確認するには、プロジェクトの build.gradle ファイルを開き、以下のように dependencies ブロック内に記述されている AGP のバージョン番号を確認します。


dependencies { 
  classpath 'com.android.tools.build:gradle:x.y.z' 
  // ... 
}

または、build.gradle に記述がない Version Catalog 記述の Android Gradle Plugin のバージョンは、以下の、どちらかのプラグインID のバージョン(共通) です。


com.android.application

com.android.library

👉 【Plugin DSL】Android Gradle Plugin のバージョンを調べる方法 hatena-bookmark
👉 【Plugin DSL】「com.android.tools.build:gradle」の記述は不要? hatena-bookmark

Gradle Version Catalogs では以下のようになります。


# libs.versions.toml 

[versions]
android-gradle-plugin = "8.0.1"

[plugins]
android-application = { id = "com.android.application", version.ref = "android-gradle-plugin" }


// buid.gradle

plugins {
  alias libs.plugins.android.application
}

また、最新の AGP バージョンを確認するには、Google's Maven Repository を参照します。
Google's Maven Repository
👉 com.android.application.com.android.application.gradle.plugin - Google's Maven Repository hatena-bookmark

 

🔗 Android Gradle Plugin と Gradle

Gradle は、オープンソースのビルドツールであり、Java や Kotlin、Groovy などのプログラミング言語に対応しています。Android Studio のビルドシステムには、Gradle が採用されています。

AGP は、Gradle に依存しており、AGP のバージョンアップに伴い、Gradle のバージョンもアップデートする必要があります。

また、Gradle のバージョンアップには、Android Studio のバージョンアップも伴う場合がありますので、注意が必要です。

Android Gradle Plugin は Gradle に依存しているため、AGP をアップデートする場合には、Gradle も同時にアップデートする必要があります。

Android Gradle Plugin と Gradle
👉 Update Gradle - Android Gradle plugin release notes  |  Android Studio  |  Android Developers hatena-bookmark

Gradle のバージョンを確認するには、プロジェクトの gradle/wrapper/gradle-wrapper.properties ファイルを開き、以下のように distributionUrl に記述されている Gradle のバージョン番号を確認します。


distributionUrl=https\://services.gradle.org/distributions/gradle-8.1.1-bin.zip

また、最新の Gradle バージョンを確認するには、Gradle 公式サイトの Gradle Distributions を参照します。
Gradle Distributions
👉 Gradle Distributions hatena-bookmark

 

🔗 Kotlin と Jetpack Compose Compiler

Kotlin は、Android アプリ開発に必要なプログラミング言語の一つです。Jetpack Compose Compiler は、Kotlin をベースにした Jetpack Compose ライブラリのコンパイラです。

Jetpack Compose は、Android のユーザーインターフェースを作成するための新しい方法を提供するライブラリであり、Kotlin と密接に関連しています。

https://developer.android.com/jetpack/androidx/releases/compose-kotlin#pre-release_kotlin_compatibility
👉 Compose to Kotlin Compatibility Map  |  Android Developers hatena-bookmark

Jetpack Compose Compiler のバージョンをアップデートする場合には、Kotlin のバージョンも確認し、必要に応じてアップデートする必要があります。

Kotlin と Jetpack Compose Compiler の依存関係を確認するには、以下のように Kotlin と Compose Compiler のバージョン番号を確認します。


# libs.versions.toml 

[versions]
compose-compiler = "1.4.7"
kotlin = "1.8.21"

[plugins]
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
kotlin-kapt = { id = "org.jetbrains.kotlin.kapt", version.ref = "kotlin" }


// build.gradle

plugins {
  alias libs.plugins.kotlin.android  // 'kotlin-android'
  alias libs.plugins.kotlin.kapt     // 'kotlin-kapt'
}

android {
  composeOptions {
    kotlinCompilerExtensionVersion libs.versions.compose.compiler.get()
  }
}

また、最新の Kotlin と Jetpack Compose Compiler のバージョンを確認するには、それぞれ以下を参照します。

👉 Maven Repository: org.jetbrains.kotlin » kotlin-gradle-plugin hatena-bookmark
👉 androidx.compose.compiler.compiler - Google's Maven Repository hatena-bookmark

 

🔗 まとめ

Android Studio のビルドシステムには、Android Gradle Plugin が使用されており、AGP は Gradle に依存しています。

また、Kotlin と Jetpack Compose Compiler、そして SDK のライブラリ同士にも依存関係があります。

最新バージョンにアップデートする際には、それらのつながりを確認し、必要に応じて一括でアップデートすることをおすすめします。

コアな部分は Stable 最新バージョンで揃える、とすると、以下が、今現在ベストでしょう。


Android Studio
Flamingo | 2022.2.1

  ↕︎

Android Gradle Plugin
8.0.1

  ↕︎

Gradle
8.1.1


Kotlin
1.8.21

  ↕︎

Jetpack Compose Compiler
1.4.7

すぐ忘れるので libs.versions.toml にコメントで貼りつける。


[versions]
# Android Studio - AGP - Gradle
# Kotlin - Compose Compiler
#
# Android Studio version	Required plugin version
# Giraffe | 2022.3.1	3.2-8.1
# Flamingo | 2022.2.1	3.2-8.0
# https://developer.android.com/studio/releases#android_gradle_plugin_and_android_studio_compatibility
#
# Plugin version	Minimum required Gradle version
# 8.2	8.1
# 8.1	8.0
# 8.0	8.0
# https://developer.android.com/studio/releases/gradle-plugin#updating-gradle
#
# Android Studio :
# https://developer.android.com/studio
#
# Android Gradle Plugin :
# https://maven.google.com/web/index.html#com.android.application:com.android.application.gradle.plugin
#
# Gradle :
# https://services.gradle.org/distributions/
android-gradle-plugin = "8.0.1"

# Compose Compiler Version	Compatible Kotlin Version
# 1.4.7	1.8.21
# 1.4.6	1.8.20
# 1.4.5	1.8.20
# 1.4.4	1.8.10
# https://developer.android.com/jetpack/androidx/releases/compose-kotlin#pre-release_kotlin_compatibility
#
# compose-compiler :
# https://maven.google.com/web/index.html?authuser=0#androidx.compose.compiler:compiler
#
# kotlin :
# https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-gradle-plugin
# https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-gradle-plugin/
compose-compiler = "1.4.7"
kotlin = "1.8.21"

コメント内URLからリンクをブラウザを開くのは、⌘ (command) + click で。



プログラミング「ChatGPT にコーディングを依頼するだけ」は嘘?

こんな記事がありました。

👉 Jay Little - Software Obsessionist - Low Code Software Development Is A Lie hatena-bookmark

Sometimes a client falls into the trap of believing that there is some kind of silver bullet they can employ which will negate the inherent complexity around coding custom solutions. Nowadays the most cliche form of this is to say, "Well I'll just ask ChatGPT to code that for me". I call bullshit. While ChatGPT can handle some simple coding tasks, anything beyond that causes it to rapidly devolve into an unmanageable mess.

「コーディングの複雑さを解消する特効薬がある」という言葉を信じて罠に陥ることがあります。最近のこの決まり文句は「ChatGPT にコーディングを依頼するだけ」というものです。 私はデタラメだと思います。ChatGPT はいくつかの単純なコーディングタスクを処理できますが、その後急に、管理不能な混乱に陥ります。

Beyond the in vogue AI Chatbot example, there are a wide variety of other snake oil tools lingering about. All of them sell prospective buyers on the premise of allowing them to cut through the cruft and quickly pump out custom software without going through the years of training that professional Software Developers tend to go through. The most relevant example of this syndrome are so-called low code tools. As it so happens, I work with one of these at my current job.

流行りのAIチャットボットの他にも、様々なゴミツールが出回っています。これらはすべて、プロのソフトウェア開発者が経験するような長年のトレーニングを受けることなく、厄介なものを切り捨て、好みのソフトウェアを素早く作り出せるという前提で、購入希望者に売り込んでいます。この問題の最もよく見られる例は、いわゆるローコードツールです。たまたま、私は現在の職場でこのうちの1つを使用しています。

This low-code tool is called ***** and my review of it is that its a steaming pile of shit. I won't go into the technical specifics of why as that probably deserves it's own post. While it has enabled some non-developers to produce custom logic and screens, it hasn't actually removed the inherent complexity around designing proper data structures, writing fault tolerant software and validating the quality of the resulting software. Because a lot of the coders in question don't have this expertise, the end result is a custom software system that is poorly thought through, is brittle and as a result will require constant fire fighting on the part of the future members of the team in an effort to keep it functional.

このローコードツールは ***** というもので、私がみたところ、とんでもないクソの山です。その理由についての技術的な詳細については、ここでは触れません。非開発者でもロジックや画面を作成できるようになりましたが、適切なデータ構造の設計、耐障害性のあるソフトウェアの作成、出来上がったソフトウェアの品質の検証など、固有の複雑さを取り除くことはできません。多くのコーダーはこのような専門知識を持ち合わせていないため、最終的にソフトウェアは、十分に考え抜かれておらず、脆弱で、その結果、機能を維持するために未来のチームメンバーによる絶え間ない消火活動が必要となります。

I haven't even mentioned the best part: Tools like this aren't cheap and they tend to structure their licenses / billing so that you end up paying for as long as you use the software you produce with the tool. On top of which, all of these tools seem to involve accepting some level of vendor lock-in. So the more time you put into tools like these, the tighter their grip on your proverbial balls becomes.

一番大事なことは、このようなツールは安くはなく、ツールで作成したソフトウェアを使用する限り、最終的には、支払いが発生するような ライセンス/請求 の仕組みとなっています。その上、これらのツールはすべてベンダーロックインを受け入れなければならず、このようなツールに時間を費やすほどベンダーロックから抜けられなくなります。

In both the AI Chatbot and the Low Code tool scenarios, the solutions each promise a shortcut around the complexity as perceived by a non-practitioner. That's the essence of the trap. Practitioners know that the writing of the code is merely the last step in a long process that involves a lot of thinking, discussion and planning. The code is generally the end result and producing it is relatively easy once you truly understand the problem at hand.

AIチャットボットとローコードツールの両方で、各ソリューションは、非専門家の複雑さを回避する近道を約束しています。それが罠の本質です。開発者は、コードの記述が、多くの思考、議論、および計画を含む長いプロセスの最後のステップにすぎないことを知っています。コードは通常、最終結果であり、目前の問題を本当に理解していれば、それを作ることは比較的簡単なことです。

TLDR: Designing a solution worth a damn is actually the most difficult part of the software development process. Low Code tools lie to customers by implying that the writing of code is the hardest part. The reality is that No Low Code tool can spare you from having to take the time to properly design your custom software or the consequences you will experience when you build solutions around a half-ass design.

TLDR:価値のあるソリューションを設計することは、実はソフトウェア開発プロセスの中で最も難しい部分です。ローコードツールは、コードを書くことが最も難しい部分であるかのように、顧客に嘘をついています。現実には、どんなローコードツールも、ソフトウェアを適切に設計するための時間や、中途半端な設計でソリューションを構築したときの結末から逃げることはできません。

 

🤔 この意見についてどう思うか ChatGPT に聞いて見た

この意見についてあなたはどう思いますか。関西弁で答えて。

めっちゃ同感やわ。コーディングの複雑さを解消する特効薬があると思ったら大間違いやで。そんなもんあったら、開発者はみんなそれを使って楽々コーディングやろうて思うてるわ。AIチャットボットやローコードツールなんか、一部の単純なタスクをこなすのには使えるやろうけど、それだけや。複雑なタスクをやるには、経験や専門知識、センスが必要なんや。ローコードツールを使っても、適切なデータ構造の設計や品質検証など、ソフトウェア開発の複雑さは取り除けへん。プロの開発者に頼るべきやな。

めっちゃ大事なことは、この手のツールは高くて、ツールで作ったソフトをつかう限り、最終的には、支払わなあかんライセンスか請求のシステムになってるねん。それだけやなくて、全部のツールはベンダーロックインを受け入れなあかんから、この手のツールに時間を使うほど、ベンダーロックから抜け出せなくなることもあるで。

AIチャットボットとローコードツールは、どっちも非専門家でも使いやすいっていうのが売りやけど、それが落とし穴なんよ。開発者たちは、コード書くのは思考や議論、計画が必要な長いプロセスの最後のステップってことを知っとる。コードは普通、最終的な結果であって、問題を本当に理解してたら、それを作ることは比較的簡単なんやで。

要するに、簡単にソリューションを作ることはできへんってことや。どんなローコードツールでも、適切にソフトを設計するための時間や、中途半端な設計から逃げられへんのや。そんなことを顧客に嘘をついて、コード書くのは難しいとか言ってるんや。

 

🤔 まとめ

それを3行にして

1. 特効薬でコーディングが楽になるというのは誤解やで。
2. AIチャットボットやローコードツールは一部のタスクにしか使えへん。
3. 開発には経験や専門知識が必要や。

ナニワ金融道ぽくてワロタ。