DEV Community: Eddie Eddie

Flow ของ OAuth 2.0

Eddie Eddie — Mon, 16 Jan 2023 15:57:20 +0000

เนื้อหาทั้งหมดเอามาจาก video ของ Okta Youtube channel และ productioncoder channel

ตั้งใจเขียน Blog นี้เพราะว่าลืม flow ของ OAuth ทุกทีว่ามันทำงานยังไง สุดท้ายต้องมานั่งดู clip ย้อนหลังใหม่เรื่อยๆ รู้สึกว่าไม่ค่อยมี time efficiency เท่าไหร่เพราะ clip ก็นานเป็นชั่วโมงอยู่เลยมาเขียน Blog ซะเลย

blog นี้พยายามจะเขียนครอบคลุมแค่เรื่อง Flow หลักๆ กับ PKCE เท่านั้นอาจจะไม่ได้ลงรายละเอียดมากเท่าไหร่

Terms

Resource Owner: เจ้าของ Resources ที่ app เราต้องการจะ access เช่น Google, Facebook, Twitter etc
Client: app ของเรา
Scope: ข้อมูลที่เราอยากได้จาก Resource Owner

Flow ของ OAuth2 ในภาพใหญ่จริงๆ มีแค่ 7 ขั้นตอน

(1) Pre-register กับ Resource Owner
เราจำเป็นต้องทำการ pre register กับ Resource Owner ก่อนที่จะทำการ implement authorization ให้ลองนึกถึงการที่เราต้องไปสร้าง apps บน Facebook, Twitter, Google ก่อนเริ่ม ใน step นี้ Resource Owner อาจจะทำการสร้าง secret key มาให้เราใช้งาน เราจำเป็นต้องเก็บไว้กับตัวเองที่ Backend server ของเรา
(2) ส่ง request ไปที่ Authorization Server ของ Resource Owner (Front channel)
หลังจากที่เราทำการ implement ปุ่ม authorization แล้ว (Login with Facebook, Login with Google, Login with Twitter) เราจะทำการส่ง Request ไปที่ authorization Server ของ Resource Owner เพื่อทำการ authorize โดยขั้นตอนนี้เราจะทำการส่ง Scope ไปด้วยพร้อมกับ callback URI

Redirect URI; myapp.com/callback
Scope: profile, contacts

Resource Owner จะขึ้นหน้าเว็บให้เราทำการ signin

(3) Resource Owner ทำการ redirect เพื่อขอ permission เราเพื่อให้ข้อมูลกับ client app (Front channel)

(4) Resource Owner redirect กลับมาที่ Callback URI (Front channel)
เมื่อ user ทำการกดอนุญาตแล้ว Resource Owner จะทำการ redirect กลับมาที่ callback URI ที่ให้ไว้ที่ step แรก พร้อมกับ return authorization code กลับมาด้วย
(5) Exchange authorization code กับ accesstoken (Back channel)
เราจะทำการแลกเปลียน authorization code ที่ได้มาจาก step ที่ 4 กับ accessToken โดยทำการส่ง authorization code + secret key ที่เราได้ตอน step ที่ 1 ไปที่ Authorization Server ของ Resource Owner
(6) Authorization Server ของ Resource Owner คืน accessToken (Back channel)
(7) Client app นำ accessToken (Back channel) ไปใช้เพื่อเข้าถึง resource ตามที่ได้ระบุไว้ใน scope ที่ step แรก

Back and Front Channels

ใน step ที่ 5 เราจะไม่ได้ accessToken returned มากลับตรงๆ แต่จะได้เป็น authorization code มาแทน สาเหตุหลักๆมาจากเรื่อง security ถ้าเกิดว่ามี malicious software ที่ทำหน้าที่ดักข้อมูลที่เรารับส่งที่ step นี้จะให้เกิดปัญหาได้ เราเลยจำเป็นต้องให้ Server ของเราเป็นคนส่ง request (Back Channel) และแนบ secret key ไปด้วยเพื่อขอ AccessToken แต่ในบางกรณีเราอาจจะไม่มี backend server เช่น app เราเป็น Static page web site นั่นทำให้เราจำเป็นที่จะต้องได้ AccessToken มาที่ step นี้ Flow นี้จะเรียกว่า Implicit Flow

Implicit Flow

Implicit Flow จะเหมือนกันกับ Flow ปกติต่างกันตรงที่ไม่มี Back channel นั่นทำให้ที่ Step 5 เราจะได้ AccessToken มาตรงๆ
ข้อเสียที่ควรรู้ไว้คือ Implicit Flow จะมี security ที่แย่กว่า Flow ปกติ

OpenID

OAuth2 ถูกสร้างมาเพื่อใช้แค่สำหรับ Authorization เท่านั้น แต่การใช้งานของมันค่อนข้างแพร่หลายเลยทำให้มีการนำมาประยุกต์ใช้กับการ Authentication ด้วย โดยสิ่งที่ถูกสร้างมาเป็น extension ของ OAuth สำหรับการ Authentication คือ OpenID

สิ่งที่เพิ่มเข้ามาจาก flow ปกติคือ

OpenID scope: เพื่อบอก Authorization Server ว่าเป็นการขอใช้ Authentication
ID Token: สำหรับการ fetch ข้อมูล user ที่ทำการ authentication
UserInfo endpoint: สำหรับดึงข้อมูล UserInfo

PKCE (Proof Key for Code Exchange)

สมมติว่าเราต้่องการทำ OAuth บน mobile app ใน flow ปกติที่ไม่ใช่ implicit flow โดย:

เราไม่มี backend server ที่ไว้ช่วยเก็บ secret key
เราไม่สามารถเก็บ secret key ไว้ที่ client app เราได้
Authorization มี option ให้เลือกว่าจะไม่ใช้ secret key

ใน step ที่ (5) ที่เราทำการส่ง authorization code ไปที่ Authorization Server เพื่อทำการแลกเปลี่ยน access token บน mobile app มีโอกาสที่ malicious app ที่มาแอบดักตัว authorization code ก่อนเราแล้วไปทำการส่งไปที่ server เพื่อขอ Access token ได้ RFC-7636

PKCE ช่วยแก้ปัญหานี้ด้วยการ

generate strings ที่มีความยาว 43-128 characters เรียกว่า code_verifier
hash code_verifier ด้วยการ hash ตามมาตราฐาน
ใน step ที่ 2 ให้ทำการส่ง code challenge และ code challenge method ไปที่ Authorization Server ด้วย โดย code challenge คือค่าที่ได้จากการ hash และ code challenge method คือวิธีในการ hash เช่น sha256 กระบวนการนี้จะทำให้ Authorization Server รู้ว่า ค่าที่ได้จากการ hash คือค่าอะไร และใช้กระบวนการ hash แบบไหน
ใน step ที่ 5 ที่เราทำการส่ง authorization code ให้เราทำการส่ง code_verifier ไปที่ authorization server ด้วย ตัว authorization server จะทำการ hash ค่า code_verifier ด้วยวิธีการที่บอกก่อนหน้า (code challenge method) แล้ว check ค่าว่าได้ hash value ที่ตรงกันกับ code challenge หรือไม่

Modernized Android architecture - JetPack Compose Part1

Eddie Eddie — Fri, 15 Jan 2021 11:59:04 +0000

Cover Photo by PixaBay from Pexels
จากที่เกริ่นไว้ใน Part แรกว่า JetPack Compose เป็นเรื่องที่ตั้งใจจะเขียนไว้ตอนแรกแต่เนื่องจากว่าใน Sample project มีจุดน่าสนใจหลายอย่าง เลยต้องแตกออกมาเป็นอีกหัวข้อนึง เรื่อง JetPack Compose ที่จะเขียนในวันนี้ อาจจะไม่ครอบคลุมเนื้อหาทั้งหมด เพราะตัว JetPack Compose เองก็มีเนื้อหาเยอะมาก รวมถึง API เองก็ยังไม่ได้อยู่ในสถานะ Stable เลยคิดว่าน่าจะมี Breaking change พอสมควร เนื้อหาที่จะเขียนในนี้จึงขอ Scope เนื้อหาเอาไว้คร่าวๆละ Sample App ละกัน

เริ่มต้นสร้าง Project

Jetpack Compose นั้น สามารถใช้งานได้บน Android Studio 4.2 (Preview) ขึ้นไปเท่านั้น เพราะฉะนั้นก่อนเริ่มสร้าง Project เราควรมั่นใจก่อนว่า Version ของ Android Studio เราถูกต้อง
เมื่อกด New Project เราสามารถเลือก Empty Compose Activity ได้เลย ใน app/build.gradle จะเห็นว่าเรามี Compose lib อยู่ข้างในด้วย

    implementation "androidx.compose.ui:ui:$compose_version"
    implementation "androidx.ui:ui-tooling:$compose_version"
    implementation "androidx.compose.material:material:$compose_version"

androidx.compose.ui:uiและ androidx.ui:ui-tooling คือ JetPack Compose ที่เราจะใช้
androidx.compose.material คือ Google Material Design system Library ที่ถูกสร้างครอบ JetPack Compose อีกที

หน้าตา Code หลังจากที่ New Project สำเร็จ

จุดที่เราสามารถสังเกตได้ชัดๆคือใน Activity ของเรานั้นไม่มีการ เรียก setContentView(R.layout.activity_main) อีกต่อไปแล้ว กลับกัน กับเรียก setContent แทนที่เป็น Extension Function ที่รับ lamda ที่มี @Composable ประกาศไว้ข้างหน้า

สิ่งที่ set เข้าไปใน lamda ของ setContent ก็คือ MyApplicationTheme ซึ้งถ้าเราไปดู เจ้าตัว MyApplicationTheme นั้นก็เป็น Function ที่มี @Composable ไว้เช่นกัน

Composable

@Composable คือ Annotation พื้นฐานสำหรับ JetPack Compose ที่ไว้ประกาศไว้หน้า Function เพื่อเป็นการบอกว่า Function นี้จะเป็น Block code ที่ไว้สำหรับ Built ด้วย Compose พูดง่ายๆคือเป็น UI Function ละกัน

Concept ของ UI เปลี่ยนไป

ใน JetPack Compose Concept ของ UI นั้นจะไม่เหมือนกับ Android View System ดั้งเดิม คือ ทุกๆ Component นั้นเป็น Composable function ไม่ใช่ Object ที่สืบทอดมาจาก View การเปลี่ยนแปลงการแสดงผลของ UI นั้นจะเกิดขึ้นเมื่อ Function นั้นมีการ "Re-composition" เกิดขึ้น

ถึงตรงนี้หลายคนอาจจะสงสัยว่าเมื่อไหร่ที่ Function จะทำการ Re-composition? โดยปกติแล้ว Composable Function จะทำการ Re-composition ก็ต่อเมื่อ State ของตัวมันเองเปลี่ยนไป โดยเรื่อง State จะกล่าวถัดไป

Unidirectional Data Flow

Unidirectional Data Flow หรือ Single Directional Data Flow
ย้อนกลับไปตอนที่เรายังเขียน Code เป็นแบบ MVC Pattern

ใน MVC เมื่อมี Action บางอย่างเกิดขึ้นเช่น User เปิดแอพ, User คลิกปุ่ม ฯลฯ Action จะถูกส่งไปให้ Controller เป็นคนจัดการ
Controller จะทำการจัดการกับ Action นั้นตามแต่ว่า Action นั้นคืออะไร เช่น User เปิดแอพ -> Controller ดึงข้อมูลจาก network เมื่อ Controller ได้ข้อมูลมาแล้ว นำข้อมูลไป parse เป็น model แล้วแสดงผลที่ View ให้ User เห็น

Flow การทำงานนี้คอนข้างเรียบง่ายถ้าเป็นแอพขนาดเล็ก แต่ถ้าหากว่าแอพเราใหญ่ขึ้น Flow การทำงานก็จะซับซ้อนขึ้น เช่น เมื่อ User เปิดแอพ เราต้อง Fetch ข้อมูลจาก API มาจาก n Endpoints และแสดงผลใน View n Views

ขอบคุณทีม Facebook Engineer ที่ได้ คิดใหม่และกลายเป็นที่มาของ Flux, Redux ฯลฯ ในปัจจุบันฝั่ง web App Development

Image from Hacker Way: Rethinking Web App Development at Facebook

ใครสนใจสามารถอ่านได้ที่ Flux documentation
สาเหตุที่จำเป็นต้องเกริ่นถึงเรื่องนี้เพราะตัว JetPack Compose เองมีสิ่งนึงที่ Build-in เข้ามาใน Library เลย นั่นก็คือ State

State

State เป็นเสมือนค่าสถานะของ Application ที่เปลี่ยนแปลงได้ตามเวลา ถ้าเราลองมองภาพกว้างๆ จะเห็นว่า Android App ของเราเองก็ทำการ แสดง State ต่างๆ ให้ User เห็นอยู่แล้ว เช่น:

State ที่ทำการแสดง Snackbar ให้ User เห็นเมื่อไม่มี Internet
State ที่ทำการแสดง Blog Post รวมถึง Comment ที่เกี่ยวข้อง
State ที่ทำการแสดง Ripple animation บนปุ่มเมื่อ User กด จะเห็นว่าแอพเราเองก็แสดง State ต่างๆ ให้ user เห็นผ่านทาง View อยู่แล้ว

แล้วเมื่อไหร่ที่ State ของหน้าแอพเรามันเปลี่ยนแปลงไปล่ะ?

โดยปกติ State ของแอพเรามักจะเปลี่ยนแปลงเนื่องจากมี Action หรือ Event บางอย่างมากระทำให้ State เปลี่ยนแปลงไป

Event ในที่นี้อาจจะเป็น Action จากการกดปุ่ม หรือข้อมูลที่เกิดจากการ Fetch มาจาก Backend
Update state class หรือ function ที่ทำหน้าที่เปลี่ยนแปลง State
Display state UI ที่ทำหน้าที่ Display ให้ User เห็น ตามแต่ละ State ที่เปลี่ยนแปลงไป

พูดอีกอย่างก็คือ เราจะแสดง UI ตาม State ที่เปลี่ยนแปลงไป ในขณะเดียวกัน State ก็อาจจะเปลี่ยนแปลงได้จากการที่ได้รับ Event บางอย่างมาจาก UI

ยกตัวอย่าง:

class MainActivity : AppCompatActivity() {

   private lateinit var binding: MainActivityBinding
   var name = ""

   override fun onCreate(savedInstanceState: Bundle?) {
       /* ... */
       binding.textUpdateButton.setOnClickListener {
           name = randomDisplayText()
           updateHello()
       }
   }

   private fun randomDisplayText(): String {
    return when((Math.random() * (4 - 1) + 1).toInt()) {
                1 -> "Android"
                2 -> "JetPack"
                3 -> "Hilt"
                4 -> "People"
                else -> "World"
       }
   }

   private fun updateHello() {
       binding.helloText.text = "Hello, $name"
   }
}

Code ข้อบนชุดนี้คือ เราจะทำการ Update ค่าที่นำมาแสดงของ helloText เมื่อ User มีการกดปุ่มเพื่อ random โดยตัวอย่างโค๊ตข้างบนสามารถทำงานได้ถูกต้อง 100% ทีนี้ปัญหาคืออะไร? 🤔

เราลองนึกถึงแอพที่ Scale ใหญ่ขึ้น หน้าจอมีความซับซ้อนมากขึ้น การเขียนโค๊ตลักษณะนี้อาจจะก่อให้เกิดปัญหาหลายอย่างเช่นการ Test เนื่องจากว่าค่าที่นำมาแสดงผลอยู่ภายใน View (State ของ helloText อยู่ใน View) การ test นั้นเป็นเรื่องค่อนข้างยาก หรือแอพมี Events มากขึ้นแล้วเราต้อง Update UI หรือ ค่า State ต่างๆ มันเป็นเรื่องง่ายมากที่เราจะลืมมาแก้ไข/เปลี่ยนแปลง Code ชุดนี้ รวมขึ้น Code Complexity ที่จะเกิดขึ้นในอนาคต

ใช้ ViewModel และ LiveData ช่วยในการจัดการ State

class MainViewModel: ViewModel() {

   // LiveData holds state which is observed by the UI
   // (state flows down from ViewModel)
   private val _name = MutableLiveData("")
   val name: LiveData<String> = _name

   // onNameChanged is an event we're defining that the UI can invoke
   // (events flow up from UI)
   fun onNameChanged() {
       _name.value = randomDisplayText()
   }

   private fun randomDisplayText(): String {
       return when((Math.random() * (4 - 1) + 1).toInt()) {
        1 -> "Android"
        2 -> "JetPack"
        3 -> "Hilt"
        4 -> "People"
        else -> "World"
       }
   }
}

class MainActivity : AppCompatActivity() {
   val helloViewModel by viewModels<MainViewModel>()

   override fun onCreate(savedInstanceState: Bundle?) {
       /* ... */

       binding.textUpdateButton.setOnClickListener {
           helloViewModel.onNameChanged() 
       }

       helloViewModel.name.observe(this) { name ->
           binding.helloText.text = "Hello, $name"
       }
   }
}

จะเห็นว่าสิ่งที่เกิดขึ้นใน Code ชุดข้างบนคือ เราให้ การกดปุ่มจะไป update ค่าของ LiveData แทนที่จะ Update UI ตรงๆ ทำการ observe LiveData ตัวนั้นเพื่อทำการเปลี่ยนแปลงค่าใน helloText

Event/Action ในที่นี้ Event หรือ Action คือ การที่ User กดปุ่ม
State Updating เกิดขึ้นที่ onNameChanged เมื่อค่าของ LiveData เปลี่ยนแปลงไป เรียกว่าเราได้ทำการ Hoist State เอาไว้ที่ LiveData ของ ViewModel ของเรา (State Hoisting)
State Displaying เกิดขึ้น Observer เมื่อทำการเปลี่ยนแปลงค่าของ helloText

ลอง Implement Code แบบเดียวกันด้วย JetPack Compose

ผมจะลองสร้าง Sample Code ขึ้นมาให้หน้าตาและการทำงานมีลักษณะดังนี้

โดยทุกๆครั้งที่ User กดปุ่ม เราจะทำการ random ข้อความขึ้นมาใหม่และแสดงที่ Text ตัวแอพจะแสดง Icon อยู่ทางขวาจะ random ขึ้นมาเหมือนกันแต่แค่ครั้งเดียวหลังจากที่เปิดแอพใหม่ โดยเราจะมี ViewModel อยู่แล้ว หน้าตาแบบนี้

class MainViewModel: ViewModel() {

    // LiveData holds state which is observed by the UI
    // (state flows down from ViewModel)
    private val _name = MutableLiveData("")
    val name: LiveData<String> = _name

    // onNameChanged is an event we're defining that the UI can invoke
    // (events flow up from UI)
    fun onNameChanged() {
        _name.value = randomDisplayText()
    }
}

พร้อมกับ Function สำหรับ Random Text

    fun randomDisplayText(): String {
        return when((Math.random() * (4 - 1) + 1).toInt()) {
            1 -> "Android"
            2 -> "JetPack"
            3 -> "Hilt"
            4 -> "People"
            else -> "World"
        }
    }

สร้าง UI ด้วย Column และ Row

Column และ Row เป็น Layout พื้นฐานของ Compose โดย

Column จะแสดง Child เรียงเป็นแนวตั้ง คล้ายกับ LinearLayout ที่มี orientation="vertical"
Row จะแสดง Child เรียงเป็นแนวนอน คล้ายกับ LinearLayout ที่มี orientation="horizontal"

เราจะให้ Text และ Button อยู่ใน Column (กรอบสีแดง)เนื่องจากเรียงจากบนลงล่างและให้ตัว Column และ Icon อยู่ภายใน Row (กรอบสีน้ำเงิน)

สร้าง Composable Function ในที่นี้ให้ชื่อว่า MyScreen

@Composable
fun MyScreen() {

}

เพิ่ม Row โดยกำหนด Modifier ให้ แสดงผลเต็มทางแนวนอน และมี padding เป็น 16dp

@Composable
fun MyScreen() {
+     Row(modifier = Modifier
+         .fillMaxWidth()
+         .padding(16.dp)){
+     }
}

เพิ่ม Column โดยกำหนด weight ให้ Column = 1

@Composable
fun MyScreen() {
    Row(modifier = Modifier
        .fillMaxWidth()
        .padding(16.dp)) {
+         Column(modifier = Modifier.weight(1f)) {

+         }
    }
}

เพิ่ม Icon ในเคสนี้เราต้องการให้ Icon ถูก random ขึ้นมาเฉพาะครั้งแรกที่เปิดแอพเท่านั้น

@Composable
fun MyScreen() {
    Row(modifier = Modifier
        .fillMaxWidth()
        .padding(16.dp)) {
         Column(modifier = Modifier.weight(1f)) {

         }
        + MyRandomIcon(asset = randomIconAsset())
    }
}

+ @Composable
+ fun MyRandomIcon(asset: VectorAsset) = Icon(asset = asset)

+ fun randomIconAsset(): VectorAsset {
+    return when((Math.random() * (14 - 1) + 1).toInt()) {
+                1 -> Icons.Default.Cloud
+                2 -> Icons.Default.CloudQueue
+                3 -> Icons.Default.CloudUpload
+                4 -> Icons.Default.CloudOff
+                5 -> Icons.Default.CloudDone
+                6 -> Icons.Default.CloudDownload
+                7 -> Icons.Default.WbCloudy
+                8 -> Icons.Default.Wifi
+                9 -> Icons.Default.WifiCalling
+                10 -> Icons.Default.WifiLock
+                11 -> Icons.Default.WifiProtectedSetup
+                12 -> Icons.Default.WifiOff
+                13 -> Icons.Default.WifiTethering
+                14 -> Icons.Default.PortableWifiOff
+                else -> Icons.Default.FavoriteBorder
+    }
+ }

เพิ่ม Text และ Button เข้าไปที่ Column

@Composable
fun MyScreen() {
    Row(modifier = Modifier
        .fillMaxWidth()
        .padding(16.dp)) {
           Column(modifier = Modifier.weight(1f)) {
+             Text("")
+             Button(onClick = {}) {
+                Text(text = "Click Me")
+             }
           }
           MyRandomIcon(asset = randomIconAsset())
    }
}

เพิ่ม MyScreen เข้าไปที่ onCreate ของ Activity

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MyAppTheme {
                Surface(color = MaterialTheme.colors.background) {
                    MyScreen(
                        text = "", {}
                    )
                }
            }
        }
    }

Preview

เราสามารถ Preview หน้าตา UI ที่เราสร้างได้ด้วย @Preview ให้เราทำการสร้าง Function แยก ชื่อว่า PreviewMyScreen เพื่อใช้สำหรับ Preview อย่างเดียว

+ @Preview(showBackground = true)
+ @Composable
+ fun PreviewMyScreen() {
+    ComposeStatePlaygroundTheme {
+        MyScreen()
+    }
+ }

showBackground = true เพื่อแสดง Background ของแอพ
ทำการ Build app 1 ครั้งเพื่อ Preview
หน้าตาที่ได้:

เรายังสามารถทำการกดปุ่ม Interactive เพื่อทำการลองเล่นหน้าตา UI ของเราก่อนที่จะ Run ลงเครื่องจริงๆ ได้ด้วย

เนื่องจากเจ้า JetPack Compose นั้นเป็น Declarative UI โดยเจ้า Declarative UI นั้นตัว Code เองคือตัวอธิบายว่าหน้าตา UI จะเป็นอย่างไร
เมื่อ User กดปุ่ม เราต้องการให้ Text แสดงค่า random Text จาก function ที่เราเตรียมไว้ หรือพูดง่ายๆก็คือ Update State ของ Text นั่นเอง

State และ MutableState

เป็น Build-in Interface ของ JetPack Compose โดยปกติ Composable Function จะทำการ "subscribe" กับ value ของ State<T> เมื่อ value มีการเปลี่ยนแปลง Composable Function จะทำการ Recompose ตัวเองเพื่อ Update UI ใหม่

@Stable
interface State<T> {
    val value: T
}

โดย value สามารถเปลี่ยนแปลงได้ผ่านทางการเรียก MutableState<T> อีกที

@Stable
interface MutableState<T> : State<T> {
    override var value: T
    ....
}

เพิ่ม State ให้ Function MyScreen

@Composable
fun MyScreen() {
+ var text: String by remember { mutableStateOf(randomDisplayText())}
    Row(modifier = Modifier.fillMaxWidth().padding(16.dp)) {
           Column(modifier = Modifier.weight(1f)) {
              Text(text)
              Button(onClick = {
+                  text = randomDisplayText()
             }) {
                 Text(text = "Click Me")
               }
           }
           MyRandomIcon(asset = randomIconAsset())
    }
}

Function mutableStateOf จะทำการ return ค่า MutableState โดยในที่นี้เราจะกำหนดค่าเริ่มต้นให้กับ State เลย ด้วยการเรียก randomDisplayText() และเมื่อมีการกดปุ่มเราจะทำการ update ค่าของ text อีกครั้งด้วยการเรียก text = randomDisplayText()
อีกจุดนึงที่สังเกตเห็นได้คือมีการเรียกใช้ function remember ซึ่งจะขออธิบายในลำดับถัดไป
ลองรันแอพ:

ทุกๆครั้งที่เรากดปุ่ม Text ของเราอัพเดทถูกต้อง แต่จะเห็นว่า Icon ก็โดนเปลี่ยนไปด้วย???? 🤨🤨🤨

อย่างที่บอกไว้ก่อนหน้านั้น เนื่องจากว่า Composable function จะ "subscribe" ตัวเองกับ State เมื่อ State เปลี่ยน (ในที่นี้คือ text) function จะมีการ Recompose เพื่อแสดงผลใหม่ ทำให้ ตัว Function เองโดนเรียกซ้ำทำให้ function randomIconAsset โดนเรียกซ้ำอีกที

ลองใส่ Log ที่ MyScreen()

Log.d("MyComposeApp", "MyScreen is called")

สังเกตุได้ว่าค่าที่ Log ไม่ถูก Print เมื่อค่าที่ Random ได้ยังเป็นค่าเดิม

เอ๊ะแล้วแบบนี้มันแตกต่างกับ randomDisplayText() ยังไง 🤔??

Memory ใน Function

จุดที่แตกต่างสำคัญเลยระหว่าง randomDisplayText randomIconAsset ที่ชัดเจนเลยคือ:

randomDisplayText เป็น Initiate value ของ State (เราเรียก randomDisplayText ใน mutableStateOf)
mutableStateOf ถูก wrap ด้วย remember Composable function จะมีความสามารถในการจดจำค่าก่อนหน้าว่าเป็นค่าอะไร เมื่อเกิดการ Recomposition ขึ้น ตัว composable function จะนำค่าที่จดจำอยู่มาแสดงแทน ในกรณีของเรา เรามีการจดจำ "State<String>" ซึ่ง value ของ State<String> ก็คือ text นั่นเอง

var text: String by remember { mutableStateOf(randomDisplayText())}

สามารถเขียนในอีกแบบได้เป็น

var text :MutableState<String> = remember { mutableStateOf(randomDisplayText())}
...
+           Text(text = text.value)
            Button(onClick = {
+               text.value = randomDisplayText()
            }) {
                Text(text = "Click Me")
            }

แก้ไม่ให้ Icon Update ทุกครั้ง

วิธีการแก้ในเคสนี้เราสามารถทำได้สองแบบ
แบบที่ 1:
เราสามารถใช้เจ้า remember กับ randomIconAsset ได้ เพื่อให้ค่าที่ถูก random มาครั้งแรก ถูกจดจำไว้:

val asset by remember { randomIconAsset() }
MyRandomIcon(asset = asset)

แบบที่ 2:
เราสามารถทำให้ MyRandomIcon ไม่มีการ Share State กันระหว่างตัวมันเองกับ MyScreen โดยเราสามารถทำได้โดยย้าย randomIconAsset ไปไว้ใน MyRandomIcon แทน

@Composable
fun MyRandomIcon() {
    Icon(asset = randomIconAsset())
}

State hoisting

จาก Code ชุดข้างบน เราจะเห็นว่าตัว Function MyScreen เองนั้นเป็นคนถือ State เอาไว้ (Stateful) ในเคสนี้นั้นเราต้องการให้ ViewModel เป็นคนถือ State แทน เรียกว่า hoist/lift State ไปไว้ที่ LiveData ของ ViewModel แทน
เมื่อ User กดปุ่ม เราจะ Update value ใน LiveData ที่อยู่ใน ViewModel เท่ากับเราต้องทำการ

Bind ค่าที่อยู่ใน LiveData กับ Text
Bind action ของการกดปุ่มเข้ากับ onNameChanged function ของ ViewModel

ทำการเพิ่ม Parameter ใน Function เป็น String และ lambda สำหรับการแสดงผลและการกดปุ่มและนำ State ของ Function ออก

@Composable
fun MyScreen(
+ text: String, 
+ onButtonClick: () -> Unit
) {
- var text : MutableState<String> = remember { mutableStateOf(randomDisplayText()) }
    Row(modifier = Modifier
        .fillMaxWidth()
        .padding(16.dp)) {
           Column(modifier = Modifier.weight(1f)) {
+             Text(text)
+             Button(onClick = onButtonClick) {
                Text(text = "Click Me")
             }
           }
           val asset by remember { randomIconAsset() }
           MyRandomIcon(asset = asset)
    }
}

@Preview(showBackground = true)
@Composable
fun PreviewMyScreen() {
   ComposeStatePlaygroundTheme {
+       MyScreen("Hello Android") {} 
   }
}

จาก Code ชุดข้างบนจะทำให้ function MyScreen ไม่มีการถือ State เอาไว้ สำหรับเปลี่ยนแปลงค่า displaying Text (Stateless)

observeAsState

JetPack Compose ได้สร้าง extension function มาให้เราแล้วชื่อ observeAsState เพื่อทำการ Convert LiveData ให้เป็น State

ใน onCreate ทำการ convert LiveData ใน ViewModel ให้เป็น State

setContent {
            MyAppTheme {
                Surface(color = MaterialTheme.colors.background) {
+                     val text by viewModel.name.observeAsState()
                    MyScreen(
+                     text = text, 
+                     onButtonClick = viewModel::onNameChanged)
                }
            }
        }

ลองรันแอพอีกครั้ง

แน่นอนว่าการทำงานยังเหมือนเดิม สิ่งที่แตกต่างคือ State นั้นอยู่ที่ LiveData ของ ViewModel แทน
จริงๆเรายังสามารถให้ State อยู่ที่ ViewModel ได้โดยตรงด้วยโดย:

เอา LiveData ออก

-     private val _name = MutableLiveData("")
-     val name: LiveData<String> = _name

เปลี่ยนเป็น State แทน

+ import androidx.compose.runtime.mutableStateOf
+ import androidx.compose.runtime.setValue
+ import androidx.compose.runtime.getValue

class MainViewModel: ViewModel() {
...
+     var name: String by mutableStateOf("")
+         private set

แก้ไข function onNameChanged

fun onNameChanged() {
        - _name.value = randomDisplayText()
+         name = randomDisplayText()
    }

ใส่ name เข้าไปตรงๆที่ MyScreen:

Surface(color = MaterialTheme.colors.background) {
- val text by viewModel.name.observeAsState()
   MyScreen(
   - text,
+    viewModel.name,
   viewModel::onNameChanged)
                }

ผลลัพธ์ที่ได้ก็ยังคงเหมือนเดิม
เราสามารถเรียกใช้ mutableStateOf ใน ViewModel ได้เมื่อเรามั่นใจว่า View นั้นเป็น Compose แต่ถ้าเรายังต้องใช้ ViewModel contact กับ Android View System เดิม ใช้ LiveData หรือ State/Share Flow น่าจะเหมาะสมกว่า
สำหรับคนที่สนใจ แนะนำว่าสามารถศึกษาเพิ่มเติมได้จาก JetPack Compose - Pathway ในบทความหน้าจะลองยกตัวอย่าง Compose UI ที่ซับซ้อนขึ้นเช่นการใช้ LazyColumnFor (RecycelerView ในโลกของ JetPack Compose) รวถึงการใช้ State/ShareFlow หรือหากท่านใดสนใจ สามารถดู source code ตัวอย่างได้จากเจ้าของ Blog ทางนี้เลย

Reference:

Modernized Android architecture - Hilt

Eddie Eddie — Sat, 02 Jan 2021 14:52:16 +0000

Cover Photo by Roman Koval from Pexels

แรกเริ่มเดิมทีว่าจะลองเขียน Blog เกี่ยวกับ JetPack Compose อย่างเดียว แต่ทำไปทำมาตอนลองทำ Sample Project แล้วมันดันมีจุดที่น่าสนใจหลายอย่างเลยคิดว่าถ้าเราเขียนเรื่อง JetPack Compose อย่างเดียวคงไม่จบ เลยอยากจะเขียนบทความนี้แยกเป็นหลายๆส่วน โดย Follow ตามตัวอย่าง code แบ่งตามเรื่องที่น่าสนใจดังนี้

Hilt
JetPack Compose (UI Component) & Unidirectional Data Flow
จัดการ ใน JetPack Compose ด้วย LiveData และ State
จัดการ ใน JetPack Compose ด้วย State/Share Flow

Hilt

Hilt คือ Library ที่ Google เพิ่งจะออกมาสดๆร้อนๆ โดยถูกสร้าง on-top ด้วย Dagger2 อีกที ใช้สำหรับการทำ Dependency Injection ใน Android ให้ง่ายขึ้น เรียกว่าเป็น Simplified version ของ Dagger Android ก็ว่าได้

ทำไมต้องทำ Dependency Injection

เพื่อให้เข้าใจภาพแบบง่ายขึ้น ยกตัวอย่าง สมมติเรามี class ที่ต้องทำหน้าที่ส่งข้อความโดยแรกเริ่มเดิมที่ ข้อความที่ส่งไปมันก็เป็น email ธรรมดา โดย function จะ return True หรือ False มาหากส่งข้อความสำเร็จหรือไม่สำเร็จ

class EmailSender {

fun sendEmail(message: String): Boolean {
 // TO-DO email sending implementation is processed here
   }
}

โดยเจ้า Class นี้ก็จะถูกเรียกใช้งานในอีก Layer นึง

class MessageProcessor {

private val emailSender = EmailSender()

fun sendProcessedMessage() {
 val message = // doing many things to get message
 emailSender.sendEmail(message)
}
}

class Main {

fun main() {
val processor = MessageProcessor()
processor.sendProcessedMessage()
}
}

ถ้าดูจากการใช้งานแล้ว ในเคสนี้ก็ไม่น่ามีอะไร เจ้า MessageProcessor ก็ไป process ข้อความมาเพื่อจะส่ง message จากนั้นก็ส่งผ่าน EmailSender ก็จบ ดูแล้วก็ไม่น่าจะมีปัญหาตรงไหน 🤔

⚠️ ประเด็นอยู่ตรงที่ว่า ถ้าเราสังเกตุดีๆ เราจะเห็นว่า MessageProcessor นั้นมัน depends กับตัว EmailSender อยู่ ถ้าเราสร้าง class MessageProcessor มาเมื่อไหร่ ตัว EmailSender ก็จะถูกสร้างมาด้วยอัตโนมัติ ให้เราลองนึกถึงการเขียน Test เจ้าตัว MessageProcessor คงเป็นเรื่องยากพอสมควร
สมมติว่าเราสามารถเขียน Test มันได้ แล้ววันนึง Requirement มันเปลี่ยนแทนที่จะต้องส่ง email กลายเป็นว่าต้องส่ง sms แทนล่ะ เท่ากับว่า Test ที่เราเขียนไปอาจจะต้องแก้พอสมควรเลย แบบนี้ไม่ดีแน่ สิ่งที่เราควรทำคือ ลด dependency ระหว่าง class แต่ละ class ลงซะ เลยเป็นที่มาของการทำ Dependency Injection
ในเคสนี้จะยกตัวอย่างการทำ Constructor Injection เนื่องจากว่าเป็นวิธีที่ง่ายต่อความเข้าใจรวมถึงง่ายต่อการเทสกว่า มากๆ

สร้าง interface MessageSender

interface MessageSender {
 fun send(message: String): Boolean
}

ให้ class EmailSender extends MessageSender

class EmailSender: MessageSender {
 override fun send(message: String): Boolean {
// TO-DO email sending implementation is processed here
 }
}

ให้ class SmsSender extends MessageSender

class SmsSender: MessageSender {
 override fun send(message: String): Boolean {
// TO-DO sms sending implementation is processed here
 }
}

inject MessageSender ไปที่ constructor ของ MessageProcessor

class MessageProcessor internal constructor(
private val msgSender: MessageSender
) {

fun sendProcessedMessage() {
 val message = // doing many things to get message
 msgSender.send(message)
}
}

class Main {

fun main() {
val processor = MessageProcessor(SmsSender())
processor.sendProcessedMessage()
 }
}

Unit Test ของ MessageProcessor

class MessageProcessorTest {

private val msgSender: MessageSender = mock()
private val processor = MessageProcessor(msgSender)

@Test
fun `test sendProcessedMessage(), msgSender send() is called`() {
  processor.sendProcessedMessage()
  Mockito.verify(msgSender.send(anyString()))
}
}

จริงๆ หลักการของ Dependency Injection มีง่ายๆแค่นี้ Dagger2, DaggerAndroid และ Hilt แค่ช่วยให้เราสามารถทำงานได้ง่ายขึ้นบน Android เท่านั้นเอง

Setup Hilt

จริงๆ วิธีการ Setup นั้นไม่ยากเลย โดย Google ได้อธิบายเป็น Step เอาไว้ให้เราแล้ว สามารถเข้าไปทำตามได้ที่นี่ ทั้งนี้ทั้งนั้นเผื่อคนที่ไม่อยาก Switch ไปอีกหน้า ผมจะเขียนวิธีการตาม Google เอาไว้ในนี้เลยละกัน

ไปที่ file build.gradle ที่ Root ของ Project เราแล้วใส่

buildscript {
    ...
    dependencies {
        ...
        classpath "com.google.dagger:hilt-android-gradle-plugin:$hilt_version"
    }
}

ไปที่ file build.gradle ของ module ที่ต้องการใช้ Hilt ในเคสนี้คือ app/build.gradle

...
apply plugin: 'kotlin-kapt'
apply plugin: 'dagger.hilt.android.plugin'

android {
    ...
}

dependencies {
    implementation "com.google.dagger:hilt-android:$hilt_version"
    kapt "com.google.dagger:hilt-android-compiler:$hilt_version"
}

Hilt ใช้ feature ของ Java8 จึงต้องประกาศด้วย

android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}

Sync Project ให้เรียบร้อย หลังจากนั้นทำการสร้าง Application class ของเราขึ้นมาแล้วใส่ @HiltAndroidApp ให้เรียบร้อย

import android.app.Application
import dagger.hilt.android.HiltAndroidApp

@HiltAndroidApp
class ComposePlaygroundApplication: Application()

ใน Activity ของเราใส่ @AndroidEntryPoint

@AndroidEntryPoint
class MainActivity : AppCompatActivity()

เท่านี้เราก็พร้อมใช้งาน Hilt แล้ว

เทียบกับ Dagger

ใน Hilt เราเพียงใส่ @HiltAndroidApp ที่ Application Class ในขณะที่
Dagger2 เราอาจจะต้องสร้าง Component class ที่มี fun inject(activity: MainActivity) ข้างใน หรือถ้าใครใช้ Dagger-Android วิธีการอาจจะซับซ้อนกว่านี้พอควร ในขณะที่ Hilt เพียงแค่เราประกาศ annotation ก็เพียงพอแล้ว

Field Injection

ใน Hilt นั้น การ inject นั้นง่ายมากๆ ยกตัวอย่างให้เห็นภาพ เรามี Activity class แล้วต้องการจะ inject class นึงเข้าไปใน Activity สมมติง่ายๆว่าเป็น EmailSender class ละกัน
Activity ของเรา

@AndroidEntryPoint
class MainActivity : AppCompatActivity() { 
}

class สำหรับส่ง email

class EmailSender {
  fun send(msg: String) {
   println("$msg is sent")
  }
}

ถ้าเราต้องการ inject EmailSender เข้าไปใน Activity เราสามารถประกาศ @Inject ที่ Constructor ได้เลยตามนี้

class EmailSender 
+ @Inject constructor() {
  fun send(msg: String) {
   println("$msg is sent")
  }
}

ภายใน Activity เราสามารถประกาศ

@AndroidEntryPoint
class MainActivity : AppCompatActivity() { 
+ @Inject
+ laterinit var emailSender: EmailSender
}

เพียงเท่านี้ EmailSender ก็พร้อมใช้งานใน MainActivity ของเรา

Constructor Injection

จากตัวอย่างข้างบน สมมติเราต้องการจะ format message ก่อนจะส่งโดยเรียกใช้class MessageFormatter โดยเราต้องการ Inject MessageFormatter เข้าไปใน EmailSender ผ่านทาง Constructor เราก็สามารถทำได้ยกตัวอย่าง

class สำหรับ format ข้อความ

class MessageFormatter {
 fun formatMessages(msg: String): String {
  return "formatted $msg"
 }
}

เพิ่ม @Inject constructor() ไปที่ MessageFormatter

class MessageFormatter 
+ @Inject constructor() {
 fun format(msg: String): String {
  return "formatted $msg"
 }
}

class EmailSender 
@Inject constructor(
+ private val formatter: MessageFormatter
) {
  fun send(msg: String) {
   println("${formatter.format(msg)}is sent")
  }
}

ปัญหา Injection กับ Interface

จากตัวอย่างข้างบนเราทำการ inject class ตรงๆ เข้าไปใน constructor ซึ่งสามารถทำได้ แต่ในหลายๆครั้ง เราต้องการให้ code ของเรามีความ abstract มากขึ้น เพื่อง่ายต่อการ Test วิธีการส่วนมากที่เราทำกันนั้นคือการสร้าง interface มาครอบ class ของเราอีกที ซึ่งใน Hilt ไม่สามารถทำได้ตรงๆตามวิธีการข้างบน
ยกตัวอย่าง:
เรามี Class ที่ชื่อ EmailSender สำหรับส่ง email อยู่แล้วโดยเราต้องการที่จะ Format ข้อความเราก่อนจะส่ง โดยในที่นี้เราจะสร้าง Interface มาเพื่อทำการ format ข้อความชื่อ MessageFormatter

สร้าง Interface ชื่อ MessageFormatter

interface MessageFormatter {
fun format(msg: String): String
}

สร้าง class ชื่อ MessageFormatterV1Impl ที่สืบทอดมาจาก MessageFormatter

class MessageFormatterV1Impl 
@Inject constructor(): MessageFormatter {
 override fun format(msg: String): String {
  return "formatted $msg"
 }
}

สร้าง class ชื่อ MessageFormatterV2Impl ที่สืบทอดมาจาก MessageFormatter

class MessageFormatterV2Impl 
@Inject constructor(): MessageFormatter {
 override fun format(msg: String): String {
  return "$msg is formatted"
 }
}

เรามี 2 classes ที่ extend มาจาก MessageFormatter ชื่อ MessageFormatterV1Impl และ MessageFormatterV2Impl โดยทั้งสอง class ทำหน้าที่ format ข้อความเหมือนกัน แต่วิธีการ format ข้อความต่างกัน

inject MessageFormatter ที่เป็น Inteface เข้าไปใน constructor ของ EmailSender

class EmailSender 
@Inject constructor(
+ private val formatter: MessageFormatter
) {
  fun send(msg: String) {
   println("${formatter.format(msg)}is sent")
  }
}

Error หลังจาก Build:

error: [Dagger/MissingBinding] MessageFormatter cannot be provided without an @Provides-annotated method.
  public abstract static class ApplicationC implements ComposePlaygroundApplication_GeneratedInjector,
                         ^

จริงๆ Error นั้นเรียกว่า make sense มากๆ ตรงที่ code ของเราจะรู้ได้ยังไงว่าจะเอา instant ไหน inject เข้าไปใน Constructor กันล่ะในเมื่อมี 2 classes ที่ implement interface เดียวกัน ซึ่งวิธีการแก้ปัญหานั้นอาจจะต้องใช้ตัวช่วยสักหน่อย นั่นก็คือการสร้าง @Module

หมายเหตุ 💡 ข้อดีของการทำ Constructor injection คือเราไม่จำเป็นต้องทำอะไรเพิ่มเติมเลยหากเราต้องการจะเขียน UnitTest ไม่ใช่แค่สำหรับ Hilt แต่ Dagger ด้วยก็เหมือนกัน โดยเฉพาะอย่างยิ่งการทำ Constructor injection ด้วย Interface นั้นทำให้การ Mock เป็นเรื่องง่ายมากๆครับ

Component

ก่อนจะเริ่มสร้าง Module นั้น สิ่งที่เราต้องทำความเข้าใจก่อนคือ Component และ Component Scope ตัว Hilt เองนั้นจะมีการ pre-create Hilt Components มาให้เราใช้งานแล้วโดยที่เราไม่จำเป็นต้องไปสร้าง Component เองเหมือนที่เราทำใน Dagger โดยสามารถแบ่งตามนี้

ถึงตรงนี้หลายคนอาจจะงงว่า Component นั้นคืออะไร ถ้าพูดให้เข้าใจง่ายคือ เปรียบเสมือน Layer ที่เราอยากจะให้ instance ที่เราสร้างเข้าไปอยู่ ยกตัวอย่าง เราอยากจะให้ EmailSender class ของเราใช้ได้ Activity เราก็เพียงแค่ต้องมั่นใจว่า มันถูก "ใส่" เข้าไปใน (@InstallIn) ActivityComponent

แล้วเมื่อไหร่ที่ instance เราถูกสร้างและถูกทำลายล่ะ?

instance ที่ถูก bound เข้าไปจะถูกสร้างและทำลายตามแต่ละ Component ที่ตัวมันเองโดน installed ลงไป

Scope

โดยปกติแล้ว instance ที่ถูกสร้างขึ้นมาจะไม่มีการกำหนด scope ของการใช้งาน (unscoped) นั่นหมายความว่า ทุกๆครั้งที่มีการเรียกใช้ class นั้น instance นั้นจะถูกสร้างขึ้นมาใหม่ ยกตัวอย่าง:
เรามี class EmailSender

class EmailSender @Inject constructor() {
    fun send(msg: String){
        println(msg)
    }
}

ทำการ inject EmailSender ในอีก class นึงผ่านทาง Constructor ชื่อว่า MessageHandler แล้วลอง Print ค่าออกมาดู

class MessageHandler @Inject constructor(
    private val sender: EmailSender
) {
    init {
        println("emailSender from ${this::class.java} $sender" )
    }
}

ทำการ inject ทั้ง EmailSender และ MessageHandler ใน Activity

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject
    lateinit var emailSender: EmailSender

    @Inject
    lateinit var messageHandler: MessageHandler

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        println("emailSender from ${this::class.java} $emailSender" )
    }
}

เรา Inject MessageHandler เพื่อให้ Hilt สร้าง instance ของ MessageHandler เพื่อดูค่า EmailSender ที่เรา print ใน init ของ MessageHandler
เรา Inject EmailSender เพื่อให้ Hilt สร้าง instance ของ EmailSender เพื่อดูค่า EmailSender ที่เรา print ใน onCreate ของ Activity

ค่าที่ได้:

2021-01-04 16:13:03.060 7374-7374/? I/System.out: emailSender from class MessageHandler EmailSender@cacc883
2021-01-04 16:13:03.102 7374-7374/? I/System.out: emailSender from class MainActivity EmailSender@72ec68a

จะเห็นว่า Instance นั้นเป็นคนละตัวกัน

ลองกำหนด Scope ลงไปใน EmailSender ในเคสนี้จะลองกำหนด @ActivityScoped

+ @ActivityScoped
class EmailSender @Inject constructor() {
    fun send(msg: String){
        println(msg)
    }
}

ค่าที่ได้:

2021-01-04 16:16:06.611 7714-7714/? I/System.out: emailSender from MessageHandler EmailSender@b6f3903
2021-01-04 16:16:06.634 7714-7714/? I/System.out: emailSender from class MainActivity EmailSender@b6f3903

Scope เปรียบเสมือนขอบเขตของการใช้งานว่าเราอยากจะให้ Instance นั้นถูกใช้ได้ในขอบเขตไหนลงไปเป็นลำดับขั้น โดย Hilt เอง ก็ได้ทำการ Predefined เอาไว้แล้วตามนี้

ยกตัวอย่าง:
ตัวอย่างที่ 1 ต้องการให้ class EmailSender ใช้งานได้ใน Activity และให้ class EmailSender และมีขอบเขตการใช้งานภายใน Activity ลงไป
เทียบตาราง:

ต้องให้ class EmailSender ถูก Inject ใน Activity
ต้องให้ class EmailSender มี Scope เป็น ActivityScope

ตัวอย่าง Code:
ประกาศ @ActivityScoped

@ActivityScoped
class EmailSender @Inject constructor() {
    fun send(msg: String) {
        println("msg is sent")
    }
}

ใช้งาน EmailSender ใน Activity

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject
    lateinit var emailSender: EmailSender
}

ตัวอย่างที่ 2 ต้องการให้ class EmailSender ใช้งานได้ใน Fragment และให้ class EmailSender และมีขอบเขตการใช้งานภายใน Fragment ลงไป
เทียบตาราง:

ต้องให้ class EmailSender ถูก Inject ใน Fragment
ต้องให้ class EmailSender มี Scope เป็น FragmentScope

ตัวอย่าง Code:
ประกาศ @FragmentScoped

@FragmentScoped
class EmailSender @Inject constructor() {
    fun send(msg: String) {
        println("msg is sent")
    }
}

ใช้งาน EmailSender ใน Fragment

@AndroidEntryPoint
class MainFragment : Fragment() {

    @Inject
    lateinit var emailSender: EmailSender
}

ตัวอย่างที่ 3 ต้องการให้ class EmailSender ใช้งานได้ใน Fragment แต่ยังให้ class EmailSender และมีขอบเขตการใช้งานภายใน Activity ลงไป
เทียบตาราง:

ต้องให้ class EmailSender ถูก Inject ใน Fragment
ต้องให้ class EmailSender มี Scope เป็น ActivityScope

ตัวอย่าง Code:
ประกาศ @ActivityScoped

@ActivityScoped
class EmailSender @Inject constructor() {
    fun send(msg: String) {
        println("msg is sent")
    }
}

ใช้งาน EmailSender ใน Fragment

@AndroidEntryPoint
class MyFragment : Fragment() {

    @Inject
    lateinit var emailSender: EmailSender
}

เนื่องจากว่า ขอบเขตการใช้งานของ EmailSender อยู่ใน Activity แต่การใช้งานเรานำไปใช้ใน Fragment ซึ่งอยู่ภายใต้ Activity อีกที ในกรณีนี้นั้นสามารถทำได้

ข้อควรระวัง Scope กับ Component นั้นมีความสัมพันธ์กันเป็นลำดับชั้น ถ้าหากเราประกาศ Scope กับ Component ไม่ถูกต้องเราอาจจะเจอ Error ได้ยกตัวอย่าง:

ให้ class EmailSender ถูกใช้งานใน Activity
แต่ให้ class EmailSender มี Scope เป็น FragmentScope เพราะต้องการให้ Class EmailSender มีขอบเขตการใช้งานแค่ภายใน Fragment

Compile Error ที่เกิดขึ้น:

error: [Dagger/IncompatiblyScopedBindings] ComposePlaygroundApplication_HiltComponents.ActivityC scoped with @dagger.hilt.android.scopes.ActivityScoped may not reference bindings with different scopes:
  public abstract static class ApplicationC implements ...,

แก้ไขปัญหา Constructor Injection กับ Interface

จากที่บอกไปด้านบนคือ วิธีการแก้ไขนั้นทำได้ไม่ยากโดยการใช้ Module ซึ่งวิธีการใช้งาน Module ของ Hilt นั้นมี 2 วิธีหลักๆ คือการ @Binds และ @Provides

Binds module

วิธีการ bind instance ด้วยการใช้ @Binds ค่อนข้างเรียบง่ายและเหมาะกับการแก้ปัญหา constructor injection ด้วย interface ในกรณีที่เรามี class ที่เราต้องการ bind instance เข้าไป ยกตัวอย่าง:

เรามี MessageFormatter ที่เป็น interface และมี class MessageFormatterImpl ที่เป็น class

interface MessageFormatter {
fun format(msg: String): String
}

class MessageFormatterImpl: MessageFormatter {
fun format(msg: String): String {
 return "Formatted $msg"
}
}

ต้องการ inject เข้าไปที่ constructor ของ EmailSender class

class EmailSender
@Inject constructor(
private val formatter: MessageFormatter
)

เราต้องการ Inject EmailSender เข้าไปที่ Activity โดยที่ Compile ผ่าน

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject
    lateinit var emailSender: EmailSender
}

เริ่มทำการสร้าง Module ในที่นี้จะให้ชื่อว่า MessageSendingModule

@Module
abstract class MessageSendingModule {

}

ทำการประกาศว่าจะทำ Module ไปใช้ที่ไหน ในที่นี้ เราต้องการใช้ EmailSender ที่ Activity เราจึงต้องประกาศ @InstallIn(ActivityComponent::class)

+ @InstallIn(ActivityComponent::class)
@Module
abstract class MessageSendingModule {

}

ทำการ Bind Instance ของ MessageFormatter

@InstallIn(ActivityComponent::class)
@Module
abstract class MessageSendingModule {

+ @Binds
+ fun bindMessageFormatter(impl: MessageFormatterImpl): MessageFormatter
}

จุดสังเกตุ ⚠️⚠️ เราใส่ MessageFormatterImpl ที่เป็น class ลงไปเป็น parameter ของ bindMessageFormatter และให้ function return MessageFormatter ที่เป็น Interface
ทำการประกาศ Scope ของ MessageFormatter เคสนี้ เราต้องการให้มันมีขอบเขตการใช้งานภายใน Activity ลงไป ดังนั้นต้องใช้ @ActivityScope

@InstallIn(ActivityComponent::class)
@Module
abstract class MessageSendingModule {

@Binds
+ @ActivityScope
fun bindMessageFormatter(impl: MessageFormatterImpl): MessageFormatter
}

เพียงเท่านี้เราก็สามารถ compile ได้ผ่านฉลุย 🚀🚀🚀

Provide module

Provide module มักใช้ในกรณีที่เราต้องการสร้าง Instance ของ Class ด้วยเราเอง ยกตัวอย่าง หากเราต้องการ Inject Gson instance การใช้ @Binds ตามตัวอย่างข้างบนไม่สามารถทำได้ วิธีการใช้ Provide module จึงเหมาะสมมากกว่า
ตัวอย่าง:

ต้องการให้ Gson เข้าถูกใช้งานที่ใดก็ได้ใน Application
ต้องการให้ Gson มีขอบเขตการใช้งานภายใน Application

สร้าง module ในที่นี้จะให้ชื่อว่า GsonModule

@Module
class GsonModule

จุดสังเกตุ ⚠️ class GsonModule ไม่ใช่ abstract class เหมือนในกรณี @Binds

ประกาศ @InstallIn(ApplicationComponent::class) เนื่องจากว่าเราต้องการให้ Gson ถูกใช้งานที่ Application level ในกรณีนี้ instance ของ Gson จะถูกนำไปใช้งานได้ทุกที่ของ App (หาก inject Gson ด้วย Hilt)

+ @InstallIn(ApplicationComponent::class)
@Module
class GsonModule

สร้าง Function ที่ทำหน้าที่ Provide Gson

@InstallIn(ApplicationComponent::class)
@Module
class GsonModule {
+ fun provideGson(): Gson = GsonBuilder().create()
}

ประกาศ @Singleton เพื่อให้ Gson มี มีขอบเขตการใช้งานภายที่ Application ลงไป

จากนั้นประกาศ @Provides

@InstallIn(ApplicationComponent::class)
@Module
class GsonModule {
+ @Singleton
+ @Provides
fun provideGson(): Gson = GsonBuilder().create()
}

เพียงเท่านี้เราก็สามารถ Inject Gson ไปที่ไหนก็ได้ใน App เพราะ Gson จะมีขอบเขตการใช้งานที่ Application layer ลงไป

หมายเหตุ 💡 วิธีการสร้าง Module จำเป็นต้องให้ component ที่เราจะระบุใน @InstallIn ตรงกันกับ Scope รวมถึงการนำไปใช้งาน (inject) ด้วย ตามตาราง:

เช่น:
ต้องการ EmailSender class ใช้งานใน Fragment ลงไป (Fragment, View, Service) เราสามารถระบุ

@InstallIn ApplicationComonent หรือ AcivityComponent หรือ FragmentComponent ได้
ระบุ Scope เป็น @Singleton หรือ @ActivityScope หรือ @FragmentScope โดยต้องตรงกับ Component ที่ InstallIn
สามารถ inject EmailSender ได้ใน Fragment, View และ Service

Monolithic components

อีกเรื่องที่สำคัญสำหรับ Hilt คือ การที่ Hilt นั้นมีโครงสร้าง แบบ Monolithic components นั่นหมายความว่า ของที่อยู่ใน Components จะถูกใช้ได้ในทุกที่ใน Layer เดียวกัน
ยกตัวอย่าง:

Application เรามี 3 Activities ชื่อ MainActivity, SecondActivity, ThirdActivity โดยให้ทั้งสาม Activities สามารถใช้งาน Hilt ได้โดยการระบุ @AndroidEntryPoint บน Activities ทั้ง 3 ตัว

@AndroidEntryPoint
class ThirdActivity  : AppCompatActivity()

@AndroidEntryPoint
class SecondActivity  : AppCompatActivity()

@AndroidEntryPoint
class MainActivity : AppCompatActivity()

ให้ EmailSender มี Scope เป็น ActivityScoped

@ActivityScoped
class EmailSender @Inject constructor() {
    fun send(msg: String){
        println(msg)
    }
}

inject EmailSender ในทั้ง 3 Activities

@AndroidEntryPoint
class ThirdActivity  : AppCompatActivity() {
    @Inject
    lateinit var emailSender: EmailSender
}

@AndroidEntryPoint
class SecondActivity  : AppCompatActivity() {
    @Inject
    lateinit var emailSender: EmailSender
}

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject
    lateinit var emailSender: EmailSender
}

ทั้งนี้ทั้งนั้น ถึงแม้ว่าเราจะ inject มันได้ ทั้ง 3 ที่ แต่ instance ก็ยังคงเป็นคนละตัวกัน

ทดสอบด้วยการ Print ออกมาใน onCreate ของแต่ละ Activity:

println("emailSender from ${this::class.java} $emailSender" )

ผลที่ได้

2021-01-04 14:51:01.868 5198-5198/? I/System.out: emailSender from class MainActivity EmailSender@245bf98
2021-01-04 14:51:02.346 5198-5198/? I/System.out: emailSender from class SecondActivity EmailSender@50720c3
2021-01-04 14:51:02.675 5198-5198/? I/System.out: emailSender from class ThirdActivity EmailSender@2026848

ลองเปลี่ยนให้ Scope เป็น @Singleton แทน

- @ActivityScoped
+ @Singleton
class EmailSender @Inject constructor() {
    fun send(msg: String){
        println(msg)
    }
}

ผลที่ได้

2021-01-04 14:51:01.868 5198-5198/? I/System.out: emailSender from class MainActivity EmailSender@245bf98
2021-01-04 14:51:02.346 5198-5198/? I/System.out: emailSender from class SecondActivity EmailSender@245bf98
2021-01-04 14:51:02.675 5198-5198/? I/System.out: emailSender from class ThirdActivity EmailSender@245bf98

ทีนี้เรามาลองอะไรเล่นๆดูบ้าง จากตัวอย่าง code ด้านบน ให้ scope เป็น @ActivityRetainedScoped ดู

@ActivityRetainedScoped
class EmailSender @Inject constructor() {
    fun send(msg: String){
        println(msg)
    }
}

ผลที่ได้

2021-01-04 14:51:01.868 5198-5198/? I/System.out: emailSender from class MainActivity EmailSender@3ade714
2021-01-04 14:51:02.346 5198-5198/? I/System.out: emailSender from class SecondActivity EmailSender@5776b47
2021-01-04 14:51:02.675 5198-5198/? I/System.out: emailSender from class ThirdActivity EmailSender@8b35fe6

จะเห็นว่า Instance นั้นยังตงเป็นคนละตัวกัน เนื่องจากว่า เรามี @AndroidEntryPoint อยู่สามที่นั่นทำให้ Hilt ทำการสร้าง Instance ของ emailSender แยกกัน

ลองใช้ @ActivityRetainedScoped เหมือนเดิม แต่เปลี่ยนให้มี @AndroidEntryPoint เพียงที่เดียวบ้าง

@ActivityRetainedScoped
class EmailSender @Inject constructor() {
    fun send(msg: String){
        println(msg)
    }
}

สร้าง ClassA และ ClassB โดย inject emailSender ไปที่ constructor

class ClassA @Inject constructor(
    private val emailSender: EmailSender
) {
    init {
        println("From $this EmailSender is $emailSender")
    }
}

class ClassB @Inject constructor(
    private val emailSender: EmailSender
) {
    init {
        println("From $this EmailSender is $emailSender")
    }
}

Print ค่าใน Activity:

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject
    lateinit var emailSender: EmailSender

    @Inject
    lateinit var classA: ClassA

    @Inject
    lateinit var classB: ClassB

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.main_activity)
        println("From $this EmailSender is $emailSender")
    }
}

ผลที่ได้

2021-01-05 10:33:21.296 13089-13089 From ClassA@5d9e5b2 EmailSender is EmailSender@b6f3903
2021-01-05 10:33:21.296 13089-13089 From ClassB@d0c6080 EmailSender is EmailSender@b6f3903
2021-01-05 10:33:21.362 13089-13089 From MainActivity@fa313f1  EmailSender is EmailSender@b6f3903

จบไปคร่าวๆ สำหรับเรื่อง Hiltเบื้องต้น หวังว่าจะนำไปใช้งานกันได้ไม่ยาก ส่วน Part หน้าจะมาพูดถึง JetPack Compose บ้าง ว่ามัน Revolutionize วิธีการเขียน UI ของ Android App เราอย่างไร

DEV Community: Eddie Eddie

Flow ของ OAuth 2.0

Terms

Flow ของ OAuth2 ในภาพใหญ่จริงๆ มีแค่ 7 ขั้นตอน

Back and Front Channels

Implicit Flow

OpenID

PKCE (Proof Key for Code Exchange)

Modernized Android architecture - JetPack Compose Part1

เริ่มต้นสร้าง Project

Composable

Concept ของ UI เปลี่ยนไป

Unidirectional Data Flow

State

ลอง Implement Code แบบเดียวกันด้วย JetPack Compose

สร้าง UI ด้วย Column และ Row

Preview

State และ MutableState

Memory ใน Function

แก้ไม่ให้ Icon Update ทุกครั้ง

State hoisting

observeAsState

Reference:

Modernized Android architecture - Hilt

Hilt

ทำไมต้องทำ Dependency Injection

Setup Hilt

เทียบกับ Dagger

Field Injection

Constructor Injection

ปัญหา Injection กับ Interface

Component

Scope

แก้ไขปัญหา Constructor Injection กับ Interface

Binds module

Provide module

Monolithic components

References: