Room

https://developer.android.com/training/data-storage/room?hl=ko
https://todaycode.tistory.com/39
https://math-coding.tistory.com/247
https://developer.android.com/codelabs/android-room-with-a-view-kotlin#0 *중요
https://medium.com/슬기로운-개발생활/안드로이드-room-사용법-1b7bd07b4cee

• Room
  • 데이터를 로컬에 유지하는 기능을 제공하는 Library
  • 스마트폰 내 로컬 DB에 데이터를 저장하고 유지할 때 사용하는 라이브러리
  • 오프라인 상태여도 사용자가 콘텐츠를 탐색할 수 있도록 데이터 캐시작업 수행
  • 원활한 Database Access가 가능하도록 SQLite 추상화 계층 제공
    -> SQLite보다 활용성 향상
  • ORM Library (Object Relational Mapping) 으로 데이터베이스 object를 kotlin object로 mapping 수행

• build.gradle

val room_version = "2.4.3"
implementation("androidx.room:room-runtime:$room_version")
annotationProcessor("androidx.room:room-compiler:$room_version")

https://velog.io/@corone_hi/DAO-Data-Access-Object-DTOData-Transfer-Object-VOValue-Object

• DAO
  • Data Access Object
  • DB에 abstract interface를 제공하는 Object
  • 실제로 DB에 접근하는 Object로서 DB에 접속해 INSERT, DELETE, SELECT 등 메소드 포함 -> Annotation으로 제공
  • Persistence Layer 퍼시스턴스 계층 (DB와 연결하는 부분이자 data CRUD를 수행하는 계층)
  • DAO에서는 CRUD 작업만 이루어짐

// DAO와는 달리 DTO는 transfer이므로 로직을 가지지 않고 getter, setter로만 동작
// DTO <-> DAO <-> DataBase => Server에서 이런 구조로 동작함.

• ex) User객체를 INSERT, DELETE, QUERY(직접 SQL문 작성)하는 메소드 정의 DAO

• Room Library를 사용해 data를 저장할 때 DAO(데이터 액세스 객체)를 정의하여 상호작용

• DAO를 이용해 앱 DB에 access하면 => can preserve separation of concerns, a critical architectural principle

• DAO에는 항상 @Dao 어노테이션(Dao클래스 식별)을 달아야 하며 class가 아닌 interface

• 메소드 어노테이션

  • @Insert : 테이블에 data 삽입 (쿼리문을 작성하지 않아도 자동으로 insert기능 부여)

  • @Delete : 테이블에 있는 특정 data 삭제 (위와 동일)

  • @Update : 테이블에 있는 특정 data 갱신 (위와 동일)

  • @Query : 직접 SQL문을 작성

  • @Insert Annotation 옆에 onConflict = OnConflictStrategy.IGNORE(충돌 정책)은 data conflict 시 처리해야 할 작업을 정의. IGNORE = data conflict 시 새로운 data 무시

• DAO에서 모든 쿼리는 비동기로 처리는게 효율적이기에 Room + Coroutines suspend 함수를 활용하여 프로그래밍이 유리

• DAO를 쓰는 이유 : https://linuxism.ustd.ip.or.kr/27

• Entity

  • @Entity 어노테이션을 붙여 data class 정의
  • 각 Entity는 연결된 Room DB의 table에 매칭되는 상응적 의미
  • Room은 default로 DB table name과 data class name이 동일
  • Entity에 정의된 각 field가 테이블의 column과 매칭되는 상응적 의미
  • 테이블과 마찬가지로 default로 field name과 column name이 동일
  • Annotation을 통해 테이블명, 칼럼명, 칼럼 타입, PK, FK 정의

  

  • PK를 지정해줘야 하지만, 가상키 활용도 가능 -> autoGenerate = true

• Database

  • DB Object

  • RoomDatabase class를 상속받는 abstarct class
    @Entity 어노테이션을 통해 만든 User 테이블 클래스, @Dao 어노테이션을 통해 만든 userDao 클래스

  • Dao를 반환하는 abstract 메소드를 포함

  • @Database 어노테이션을 통해 DB로 식별 + 어노테이션 안에 해당 DB의 Entity들을 포함시켜 지정 -> 여러 개의 entity는 array로 묶여서 지정

  • 어노테이션 안에 version var를 통해 앱 업데이트 여부를 구분할 수 있는 content 제공

  • Application이 Room DB로부터 Dao를 가져옴 -> Dao를 통해 Entity access

  • Dao에 포함된 메소드를 통해 -> Entity data를 읽고 씀.

• Repository
  • repository class는 multiple data sources에 access 하는 것을 추상화함.
  • repository class를 활용함으로써 나머지 application의 data에 access할 수 있는 clean API 구축 가능
  • query들을 관리하고 multiple backends를 사용하게끔 할 수 있음.
  • 일반적으로, 데이터를 Network에서 가져올지, 로컬DB에 캐시된 결과를 사용할지 결정하는 로직을 구현

• ViewModel
  https://medium.com/androiddevelopers/viewmodels-a-simple-example-ed5ac416317e

  • ViewModel's role: UI에 data 제공 & 이러한 data들은 configuration 변경에도 유지되어야 함.

  • Repository와 UI 사이의 communication center 역할처럼 작업을 수행

  • lifecycle Library의 일부

  • fragment들 사이에서 data를 공유할 수 있게끔 함

  • lifecycle을 고려하여 configuration 변경에도 앱의 UI data를 유지

  • 정리)
    Activity, Fragment 클래스로부터 앱의 UI data를 분리 ->

    • Activity, Fragment => 화면에 data를 그리는 것을 담당
    • ViewModel => UI에 필요한 모든 Data를 관리하고 처리

• LiveData
  https://velog.io/@eoqkrskfk94/LiveData%EC%99%80-Flow
  • observable data holder = 관찰 가능한 데이터 홀더
  • data가 변경될 때마다 알림을 받음
  • Flow와는 달리 lifecycle을 인식해 Activity, Fragment 등의 다른 components들의 lifecycle도 고려
  • 즉, LiveData는 UI에서 사용(use)하거나 표시(display)하는 변경 가능한(changeable) data에 적합한 component
  • 정리)
    ViewModel은 Repository의 data를 Flow에서 LiveData로 변환하고 data를 LiveData로 UI에 expose시킴. -> 이런 식으로 구조를 구축하면, Database의 data가 변경될 때마다 UI가 자동으로 업데이트됨.