무식스택

android 개발팀에서 husky로 git hook 공유하기

이도일 — Fri, 19 Apr 2024 15:10:11 +0900

사건의 발단

현재 우리팀은 commit-msg title에 prefix로 브랜치 구분(feature / chore / hotfix…etc) 을 적용하고,

commit-msg content에 티켓 넘버를 자동으로 붙이는 hook을 적용중이다.

hook은 기본적으로 공유가 안 되어서, 굳이굳이 ignore를 풀고..

브랜치를 변경할 때마다 복잡한 cli 명령어를 쓰고…(매번 까먹어서 확인해야한다)

암튼 이런 짓을 해야하는데

husky 라는 node 모듈을 쓰면 hook의 공유가 가능하다는 것을 알게되었다!

게다가 앞으로 추가될(지 모를) 노드 모듈들과도

npm install

이 명령어 하나만으로 묶일 수 있다는 것!

물론 웹 개발자들과 다르게.. 안드로이드는 노드 모듈을 사용할 일이 많지않아서

npm install 하는것도 초반엔 매번 까먹겠지만

어쨌든 도입해보기로 했다.

설정 방법

초기 설치

// Using npm
npx husky-init && npm install

// Using yarn
yarn dlx husky-init --yarn2 && yarn

// Using pnpm
pnpm dlx husky-init && pnpm install

루트 프로젝트에 .husky 확인

사용할 hook 파일 생성

나는 두 개를 사용한다. (pre-commit은 자동으로 그냥 생성된다!)
- commit-msg : 커밋 메세지 내용으로 티켓 넘버를 붙이기 위함
- prepare-commit-msg : 커밋 메세지 타이틀에 구분을(feature / hotfix…) 를 붙이기 위함

hook file 내용 작성

# commit-msg

#!/bin/bash

COMMIT_MESSAGE_FILE_PATH=$1
MESSAGE=$(cat "$COMMIT_MESSAGE_FILE_PATH")

# 커밋 메시지가 있을 때만 티켓 넘버를 추가한다.
if [[ $(head -1 "$COMMIT_MESSAGE_FILE_PATH") == '' ]]; then
  exit 0
fi

# 브랜치 이름에서 마지막 '_' 이후의 문자열만 남긴다. '/'가 없다면 브랜치 전체 이름이 POSTFIX 된다.
# POSTFIX의 첫 번째 '-' 앞뒤의 문자열만 포함한다. '-'가 없다면 변경은 없다

POSTFIX=$(git branch | grep '\\*' | sed 's/* //' | sed 's/^.*\\///' | sed 's/^.*_//')

printf "%s\\n\\n[%s]" "$MESSAGE" "$POSTFIX" > "$COMMIT_MESSAGE_FILE_PATH"

# prepare-commit-msg

#!/bin/sh

COMMIT_MESSAGE_FILE_PATH=$1

# merge commit에 대해서는 prefix를 생성하지 않는다.
MERGE=$(grep -c -i 'merge' < "$COMMIT_MESSAGE_FILE_PATH" || true)
if [ "$MERGE" != "0" ] ; then
  exit 0
fi

TYPE=$(git branch | grep '\\*' | sed 's/\\* //' | sed 's/\\([^/]*\\).*/\\1/' || true)
DESCRIPTION=$(git config branch."$TYPE".description || true)

echo "$TYPE: $(cat "$COMMIT_MESSAGE_FILE_PATH")" > "$COMMIT_MESSAGE_FILE_PATH"
if [ -n "$DESCRIPTION" ]
then
   echo "" >> "$COMMIT_MESSAGE_FILE_PATH"
   echo "$DESCRIPTION" >> "$COMMIT_MESSAGE_FILE_PATH"
fi

→ 참고로 branch naming convention은 구분/티켓명_티켓넘버다.

package.json에 권한 설정

{
  "devDependencies": {
    "husky": "^9.0.11"
  },
  "scripts": {
    "prepare": "husky",
    "postinstall": "chmod +x .husky/"
  }
}

커밋 메세지 확인

트러블 슈팅

파일 위치 문제

원래는 .husky 밑에 바로 hook 파일들을 넣어야한다..그걸 몰라서 .husky/_/하위 hook 파일의 내용을 고쳤다..... (git hook 설정시 내용 변경후 .sample확장자를 제거하면 되는것처럼)

당연히 저렇게 하면 안 된다. npm install시 저 파일이 덮어씌워진다.

.husky/_/ 하위 파일들은 .husky/ 하위 파일의 트리거일 뿐이다…..

이걸 몰라서 한참을 헤멨다

파일 권한 문제

훅 초기 세팅시에 권한이 없으면 커밋 메세지를 마음대로 커스텀 할 수 없다.

그래서… npm install시에 .husky/하위 파일의 권한을 올려주는 방식으로 해결했다

package.json에 권한 설정 부분이 그 결과물이다.

prepare-commit-msg hook 에러

husky - prepare-commit-msg script failed (code 1)

이런 에러가 발생했다…..시부레

수정 전 스크립트는 다음과 같다

#!/bin/sh

COMMIT_MESSAGE_FILE_PATH=$1

# merge commit에 대해서는 prefix를 생성하지 않는다.
MERGE=$(grep -c -i 'merge' < "$COMMIT_MESSAGE_FILE_PATH")
if [ "$MERGE" != "0" ] ; then
  exit 0
fi

TYPE=$(git branch | grep '\\*' | sed 's/\\* //' | sed 's/\\([^/]*\\).*/\\1/')
DESCRIPTION=$(git config branch."$TYPE".description)
echo "$TYPE: $(cat "$COMMIT_MESSAGE_FILE_PATH")" > "$COMMIT_MESSAGE_FILE_PATH"
if [ -n "$DESCRIPTION" ]
then
   echo "" >> "$COMMIT_MESSAGE_FILE_PATH"
   echo "$DESCRIPTION" >> "$COMMIT_MESSAGE_FILE_PATH"
fi

서브 커맨드의 종료 조건이 (ex: grep -c -i 'merge' < .git/COMMIT_EDITMSG) 의 리턴값이 에러로 잡혀서..

허스키는 이 경우 아예 exit을 시켜버리기 때문에 발생한 문제였다.

수정 후 스크립트

#!/bin/sh

COMMIT_MESSAGE_FILE_PATH=$1

# merge commit에 대해서는 prefix를 생성하지 않는다.
MERGE=$(grep -c -i 'merge' < "$COMMIT_MESSAGE_FILE_PATH" || true)
if [ "$MERGE" != "0" ] ; then
  exit 0
fi

TYPE=$(git branch | grep '\\*' | sed 's/\\* //' | sed 's/\\([^/]*\\).*/\\1/' || true)
DESCRIPTION=$(git config branch."$TYPE".description || true)

echo "$TYPE: $(cat "$COMMIT_MESSAGE_FILE_PATH")" > "$COMMIT_MESSAGE_FILE_PATH"
if [ -n "$DESCRIPTION" ]
then
   echo "" >> "$COMMIT_MESSAGE_FILE_PATH"
   echo "$DESCRIPTION" >> "$COMMIT_MESSAGE_FILE_PATH"
fi

서브 커맨드에서 true를 반환하도록 수정했다.

이 에러 때문에 진짜 한 3시간은 쓴 것 같은데ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

아무튼 해결.

결론

이왕 node module을 쓰게 된 거..

다양한 프로젝트 세팅에 필요한 모듈들을 찾아서 적용해봐야겠다.

Flutter padding 위젯 util화

이도일 — Sat, 13 Apr 2024 09:26:31 +0900

회사에서 피그마 value 값을 토큰화 시키는 작업을 진행중이다.

(참고로 style dictionary 는 아래와 같은 토큰값을 지원한다)

color
dimension
custom-radius
custom-spacing
custom-fontStyle
custom-icon

https://github.com/aloisdeniel/style-dictionary-figma-flutter

GitHub - aloisdeniel/style-dictionary-figma-flutter: Custom style-dictionary transforms and formats to generate Flutter resource

Custom style-dictionary transforms and formats to generate Flutter resources from a Figma Design Token plugin export.. - aloisdeniel/style-dictionary-figma-flutter

github.com

아무튼

code generator를 사용해서 만들어지는 값들은(ex: style dictionary) 영 마음에 안들어서...

  final Color colorsMultipleFills0;
  final Color colorsMultipleFills1;
  final Color colorsRefBlue;
  final Color colorsSingleBlue;
  final Color colorsSpecialCharacters;
  final Color colorsSpecialCharactersNderung;
  final Color darkBackground;
  final Color invalidEmpty;
  final Color lightBackground;

이런식으로 이름 그대로 지정이 된다.

color는 material color 사용하는것처럼 color를 만들고, (이건 다음 글로)

static const dsRed = MaterialColor(_dsRedPrimaryValue, <int, Color>{
    100: Color(0xFFFFD6DA),
    200: Color(0xFFFFA3AC),
    300: Color(0xFFFF808B),
    400: Color(0xFFFF5262),
    500: Color(_dsRedPrimaryValue),
    600: Color(0xFFCC0013),
    700: Color(0xFF99000E),
    800: Color(0xFF66000A),
    900: Color(0xFF330005),
  });
  static const _dsRedPrimaryValue = 0xFFFF0018;

(이렇게 사용하면 dsRed[100]과 같은 형태로 사용이 가능하다)

padding widget은 side flag를 넣어서 아래와 같이 방향, 픽셀값만 지정하면 사용할 수 있게끔 util화 시켰다.

import 'package:flutter/material.dart';

class Dimension {
  late _DimensionSide _left;
  late _DimensionSide _top;
  late _DimensionSide _right;
  late _DimensionSide _bottom;
  late _DimensionSide _horizontal;
  late _DimensionSide _vertical;
  late _DimensionSide _all;

  Dimension() {
    _left = _DimensionSide(_SideFlag(1, 0, 0, 0));
    _top = _DimensionSide(_SideFlag(0, 1, 0, 0));
    _right = _DimensionSide(_SideFlag(0, 0, 1, 0));
    _bottom = _DimensionSide(_SideFlag(0, 0, 0, 1));
    _horizontal = _DimensionSide(_SideFlag(1, 0, 1, 0));
    _vertical = _DimensionSide(_SideFlag(0, 1, 0, 1));
    _all = _DimensionSide(_SideFlag(1, 1, 1, 1));
  }

  _DimensionSide get left => _left;
  _DimensionSide get top => _top;
  _DimensionSide get right => _right;
  _DimensionSide get bottom => _bottom;
  _DimensionSide get horizontal => _horizontal;
  _DimensionSide get vertical => _vertical;
  _DimensionSide get all => _all;
}

class _DimensionSide {
  _SideFlag sideFlag;

  _DimensionSide(this.sideFlag);

  EdgeInsets get none {
    return _DimensionSize(sideFlag, _Helper.none).data;
  }

  EdgeInsets get px_4 {
    return _DimensionSize(sideFlag, _Helper.px_4).data;
  }

  EdgeInsets get px_6 {
    return _DimensionSize(sideFlag, _Helper.px_6).data;
  }

  EdgeInsets get px_8 {
    return _DimensionSize(sideFlag, _Helper.px_8).data;
  }

  EdgeInsets get px_12 {
    return _DimensionSize(sideFlag, _Helper.px_12).data;
  }

  EdgeInsets get px_16 {
    return _DimensionSize(sideFlag, _Helper.px_16).data;
  }

  EdgeInsets get px_24 {
    return _DimensionSize(sideFlag, _Helper.px_24).data;
  }
}

class _DimensionSize {
  _SideFlag sideFlag;
  double factor;

  _DimensionSize(this.sideFlag, this.factor);

  get data => EdgeInsets.fromLTRB(
        sideFlag.leftFlag * factor,
        sideFlag.topFlag * factor,
        sideFlag.rightFlag * factor,
        sideFlag.bottomFlag * factor,
      );
}

class _SideFlag {
  double leftFlag = 0;
  double topFlag = 0;
  double rightFlag = 0;
  double bottomFlag = 0;

  _SideFlag(
    this.leftFlag,
    this.topFlag,
    this.rightFlag,
    this.bottomFlag,
  );
}

class _Helper {
  static double none = 0;
  static double px_4 = 4;
  static double px_6 = 6;
  static double px_8 = 8;
  static double px_12 = 12;
  static double px_16 = 16;
  static double px_24 = 24;
}

Dimension spacer = Dimension();

코드를 보면 알겠지만, sideflag는 boxshadow등등, 방향 지정이 필요한 곳에서 반복적으로 사용될것이므로 private로 선언했다.

helper 키워드 같은 경우에는, 피그마에서 토큰 값이 추가될 경우 변경되는 부분이다. 현재 우리는 저 7가지 값만을 사용중이다.

전역으로 사용 가능한 객체인 spacer를 사용하면

class DSDotTag extends StatelessWidget {
  final String label;
  final Color? backgroundColor;
  final Color? textColor;
  final TextStyle textStyle;

  const DSDotTag({
    super.key,
    required this.label,
    required this.backgroundColor,
    required this.textColor,
    required this.textStyle,
  });

  @override
  Widget build(BuildContext context) {
    return Card(
      elevation: 0,
      color: backgroundColor,
      shape: RoundedRectangleBorder(
        borderRadius: borderRadiusWidget.px_6,
      ),
      child: Padding(
        padding: spacer.top.px_4 + spacer.bottom.px_4 + spacer.left.px_8 + spacer.right.px_6,
        child: Row(
          mainAxisSize: MainAxisSize.min,
          children: [
            Icon(
              size: 4,
              Icons.circle,
              color: textColor,
            ),
            sizedBox.horizontal.px_4,
            Text(
              label,
              style: textStyle.copyWith(color: textColor),
            ),
          ],
        ),
      ),
    );
  }
}

이 예시처럼

요런 식으로..

        padding: spacer.top.px_4 + spacer.bottom.px_4 + spacer.left.px_8 + spacer.right.px_6,

spacer를 불러와 어느 위젯에서든 자유자재로 지정이 가능하다.

회사 디자인 시스템의 uikit를 flutter로 구현하면서,

구체적인 하드코딩 값을 사용하지 않는 위젯 코드를 끊임없이 연구중이다.

앞으로도 자주 구체적인 사례를 공유하러 와야지..

끗!

Retrofit API Test

이도일 — Wed, 3 Jan 2024 10:55:34 +0900

대부분 restful API를 사용하는 안드로이드 네이티브 개발자들이라면

Retrofit을 쉽게 사용할것이다.

구현 자체는 어렵지 않으나… API 개발은 프로젝트에서 독립적인 영역이고,

때문에 시간이 지남에 따라 API의 변경이라든지, 구조의 변경..뭐 이런게 있을 수 있다.

변경 정도면 양반이고….API가 없는 상태에서 개발을 시작하게 되는 경우도 드물지 않다……

이 말은 즉슨, mock test가 필수적이라는것

MockWebServer

전제 조건

Retrofit 기반이므로 미리 준비되어 있어야 한다

req /response 객체 있어야 한다

단위 테스트의 기본을 이해해야 한다

구현 방법

dependency 추가

testImplementation ("com.squareup.okhttp3:mockwebserver: 4.11 . 0 ")

API interface 준비

interface FeedbackApi {

    @GET("feedback/user/get/?")
    suspend fun getFeedbackQuestions(
        @Query("uid") userId: String,
        @Query("fid") featureId: String
    ): FeedbackQuesDTO
}

API에 해당하는 테스트 클래스 만들기
1. tip ; 이 인터페이스를 클래스로 변경한 다음 ALT+INSERT -> 테스트 -> 테스트 클래스 생성을 누른 다음 다시 인터페이스로 되돌리면 됨

테스트 클래스에 mock server의 인스턴스, 인터페이스 준비

class  FeedbackApiTest { 
    private  lateinit  var server: MockWebServer 
    private  lateinit  var api: FeedbackApi 

    @BeforeEach //JUnit5 사용 
    fun  beforeEach () { 
        server = MockWebServer() 
        api = Retrofit.Builder() 
            .baseUrl(server. url( "/" )) //이와 같은 기본 URL을 전달
             . .addConverterFactory(GsonConverterFactory.create()) 
            .build().create(FeedbackApi:: class .java) 
    } 
}

memory leak 을 방지하기 위해 서버 종료도 잊지말기

@AfterEach 
    fun  afterEach () { 
        server.shutdown() 
    }

테스트 코드 예시

@Test 
    fun `getFeedbackQuestions, presents Success` () = runTest { 
        val dto = FeedbackQuesDTO() //응답으로 돌려주고 싶은 객체 
        private  val gson: Gson = GsonBuilder().create() 
        val json = gson.toJson(dto )!! //GSON을 사용하여 객체를 json 문자열로 변환 
        val res = MockResponse() //서버 호출
         res.setBody(json) //fake response의 body를 json string으로 변환
         server.enqueue(res) //서버 응답 큐에 추가 

        val  data = api.getFeedbackQuestions( "" , "" ) // fake call
         server.takeRequest () //서버가 요청을 받도록

         .assertEquals( data , dto) //호출 응답으로 얻는 데이터는 동일해야함
     . }

wrapper사용하는 경우

@Test 
    fun `getFeedbackQuestions, presents Success` () = runTest { 
        val res = MockResponse() //서버 호출에 대한 가짜 응답 만들기
         res.setBody( "[]" ) // 응답으로 예상되는 json 문자열
         server.enqueue(res) //서버 응답 큐에 추가 

        val  data = api.getFeedbackQuestions( "" , "" ) //가짜 서버를 호출
         server.takeRequest() //서버가 요청을 받도록

         AssertEquals( data .body()!!.isEmpty(), true ) //호출 응답으로 얻는 데이터는 동일해야함
     }

응답코드 설정해서 test하는 경우

fun `getFeedbackQuestions, returns Error`() = runTest {
        //서버가 응답을 받을 수 있도록 준비
        val res = MockResponse()
        res.setResponseCode(404)
        server.enqueue(res)

        //호출 생성
        val repo = FeedbackRepoImpl(api, mockk())
        val data = repo.getFeedbackQuestions("", "")

        //서버에 생성된 호출을 수락하도록 지시
        server.takeRequest()

        assert(data is MyResponseState.Error)//응답코드 400이므로 RepoImpl을 사용하여 MyResponseState.Error를 보냄
    }

Uploaded by N2T

메모리 누수를 해결하는 조금 더 자세한 방법

이도일 — Wed, 3 Jan 2024 10:55:31 +0900

이전에 관련된 글을 작성한 적 있으므로,

중복된 항목에 대해서 이유를 자세하게 적지는 않겠다.

Inner class와 익명 class

밖의 클래스보다 inner class의 주기가 더 길면 생기는 문제

암시적 참조를 주의할것

class MyActivity : AppCompatActivity() {

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

        val button = findViewById<Button>(R.id.myButton)
        button.setOnClickListener {
            // This is an anonymous inner class
            // It holds an implicit reference to MyActivity
            // Long-running operations or delayed execution here can cause leaks
        }
    }
}

onCreate 안에서 click listener가 설정되었으므로, 저 리스너는 activity에 대해서 암시적 참조를 가지게된다.
→ 리스너의 행위는 정해진게 없으므로, 만약 리스너가 작업을 계속 진행하는 동안 activty가 삭제되거나 하면 메모리 누수가 발생함.

해결 방안

static inner class를 사용할것

weakReference를 사용할것

class MyActivity : AppCompatActivity() {

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

        MyStaticAsyncTask(this).execute()
    }

    private class MyStaticAsyncTask(activity: MyActivity) : AsyncTask<Void, Void, String>() {
        private val activityReference = WeakReference(activity)

        override fun doInBackground(vararg params: Void?): String {
            // Perform a long-running task
            return "Result"
        }

        override fun onPostExecute(result: String) {
            activityReference.get()?.let { activity ->
                // Safely update the Activity's UI
            }
        }
    }
}

Activity에 대한 weakReference를 가지고 있는게 포인트!

Handler & Runnable

마찬가지로, 스레드에서 뷰에 대한 암시적인 참조가 있을 때 문제가 됨.

딜레이가 있는 실행동안 뷰가 삭제되면 GC안될 수 있음

class  MyActivity : AppCompatActivity () { 

    private  val handler = Handler() 

    private  val updateRunnable = object : Runnable { 
        override  fun  run () { 
            // 해당 Runnable은 MyActivity에 대한 암시적 참조를 보유
            // 여기서 장기 실행 작업이나 지연 실행으로 인해 Leaks
         } 
    } 

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

        // 지연된 작업 게시
         handler.postDelayed(updateRunnable, 60000 ) // 60초 지연
     } 
}

해결 방안

static inner class 혹은 별도의 클래스 사용할 것

onDestroy()에서 알아서 주울것

class MyActivity : AppCompatActivity() {

    private val handler = Handler()
    private val updateRunnable = UpdateRunnable(this)

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

        handler.postDelayed(updateRunnable, 60000) // 60-second delay
    }

    override fun onDestroy() {
        super.onDestroy()
        handler.removeCallbacks(updateRunnable) // Remove pending callbacks
    }

    private class UpdateRunnable(activity: MyActivity) : Runnable {
        private val weakActivity = WeakReference(activity)

        override fun run() {
            weakActivity.get()?.let {
                // Perform actions without risking a memory leak
            }
        }
    }
}

마찬가지로 weakReference를 가지고 있는게 포인트~

추가로, destroy 시점에 적절하게 callback을 삭제해줌

익명 listener

리스너가 뷰 내부에 선언되면서 암시적인 참조를 보유하게 될 때 생기는 문제

1번 예시가 곧 예제가 됨

해결 방안

리스너에서 장기적으로 실행되는 작업이 없도록 방지할 것

마찬가지로 WeakReference를 사용할것!

static 중첩 클래스나 람다를 활용할 것 → 약한 참조를 가능하게 해줌!

class MyActivity : AppCompatActivity() {

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

        val button = findViewById<Button>(R.id.myButton)
        button.setOnClickListener { view ->
            // Lambda expression for click listener
            // Handle click event without risking a memory leak
        }
    }
}

static view / context

정적인 필드가 뷰에 대한 참조를 보유할 때 발생함..

컨텍스트가 사용되지 않더라도 GC가 메모리를 회수하는것을 방지하게됨

class  MyActivity : AppCompatActivity () { 

    companion  object { 
        // 뷰에 대한 정적 참조 
        var staticView: View? = null
     } 

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

        staticView = findViewById(R.id.myView) // 정적 필드에 뷰 할당
     } 
}

companion object는 인스턴스가 아닌 속한 클래스에 연결됨

위의 object는 activity가 삭제 된 후에도 참조를 유지함

해결 방안

static한 친구에게 view의 참조를 넘기지말것…
1. 뭔가 데이터 및 상태를 유지해야 하는 상황이라면
  1. → viewmodel / savedInstanceState를 사용할것!

LiveData의 부적절한 사용

LiveData의 수명 주기가 소유자보다 오래 지속되는 경우 발생

class  MyActivity : AppCompatActivity () { 

    private  val viewModel: MyViewModel by viewModels() 

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

        // 부적절한 관찰
         viewModel.myLiveData.observe( this , Observer { data -> 
            // UI 업데이트 - 올바르게 처리되지 않으면 메모리 누수가 발생할 수 있습니다.
         }) 
    } 
}

해결 방안

viewLifeCycleOwner 사용

destroy에서 적절하게 옵저버 제거

class  MyFragment : Fragment () { 

    private  val viewModel: MyViewModel by viewModels() 

    override  fun  onViewCreated (view: View , saveInstanceState: Bundle ?) { 
        super .onViewCreated(view, selectedInstanceState) 

        viewModel.myLiveData.observe(viewLifecycleOwner, Observer { data - > 
            // UI 업데이트 - viewLifecycleOwner로 올바르게 관찰
         }) 
    } 
}

Context 가 있는 Singleton

당연히 안됨..

singleton은 전체 생애주기 중 단 하나만 존재하도록 설계됨
→ 당연히 context가 있음 안된ㄷ ㅏ!

class MySingleton private constructor(context: Context) {
    init {
        // Initialization code that uses the context
    }

    companion object {
        private var instance: MySingleton? = null

        fun getInstance(context: Context): MySingleton {
            if (instance == null) {
                instance = MySingleton(context)
            }
            return instance!!
        }
    }
}

해결방안

굳이 context가 필요하다면 application context를 사용하자

class MySingleton private constructor(context: Context) {
    init {
        // Use the application context to avoid memory leaks
        val applicationContext = context.applicationContext
    }

    companion object {
        private var instance: MySingleton? = null

        fun getInstance(context: Context): MySingleton {
            if (instance == null) {
                instance = MySingleton(context.applicationContext)
            }
            return instance!!
        }
    }
}

가능하다면 그냥 쓰지말자

비트맵

고해상도 이미지를 처리 할 때 해당 부분이 문제가 될 수 있음
- OutOfMemoryError가 발생 할 수 있음(처리 과정 중에)

명시적으로 재활용하지 않을 경우 메모리가 해제되지 않아 문제가 있을 수 있음

class MyActivity : AppCompatActivity() {

    private var myBitmap: Bitmap? = null

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

        val imageView = findViewById<ImageView>(R.id.myImageView)
        myBitmap = BitmapFactory.decodeResource(resources, R.drawable.large_image)
        imageView.setImageBitmap(myBitmap)
    }
}

해결방안

적절한 사이즈의 비트맵을 사용할 것. (표시에 필요한 사이즈로만)

onDestroy에 recycle을 해줄것

라이브러리 사용할것 (글라이드 / 피카소 / 코일)

class MyActivity : AppCompatActivity() {

    private var myBitmap: Bitmap? = null

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

        val imageView = findViewById<ImageView>(R.id.myImageView)
        myBitmap = BitmapFactory.decodeResource(resources, R.drawable.large_image)
        // Resize bitmap as needed before setting it to ImageView
        imageView.setImageBitmap(myBitmap)
    }

    override fun onDestroy() {
        super.onDestroy()
        myBitmap?.recycle() // Recycle the bitmap
        myBitmap = null
    }
}

보면 알겠지만 recycle을 해주고있다~

웹뷰

앱 내에서 웹 콘텐츠를 처리하는 방식 때문에 문제가 생길 수 있다~

웹뷰의 주기는 속해있는 액티비티 / 프래그먼트와 다르다. 제대로 관리되지 않으면 상위 뷰의 주기가 끝났는데도 리소스를 계속 소비할 수 있다

class MyActivity : AppCompatActivity() {

    private lateinit var myWebView: WebView

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

        myWebView = findViewById(R.id.myWebView)
        myWebView.loadUrl("https://example.com")
    }
}

현재 웹뷰가 뷰의 컨텍스트를 암시적으로 참조하는 부분에서 초기화되고있음

해결 방안

적절히 해제할것 : webview.destroy()를 뷰가 해제되는 시점에 호출할 수 있게 할것

application context를 사용할 것 : 만약 컨텍스트의 참조가 필요한 상황이라면 application context를 사용할 것
1. 앱 컨텍스트가 항상 나쁜것만은 아니다!

class MyActivity : AppCompatActivity() {

    private lateinit var myWebView: WebView

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

        myWebView = findViewById(R.id.myWebView)
        myWebView.loadUrl("https://example.com")
    }

    override fun onDestroy() {
        myWebView.destroy() // Properly destroy the WebView
        super.onDestroy()
    }
}

BroadCast Receiver

얘 또한.. 참조를 보유할 수 있기때문에, 뷰가 사라지는 시점에 적절히 취소해주지 않으면 메모리에 혼백이 되어서 떠돌게된다

class  MyActivity : AppCompatActivity () { 

    private  val myReceiver = object : BroadcastReceiver() { 
        override  fun  onReceive (context: Context ?,intent: Intent ?) { 
            // 브로드캐스트 처리
         } 
    } 

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

        // 수신자 등록
         IntentFilter(Intent.ACTION_AIRPLANE_MODE_CHANGED). also { filter -> 
            registerReceiver(myReceiver, filter) 
        } 
    } 
}

해당 경우에서는 액티비티 삭제되어도 계속 참조를 보유하게 된다

해결 방안

알아서 destroy 적절히 해주기

(익명 클래스 피하기)

class  MyActivity : AppCompatActivity () { 

    private  val myReceiver = object : BroadcastReceiver() { 
        override  fun  onReceive (context: Context ?,intent: Intent ?) { 
            // 브로드캐스트 처리
         } 
    } 

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

        IntentFilter(Intent.ACTION_AIRPLANE_MODE_CHANGED). also { filter -> 
            registerReceiver(myReceiver, filter) 
        } 
    } 

    override  fun  onDestroy () { 
        super .onDestroy() 
        unregisterReceiver(myReceiver) // 수신자 등록 취소
     } 
}

RecyclerView Adapter의 event listener

어댑터나 뷰홀더가 뷰에 대한 참조를 보유할 때 발생함

class MyAdapter(private val items: List<Item>, private val context: Context) : RecyclerView.Adapter<MyAdapter.ViewHolder>() {

    class ViewHolder(view: View) : RecyclerView.ViewHolder(view) {
        val button: Button = view.findViewById(R.id.myButton)
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val view = LayoutInflater.from(context).inflate(R.layout.item_view, parent, false)
        return ViewHolder(view)
    }

    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        holder.button.setOnClickListener {
            // This listener holds a reference to 'context' which can cause a memory leak
        }
    }
}

해결 방안

어댑터에 컨텍스트 전달하지말것.
1. parent.context
1. onCreateView에서는 holder.itemview.context를 사용하세요~

리스너에 weakReference를 사용하세용

리스너를 잘 분리하세용

class MyAdapter(private val items: List<Item>) : RecyclerView.Adapter<MyAdapter.ViewHolder>() {

    class ViewHolder(view: View) : RecyclerView.ViewHolder(view) {
        val button: Button = view.findViewById(R.id.myButton)
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val view = LayoutInflater.from(parent.context).inflate(R.layout.item_view, parent, false)
        return ViewHolder(view)
    }

    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        holder.button.setOnClickListener {
            // Listener that doesn't hold a strong reference to the context
        }
    }

    override fun onViewRecycled(holder: ViewHolder) {
        holder.button.setOnClickListener(null) // Detach listener
    }
}

결론은

항상 뷰에 대한 약한 참조를 사용하자

웬만하면 context는 넘기지 말자

Uploaded by N2T

Android SSL Pinning

이도일 — Fri, 15 Dec 2023 13:53:26 +0900

Pinning

ssl 인증서에 의존하는 서비스나 사이트의 보안을 향상시키기 위한 선택적 메커니즘

피닝을 쓰면 암호화 id와 호스트를 연결할 수 이씀.

pinning은 보안 연결을 설정할때 허용할 특정 id를 클라이언트에 알려줌

SSL Pinning

호스트를 해당 인증서 또는 공개 키와 연결하는 프로세스

호스트의 인증서 / 공개키를 알게되면, 이를 해당 호스트에 pin

→ 사전에 정의된 공개키가 아니면 모두 거부!

이걸 왜 쓰나요?

ca로 인증받는 방식에서 끝나게되면,

디바이스의 루트 ca를 해킹하게 되거나, android trust store에 등록하게 되면, 중간에서 중간자 공격이 가능해짐

→ 이를 막기위함!

중간자 공격으로부터 보호할 수 있고

ca손상에 영향을 받지 않으며

민감 정보를 보호할 수 있다

SSL Pinning 유형

인증서 고정 : 서버의 인증서를 다운하여 앱에 묶음. 런타임시 앱은 서버의 인증서를 사용자가 삽입한 인증서와 비교

공개 키 고정 : 인증서의 공개 키를 검색해 코드에 문자열로 포함할 수 있음. 런타임시 앱은 인증서의 공개 키를 코드에 하드코딩된 키와 비교

안드로이드에서 신뢰할 수 있는 루트 인증서를 보는 방법은
1. 설정 열기
1. 보안 및 위치
1. 암호화 및 자격 증명
1. 신뢰할 수 있는 자격 증명

Android network 구성

가장 간단한 network_security_config.xml 구성

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set>
            <!-- Pin for the SSL/TLS certificate of example.com -->
            <pin digest="SHA-256">ReplaceWithYourPin</pin>
            <!-- Backup Pin for the SSL/TLS certificate of example.com -->
            <pin digest="SHA-256">ReplaceWithYourPin</pin>
        </pin-set>
    </domain-config>
</network-security-config>

여기서 핀 값은 X.509 SPKI의 base64로 인코딩된 다이제스트.

신뢰할 수 있는 도메인에 대한 공개 키 또는 인증서의 sha-256해시값. (base64)
- 서버의 ssl / tls인증서를 검사하여 얻거나
- ssllabs 웹사이트 를 이용하는것도 가능!

그 다음은 manifest에 해당 파일 추가

<application
    android:networkSecurityConfig="@xml/network_security_config"
    ...>
    ...
</application>

테스트!

try {
    // Create a URL object for the target server
    val mURL = URL("https://example.com/api/data")
    with(mURL.openConnection() as HttpsURLConnection) {
        requestMethod = "GET"
        // Add any necessary headers here
        println("URL: ${this.url}")
        println("Response Code: ${this.responseCode}")
        // Perform the actual connection and handle the response
        val responseCode = responseCode
        if (responseCode == HttpsURLConnection.HTTP_OK) {
            // Hooray! Connection successful - time to celebrate!
            // Now, let's process the response and show off our data handling skills!  
        } else {
            // Oops! Handle other response codes (e.g., error cases) gracefully  
            // Every superhero faces challenges - it's how we handle them that matters!
        }
    }
} catch (e: Throwable) {
    // Uh-oh! Invalid ssl pinning or some other Network errors - but fear not, we're prepared!  ️
    // Time to troubleshoot and save the day with proper error handling!
    println(e)
}

Uploaded by N2T

Android의 모듈식 접근 방식

이도일 — Fri, 15 Dec 2023 13:53:17 +0900

모듈의 종류

App Module : 메인 모듈. ui, android 구성요소, 부트스트랩 코드 포함

Feature Module : 각각 앱의 기능을 담당하는 모듈. 독립적으로 개발하고 테스트가 필요한 친구들을 이렇게 구분함

Library Module : 네트워크 계층, 데이터베이스 서비스 또는 유틸리티 클래스와 같은 재사용 가능한 구성 요소

Dynamic Feature Module(DFM) : 필요하지 않은 기능은 다운을 받지 않는 등, 선택적인 기능을 위한 동적 모듈 (ex : 앱 초기 설치 후 필요하지 않은 기능인 온보딩 모듈 등)

예시

앱 모듈:app

기능 모듈: feature_login, feature_dashboard

라이브러리 모듈: network,database

동적 기능 모듈:feature_extras

Feature 모듈 구현(로그인)

모듈 생성 :feature_login

dependencies 설정: 필요한 경우 network, database 에 설정

기능 구현: 로그인과 관련된 Kotlin 클래스, 리소스, Android 구성요소 구현

모듈간의 Communication

interface / DI를 사용해 모듈간의 통신을 함

기능 모듈 간의 직접적인 종속성을 피하기!

테스트

각 모듈의 단위 / 통합 테스트 작성

모듈간의 상호 작용을 테스트

빌드 및 실행

각 모듈은 독립적으로 컴파일 / 테스트 될 수 있음

앱 모듈은 모든 모듈을 단일 APK / AAR로 결합

장점

확장성 : 새로운 기능 추가 쉬움

유지보수 : 한 모듈 변경해도 다른 모듈은 영향 받지않음

더 빠른 빌드시간 : 변경된 모듈만 리컴파일

협업 : 여러명의 개발자가 서로 다른 모듈 동시 작업 가능

주의사항

모듈에 집중하고, 종속성 피하기

gradle / dependency는 주기적으로 업데이트하기

모듈 전반에 일관된 코딩 컨벤션을 적용하기

Example

settings.gradle

build.gradle

앱의 메인 진입점

feature_login

feature_dashboard

네트워크 서비스, 유틸 등의 모듈 위치

모든 모듈을 포함하기

include ':app', ':feature_login', ':feature_dashboard', ':core'

build.gradle (app)

feature modules + core library.

dependencies {
     implementation project(':feature_login')
     implementation project(':feature_dashboard')
     implementation project(':core')
}

build.gradle (feature_login)

dependencies {
     implementation project(':core')
     // Core module for shared functionality
     // ... other dependencies
}

LoginActivity.kt

package com.example.feature_login
import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
class LoginActivity : AppCompatActivity() {
     override fun onCreate(savedInstanceState: Bundle?) {
         super.onCreate(savedInstanceState)
         setContentView(R.layout.activity_login)
         // Login logic here
     }
}

feature_login 랑 비슷하나, dashboard features에 특정되는것~

build.gradle (core)

Retrofit, Room, etc.

dependencies {     // Shared libraries like Retrofit, Room }

NetworkService.kt

package com.example.core.network  class NetworkService {
     // Implementation of network calls
}

Uploaded by N2T

MenuProvider

이도일 — Fri, 15 Dec 2023 13:53:09 +0900

setHasOptionsMenu() , onCreateOptionsMenu(), onOptionsItemSelected() 는 Deprecated 되었다…………….

그렇다면 대체제는 무엇일까?

MenuProvider

4개의 메소드를 포함한 인터페이스이다

onCreateMenu : menu를 inflate하는 부분

onMenuItemSelected : option메뉴를 클릭할 때 발생하는 부분

onPrepareMenu : menu item을 customizing하는 부분. visibility나 menuItem의 customize를 할 수 있다

onMenuClosed : 메뉴 닫히면 발생하는 부분

MenuHost

ComponentActivity, AppCompatActivity에 implement된 인터페이스. menu provider를 사용해 추가된 메뉴들의 control 메소드를 제공함

addMenuProvider() : 3개의 케이스로 사용 가능하다

// 1. It only takes 1 parameter - [MenuProvider]

/*
* We need to manually remove the MenuProvider by calling removeMenuProvider().
* */
addMenuProvider(object : MenuProvider {
    override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
        menuInflater.inflate(R.menu.main_menu, menu)
    }
    override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
        return when (menuItem.itemId) {
            R.id.settings -> {
                true
            }
            else -> false
        }
    }
})

// 2. It takes 2 parameters - [MenuProvider, LifeCycleOwner]

/*
* Adds the given MenuProvider to the MenuHost. 
  MenuProvider will be removed once the given LifecycleOwner receives an Lifecycle.Event.ON_DESTROY event.
* */
addMenuProvider(object : MenuProvider {
    override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
        menuInflater.inflate(R.menu.main_menu, menu)
    }
    override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
        return when (menuItem.itemId) {
            R.id.settings -> {
                Toast.makeText(this@MainActivity, "Settings...", Toast.LENGTH_SHORT).show()
                true
            }
            else -> false
        }
    }
}, /*lifecycleOwner*/ this)


// 3. It takes 3 parameters - [MenuProvider, LifeCycleOwner, Lifecycle.State]

/*
* Adds a MenuProvider to the MenuHost when a given LifecycleOwner reaches a given Lifecycle.State. 
  LifecycleOwners will be removed once they reach a lower Lifecycle.State.
* */
addMenuProvider(object : MenuProvider {
    override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
        menuInflater.inflate(R.menu.main_menu, menu)
    }
    override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
        return when (menuItem.itemId) {
            R.id.settings -> {
                Toast.makeText(this@MainActivity, "Settings...", Toast.LENGTH_SHORT).show()
                true
            }
            else -> false
        }
    }
}, /*lifecycleOwner*/ this, /*Lifecycle.State*/ Lifecycle.State.RESUMED)

invalidateMenu()

removeMenuProvider()

Activity에 menu를 등록하기

addMenuProvider(object : MenuProvider {
    override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
        menuInflater.inflate(R.menu.main_menu, menu)
    }
    override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
        return when (menuItem.itemId) {
            R.id.settings -> {
                Toast.makeText(this@MainActivity, "Settings...", Toast.LENGTH_SHORT).show()
                true
            }
            else -> false
        }
    }
})

Fragment에 menu를 등록하기

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    // Add options menu to the toolbar
    requireActivity().addMenuProvider(object : MenuProvider {
        override fun onCreateMenu(menu: Menu, menuInflater: MenuInflater) {
            menuInflater.inflate(R.menu.main_menu, menu)
        }
        override fun onMenuItemSelected(menuItem: MenuItem): Boolean {
            return when (menuItem.itemId) {
                R.id.settings -> {
                    true
                }
                else -> false
            }
        }
    }, viewLifecycleOwner)
}

Uploaded by N2T

메모리 누수의 원인 10가지

이도일 — Fri, 15 Dec 2023 13:53:02 +0900

1. Non-Static Inner Classes

Kotlin의 내부 클래스는 외부 클래스에 대한 암시적 참조를 보유할 수 있음

class MyActivity : AppCompatActivity() {
     private inner class MyThread : Thread() {
         override fun run() {
             // Task
         }
     }
}

해결 방법: 내부 클래스를 정적으로 만들거나, 별도의 클래스를 사용하기. 필요한 경우 외부 클래스에 대한 약한 참조를 전달

2. Handlers and Runnables

핸들러가 외부 클래스에 대한 참조를 보유하는 경우 메모리 누수가 발생할 수 있음

class MyActivity : AppCompatActivity() {
     private val handler = Handler(Looper.getMainLooper())
     private val runnable = Runnable { /* Task */ }
     override fun onDestroy() {
         super.onDestroy()
         handler.removeCallbacks(runnable)
     }
}

해결 방법: onDestroy메서드에서 콜백을 모두 제거

3. Anonymous Listeners

리스너가 실수로 Activity나 View에 대한 참조를 보유할 수 있음

class MyActivity : AppCompatActivity() {
     override fun onCreate(savedInstanceState: Bundle?) {
         findViewById<Button>(R.id.myButton).setOnClickListener {
             // Click action
         }
     }
}

해결방법: onDestroy 메소드에서 리스너를 지우거나 정적 클래스를 사용

4. Static Views or Contexts

정적 뷰 또는 컨텍스트 참조는 메모리 누수로 이어질 수 있음

class MyActivity : AppCompatActivity() {
     companion object {
         private var staticView: View? = null
     }
     override fun onCreate(savedInstanceState: Bundle?) {
         staticView = findViewById(R.id.myView)
     }
}

해결 방법: 뷰나 컨텍스트에 대한 정적 참조를 피하고, 필요한 경우 약한 참조를 사용

5. Improper LiveData Observations

수명주기를 고려하지 않고 LiveData를 관찰함

class MyActivity : AppCompatActivity() {
     private val viewModel: MyViewModel by viewModels()
      override fun onCreate(savedInstanceState: Bundle?) {
         viewModel.myLiveData.observe(this, { data ->
             /* Update UI */
          })
     }
}

해결 방법: viewLifecycleOwnerFragments와 같은 수명 주기 인식 구성 요소를 사용하여 LiveData를 관찰

6. Singleton with Context

컨텍스트에 대한 참조를 보유하는 싱글톤은 누출을 일으킬 수 있음

object MySingleton {
     var context: Context? = null
}

해결 방법: Activity나 View컨텍스트 대신, 애플리케이션 컨텍스트를 싱글톤에 전달

7. Bitmaps

대형 비트맵을 제대로 관리하지 않으면 많은 메모리를 소비할 수 있음

class MyActivity : AppCompatActivity() {
     override fun onCreate(savedInstanceState: Bundle?) {
         val bitmap = BitmapFactory.decodeResource(resources, R.drawable.large_image)
         // Use bitmap
     }
}

해결방법: 비트맵을 신중하게 사용하고 recycle()완료되면 호출. Glide나 Picasso와 같은 이미지 로딩 라이브러리를 사용

8. WebViews

WebView는 컨텍스트에 대한 참조를 보유할 수 있음

class MyActivity : AppCompatActivity() {
     private lateinit var webView: WebView
     override fun onCreate(savedInstanceState: Bundle?) {
         webView = findViewById(R.id.myWebView)
         // Set up WebView
     }
}

해결 방법: onDestroy 메소드에서 WebView를 지우고, 가능한 경우 애플리케이션 컨텍스트를 사용

9. Broadcast Receivers

broadcast receivers등록을 취소하지 않으면 누출이 발생할 수 있음

class MyActivity : AppCompatActivity() {
     private val receiver = MyReceiver()
      override fun onStart() {
         registerReceiver(receiver, IntentFilter("SOME_ACTION"))
     }
     override fun onStop() {
         unregisterReceiver(receiver)
         super.onStop()
     }
}

해결 방법: 항상 해당 수명 주기 메서드에서 등록을 취소하기

10. Event Listeners in RecyclerView Adapters

RecyclerView 어댑터의 이벤트 리스너는 Activity 또는 Fragment에 대한 참조를 보유할 수 있음

class MyAdapter(private val items: List<Item>, private val activity: AppCompatActivity) : RecyclerView.Adapter<MyViewHolder>() {
     // Adapter implementation
}

해결 방법: 콜백에 인터페이스나 람다 함수를 사용하고, Activity나 Fragment 컨텍스트를 어댑터에 전달하지 않기.

Uploaded by N2T

Coroutine Flow BackPressure & Buffer

이도일 — Thu, 30 Nov 2023 11:01:20 +0900

BackPressure

업스트림 생산자가 다운스트림 소비자에게 스트림을 emit하는데, 소비자가 emit속도를 맞춰 방출할 수 없을 때 발생 ( 처리속도 고려 없이 emit )

메모리 사용 및 성능 문제가 발생

해결하기 위한건? → buffer

Buffer

아래와 같이 적용하면 됩니다

lifecycleScope.launch {
            flowOf("A","B","C","D","E")
                .onEach { println("Wizard emits: $it") }
                .buffer()
                .collect {
                    println("Lady collects: $it")
                    delay(2000)
                }
        }

요것이

Wizard emits A
Lady collects A
Wizard emits B
Lady collects B
Wizard emits C
Lady collects C
Wizard emits D
Lady collects D
Wizard emits E
Lady collects E

이렇게 바뀝니다

Wizard emits A
Wizard emits B
Wizard emits C
Wizard emits D
Wizard emits E
Lady collects A
Lady collects B
Lady collects C
Lady collects D
Lady collects E

효과

원래, flow를 만들고, 작업을 수행하고, emit하고, collect를 하는 전체 프로세스가 단일 코루틴에서 발생함. buffer는 단일 코루틴을 두 개로 분할함

flowOf("A","B","C","D","E")
                .onEach { println("Wizard emits: $it") } // Wizard CR
                .buffer()
                .collect {                                // Lady CR
                    println("Lady collects: $it")
                    delay(2000)
                }

둘은 연결된 채널이 존재하고, 아래와 같이, 너무 많은 데이터 스트림이 한 번에 전달되면, 다운스트림에서 이걸 소화할 수 있을 때 까지 emit을 중단함

버퍼함수 인수

버퍼 함수는 두 가지 인자를 받는다

capacity: Integer type
- 버퍼가 보유할 수 있는 최대 값 수
- 초과하면 일시 중지됨
- 불규칙한 패턴으로 데이터를 수신하는 앱을 개발하는 경우 사용~

onBufferOverflow: BufferOverflow class
- 용량을 초과하게 오는 데이터를 처리하는 로직
  1. BufferOverflow.SUSPEND(기본값) : 버퍼에 공간이 생길 때 까지, 추가 일시 중지됨
  1. BufferOverflow.DROP_OLDEST : 버퍼의 가장 오래된 문자를 삭제, 새로운 문자 허용
  1. BufferOverflow.DROP_LATEST : 버퍼의 최신 문자를 삭제하고 새 문자를 허용

Uploaded by N2T

Android 에서 TDD를 습관화하기

이도일 — Thu, 30 Nov 2023 11:01:11 +0900

TDD?

Test Driven Development

sw의 개발 전에, 테스트 사례로 제시되는 요구사항에 의존하는 개발 프로세스

가장 쉽고 빠르고, 신뢰 가능한 방법은 Red, Green, Refactor로 구성하는 방법!

테스트 라이브러리

Truth — value를 asserting하기 위한 라이브러리

Turbine — Flow에서 받은 value를 asserting하기 위한 라이브러리

Mockito — mock데이터를 위한 라이브러리

JUnit4 — java 기본 유닛 테스트 프레임워크

JUnit5 — Java 단위 테스트 프레임워크

→ 알아서 추가하시오

예제

@AndroidEntryPoint
class ContactsFragment : Fragment() {
    // Let's pretend this is a class responsible to retrieve data from API
    @Inject
    lateinit var megaApi: MegaApi

    private var _binding: FragmentContactsBinding? = null
    private val binding get() = _binding!!

    private var mAdapter: ContactsAdapter? = null

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?,
    ): View {
        _binding = FragmentContactsBinding.inflate(layoutInflater)
        binding.recyclerView.apply {
            addItemDecoration(SimpleDividerItemDecoration(requireContext()))
            layoutManager = LinearLayoutManager(requireContext())
            itemAnimator = DefaultItemAnimator()
        }
        return binding.root
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        fetchContacts()
    }

    override fun onDestroyView() {
        _binding = null
        super.onDestroyView()
    }

    private fun fetchContacts() = lifecycleScope.launch(Dispatchers.Main) {
        binding.loadingLayout.isVisible = true
        val contacts = try {
            withContext(Dispatchers.IO) { 
                megaApi.getContacts() 
            }
        } catch (e: Exception) {
            showErrorLayout()
            return
        }
        updateContactsUI(contacts)
    }

    private fun updateContactsUI(contacts: List<Contact>?) {
        when {
            contacts.isNullOrEmpty() -> showEmptyLayout()
            else -> {
                if (mAdapter == null) {
                    mAdapter = ContactsAdapter(
                        requireActivity(),
                        this,
                        contacts
                    )
                }
                
                binding.recyclerView.adapter = mAdapter
                binding.recyclerView.isVisible = true
                binding.loadingLayout.isVisible = false
                binding.emptyLayout.isVisible = false
                binding.errorLayout.isVisible = false
            }
        }
    }

    private fun showEmptyLayout() {
        binding.emptyLayout.isVisible = true
        binding.recyclerView.isVisible = false
        binding.errorLayout.isVisible = false
        binding.loadingLayout.isVisible = false
    }

    private fun showErrorLayout() {
        binding.errorLayout.isVisible = true
        binding.recyclerView.isVisible = false
        binding.emptyLayout.isVisible = false
        binding.loadingLayout.isVisible = false
    }
}

이걸로 compose 적용 + tdd 적용할 예정

필요 클래스

Contact.kt — contacts list의 각 contact에 대한 데이터 클래스

ContactsViewModel.kt— 뷰에 대한 뷰 모델

ContactsRoute.kt— Jetpack Compose의 경로, 화면, 보기

ContactsRepository.kt— 데이터를 검색하는 저장소

UIState.ktContactsScreen— 뷰 상태를 유지할 UI 상태

테스트 클래스

ContactsViewModelTest.kt— ContactsViewModel 의 테스트 클래스

ContactsScreenTest.kt— ContactsScreen 의 테스트 클래스

1단계. viewModel의 테스트 클래스 생성하기

아래와 같이 테스트 클래스를 먼저 생성해준다

class ContactsViewModelTest {}

그 다음, 테스트의 명세를 작성해준다

fun `ViewModel이 처음 로드될 때 loading indicator의 가시 상태 가 true 인지 테스트합니다.`() {}

fun ` 연락처 가져오기가 성공적으로 완료 되면 loading indicator 가시 상태가 false 인지 테스트합니다.`  ()  {}
 fun ` 연락처 가져오기가 오류를 반환할 때 loading indicator 가시 상태가 false 인지 테스트합니다  ` ()  {}

fun ` 연락처 가져오기 성공 시 연락처 데이터가 업데이트되어야 하는지 테스트 ` () {}
 fun ` 연락처 가져오기 에서 오류가 발생 하면 오류 레이아웃 가시성이 true 인지  테스트` ()  {}

2단계. AAA(Arrange, Action, Assert)

각 테스트를 3개의 섹션으로 나누기

@Test 
fun ` ViewModel이 처음 로드될 때 로드 표시기 가시성 상태 가  true 인지 테스트합니다.`  () { 
		// Arrange
    // Act
    // Assert
 }

ui상태 클래스 안만들었으면 지금 만들기

data class UIState(
    val isLoading: Boolean = false,
    val isError: Boolean = false,
    val contacts: List<Contact> = emptyList()
)

Repository도 만들기

class ContactsRepository @Inject constructor(
    private val megaApi: MegaApiAndroid
) {
    suspend fun getContacts(): List<Contact> = withContext(Dispatchers.IO) {
        megaApi.getContacts()
    }
}

연락처 데이터 받을 데이터 클래스(모델) 도 만들기

data class Contact(
    val name: String,
    val email: String,
    val phone: String
)

2.1단계 - Assert

최종 목표

2.2단계 — Act

기본적으로 결과를 달성하는 데 필요한 조치

여기에서 메서드를 호출

2.3단계 - Arrange

전제 조건

몇몇 테스트 케이스에서 viewmodel만 필요하므로 잠시 init에선 비워둠

@Test
fun `ViewModel이 처음 로드될 때 loading indicator의 가시 상태 가 true 인지 테스트합니다.`() {}    // Arrange
    
    // Act
    initTestClass()
    
    // Assert
    Truth.assertThat(state.isLoading).isTrue()
}

@Test
fun ` 연락처 가져오기가 성공적으로 완료 되면 loading indicator 가시 상태가 false 인지 테스트합니다.`  ()  {}
    // Arrange
    val contacts: List<Contact> = mock()
    whenever(contactsRepository.getContacts()).thenReturn(contacts)
    
    // Act
    initTestClass()
    
    // Assert
    Truth.assertThat(state.isLoading).isFalse()
}

@Test
 fun ` 연락처 가져오기가 오류를 반환할 때 loading indicator 가시 상태가 false 인지 테스트합니다  ` ()  {}    // Arrange
    whenever(contactsRepository.getCurrengetContactstUserContacts()).thenThrow(RuntimeException())
    // Act
    initTestClass()
    
    // Assert
    Truth.assertThat(state.isLoading).isFalse()
}

@Test
fun ` 연락처 가져오기 성공 시 연락처 데이터가 업데이트되어야 하는지 테스트 ` () {}
    // Arrange
    val contacts: List<Contact> = mock()
    whenever(contactsRepository.getContacts()).thenReturn(contacts)
    // Act
    initTestClass()
    
    // Assert
    verify(contactsRepository).getContacts()
    Truth.assertThat(state.isLoading).isFalse()
    Truth.assertThat(state.contacts).isEqualTo(contacts)
}

@Test
 fun ` 연락처 가져오기 에서 오류가 발생 하면 오류 레이아웃 가시성이 true 인지  테스트` ()  {}    // Arrange
    whenever(contactsRepository.getContacts()).thenThrow(RuntimeException())
    // Act
    initTestClass()
    
    // Assert
    Truth.assertThat(state.isError).isTrue()
}

3단계. ViewModel생성

이전 단계에서 정의한 각 테스트 케이스를 구현하고, 이를 뷰모델에 적용하자. 모든 테스트 케이스가 구현되었는지 확인하고, 결과를 추적하자.

아래는 연락처를 가져오는 테스트의 구현 부분만 비운 코드다.

@HiltViewModel
class ContactsViewModel @Inject constructor(
    private val contactsRepository: ContactsRepository
) {
    private val _uiState = MutableStateFlow(UIState())
    val uiState = _uiState.asStateFlow()

    init {
        fetchContacts()
    }

    private fun fetchContacts() = viewModelScope.launch {
        // TODO
    }

이제 테스트 클래스로 돌아가서, 컴파일이 가능한지 확인하고, 모든 테스트가 실패했는지도 확인하자.

Red / Green / Refactor중 Red가 가장 중요하다.!

코드는 아래와 같이 완성되어야한다

@OptIn(ExperimentalCoroutinesApi::class)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class ContactsViewModelTest {
    private val contactsRepository: ContactsRepository = mock()
    private lateinit var underTest: ContactsViewModel
    
    @BeforeAll
    fun init() {
        Dispatchers.setMain(UnconfinedTestDispatcher())
    }

    @AfterAll
    fun tearDown() {
        Dispatchers.resetMain()
    }

    @BeforeEach
    fun setup() {
        reset(contactsRepository)
    }
    
    private fun initTestClass() {
        underTest = ContactsViewModel(contactsRepository)
    }
    
    @Test
		fun `ViewModel이 처음 로드될 때 loading indicator의 가시 상태 가 true 인지 테스트합니다.`() {}    // Arrange
        // Arrange
        
        // Act
        initTestClass()
        
        // Assert
        underTest.uiState.test {
            val state = awaitItem()
            Truth.assertThat(state.isLoading).isTrue()
        }
    }
    
    @Test
		fun ` 연락처 가져오기가 성공적으로 완료 되면 loading indicator 가시 상태가 false 인지 테스트합니다.`  ()  {}
        // Arrange
        val contacts: List<Contact> = mock()
        whenever(contactsRepository.getContacts()).thenReturn(contacts)
        
        // Act
        initTestClass()
        
        // Assert
        underTest.uiState.test {
            awaitItem()
            val state = awaitItem()
            Truth.assertThat(state.isLoading).isFalse()
        }
    }
    
    @Test
		 fun ` 연락처 가져오기가 오류를 반환할 때 loading indicator 가시 상태가 false 인지 테스트합니다  ` ()  {}    // Arrange
        // Arrange
        whenever(contactsRepository.getContacts()).thenThrow(RuntimeException())
    
        // Act
        initTestClass()
        
        // Assert
        underTest.uiState.test {
            awaitItem()
            val state = awaitItem()
            Truth.assertThat(state.isLoading).isFalse()
        }
    }
    
    @Test
		fun ` 연락처 가져오기 성공 시 연락처 데이터가 업데이트되어야 하는지 테스트 ` () {}
        // Arrange
        val contacts: List<Contact> = mock()
        whenever(contactsRepository.getContacts()).thenReturn(contacts)
    
        // Act
        initTestClass()
        
        // Assert
        verify(contactsRepository).getContacts()
        underTest.uiState.test {
            awaitItem()
            val state = awaitItem()
            Truth.assertThat(state.isLoading).isFalse()
            Truth.assertThat(state.contacts).isEqualTo(contacts)
        }
    }
    
    @Test
	 fun ` 연락처 가져오기 에서 오류가 발생 하면 오류 레이아웃 가시성이 true 인지  테스트` ()  {}    // Arrange
        // Arrange
        whenever(contactsRepository.getContacts()).thenThrow(RuntimeException())
    
        // Act
        initTestClass()
    
        // Assert
        underTest.uiState.test {
            awaitItem()
            val state = awaitItem()
            Truth.assertThat(state.isError).isTrue()
        }
    }
}

4단계 - 테스트는 실패하고, 컴파일은 가능한지 확인(RED)

이 시점에서 컴파일은 가능해야한다. 이제 테스트를 통과하도록 만들 차례다.

loading indicator는 viewModel이 처음 로드될 때 나타나야하므로, init ViewModel부분에서 이를 true로 설정한다.

@HiltViewModel
class ContactsViewModel @Inject constructor(
    private val contactsRepository: ContactsRepository
) {
    private val _uiState = MutableStateFlow(UIState())
    val uiState = _uiState.asStateFlow()

    init {
        // test that loading indicator visibility state is true when ViewModel first load
        _uiState.update { it.copy(isLoading = true) }
        fetchContacts()
    }

    private fun fetchContacts() = viewModelScope.launch {
            // TODO
        }
    }
}

테스트 해보기

@Test 
fun `ViewModel이 처음 로드될 때 loading indicator의 가시 상태가 true 인지 테스트합니다.`() {}    // Arrange
    // 배열 
    
    // Act
     initTestClass() 
    
    // Assert
     underTest.uiState.test { 
        val state = waitItem() 
        Truth.assertThat( state.isLoading).isTrue() 
    } 
}

다음으로는, API 로드가 성공적으로 끝나면 loading indicator가 사라져야 한다는것

private  fun  fetchContacts () = viewModelScope.launch { 
    runCatching { 
        // 저장소에서 데이터 가져오기
         contactRepository.getContacts() 
    }.onSuccess { 
        // 연락처 가져오기 성공 시 로딩 표시기 가시성 상태가 false인지 테스트
         _uiState.update { 
            it.copy(isLoading = false ) 
        } 
    } 
}

테스트

@Test 
fun `ViewModel이 처음 로드될 때 loading indicator의 가시 상태가 true 인지 테스트합니다.`() {}    // Arrange
    ... 
} 

@Test 
fun ` 연락처 가져오기가 성공적으로 완료 되면 loading indicator 가시 상태가 false 인지 테스트합니다.`  ()  {}
    // 
    val 연락처 정렬 : List<Contact> = mock() 
    when(contactsRepository.getContacts()).thenReturn(contacts) 
    
    // Act
     initTestClass() 
    
    // Assert
     underTest.uiState.test { 
        waitItem() 
        val state = waitItem() 
        Truth .assertThat(state.isLoading).isFalse() 
    } 
}

API호출에서 오류가 있다면 로딩 상태 false 인지 확인

private  fun  fetchContacts () = viewModelScope.launch { 
    runCatching { 
        // 저장소에서 데이터 가져오기
         contactRepository.getContacts() 
    }.onSuccess { 
        // 연락처 가져오기에 성공하면 로드 표시기 가시성 상태가 false인지 테스트
         ... 
    }.onFailure { 
        // 연락처 가져오기 오류가 반환될 때 로드 표시기 가시성 상태가 false인지 테스트합니다.
         _uiState.update { it.copy(isLoading = false ) } 
    } 
}

테스트

  @Test
		 fun ` 연락처 가져오기가 오류를 반환할 때 loading indicator 가시 상태가 false 인지 테스트합니다  ` ()  {}    // Arrange
        // Arrange
        whenever(contactsRepository.getContacts()).thenThrow(RuntimeException())
    
        // Act
        initTestClass()
        
        // Assert
        underTest.uiState.test {
            awaitItem()
            val state = awaitItem()
            Truth.assertThat(state.isLoading).isFalse()
        }
    }

API가 제대로 오면 연락처 데이터 상태가 업데이트 되는지 확인

private  fun  fetchContacts () = viewModelScope.launch { 
    runCatching { 
        // 저장소에서 데이터 가져오기
         contactRepository.getContacts() 
    }.onSuccess { 
        // 연락처 가져오기가 성공하면 로드 표시기 가시성 상태가 false인지 테스트 
        // 연락처 데이터를 업데이트해야 하는지 테스트 연락처 가져오기 성공 시
         _uiState.update { it.copy(isLoading = false , contact = currentContacts) } 
    }.onFailure { 
        // 연락처 가져오기 오류가 반환될 때 로드 표시기 가시성 상태가 false인지 테스트
         _uiState.update { it.copy(isLoading = false) } 
    }

테스트

 
    @Test
		fun ` 연락처 가져오기 성공 시 연락처 데이터가 업데이트되어야 하는지 테스트 ` () {}
        // Arrange
        val contacts: List<Contact> = mock()
        whenever(contactsRepository.getContacts()).thenReturn(contacts)
    
        // Act
        initTestClass()
        
        // Assert
        verify(contactsRepository).getContacts()
        underTest.uiState.test {
            awaitItem()
            val state = awaitItem()
            Truth.assertThat(state.isLoading).isFalse()
            Truth.assertThat(state.contacts).isEqualTo(contacts)
        }
    }

API호출에서 오류 발생하면 오류 레이아웃의 가시성이 true 인지 확인

@HiltViewModel
class ContactsViewModel @Inject constructor(
    private val contactsRepository: ContactsRepository
) {
    private val _uiState = MutableStateFlow(UIState())
    val uiState = _uiState.asStateFlow()

    init {
        // test that loading indicator visibility state is true when ViewModel first load
         _uiState.update { it.copy(isLoading = true) }
        fetchContacts()
    }

    private fun fetchContacts() = viewModelScope.launch {
        runCatching { 
            // 저장소에서 데이터 가져오기
             contactRepository.getContacts() 
        }.onSuccess { 
            // 로딩 표시기 가시성 테스트 연락처 가져오기 성공 시 상태는 false입니다 
            . // 연락처 가져오기 성공 시 연락처 데이터가 업데이트되어야 하는지 테스트합니다.
             _uiState.update { it.copy(isLoading = false , Contacts = currentContacts) } 
        }.onFailure { 
            // 로딩 표시기 가시성 상태가 다음과 같은지 테스트합니다. 연락처 가져오기에서 오류가 반환되면 false // 연락처 가져 오기 
            에서 오류가 발생하면 오류 레이아웃 가시성이 true인지 테스트합니다.
             _uiState.update { it.copy(isLoading = false , isError = true ) } } 
        }
    }
}

테스트

@Test
 fun ` 연락처 가져오기 에서 오류가 발생 하면 오류 레이아웃 가시성이 true 인지  테스트` ()  {}    // Arrange
    whenever(contactsRepository.getContacts()).thenThrow(RuntimeException())
    // Act
    initTestClass()
    
    // Assert
    Truth.assertThat(state.isError).isTrue()
}

이제 전부 통과해야함. 하나라도 안 되면, 다음 단계로 넘어가서는 안된다!

5단계 - 리팩터링

이제 Refactoring 하면 된다~

Uploaded by N2T