아래의 과정으로 배포를 진행하겠다.

1. Github actions 로 CI/CD 적용
2. aws s3 에 호스팅
3. cloudfront 로 도메인 주소 적용

github action

Github Repository 생성 후 .github/workflows 폴더 내에 yaml 파일을 생성한다. yaml 파일을 통해 Github action 의 workflow 가 생성된다. workflow 파일을 따라 CI/CD 작업이 진행되는데 workflow 파일을 살펴보겠다.

name: Deploy to production /// action 의 이름 

on: /// action 이 trigger 되는 방식 git 의 main branch 
  push:
    branches:
      - main
    tags:
      - "v*.*.*"

  workflow_dispatch:

jobs:
  build-web:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Flutter SDK
        uses: subosito/flutter-action@v2
        with:
          flutter-version: "3.7.1"
          channel: "stable"

      - name: Enable desktop
        run: flutter config --enable-web

      - name: Flutter get packages
        run: flutter pub get

      - name: Build Runner & version
        run: flutter packages pub run build_runner build --delete-conflicting-outputs

      - name: Flutter build app
        run: flutter build web --release --base-href / --dart-define="BASE_URL=https://reward-api.danbicorp.com/api"

      - name: Use random for fix cache
        run: |
          ran=$RANDOM
          echo $ran
          sed -i "s|flutter\.js|flutter.js?v=$ran|" ./build/web/index.html
          sed -i "s|main\.dart\.js|main.dart.js?v=$ran|" ./build/web/flutter.js

      - name: Archive Production Artifact
        uses: actions/upload-artifact@master
        with:
          name: web-build
          path: build/web

  deploy-web:
    name: Deploy Website to AWS Hosting
    needs: build-web
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3

      - name: Download Artifact
        uses: actions/download-artifact@master
        with:
          name: web-build
          path: build/web 

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Upload to S3 🚀
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --follow-symlinks --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET_PROD }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: ${{ secrets.AWS_REGION }}
          SOURCE_DIR: 'build/web'

      - name: Create CloudFront Cache Invalidation ☁️
        uses: chetan/invalidate-cloudfront-action@master
        env:
          DISTRIBUTION: ${{ secrets.AWS_CLOUDFRONT_DISTRIBUTION_ID_PROD }}
          PATHS: '/*'
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: ${{ secrets.AWS_REGION }}

s3 호스팅

1. AWS S3에 접근하기 위한 IAM 계정 만들기
2. S3 bucket 생성
3. S3 bucket 정적 웹 사이트 호스팅 활성화
4. 버킷 웹 사이트 엔드포인트 복사

cloudfront 로 도메인 주소 적용

cloudFront 를 이용하여 s3 에서 생성한 버킷의 엔드포인트를 생성한 도메인 주소로 연결한다.

GlobalKey사용 child Widget 의 State를 GlobalKey 로 전달

Global Key 란?

key는 무엇인가?

1. 위젯의 state를 보존 ( 예- 체크박스의 상태, 텍스트 필드의 문자들이 입력되고 있는지 등)
2. 위젯을 식별 Global Key : 위젯의 state를 외부 위젯에서 접근

적용 방법

1. child Widget의 State를 사용하기 위해 _삭제
2. Parent Widget 에서 global key 생성
3. child Widget 생성 시 global Key 선언
4. global key로 child 의 state 내부 method 호출

• child Widget Code

  class ChildWidget extends StatefulWidget {
  const ChildWidget({Key? key,}) : super(key: key);
  
  @override
  State<ChildWidget> createState() => ChildWidgetState();
  }
  

class ChildWidgetState extends State { Color _color = Colors.red;

void changeColor(Color color) { setState(() { _color = color; }); }

@override Widget build(BuildContext context) { return InkWell( child: Container( width: 200, height: 200, color: _color, child: const Text('Child Widget'), ), ); } }

- parent Widget Code

class MyHomePage extends StatefulWidget { const MyHomePage({super.key, required this.title});

final String title;

@override State createState() => _MyHomePageState(); }

class _MyHomePageState extends State { final GlobalKey _globalKey = GlobalKey();

@override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: Text(widget.title), ), body: Center( child: Column( mainAxisAlignment: MainAxisAlignment.center, children: [ ChildWidget( key: _globalKey, ), const SizedBox(height: 10,), InkWell( onTap: () { _globalKey.currentState?.changeColor(Colors.red); }, child: Container( height: 50, color: Colors.yellow, child: const Text('Parent Widget Button') ), ) ], ), ), ); } } ```

flutter 는 widget들의 조합이다. 화면이 복잡해져 위젯이 많아 질수록 코드는 거대 해진다. 가독성을 위해 위젯을 분할하는 것이 중요하다. 위젯을 별도의 class 로 분리했을 때 child-Parent widget 사이의 method를 호출하는 법에 대해 알아보았다.

Child -> Parent 함수 호출

Child instance 생성 시 parameter로 Parent Widget의 callBack 함수 전달, child 에서 call

• child widget

  class ChildWidget extends StatefulWidget {
  final VoidCallback onTapped;
  const ChildWidget({Key? key, required this.onTapped}) : super(key: key);
  
  @override
  State<ChildWidget> createState() => _ChildWidgetState();
  }
  

class _ChildWidgetState extends State { @override Widget build(BuildContext context) { return InkWell( onTap: widget.onTapped.call, child: Container( width: 200, height: 200, color: Colors.red, ), ); } }

- parnet widget

        ChildWidget(
          onTap: () {
            Get.snackbar('알림', '자식 위젯 onTapped');
          },
        )

> ### CallBack 함수의 parameter 로 data 를 전달하고 싶은 경우?
callback 함수의 정의는 다음과 같다.

typedef void VoidCallback();

데이터를 담고 싶다면 typedef 로 함수를 정의하여 child 로 전달할 수 있다.

- child Widget Code

typedef Int2VoidFunc = void Function(int arg);

class ChildWidget extends StatefulWidget { final Int2VoidFunc onTapped; const ChildWidget({Key? key, required this.onTapped}) : super(key: key);

@override State createState() => _ChildWidgetState(); }

class _ChildWidgetState extends State { @override Widget build(BuildContext context) { return InkWell( onTap: () { widget.onTapped(5); }, child: Container( width: 200, height: 200, color: Colors.red, ), ); } }

- Parent Widget Code

        ChildWidget(
          onTapped: (arg) {
            Get.snackbar('알림', '자식 위젯 onTapped, $arg');
          },
        )

startActivityForResult()와 onActivityResult() 가 deprecated 되었습니다. 이를 대신하여 AndroidX Activity 1.2.0-alpha02 와 Fragment 1.3.0-alpha02에 도입된 Activity Result API를 사용합니다.

registerForActivityResult() 란..?

결과를 얻기 위해 활동을 시작할 때, 메모리 부족으로 인해 프로세스와 활동이 소멸될 수 있습니다(특히, 카메라 사용과 같이 메모리를 많이 사용하는 작업의 경우 소멸 확률이 매우 높음).

따라서, Activity Result API는 다른 활동을 실행하는 코드 위치에서 결과 콜백을 분리합니다. 결과 콜백은 프로세스와 활동을 다시 생성할 때 사용할 수 있어야 하므로 다른 활동을 실행하는 로직이 사용자 입력 또는 기타 비즈니스 로직을 기반으로만 발생하더라도 활동이 생성될 때마다 콜백을 무조건 등록해야 합니다.

ComponentActivity 또는 Fragment에 있을 때, Activity Result API에서 제공하는 registerForActivityResult() API를 통해 결과 콜백을 등록할 수 있습니다. registerForActivityResult()는 ActivityResultContract 및 ActivityResultCallback을 가져와서 다른 활동을 실행하는 데 사용할 ActivityResultLauncher를 반환합니다.

적용 예제

MainActivity

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        startSecondActivity()
    }

    private fun startSecondActivity() {
        val intent = Intent(this@MainActivity, SecondActivity::class.java)
        activityResultLauncher.launch(intent)
    }

    private val activityResultLauncher =
        registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
            if (it.resultCode == RESULT_OK) {
                it.data?.let { intent ->
                    if (intent.hasExtra(SecondActivity.RESULT_DATA)) {
                        Toast.makeText(
                            this@MainActivity,
                            intent.getStringExtra(SecondActivity.RESULT_DATA),
                            Toast.LENGTH_SHORT
                        ).show()
                    }
                }
            }
        }
}

SecondActivity

class SecondActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_second)

        val button = findViewById<Button> (R.id.button_close)
        button.setOnClickListener {
            val intent = Intent().putExtra(RESULT_DATA, "hello")
            setResult(RESULT_OK, intent)
            finish()
        }
    }

    companion object {
        const val RESULT_DATA = "result_data"
    }
}

Reference

[android developers] 활동에서 결과 가져오기

비즈니스 로직을 처리하는 함수보다는 데이터를 저장하는 속성을 갖는 클래스. 데이터를 처리하는데 필요한 아래의 함수들을 코틀린 컴파일러가 자동으로 생성해줍니다.

• equals() : 클래스 인스턴스끼리 각 속성의 값을 비교
• hashCode() : 인스턴스를 컬렉션(ex, HashMap) 에 저장할 때 사용할 키 값들을 생성
• toString() : 속성값을 문자열로 출력

MVC 아키텍처

• Model : 데이터를 보존, 관리
• View : 화면에서 볼 수 있는 것
• Controller : 뷰 객체에 의해 발생하는 다양한 이벤트에 응답, 모델과 뷰의 중간에서 주고받는 데이터를 관리. MVC 를 사용하면 각 계층이 분리되어 앱을 설계하고 이해하는데 도움이 됩니다. 또한, 클래스를 재사용하기 쉽습니다. 크고 복잡한 앱에서는 컨트롤러가 커지거나 복잡해질 수 있습니다. 그럴 땐 MVVM 아키텍처가 대안이 될 수 있습니다.

화면 픽셀 밀도

• px : pixel, 픽셀은 장치의 화면밀도에 적합하게 조정되지 않음.
• dp : density-independent pixel(밀도 독립적 픽셀), 1dp는 항상 장치 화면의 1/160 인치, 화면 밀도와 무관하게 일정한 크기를 갖는다.
• sp : scale-independent pixel(크기 독립적 픽셀), 사용자의 폰트 크기 설정을 고려, 텍스트 크기 설정을 위해 사용

Reference

[실무에 바로 적용하는 안드로이드 프로그래밍], 크리스틴 마시캐노, 브라이언 가드너, 빌 필립스, 크리스 스튜어트

안드로이드의 내부 DB 로 자주 사용되는 Room, Realm, SQLite 를 비교하고 Room 에 대해 좀 더 자세히 알아보겠습니다.

Room VS SQLite

Room은 SQLite 에 대한 추상화 레이어를 제공하여 원활한 데이터베이스 액세스를 지원하며 ORM 방식입니다. SQLite 와 비교하여 Room 의 장점들은 다음과 같습니다.

• 컴파일 타임에서 에러 처리
• Boiler plate code( 예) getter, setter ) 필요 없음
• schema 변경 시 자동 업데이트
• Rxjava 를 위한 Observable 제공

Room VS Realm

그렇다면 현재 많이 사용되는 Room 과 Realm 을 비교해 보겠습니다. Realm 은 안정성이 좋고, 처리 속도가 빨라 대용량 데이터 처리에 좋습니다. 그러나, 내부 라이브러리가 커 용량을 많이 차지 합니다. 또한, SQL 쿼리를 사용했다면 러닝 커브가 있습니다. 큰 용량의 데이터 처리가 아닌 경우라면 Room 또한 좋습니다.

Room 이란..?

Room은 SQLite에 대한 추상화 레이어를 제공하여 원활한 데이터베이스 액세스를 지원하는 동시에 SQLite를 완벽히 활용합니다. 앱은 Database 를 사용하여 Dao 를 가져오고, 가져온 Dao 로 Entity 들을 Database 에 저장하고 변경합니다.

Room 의 구성

• Database : Dao 를 포함한 액세스 포인트 역할
• Entity : 테이블 구조 정의 예) 칼럼 명, 칼럼 타입
• Dao(Database Access Object) : db 접근 메소드들(예) insert, delete) 을 정의

Room 구현

build.gradle 파일에 다음의 dependency 를 추가합니다.

  def room_version = "2.3.0"
  implementation "androidx.room:room-runtime:$room_version"
  kapt "androidx.room:room-compiler:$room_version"

Entity

@Entity
data class User (
    @PrimaryKey val uId : Int,
    @ColumnInfo(name = "first_name") val firstName: String?,
    @ColumnInfo(name = "last_name") val lastName: String?,
    @Ignore val isChecked: Boolean
)

@Entity(tableName = "테이블 이름") 테이블 이름을 지정할 수 있습니다. 기본값은 클래스명 입니다. @PrimaryKey PrimaryKey 를 지정합니다. @ColumnInfo 칼럼 명을 지정합니다. 기본 값은 변수명입니다. @Ignore DB 에 저장하긴 싫지만 이 클래스 내에 있어야 하는 변수에 사용합니다.

Dao

@Dao
interface UserDao {
    @Query("SELECT * FROM user")
    fun getAll() : List<User>

    @Query("SELECT * FROM user WHERE uId IN (:userIds)")
    fun getAllByIds(userIds: IntArray) : List<User>

    @Insert
    fun insertAll(vararg users: User)

    @Delete
    fun delete(user: User)
}

@Query Query 문을 작성합니다. 쿼리에 매개변수를 전달하려면 :변수명 방식으로 사용합니다.

Database

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao

    companion object {
        private var INSTANCE: AppDatabase? = null
        fun getInstance(context: Context): AppDatabase? {
            if (INSTANCE == null) {
                synchronized(AppDatabase::class) {
                    INSTANCE = Room.databaseBuilder(
                        context.applicationContext,
                        AppDatabase::class.java,
                        "user.db"
                    ).build()
                }
            }

            return INSTANCE
        }
    }
}

Database 는 RoomDatabase() 를 상속받는 abstract 클래스여야 합니다. @Database 어노테이션에는 해당 database 와 관련된 Entity 의 목록을 나열해야 합니다. 또한, 클래스 내에는 arguments 가 0개인 @Dao 를 반환하는 abstract 메소드를 포함해야 합니다. 런타임 시 Room.databaseBuilder() 또는 Room.inMemoryDatabaseBuilder() 를 호출하여 Database 인스턴스를 가져올 수 있습니다. Database 객체를 Singleton 으로 생성합니다.

TypeConverter

Room 에 Primitive type 이 아닌 값을 저장하기 위해서는 TypeConverter 를 사용하여 Room 에게 특정 타입을 데이터베이스에 저장하고, 가져오는 방법을 알려주어야 합니다. TypeConverter 클래스를 생성하고, 생성한 클래스를 Database 클래스에 추가하여 사용합니다.

TypeConverter class

class UserTypeConverters {

    @TypeConverter
    fun fromDate(date: Date?): Long? {
        return date?.time
    }

    @TypeConverter
    fun toDate(millisSinceEpoch: Long?): Date? {
        return millisSinceEpoch?.let {
            Date(it)
        }
    }

    @TypeConverter
    fun toUUID(uuid: String?): UUID? {
        return UUID.fromString(uuid)
    }

    @TypeConverter
    fun fromUUID(uuid: UUID?): String? {
        return uuid?.toString()
    }
}

DataBase Class

@Database(entities = [Crime::class], version = 1)
@TypeConverters(UserTypeConverters::class)
abstract class AppDatabase : RoomDatabase() {
}

Room 비동기 처리

DB 에 데이터를 처리하는 일은 시간이 많이 걸리 수 있기 때문에 메인스레드에서 처리할 수 없습니다. 그래서 백그라운드 스레드에서 처리를 해주어야 합니다. 비동기 처리의 방법에는 AsyncTask, Rxjava, coroutin 등 다양한 방법이 있습니다. 이번에는 코루틴을 사용해 보겠습니다.

    val db = AppDatabase.getInstance(applicationContext)

        lifecycleScope.launch(Dispatchers.IO) {
            db!!.userDao().insertAll(User(0, "han", "hi", true))
        }

Reference

슬기로운 개발생활[안드로이드 Room 사용법] 안드로이드 developers[Room을 사용하여 로컬 데이터베이스에 데이터 저장]

액티비티를 회전하여 액티비티가 소멸되고 재생성되거나, 프로세스가 종료되어 액티비티가 유실될 때도 있습니다. 이런 경우들의 경우 기존 액티비티의 데이터를 어떻게 유지하는지 다양한 방법들을 살펴 보겠습니다.

AAC ViewModel

AAC ViewModel 이란...?

AAC의 ViewModel은 수명 주기를 고려해 관련 데이터를 저장하고 관리하도록 설계된 클래스이며 안드로이드 jetpack 의 lifecylce-extensions 라이브러리에 포함되어 제공됩니다. ViewModel 인스턴스는 액티비티의 생명주기와 연동됩니다. ViewModel 인스턴스는 액티비티 상태 변화와 무관하게 액티비티가 종료될 때까지 (예, 사용자가 백 버튼을누를 때) 메모리에 남아 있다가 액티비티가 종료되면 소멸됩니다.

사용 예제

app 수준의 gradle 에 lifecycle-extensions dependency를 추가합니다.

dependencies {
    ...
    implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
}

ViewModel 은 특정 액티비티 화면과 연동되며, 모델 데이터를 화면에 보여주는 기능을 수행합니다. ViewModel 을 상속하는 ViewModel 을 생성해 줍니다.

class QuizViewModel : ViewModel() {
    // ViewModel 인스턴스가 소멸되기 전에 호출되므로 클린업할 것이 있으면 추가
   override fun onCleared() {
        super.onCleared()
        Log.d(TAG, "ViewModel instance about to be destroyed")
    }
}

연동되는 액티비티에 ViewModel 인스턴스를 연결합니다. AAC ViewModel 클래스는 개발자가 직접 생성자 메서드로 인스턴스 생성이 불가능합니다. ViewModelProvider를 사용하여 인스턴스를 생성해야 합니다. ViewModelProvider 의 생성자로 Lifecycle 을 동일시 할 액티비티를 제공합니다.

class MainActivity : AppCompatActivity() {
    ...
    override fun onCreate(savedInstanceState: Bundle?) {
        val provider: ViewModelProvider = ViewModelProVider(this)
        val quizViewModel = provider.get(QuizViewModel::class.java)
    }
}

ViewModel 과 Activity 의 관계

액티비티는 ViewModel 을 참조하지만, ViewModel 은 액티비티를 참조하지 않습니다. 화면 회전 시에 액티비티 인스턴스는 소멸되지만, ViewModel 인스턴스는 메모리에 남습니다. 이런 상황에서 ViewModel 이 액티비티를 참조한다면 액티비티 인스턴스가 메모리에 남게되어 메모리 유실(memory leak) 이 발생할 수 있습니다.

SIS(Saved Instance State)

SIS 란...?

: 저장된 인스턴스 상태, 안드로이드 운영체제가 일시적으로 액티비티 외부에 저장하는 데이터이며, Activity.onSaveInstanceState(Bundle) 을 override 하여 SIS에 데이터를 추가할 수 있습니다.

액티비티가 Stopped 될 때 (예, 사용자가 홈 버튼을 누른 후 다른 앱을 실행할 때) 안드로이드 운영체제가 Activity.onSaveInstanceState(Bundle) 을 호출합니다. Activity.onSaveInstanceState(Bundle) 에서는 현재 액티비티의 모든 뷰들의 상태를 Bundle 데이터로 저장합니다. 저장된 데이터는 액티비티가 다시 create 될 때, Activity.onCreate(Bundle?) 에서 전달받습니다. Bundle 객체에 저장된 뷰들의 상태 데이터들을 사용해서 액티비티를 다시 생성합니다.

사용 예제

private const val KEY_INDEX = "index"

class MainActivity : AppCompatActivity() {
    ...

    ovverride fun onSaveInstanceState(outState: Bundle){
        super.onSaveInstanceState(outState)
        outState.putInt(KEY_INDEX, quizViewModel.currentIndex)
    }

    override fun onCreate(savedInstanceState: Bundle?){
        ...
        val currentIndex = savedInstanceState?.getInt(KEY_INDEX, 0) ?: 0
    }
}

activity record

액티비티(프로세스)의 소멸에도 onSaveInstanceState(Bundle)에 저장된 데이터가 존속할 수 있는 이유는 Bundle 객체가 액티비티의 activity record 로 저장되기 때문입니다.

SIS vs AAC ViewModel

SIS 에는 크거나 복잡한 객체를 저장하는 것은 피해야 합니다. 즉, UI 상태를 저장하기 위해 필요한 소량의 정보를 저장할 때는 SIS 를 사용하고, 장치의 구성 변경이 생겨 UI 에 넣는 데 필요한 많은 데이터에 빠르고 쉽게 접근하고자 메모리에 케싱할 때는 ViewModel 을 사용합니다. 프로세스가 종료된 후 액티비티 인스턴스가 다시 생성될 때는 SIS 데이터를 사용하고, 그 SIS 데이터를 사용해서 ViewModel 을 설정할 수 있습니다.

Reference

크리스틴 마시캐노, 실무에 바로 적용하는 안드로이드 프로그래밍

안드로이드 어플리케이션은 Activity, Service, Broadcast Receiver, Content Provider 로 구성되어 있습니다. 이 컴포넌트들은 독립된 형태로 존재하며 intent 를 통해 상호작용 합니다.

Activity

액티비티는 UI를 담당하는 컴포넌트입니다. 즉, 사용자에게 보여지는 화면입니다. 어플리케이션은 반드시 1개 이상의 액티비티를 가지고 있어야 합니다.

Service

서비스는 백그라운드에서 실행되는 컴포넌트입니다. 오랫동안 실행되는 작업이나 원격 프로세스를 위한 작업을 수행합니다. 메인 쓰레드에서 실행되므로 서비스에서 별도의 스레드를 생성해서 작업을 처리해야 합니다.

BroadCast Receiver

브로드캐스트 리시버는 안드로이드 OS로부터 발생하는 이벤트와 정보(BroadCast) 를 핸들링하는 컴포넌트입니다. 브로드캐스트에는 시스템 부팅 완료, 배터리 부족, 언어설정 변경, 문자메세지 수신 등이 있습니다. 10초 이내의 작업만 보증하므로 오랜 시간 동작해야한다면 별도의 쓰레드나 서비스로 처리해야 합니다. Broadcast Receiver 를 등록하는 방법에는 2가지가 있습니다. AndroidManifest 에 등록하는 정적 등록과 코드상에서 등록하는 동적 등록이 있습니다.

Content Provider

컨텐트 프로바이더는 애플리케이션 사이에서 각 데이터들을 공유할 수 있도록 하는 구성요소입니다. 안드로이드는 기본적으로 주소록, 이미지, 오디오 등 주요 데이터에 대한 내장 Content Provider를 제공합니다. 위의 그림처럼 외부 어플리케이션에서 local DB 의 데이터가 필요한 경우, 외부 어플리케이션은 Content Resolver 를 통해 Uri 를 어플리케이션에 보내고, 해당 어플리케이션의 Content Provider 가 Uri 를 해석하여 필요한 DB 작업을 합니다. 컨텐트 프로바이더는 기본적인 CRUD(Create, Read, Update, Delete) 연산이 가능합니다.

Reference

Android Developers[애플리케이션 기본 항목] https://salix97.tistory.com/11

Activity 의 생명주기

기존 액티비티에서 전화가 오거나 문자가 오는 등, 액티비티가 사용자에게 보이긴 하지만 포커스가 없는 경우 onPause 가 호출됩니다. 액티비티가 사용자에게 전혀 보이지 않는 경우 onStop 이 호출됩니다. 다이얼로그를 띄운 경우, 다이얼로그는 액티비티의 일부이므로 onPause 가 호출되지 않습니다.

Fragment 간의 데이터 공유

안드로이드의 Context

UI Thread / Worker Thread / Handler / Message Queue

비동기 처리를 위한 방법(AsyncTask, Rxjava 등)

커스텀뷰 개발 관련 지식( 꼭 신경써야하는 처리, onMeasure, onLayout)

안드로이드에서 Image를 다루기 위한 방법

RecyclerView 와 ViewHolder 패턴

Intent, IntentFilter 와 IntentService

ANR, OverDraw 등의 문제와 그것을 디버깅하는 개발자 도구

옵저버 패턴은 객체(subject)의 상태 변화를 관찰하는 관찰자들, 즉 옵저버(observer)들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 각 옵저버에게 변화를 알리는(notify) 디자인 패턴입니다. 옵저버 패턴에서 객체(subject)는 옵저버에 대한 정보가 없습니다. 오직 옵저버가 특정 인터페이스(Interface)를 구현한다는 것 만 알고 있습니다. 즉, 옵저버가 무슨 동작을 하는지 모른다는 것입니다. 게다가 옵저버는 언제든지 새로 추가되거나 제거될 수 있으며 새로운 형식의 옵저버를 추가할 때에도 주제에 전혀 영향을 주지 않습니다. 이러한 관계를 느슨한 결합(Loose coupling)이라고 합니다.

예제

typealias Observer<T> = (event: T) -> Unit
class EventSource<T> {
    // observer 객체들을 담는 리스트
    private val observers = mutableListOf<Observer<T>>()
    // observer 리스트에 observer 추가
    fun addObserver(observer: Observer<T>) {
        observers.add(observer)
    }
    // observer 들에게 이벤트 알림
    fun notify(event: T) {
        observers.forEach {
            it(event)
        }
    }
}

fun main() {
    val eventSource = EventSource<String>()
    eventSource.addObserver { println("첫번째 옵저버: $it") }
    eventSource.addObserver { println("두번째 옵저버: $it") }
    eventSource.notify("Hello")
    eventSource.notify("Hi")
}

👉 결과

첫번째 옵저버: Hello
두번째 옵저버: Hello
첫번째 옵저버: Hi
두번째 옵저버: Hi

Rxjava 의 특징

Rxjava에는 크게 3가지의 역할이 있습니다.

• 생산자 -> 데이터를 생산하여 전달
• 소비자 -> 데이터를 받아서 처리
• 연산자 -> 데이터를 중간에서 가공(생산, 변환, 조합, 거름) 처리

Rxjava는 소비자(Subscriber/Observer)가 생산자(Observable/Flowable/Completable/Maybe/Single)를 소비(subscribe)하는 형태로 만들어져 있습니다.

간단히 말하면, 생산자는 데이터를 생산하고 통지하는 클래스이며, 소비자는 통지된 데이터를 전달받아 이 데이터를 처리합니다.

fun main() {
    Observable // 생산자
        .just(0,1,2,3) // 생산 연산자
        .map { it * 2 } // 변경 연산자
        .subscribe { println(it) } // 소비자
}

Observable 의 소비자 추가 방법

Observer 방식

observer interface 를 구현한 객체를 subscribe 해서 소비자를 추가합니다. return type 은 Unit 입니다.

val observer = object : Observer<Int> {
        override fun onSubscribe(d: Disposable?) {
            // Observable이 데이터 전달할 준비가 되었을 때,
            // 작업 취소를 위한 Disposable를 여기서 받음
        }

        override fun onNext(t: Int?) {
            // Observable이 데이터를 전달할 때 호출
        }

        override fun onError(e: Throwable?) {
            // Observable이 에러를 전달할 때 호출. Error시 Complete없이 종료 된다.
        }

        override fun onComplete() {
            // Observable이 완료된 경우 호출
        }
    }
    Observable.just(1, 2, 3, 4).subscribe(observer)

Consumer 방식

각각의 Consumer를 subscribe해서 소비자를 추가합니다. Consumer는 메소드 한개짜리 자바 인터페이스이므로 SAM을 통해 람다로 표현할 수 있습니다. subscribe의 return type은 Disposable 입니다.

val disposable = Observable.just(1, 2, 3, 4).subscribe(
        { println("onNext: $it") }, //onNext
        { println("onError: $it") }, //onError
        { println("onComplete") } //onComplete
    )

Disposable

유한한 아이템을 발행하는 observable 의 경우 onComplete() 호출로 안전하게 종료되지만, 무한하게 아이템을 발행하거나 오랫동안 실행되는 observable 의 경우에는 명시적인 폐기(dispose)가 필요합니다. Disposable.dispose() 메소드를 호출하면 아이템 발행을 중단할 수 있습니다.

val disposable = Observable.just(1, 2, 3, 4).subscribe(
        { println("onNext: $it") }, //onNext
        { println("onError: $it") }, //onError
        { println("onComplete") } //onComplete
    )
disposable.dispose()

CompositeDisposable

CompositeDisposable 은 여러 disposable 들을 저장하는 container 입니다. 여러 disposable 들을 한꺼번에 dispose 할 때 사용합니다. add, addAll 함수로 disposable 을 추가하고, clear, dispose 함수로 dispose 처리합니다.

clear 함수는 CompositeDisposable을 재사용 가능한 반면, dispose 함수는 CompositeDisposable 를 재사용할 수 없습니다.

compositeDisposable.clear() 예제

val compositeDisposable = CompositeDisposable()
    val disposable1 = Observable.just(1, 2).subscribe { println(it) }
    compositeDisposable.add(disposable1)
    compositeDisposable.clear()

    val disposable2 = Observable.just(3,4).delay(1, TimeUnit.SECONDS).subscribe { println(it) }
    compositeDisposable.add(disposable2)
    Thread.sleep(2000L)

👉결과

1
2
3
4

compositeDisposable.dispose() 예제

 val compositeDisposable = CompositeDisposable()
    val disposable1 = Observable.just(1, 2).subscribe { println(it) }
    compositeDisposable.add(disposable1)
    compositeDisposable.dispose()

    val disposable2 = Observable.just(3,4).delay(1, TimeUnit.SECONDS).subscribe { println(it) }
    compositeDisposable.add(disposable2)
    Thread.sleep(2000L)

👉결과

1
2

Reference

옥수환, 아키텍처를 알아야 앱 개발이 보인다 [LuckyGg][Design Pattern] 옵저버 패턴(Observer Pattern) 이야기 #1 (예제 포함) https://velog.io/@p4stel-dev/RxJava-정리-1-Rxjava란- https://velog.io/@cmplxn/RxJava-입문하기-Kotlin

Rxjava란 ReactiveX(Reactive Extensions)를 자바로 구현한 라이브러리입니다. 옵저버 패턴, 이터레이터 패턴, 함수형 프로그래밍의 장점과 개념을 접목한 반응형 프로그래밍 기법을 의미합니다. Rxjava는 이벤트 처리 및 비동기 처리의 구성에 최적화된 라이브러리입니다.

Rxjava 설정하기

Rxjava를 프로젝트에 설정하려면 모듈 레벨의 build.gradle 에 아래의 dependency를 추가합니다.

implementation 'io.reactivex.rxjava3:rxandroid:3.0.0'
implementation 'io.reactivex.rxjava3:rxjava:3.0.7'

RxAndroid 는 Rxjava에 몇 가지 클래스를 추가해 안드로이드 개발을 쉽게 해주는 라이브러리입니다.

명령형 프로그래밍 vs 반응형 프로그래밍

명령형 프로그래밍(Imperative Programming)

명령형 프로그래밍은 작성된 코드가 순서대로 실행되는 방식의 프로그래밍입니다. 코드가 순서대로 실행되는 것은 개발자가 작성한 조건문, 반복문 또는 함수 호출 등에 의해 컴파일러가 다른 코드로 이동하는 것을 의미합니다.

반응형 프로그래밍(Reactive Programming)

반응형 프로그래밍이란 데이터의 흐름을 먼저 정의하고 데이터가 변경되었을 때, 연관되는 함수가 알아서 처리하는 것입니다. 즉, 프로그래머가 어떠한 기능을 직접 정해서 실행하는 것이 아닌, 시스템에 이벤트가 발생하였을 때 알아서 처리되는 것입니다.

기존의 명령형 방식을 pull 방식, 반응형 방식을 push 방식이라고도 합니다. pull 방식은 데이터를 사용하는 곳(consumer) 에서 데이터를 직접 가져와 사용한다면, push 방식은 데이터의 변화가 발생한 곳에서 새로운 데이터를 consumer 에게 전달합니다.

Rxjava의 필요성

Rxjava는 동시성 문제, 다중 이벤트 처리, 백그라운드 스레드 처리 등에 대해 해결책을 제시합니다. 또한, 데이터들을 빠르게 처리하고 이와 동시에 데이터들을 병합, 필터링, 분할 및 변환 확장할 방법을 제시합니다. Rxjava는 기존에 작성한 비지니스 로직에 변경사항이 생겨도 큰 리팩토링 없이 쉽게 수정할 수 있습니다. 그러므로 Rxjava를 사용하면 프로덕션의 안정성을 유지하면서 애플리케이션을 전략적으로 진화시킬 수 있습니다.

마블 다이어그램

마블 다이어그램은 Rxjava에 대한 설명시 주로 사용됩니다. 데이터의 흐름을 시각화한 도표로 내용을 이해하는데 도움이 됩니다. 화살표는 타임라인을 의미하고, 화살표에 있는 막대는 데이터의 완료를 의미합니다. 가운데의 박스는 데이터의 변형을 의미하며, 아래의 화살표는 변형 결과의 타임라인 입니다. 엑스표는 에러를 나타냅니다.

Reference

옥수환, 아키텍처를 알아야 앱 개발이 보인다 http://reactivex.io/ [Herstroy] Rxjava 이해하기

ViewModel 에서 View 에 이벤트를 전달할 때, 값을 전달하는 경우가 아닌 이벤트가 발생했다는 사실만을 전달하고 싶을 때, 아래의 코드와 같이 Unit 값을 전달하여 이벤트를 감지하도록 했었습니다.

    private val _signUpClickEvent = MutableLiveData<Unit>()
    _signUpClickEvent.value = Unit

위의 코드는 비효율적일 뿐만 아니라, LiveData를 이용하기에 View의 재활성화 (start나 resume 상태로 재진입)가 될 경우에도 LiveData가 observe를 호출하여, 불필요한 이벤트까지 일어나는 경우가 있습니다. 이를 방지하기 위해 SingleLiveEvent 를 사용합니다.

구글 샘플 코드

class SingleLiveEvent<T> : MutableLiveData<T>() {
    private val isPending = AtomicBoolean(false)


    @MainThread
    override fun setValue(value: T?) {
        isPending.set(true)
        super.setValue(value)
    }


    // Observe the internal MutableLiveData
    @MainThread
    override fun observe(owner: LifecycleOwner, observer: Observer<in T>) {
        super.observe(owner, Observer {
            if (isPending.compareAndSet(true, false)) {
                observer.onChanged(it)
            }
        })
    }

    /**
     * Used for cases where T is Void, to make calls cleaner.
     */
    @MainThread
    fun call() {
        value = null
    }
}

SingleLiveEvent라는 MutableLiveData를 상속한 클래스를 만듭니다. isPending.compareAndSet(true, false)라는 것은, 위의 pending 변수가 true면 if문 내의 로직을 처리하고 false로 바꾼다는 것입니다. setValue를 통해서만 pending값이 true로 바뀌기 때문에, Configuration Changed가 일어나도 pending값은 false이기 때문에 observe가 데이터를 전달하지 않습니다.데이터의 속성을 지정해주지 않아도 call만으로 setValue를 호출 가능합니다.

사용법

class ListViewModel : ViewModel {
    private val _navigateToDetails = SingleLiveEvent<Any>()

    val navigateToDetails : LiveData<Any>
        get() = _navigateToDetails


    fun userClicksOnButton() {
        _navigateToDetails.call()
    }
}

Reference

[medium]LiveData with SnackBar, Navigation and other events (the SingleLiveEvent case) [찰스의 안드로이드]SingleLiveEvent로 이벤트 처리하기 [치킨과 개발의 상관관계] [Android] SingleLiveEvent의 원리

의존성 주입 은 의존 관계에 있는 클래스의 객체를 외부로 부터 생성하여 주입받는 것입니다. 의존성 주입을 적용한 코드와 적용하지 않은 코드를 비교해 보면 더 잘 이해할 수 있습니다.

// 의존성 주입이 없는 코드
class MemoRepository {
    private val db = SQLiteDatabase()

    fun load (id: String) {...}
}

fun main() {
    val repository = MemoRepository()
    repository.load("8092")
}

// 의존성 주입을 적용한 코드
class MemoRepository(private val db: Database) {

    fun load (id: String) {...}
}

fun main() {
    val db = SQLiteDatabase()
    val repository = MemoRepository(db)
    repository.load("8092")
}

의존성 주입의 장단점

• 장점 리팩토링이 수월하다. 클래스간의 결합도를 느슨하게 한다. stub이나 mock 객체를 사용하여 단위 테스트가 용이하다.
• 단점 러닝커브가 높다 간단한 프로그램을 만들때는 번거롭다.

Hilt

Dagger Hilt는 2020년 6월 Google에서 오피셜하게 발표한 Android 전용 DI 라이브러리입니다. Hilt는 Dagger2를 기반으로 Android Framework에서 표준적으로 사용되는 DI component와 scope를 기본적으로 제공하여, 초기 DI 환경 구축 비용을 크게 절감시키는 것이 가장 큰 목적입니다.

Hilt Annotation

@HiltAndroidApp

Hilt 를 사용하는 모든 앱은 @HiltAndroidApp 어노테이션을 포함하는 application 을 생성해야 합니다. @HiltAndroidApp은 Hilt 컴포넌트의 코드 생성과 컴포넌트를 사용하는 Application의 기본 클래스를 생성하게 됩니다.

@HiltAndroidApp
class App : Application () {
    override fun onCreate() {
        super.onCreate()
    }
}

@AndroidEntryPoint

Application에서 멤버 주입이 가능하게 설정하고 나면, 다른 안드로이드 클래스들에서도 @AndroidEntryPoint 어노테이션을 사용하여 안드로이드에 DI 컨테이너를 추가하여 멤버 주입을 하는 것이 가능해 집니다. @AndroidEntryPoint를 사용할 수 있는 타입은 다음과 같습니다.

• Activity, Fragment, View, Service, BroadCastReceiver

  @AndroidEntryPoint
  class MyActivity : MyBaseActivity() {
    @Inject lateinit var bar: Bar // ApplicationComponent 또는 ActivityComponent으로 부터 의존성이 주입된다.
    override fun onCreate() {
  // super.onCreate()에서 의존성 주입이 발생한다.
        super.onCreate()
  // Do something with bar ...
    }
  }

  Hilt Module

  때로 생성자 삽입할 수 없는 상황도 있습니다. 예를 들어 인터페이스를 생성자 삽입할 수 없습니다. 또한 외부 라이브러리의 클래스와 같이 소유하지 않은 유형도 생성자 삽입할 수 없습니다. 이럴 때는 Hilt 모듈을 사용하여 Hilt에 결합 정보를 제공할 수 있습니다.

@Module, @InstallIn

모듈은 컴포넌트에 의존성을 제공하는 역할을 합니다. 클래스에 @Module 어노테이션을 붙여 모듈 클래스를 만들 수 있습니다. 모듈 클래스 내에 선언되는 매서드에 @Provides 어노테이션을 붙여 컴파일 타임에 의존성을 제공하는 바인드된 프로바이더를 생성합니다. 간단히 설명하면 @Module 은 의존성을 제공하는 클래스에 붙이고, @Provides 는 의존성을 제공하는 메소드에 붙인다고 생각하면 됩니다. Hilt의 모듈은 @InstallIn이라는 추가적인 어노테이션을 갖습니다. @InstallIn은 Hilt의 표준 컴포넌트들 중 어떤 컴포넌트에 모듈을 설치할지 결정합니다.

@Module
@InstallIn(ApplicationComponent.class) // 생성되는 ApplicationComponent에 FooModule을 설치함
        public final class FooModule {
    @Provides
    static Bar provideBar() {...}
}

@Binds를 사용하여 인터페이스 인스턴스 삽입

인터페이스라면 이 인터페이스를 생성자 삽입할 수 없습니다. 대신 Hilt 모듈 내에 @Binds로 어노테이션이 지정된 추상 함수를 생성하여 Hilt에 결합 정보를 제공합니다. @Binds 어노테이션은 인터페이스의 인스턴스를 제공해야 할 때 사용할 구현을 Hilt에 알려줍니다.

@Provides를 사용하여 인스턴스 삽입

인터페이스가 유형을 생성자 삽입할 수 없는 유일한 경우는 아닙니다. 클래스가 외부 라이브러리에서 제공되므로 클래스를 소유하지 않은 경우(Retrofit, OkHttpClient 또는 Room 데이터베이스와 같은 클래스) 또는 빌더 패턴으로 인스턴스를 생성해야 하는 경우에도 생성자 삽입이 불가능합니다. 클래스를 직접 소유하지 않으면 Hilt 모듈 내에 함수를 생성하고 이 함수에 @Provides 어노테이션을 지정하여 이 유형의 인스턴스를 제공하는 방법을 Hilt에 알릴 수 있습니다.

@Module
@InstallIn(ActivityComponent::class)
object AnalyticsModule {

  @Provides
  fun provideAnalyticsService(
    // Potential dependencies of this type
  ): AnalyticsService {
      return Retrofit.Builder()
               .baseUrl("https://example.com")
               .build()
               .create(AnalyticsService::class.java)
  }
}

Hilt component

기존의 Dagger와 다르게 Hilt사용자는 Dagger 컴포넌트를 직접적으로 정의하거나 인스턴스화 할 필요가 없어졌습니다. Hilt는 안드로이드 Application의 다양한 생명주기에 자동으로 통합되는 내장 컴포넌트 세트를 해당 스코프 어노테이션과 함께 제공합니다. 아래에 있는 다이어그램은 표준 Hilt 컴포넌트 계층을 보여주고 있습니다다. 각 컴포넌트에 위에달린 어노테이션은 컴포넌트 바인딩의 생명주기를 지정하는 데 사용됩니다. 각 컴포넌트 아래에 있는 화살표는 하위 컴포넌트를 가르키고 있습니다. 하위 컴포넌트의 바인딩은 상위 컴포넌트의 바인딩이 가지고 있는 의존성들을 가질 수 있습니다.

@InstallIn이 달린 모듈의 바인딩에 스코프가 지정될 때는 반드시 모듈이 설치되는 컴포넌트의 스코프와 일치해야 합니다. 예를 들면, @InstallIn(ActivityComponent.class) 모듈은 @ActivityScoped 만 사용할 수 있습니다.

Component 수명

컴포넌트의 수명은 안드로이드 클래스에 대응하는 인스턴스 생성과 소멸을 따라갑니다. 컴포넌트가 생성되고 종료될 때, 해당 스코프 어노테이션이 지정된 바인딩 또한 수명을 함께합니다. 컴포넌트 수명은 멤버 주입된 값들이 사용될 수 있는 시기를 나타냅니다. 다음 표는 스코프 어노테이션과 각 컴포넌트에 맞는 수명을 목록으로 보여주고 있습니다.

@InstallIn(ApplicationComponent::class)
@Module
class RetrofitCreate {

    @Provides
    @Singleton
    fun createRetrofit(): Retrofit {...}
    }
}

Hilt AndroidX Extensions

Hilt는 jetpack 라이브러리 클래스를 위해 extensions 를 제공합니다. 지원하는 컴포넌트로 ViewModel, WorkManager 가 있습니다.

@ViewModelInject

class MainViewModel @ViewModelInject constructor(
    private val loginRepositoryImpl: LoginRepositoryImpl
) : BaseViewModel() {...}

Reference

[Android Developers] Hilt를 사용한 종속 항목 삽입 [드로이드나이츠 2020] 옥수환 - Hilt와 함께 하는 안드로이드 의존성 주입 [하이퍼커넥트 기술블로그] Dagger Hilt로 안드로이드 의존성 주입 시작하기

메인액티비티가 실행되기 전까지 로딩화면을 보여주는 splash 화면을 효율적으로 적용해 보았습니다. 메인액티비티에 Splash Theme 을 적용하고, 메인액티비티가 생성되면 Theme 을 전체 프로젝트의 AppTheme 으로 변경하였습니다.

background_splahs.xml 생성

drawable 폴더 내에 splash 화면을 생성합니다.

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <item>
        <bitmap android:src="@drawable/intropage"
            android:gravity="center"/>
    </item>
</layer-list>

SplashTheme 생성

values 폴더 내 themes 파일에 splash 를 위한 style 을 생성합니다.

<!--Splash theme -->
    <style name="SplashTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="android:windowBackground">@drawable/background_splash</item>
    </style>

MainActivity 에 Theme 적용

AndroidManifest 파일 내에 MainActivity 에 theme 을 적용합니다.

<activity android:name=".view.main.MainActivity"
            android:theme="@style/SplashTheme">

MainActivity 생성 후 원래 Theme 으로 변경

MainActivity 의 onCreate 내에 setTheme 함수를 이용하여 원래의 theme 으로 변경시켜 줍니다. super.onCreate(savedInstance) 가 호출되기 전에 setTheme 함수를 적용합니다.

 override fun onCreate(savedInstanceState: Bundle?) {
        setTheme(R.style.TripProjectTheme)
        super.onCreate(savedInstanceState)
    }

Reference

[https://velog.io/@pish11010/Android-Splash-Screen-구현] (https://velog.io/@pish11010/Android-Splash-Screen-구현) [https://holika.tistory.com/entry/내-맘대로-정리한-안드로이드-스플래시Splash-화면은-어떻게-만들어야-효율적으로-활용할-수-있을까] (https://holika.tistory.com/entry/내-맘대로-정리한-안드로이드-스플래시Splash-화면은-어떻게-만들어야-효율적으로-활용할-수-있을까)

Android KTX 는 android 를 위한 코틀린(Kotlin) 개발용 확장(Extensions) 라이브러리입니다. Android KTX 는 안드로이드 프레임워크와 서포트 라이브러리를 모두 지원하여 코틀린 코드를 더 자연스럽게 사용할 수 있도록 합니다. Android KTX 는 모듈로 구성됩니다. 필요한 기능을 담은 모듈을 추가하여 사용할 수 있습니다.

Android KTX 사용

android KTX 를 사용하려면 프로젝트 수준의 build.gradle 파일에 아래의 코드를 추가해야 합니다.

repositories {
    google()
}

Android KTX 모듈별 사용 예

• Core KTX Core KTX 모듈은 Android 프레임워크의 일부인 일반 라이브러리에 확장 프로그램을 제공합니다. 이 모듈을 포함하려면 app 수준의 build.gradle 파일에 다음을 추가합니다.

  dependencies {
    implementation "androidx.core:core-ktx:1.3.2"
  }

  Core KTX 모듈을 사용하면 Sharedpreference 를 더 쉽게 편집할 수 있습니다.

        preference.edit().putString(key, value).apply()

  위의 코드를 아래와 같이 쓸 수 있습니다.

        preference.edit { putString(key, value) }

• Activity KTX Activity KTX 는 여러 확장 프로그램을 제공하여 Activity API 를 단순화합니다. Activity KTX 모듈을 포함하려면 다음을 추가합니다.

  dependencies {
    implementation "androidx.activity:activity-ktx:1.2.0"
  }

  Activity KTX 를 사용하면 ViewModel 을 간단하게 할당할 수 있습니다.

    private lateinit var vm: MainViewModel
    vm = ViewModelProvider(this).get(MainViewModel::class.java)
  

위의 코드를 아래와 같이 쓸 수 있습니다.
```kotlin
    private val vm: MainViewModel by viewModels()
```
그 외에도 아래와 같은 KTX 모듈들이 있습니다.
- Collection KTX
- Fragment KTX
- LiveData KTX
- LifeCycle KTX
- Room KTX 
...

---
## Reference
[Android Developer](https://developer.android.com/kotlin/ktx?hl=ko#core)
[Google Developers](https://developers-kr.googleblog.com/2018/02/introducing-android-ktx-even-sweeter-kotlin-development-for-android.html)
[AndroidX Tech](https://androidx.tech/artifacts/activity/activity-ktx/)

application context 를 전역에서 불러오기 위해 application context를 singleton 으로 생성해 줍니다.

Manifest 추가

<application
        android:name=".utils.App">
        ...
    </application>

App 클래스 생성

application Context 를 singleton 으로 생성합니다.

class App : Application () {
    init {
        instance = this
    }
    companion object {
        private var instance: App? = null
        fun applicationContext() : Context {
            return instance!!.applicationContext
        }
    }
}

아래와 같은 방식으로 context 를 불러 사용합니다.

App.applicationContext()

Reference

https://ddangeun.tistory.com/78 남갯,YTS의 개발,일상블로그

네이버 developer 사이트에 들어가서 어플리케이션을 등록하고 api key를 생성합니다. 생성한 api key 는 보안을 위해 key.properties 파일을 생성하여 저장합니다. 앱 단위의 build.gradle 파일에 아래의 코드를 추가하여 key.properties 파일의 값들을 불러옵니다.

def keys = new Properties()
file("../key.properties").withInputStream {
    stream -> keys.load(stream)
}

defaultConfig {
        ...
        buildConfigField("String", "NAVER_CLIENT_ID", keys.NAVER_CLIENT_ID)
        buildConfigField("String", "NAVER_CLIENT_SECRET", keys.NAVER_CLIENT_SECRET)
    }

key.properties 파일을 gitignore 파일에 추가합니다.

환경 설정

앱 모듈의 build.gradle 에 dependency를 추가해 줍니다.

implementation 'com.naver.nid:naveridlogin-android-sdk:4.2.6'

버튼 추가

OAuthLoginButton 객체로 버튼을 추가합니다.

<com.nhn.android.naverlogin.ui.view.OAuthLoginButton
            android:id="@+id/main_login_naver"
            android:layout_width="250dp"
            android:layout_height="53dp"
            />

startOAuthLoginActivity() 메소드를 이용한 로그인

    // 네이버 아이디 로그인 인스턴스 초기화 
            mOAuthLoginInstance = OAuthLogin.getInstance()
            mOAuthLoginInstance.init(
                App.context,
                BuildConfig.NAVER_CLIENT_ID,
                BuildConfig.NAVER_CLIENT_SECRET,
                R.string.app_name.toString()
            )

    // OAuthLoginHandler 로 accessToken 가져오기
            mOAuthLoginInstance.startOauthLoginActivity(this, @SuppressLint("HandlerLeak")
            object : OAuthLoginHandler() {
                override fun run(success: Boolean) {
                    if (success) {
                        val accessToken: String = mOAuthLoginInstance.getAccessToken(baseContext)
                        Toast.makeText(baseContext, accessToken, Toast.LENGTH_SHORT).show()
                    } else {
                        val errorCode: String =
                            mOAuthLoginInstance.getLastErrorCode(App.context).code
                        val errorDesc = mOAuthLoginInstance.getLastErrorDesc(App.context)

                        Toast.makeText(
                            baseContext,
                            "errorCode: $errorCode, errorDesc: $errorDesc",
                            Toast.LENGTH_SHORT
                        ).show()
                    }
                }
            })

Reference

Naver Developers

data binding 을 위해 앱 모듈의 build.gradle 파일을 수정합니다.

dataBinding {
        enabled = true
    }

xml 파일에 <layout> 태그를 추가하여 databinding 을 적용합니다.

<layout ...>
    <data>
        ...
    </data>

    <androidx.constraintlayout.widget.ConstraintLayout
        ...
    </androidx.constraintlayout.widget.ConstraintLayout>
</layout>

해당 액티비티에서 binding 클래스 객체를 생성해 주고, LiveData 를 위한 lifeCycleOwner 도 설정합니다.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val binding : ActivityMainBinding = DataBindingUtil.setContentView(this, R.layout.activity_main)
        binding.lifecycleOwner = this
    }
}

ViewModel 생성

View 에서 쓰이는 속성들을 담은 ViewModel 을 생성해 줍니다. 화면전환과 같은 변화에도 데이터가 유지될 수 있도록 AAC ViewModel 도 적용시켜 줍니다. ViewModel 내에서만 data 를 변경할 수 있도록 private val 로 data 를 선언합니다. 이벤트(input)가 감지되면 ViewModel 내에서 data를 변화시키는 함수를 생성합니다. View 에서 LiveData 를 Observe 하고 있으니 LiveData 에 변화가 있으면 View 에서 이를 파악하고 View 를 갱신합니다.

import androidx.lifecycle.ViewModel

class MainViewModel : ViewModel() {
    private val _signUpEvent = MutableLiveData<Unit>()
    val signUpEvent : LiveData<Unit> = _signUpEvent

    private val _loginEvent = MutableLiveData<Unit>()
    val loginEvent : LiveData<Unit> = _loginEvent

    fun login() {
        _signUpEvent.value = Unit
    }

    fun signUp() {
        _loginEvent.value = Unit
    }
}

DataBinding

ViewModel 변수를 선언해주고, 변화가 감지될 이벤트에 ViewModel의 속성을 DataBinding 해줍니다.

    <data>
        <variable
            name="vm"
            type="com.hhi.tripproject.viewmodel.MainViewModel" />
    </data>

    <TextView
            ...
            android:onClick="@{()->vm.signUp()}"
     />

액티비티에서 ViewModel 을 바인딩 해줍니다.

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

        vm = MainViewModel()
        binding.vm = vm
    }

binding 된 LiveData를 Observe 하고, 변화된 data 에 따라 View 가 갱신되도록 로직을 설정해 줍니다.

vm.signUp.observe(this, Observer {
            startActivity(Intent(this, SignUpActivity::class.java))
        })

        vm.login.observe(this, Observer {
            startActivity(Intent(this, LoginActivity::class.java))
        })

불필요한 코드의 중복을 방지하고, 코드를 효율적으로 재활용하기 위해 많은 디자인 패턴들이 사용됩니다. 그 중 많이 사용되고 있는 디자인 패턴들에 대해 찾아 봤습니다.

MVC

MVC 패턴은 사용자에게 보여지는 UI를 담당하는 View, input 을 받아 처리하는 Controller, data를 담고 있는 Model 로 이루어져 있습니다. controller 에서 event를 받으면, Model 에서 data 를 가져와 처리한 후 View 에 결과를 뿌려줍니다. 데이터의 입력과 처리를 모두 Controller 가 담당하여 Controller 가 무거워 졌습니다. 이를 개선한 것이 MVP 패턴입니다.

MVP

MVP 패턴은 사용자에게 보여지는 UI와 입력을 담당하는 View, 데이터를 처리하는 Presenter, data를 담고 있는 Model 로 이루어져 있습니다. View 에서 이벤트를 받으면 그 사실을 Presenter 에게 전달합니다. Presenter 가 처리한 후 다시 결과를 View에게 전달합니다. Presenter 는 데이터의 처리만을 담당하게 되었습니다. 각 View에 대한 입력을 처리하기 위해 View 와 Presenter는 1대 1의 관계가 요구됩니다. 비슷한 동작을 하는 View 일지라도, Presenter 를 재활용할 수 없습니다. 이를 개선한 것이 MVVM 패턴입니다.

MVVM

MVVM 패턴은 UI를 담당하는 View, 데이터를 담고 있는 Model, 비지니스 로직이 구현되어 있는 ViewModel 로 이루어져 있습니다.

MVVM 패턴의 기본은 View 와 ViewModel 을 직접 연결하지 않는 것입니다. 그렇다면 둘은 어떻게 변화를 파악할 수 있을까요? Data Binding 을 사용하면 해결할 수 있습니다. View 는 ViewModel 을 선택해 Data Binding 합니다. View 는 ViewModel 을 직접 참조하지 않고, 관찰(Observe) 하다가 변화가 생기면 View를 갱신합니다. ViewModel 은 View가 Data Binding 할 수 있는 속성과 명령들로 이루어져 있습니다.

View와 ViewModel, View 와 Model 사이의 의존성이 없으므로 테스트가 용이 합니다.

AAC 의 ViewModel 과 MVVM 의 ViewModel

AAC 의 ViewModel 은 액티비티, 프래그먼트의 lifecycle 과 독립된 환경 변화에도 유지되는 lifecycle 을 가지는 클래스를 의미하고, MVVM 의 ViewModel 은 View 와 Model 사이에서 바인딩하고, 로직을 처리하는 클래스를 의미합니다. MVVM 의 ViewModel 에서 AAC 의 ViewModel 을 사용할 수도 있고, 사용하지 않아도 MVVM 의 ViewModel은 구현 가능합니다.

Reference

https://www.youtube.com/watch?v=bjVAVm3t5cQ https://github.com/KRMKGOLD/Android-MVVMSample https://velog.io/@jojo_devstory/안드로이드-아키텍처-패턴-MVVM이-뭘까

LiveData 는 관찰 가능한(Observable) 데이터 클래스입니다. LiveData는 Lifecycle 을 통해 생명 주기를 인식합니다. 즉, 주어진 LifecycleOwner (액티비티, 프래그먼트, 서비스와 컴포넌트들) 의 생명 주기가 STARTED 또는 RESUME 상태인 경우만 Observer 를 활성(active) 상태로 봅니다. LiveData의 장점들은 아래와 같습니다.

• UI와 data 의 동기화
• memory leak 없음
• 액티비티가 갑작스럽게 종료될 때도 안전하다
• 생명 주기에 대한 고민 필요 없음
• 최신의 데이터를 유지한다
• 구성 변경에 대응한다
• 자원 공유하기

DataBinding 과 LiveData 사용하기

dataBinding 과 liveData를 사용하면 lifecycle 에 대한 걱정없이 데이터의 변경에 따른 UI 변경을 자동으로 처리하도록 설정할 수 있습니다.

1. 바인딩 클래스에 LifecycleOwner를 명시하여, 생명주기를 인식하도록 합니다.

   binding.lifecycleOwner = this

2. ViewModel 에서 LiveData 생성할 때, ViewModel 에서만 값을 변경할 수 있도록 하는것이 보안에 좋습니다. 참조될 때는 LiveData, ViewModel 내에서는 MutableLiveData 로 변환하여 사용합니다.

   private val _hideKeyBoardEvent = MutableLiveData<Unit>()
   val hideKeyBoardEvent: LiveData<Unit> = _hideKeyBoardEvent

3. 위와 같은 데이터를 Activity에서 observe 하도록 합니다.

   vm.hideKeyBoardEvent.observe(this, Observer {
   ...
   }) 

4. xml 에서 dataBinding 합니다.

   android:onClick="@{()->vm.hideKeyBoardEvent()}"

setValue, postValue

• setValue 는 mainThread 에서 값을 변경해줍니다. 그렇기 때문에, setValue 바로 뒤에 getValue를 해도 변경된 값을 받아옵니다. setValue 는 mainThread 에서 값을 dispatch 하기 때문에 백그라운드에서 setValue 를 호출하면 오류가 발생합니다.
• postValue 는 백그라운드에서 값을 변경합니다. 백그라운드 thread에서 동작하다가 mainThread 로 값을 post 해주는 방식으로 동작합니다. 함수 내부적으로는 아래와 같은 코드가 동작합니다. postValue 를 호출한 뒤 바로 getValue로 값을 읽으려고 하면, 변경되지 않은 값을 불러올 수도 있습니다. Handler 를 통해 mainThread 에 값이 적용되기 전에 getValue 로 호출하기 때문입니다.

  new Handler(Looper.mainLooper()).post(() -> setValue())

Reference

android developer 해리의 유목코딩 꾸준하게