일반대학원을 준비하면서 누군가에게 도움이 되고자 공유의 목적으로 작성하였습니다. 대학원을 준비하시는 분들 모두 힘내시고 화이팅입니다 !

원하는 대학원에 합격 후 후기를 써야겠다 생각하다가 이제서야 끄적끄적 써봅니다. ㅎㅎ...

1. 대학원 진학 계기

회사 사정이 어려워져 다니던 회사를 갑작스럽게 나오게 되었습니다. 임금 정산이 늦어지고 생각은 많아지고 다시 일어날 힘을 점점 잃게되었는데 마냥 손놓고 있을순 없기에 예전부터 꿈꾸었던 대학원 을 생각하게되었습니다. 갑작스럽게 대학원을 어떻게 준비해야하는가 부터 모든 과정이 우여곡절이 많을 것이라 생각하였지만 현재의 상황이 위기가 아닌 기회로 받아들이자는 마음가짐으로 새로 마인드셋을 하면서 "아무렴 뭐 어때, 이참에 대학원을 도전해보자 !" 라는 마음을 먹게 되었습니다.

로보어드바이저와 조각투자 등 금융 카테고리를 가진 스타트업에서 개발자로 일을 해보니 개발 지식 뿐 아니라 금융에 대하여 전반적인 개념과 이론을 머릿속에 집어넣어야 겠다고 생각했습니다. 그리고 직장과 병행하는 특수대학원도 고려를 안해본 것은 아니지만 더욱 더 깊이있는 학문과 연구를 하고싶은 마음에 일반대학원 진학을 하기로 결심하였습니다.

여러 대학원을 알아가는 과정속에서 정말 가고싶다고 생각이 되었던 학교과 학과는

• 성균관대학교 대학원 - 핀테크 융합전공

이였습니다. 해당 학과의 연구와 커리큘럼을 보고 처음으로 무엇인가 배워보고 연구해보고싶다는 생각이 들었습니다.

2. 준비 과정

성균관대학교 모집 요강 공식 사이트

우선, 대학원 홈페이지에 들어가서 입시 모집 요강을 보았습니다. 원서 접수는 모두 진학사 어플라이 에서 진행하였습니다.

원서 접수에서 입학원서와 학업계획서를 작성하여 제출하는데 처음 작성해본 학업계획서여서 막막하였습니다. 작성해야할 목록은 아래와 같습니다.

• 자신의 학문적 지향 ( 2800 Byte )
• 진학동기 및 목표 ( 2800 Byte )
• 미래의 연구계획 ( 2800 Byte )
• 기타 ( 2800 Byte )

저같은 경우에는 개발자로써 어려움을 해결한 경험과 계획,연구,성과 순으로 경험을 작성하였습니다. 지나고나서 돌이켜보니 학업계획서에는 정답이 없고 개인의 주관과 지원 동기가 확실히만 어필된다면 완벽 한 것 같습니다. 저는 망했어요..ㅎㅎ..

모든 작성을 완료 후 원서 접수 마감일 하루전 무사히 마쳤습니다. 다음날, 성균관 대학교에 방문하여 서류 제출도 무사히 마쳤고 간김에 학교 구경도 한번 해보았습니다.

이외의 추가 서류

• 학사 졸업증명서
• 학사 성적증명서
• 공인어학시험 (최근 2년내) 학과마다 추가의 서류가 있으므로 모집 요강 확인 필수!!

• 성균관대학교 대학원 2025 전기 모집 요강

3. 대학원 면접

일부 학과를 제외한 나머지 학과들은 전부 대면 면접으로 진행되었습니다. 이전에 서류 제출을 하기 위하여 학교를 방문하였을때 이곳저곳 돌아다니면서 동선을 미리 파악해두었던 것이 도움이 되었습니다.

저의 경우 면접 일정은 아래와 같았어요.

10월 26일 (토) AM 10시

면접지원자의 경우 모두 AM 9시 30분 까지 면접 대기실에 입장하여 대기요망

아슬아슬하게 도착하는것 보단 커피를 사서 여유롭게 가는게 좋은 것 같습니다. 화장실도 가고 학교도 둘러볼겸 9시 도착으로 계획하고 진행 하였습니다. 물론, 복장은 정장을 입고 갔습니다. 대학원 면접에 무슨 정장이냐 하시는 분들도 계신데 저는 아무래도 깔끔하고 단정하게 보이고 싶어서 정장을 입었습니다. 대기실에 도착하니 저보다 빨리 오신 분들이 5명 정도 있었습니다. 추후, 10시정도가 되었을땐 어림잡아 30~40명 정도 계셨습니다. 저의 경우 순번이 마지막 조에 편성되어서 하염없이 대기실에서 기다려야했습니다 ㅠ.. 면접 대기실에서 대략 1시간 정도 대기하였으며, 대기 시간 동안 준비해온 자기소개와 지원 동기 , 학업 계획에 대하여 암기를 진행하였습니다. 프린트물로 준비해오셔서 외우시는 분도 계셨고 휴대폰에 적어 외우시는분들도 적지 않게 보았습니다.

4. 면접 후

면접은 면접관 2 / 지원자 3 의 형태로 진행되었습니다. 1명씩 돌아가면서 자기소개와 지원동기를 포함하여 30초 ~ 1분 내외로 자기소개를 하였고 각각 개별 질문은 2~3가지의 내용으로 진행되었습니다. 긴장을 많이 풀어주시려고 하셨으며 편안한 분위기에서 진행되었습니다. 면접 대기실에 있을때 까지만 해도 긴장이 전혀 안되고 떨림이란게 안느껴졌었는데 면접 대기실을 떠나 면접 장소 문을 여는 순간 심장이 터지는줄 알았습니다. 긴장을 엄청 하였지만 그래도 준비한 만큼, 간절한 만큼 후회없이 보고 돌아오자 마음을 먹고 자신감과 패기로 답변을 하였습니다. 마지막에 할말이 있냐는 질문에는 사실 아무말도 못하고 나오긴 하였지만요.. 그래도 속은 후련했습니다.

5. 대학원 결과

합격자 발표일 : 11월 7일(목) 17:00

면접 이후 약 2주 뒤에 결과 발표를 하였습니다. 운동도 하고 공부도 하며 생각보다 시간이 빠르게 흘러가는 것을 느끼며 노트북과 휴대폰을 챙겨 카페로 갔습니다. 사실 집에서 결과 확인을 해도 괜찮았는데 커피가 너무 마시고 싶어서 카페로 갔어요.. ㅎㅎ.. 결과 발표 당일날 발표시간이 17:00 라는게 조금 신경쓰이고 "시간이 정말 안간다." 라고 느꼈지만 긴장감을 가지며 하염없이 기다렸습니다. 시간이 흘러 17:00가 되었고 휴대폰으로 문자가 왔습니다. > 결과 발표가 나왔으니 홈페이지에서 확인해보세요

합격자 조회 홈페이지에서 이름과 수험번호를 입력하여 확인해보았습니다.

결과는....

...합격....?!?!?!?!?

사실 합격 글자와 저 화면을 보았을때 카페에서 소리질렀습니다 " ㅠㅠㅠ노력한 보람이 있구나! " 갑작스럽게 회사를 나오게 되어 부랴부랴 대학원 진학에 대하여 막연히 생각만 했었고 현실적으로 여러가지 고민과 더불어 할 수 있을까? 란 의구심이 항상 들어 마음이 불안안 상태로 꽤 오랜 시간 지내왔는데 한방에 다 녹아서 없어지는 느낌이 들었습니다. 잠도 안자며 노력한 결과에 대한 보상을 받은 기분이라 성취감이 너무 대단했습니다. 일단 하면 된다..! 를 너무 깨닫게 되었던 시간이였습니다. 혹시나 대학원을 준비하시는 분들이나 고민중이신 분들이라면 주저하지 말고 도전해보시는걸 권해드리고 싶습니다. 왜냐하면 저같은 쫌쫌따리 개발자도 되었으니까요 !

사용 케이스

• 이벤트 리스너를 등록하고 제거할 때
• 애니메이션을 시작하고 정지 할 때
• 카메라와 LocationManager와 같이 센서 리소스를 바인딩 또는 언바인딩 할 때
• DB 연결을 관리 할 때

LaunchedEffect

사용 케이스

• 네트워크로부터 데이터를 가져 올 때
• 이미지 프로세싱을 수행 할 때
• DB를 업데이트 할 때

SideEffect

사용 케이스

• 로깅 및 분석을 위한 코드를 사용 할 때
• 블루투스 장치에 연결을 하기 위하여 한번 초기화를 진행 할 때
• 파일로부터 데이터를 최초 한번 로딩 할 때
• 라이브러리를 초기화 할 때

결론

SideEffect, DisposableEffect , LaunchedEffect 의 주요 차이점 요약

• SideEffect 은 상위 컴포저블이 재구성 될 때 실행되며 컴포저블의 상태나 속성에 의존하지 않는 작업을 실행하는데 유용
• DisposableEffect 는 상위 컴포저블이 처음 렌더링 될 때 실행되며 컴포저블이 더 이상 사용되지 않을 때 정리가 필요한 리소스를 관리하는 데 유용합니다. 첫 번째 컴포지션 또는 키가 변경 될 때 트리거 되며 종료 시 onDispose() 메소드를 호출합니다.
• LaunchedEffect 는 별도의 코루틴 스코프에서 부수효과를 실행하며 UI 쓰레드를 차단하지 않고 시간이 오래 걸리는 작업을 실행하는 데 유용합니다. 첫 번째 컴포지션이나 키가 변경 시 트리거 됩니다.

Flutter 개발 환경 셋팅 및 초기 가이드

1. Flutter SDK 다운로드

https://docs.flutter.dev/release/archive?tab=windows

노트북 스펙 : MacBook Pro Apple M1

24.08.05 기준 최신 버전 arm 64 다운로드를 진행

2. 환경 변수 설정

$ open ~/.zshrc 또는 
$ open ~/.bash_profile

#Flutter
export PATH="$PATH:/Users/${본인 Flutter SDK 경로}"

-> 예시: export PATH="$PATH:/Users/kkjang/flutter/bin"

환경변수 입력 완료 후 저장하고 닫기

$ source ~/.zshrc 또는
$ source ~/.bash_profile

3. flutter doctor

> $ flutter doctor 실행

**[v] 이미 Flutter 를 실행하기에 조건 충분합니다. **

[x] Android Studio 에러 Android Studio 설치안한 것이므로 Android Studio 설치 !

[x] Android license status unknown 에러 그 밑에 나오는 flutter doctor --android-licenses 이걸 터미널에 입력하고 모두 동의하면 끝 !

[x] cmdline-tools component is missing 에러 위에서 Android Studio 에서 SDK Manager 설치 과정중 일부 설치가 누락된 것입니다.

**[x] Chrome 에러 ** 크롬 브라우저가 없으므로 크롬을 설치해주세요.

[x] xcode, cocoapods 에러 iOS 개발에 필요한 것이며, xcode 및 cocoapds 설치를 진행해야합니다.

4. Android Studio 셋팅

다른 IDE를 사용하고 싶어도 일단 Android Studio 셋팅은 해놓고 다른 에디터 사용해야 합니다.

1. flutter 검색
2. flutter Install

3. SDK Tools
4. Android SDK Command-line Tools (lastest) 체크
5. Apply -> Ok

5. Xcode , Cocoapods Install

1. AppStore - Xcode Install
2. 아래 명령어 순서대로 입력

$ sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
$ sudo xcodebuild -runFirstLaunch

3. 완료 후 Xocde License 에 서명을 진행

$ sudo xcodebuild -license

4. Space 를 눌러 단락 이동을 한다. ( 최하단으로 이동 )

By typing 'agree' you are agreeing to the terms of the software license agreements. Type 'print' to print them or anything else to cancel, [agree, print, cancel]

5. 위와 같은 메시지 출력시 agree 를 입력 후 Enter !
6. cocoapods Install

$ sudo gem install cocoapods

6. Flutter App Init

Flutter Tutorial App 만들기 종료 !

참고 & Docs https://docs.flutter.dev/release/archive?tab=windows https://codingapple.com/unit/flutter-install-on-windows-and-mac/

1. Commit Message Structure

• 기본적인 커밋 메시지 구조 (각 파트는 빈줄로 구분한다.)

제목 (Type: Subject) (한줄 띄어 분리) 본문 (Body) (한줄 띄어 분리)

2. Commit Type

• 커밋의 타입 구성

태그: 제목 :(space)제목 으로 :뒤에만 space를 넣는다.

추가적인 문맥 정보를 제공하기 위한 목적으로 괄호 안에 적을 수도 있다.

ex)
 Feat(navigation)
 Fix(db)

3. Subject

• 제목은 50글자 이내로 작성한다.
• 첫글자는 대문자로 작성한다.
• 마침표 및 특수기호는 사용하지 않는다.
• 영문으로 작성하는 경우 동사(원형)을 가장 앞에 명령어로 작성한다.
• 과거시제는 사용하지 않는다.
• 간결하고 요점적으로 즉, 개조식 구문으로 작성한다.

ex)
Fixed --> Fix
Added --> Add
Modified --> Modify

4. Body

• 72이내로 작성한다.
• 최대한 상세히 작성한다. (코드 변경의 이유를 명확히 작성할수록 좋다)
• 어떻게 변경했는지보다 무엇을, 왜 변경했는지 작성한다.

5. Footer

• 선택사항

• issue tracker ID 명시하고 싶은 경우에 작성한다.

• 유형: #이슈 번호 형식으로 작성한다.

• 여러 개의 이슈번호는 쉼표(,)로 구분한다.

• 이슈 트래커 유형은 다음 중 하나를 사용한다. Fixes: 이슈 수정중 (아직 해결되지 않은 경우) Resolves: 이슈를 해결했을 때 사용 Ref: 참고할 이슈가 있을 때 사용 Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)

ex) 
Fixes: #45 Related to: #34, #23

6. Example

예시 1

Feat: 회원 가입 기능 구현

SMS, 이메일 중복확인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

예시 2

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

그 외 자주 쓰이는

Fix : 버그 수정
  Fix my test
  Fix typo in style.css
  Fix my test to return undefined
  Fix error when using my function

  Update : Fix와 달리 원래 정상적으로 동작했지만 보완의 개념
  Update harry-server.js to use HTTPS

  Add
  Add documentation for the defaultPort option
  Add example for setting Vary: Accept-Encoding header in zlib.md

  Remove(Clean이나 Eliminate) : ‘unnecessary’, ‘useless’, ‘unneeded’, ‘unused’, ‘duplicated’가 붙는 경우가 많음
  Remove fallback cache
  Remove unnecessary italics from child_process.md

  Refactor : 리팩토링

  Simplify : Refactor와 유사하지만 약한 수정, 코드 단순화

  Improve : 호환성, 테스트 커버리지, 성능, 검증 기능, 접근성 등의 향상
  Improve iOS's accessibilityLabel performance by up to 20%

  Implement : 코드 추가보다 큰 단위의 구현
  Implement bundle sync status

  Correct : 주로 문법의 오류나 타입의 변경, 이름 변경 등에 사용
  Correct grammatical error in BUILDING.md

  Prevent
  Prevent hello handler from saying Hi in hi.js

  Avoid : Prevent는 못하게 막지만, Avoid는 회피(if 등)
  Avoid flusing uninitialized traces

  Move : 코드나 파일의 이동
  Move function from header to source file

  Rename : 이름 변경
  Rename node-report to report

7. Commit Message Emoji (gitmoji)

하지만 Dagger2에서 Hilt로 마이그레이션을 하거나 특별한 사유가 있는 경우 모든 모듈 클래스에 @InstallIn을 추가하기 어려운 경우가 있다. 이때 다음 예제코드 처럼, 해당 모듈의 그레이들 스크립트에 disableModulesHaveInstallInCheck 옵션을 추가 할 수 있다.

// build.gradle.kts
android {
    ...
    defaultConfig {
    ...                  
    javaCompileOptions.annotationProcessorOptions.arguments["dagger.hilt.disableModulesHaveInstallInCheck"] = "true"
    }
}

gradle 명령어를 사용하여 컴파일(빌드)하는 경우에는 다음과 같이 플래그를 추가 할 수 있다.

-Adagger.hilt.disableModulesHaveInstallInCheck=true.

또는

개별적으로 모듈 클래스에 @DisableInstallInCheck 를 추가하여 @InstallIn 검사를 비활성화 시킬 수 있다.

코틀린에는 invoke라는 특별한 함수, 정확히는 연산자가 존재한다. invoke연산자는 이름 없이 호출될 수 있다. 이름 없이 호출된 다는 의미를 파악하기 위해 아래의 코드를 보자.

object MyFunction {
    operator fun invoke(str: String): String {
        return str.toUpperCase() // 모두 대문자로 바꿔줌
    }
}

MyFunction이라는 오브젝트 하나가 있다. obeject키워드로 만들었기 때문에 MyFunction은 하나의 객체처럼 사용될 수 있다. 즉, 하나의 객체이기 때문에 객체 안의 메서드를 호출하기 위해서 아래와 같이 호출하고 싶을 것이다.

MyFunction.invoke("hello") // HELLO 물론 잘 동작하지만, kotlin에서 invoke라는 이름으로 만들어진 함수는 특별한 힘을 갖는다. 이름 없이 실행될 수 있는 힘이다. 즉, 아래와 같이 호출이 가능하다.

MyFunction("hello") // HELLO MyFunction은 객체다. 그렇기 때문에 MyFunction을 print해보면 MyFunction의 주소값만 출력될 뿐이다. 그런데 MyFunction안에 invoke()함수가 정의 되어있으므로 MyFunction에서 메서드 이름 없이 바로 호출한 것이다. 물론 파라미터를 받을 창구가 있어야 하므로 ()안에 파라미터를 넣어서 실행이 가능하다.

연산자 이렇듯 분명히 invoke와 같이 이름을 부여한 함수임에도 불구하고 실행을 간편하게 할 수 있게 하는 것들을 연산자라고 부른다. 그런 연산자들 몇 개를 코틀린에서 미리 정해놓았다. 대표적으로 + 연산자가 있다. 간단히 예제 하나를 보면서 연산자가 무엇인지 알고 다음으로 넘어가자.

object Sample {
    operator fun plus(str: String):String {
        return this.toString() + str
    }
}

main() {
    Sample + " Hello~!" // [Sample의 주소값] Hello~!
}

실행해보면 [Smaple의 주소값]부분에는 실제로 주소값이 들어가고, 그 뒤에 바로 Hello~!라는 글자가 붙을 것이다. 즉 plus라는 이름으로 함수를 만들었지만 plus는 코틀린에서 연산자로 정의해 놓았으므로 plus연산자를 호출하기 위해 틀별히 + 기호를 사용해서 호출한다.

람다는 invoke 함수를 가진 객체다. 코틀린은 람다를 지원한다. 예를 들어 아래와 같은 람다 함수가 있다고 하자. 이미 코틀린이 기본으로 제공하는 함수를 한 번 감싸는 의미 없는 코드이지만 이해를 위해 작성해보았다.

val toUpperCase = { str: String -> str.toUpperCase() } 모든 값, 또는 값을 담는 변수에는 타입이 있다. Int일 수도, String일 수도, 또는 우리가 만든 클래스 타입일 수도 있다. 그렇다면 위의 toUpperCase는 타입이 무엇일까? Int도, String도 아니다. String을 받고, 다시 String을 반환하는 (String) -> String 타입이다.

그러나 (String) - String은 좀 생소하다. 더 정확히 어떤 걸 의미하는 것일까? 사실 위 타입은 코틀린 표준 라이브러리에 정의된 Function1<P1, R>인터페이스 타입이다. Function<P1, R>의 구현을 살펴보면 invoke(P1) : R 연산자 하나만 달랑 존재한다. 위에서 언급했듯이 invoke연산자는 이름 없이 호출할 수 있다. 이름 없는 함수인 람다와 연관성이 조금 보인다.

결국 위에서 작성한 toUpperCase는 아래 코드와 같다.

val toUpperCase = object : Function1<String, String> {
    override fun invoke(p1: String): String {
        return p1.toUpperCase()
    }
}

실제로 코틀린에서 작성한 람다는 위의 코드와 같기 때문에 결국 람다도 컴파일 시간에 람다가 할당된 객체로 변환된다는 뜻이다. 개발자는 그것의 invoke를 호출하는 셈이다.

toUpperCase는 현재 invoke라는 연산자 하나를 가진 객체이다. 이제 위에서 언급 알아본대로 toUpperCase.invoke("hello")가 아닌 toUpperCase("hello")와 같이 호출할 수 있음을 기억한 채로 toUpperCase를 사용해 보자.

fun main() {
    val strList = listOf("a","b","c")
    println(strList.map(toUpperCase)) // [A,B,C]
}

map함수는 strList의 요소들을 순회하면서 각각의 요소(a,b,c)마다 toUpperCase(요소)를 실행할 것이다. toUpperCase가 invoke연산자를 가지고 있기 때문에 이렇게 편하게 사용 가능한 것이다. 또한 위의 코드는 아래와 같이 작성할 수 있다.

fun main() {
    val strList = listOf("a","b","c")
    println(strList.map {str: String -> str.toUpperCase()}) // [A,B,C]
}

{str: String -> str.toUpperCase()} 이 부분이 결국 런타임 시 invoke를 하나 가지는 오브젝트로 변환된다.

Enum Class

특징

• 상수 집합: Enum 클래스는 미리 정의된 상수 집합을 나타낼 때 유용합니다.
• 단순성: 정의가 단순하고 직관적입니다.
• 일반적인 사용: 열거형 상수 간에 비교하거나 특정 상수에 대한 작업을 수행할 때 적합합니다.
• 상수 메서드: Enum 상수 각각에 메서드를 정의할 수 있습니다.

사용 시점

상수 값들의 집합이 고정된 경우 (예: 요일, 방향, 상태 등). 간단한 상태나 값을 나타내야 할 때. 각 상수가 동일한 메서드나 속성을 가져야 할 때.

예제

enum class Direction {
    NORTH, SOUTH, EAST, WEST
}

Sealed Class

특징

• 계층 구조: 서브 클래스들이 정의될 수 있으며, 이들 서브 클래스는 모두 같은 파일 내에 정의되어야 합니다.
• 확장성: 더 복잡한 데이터 구조나 상태를 표현할 수 있습니다.
• 패턴 매칭: when 절에서 사용할 때 모든 가능한 하위 클래스들을 체크하므로 안전성이 높습니다.
• 불변성: 불변 데이터를 나타내는 데 유용합니다.

사용 시점

데이터의 서브 타입을 나타내고 싶을 때 (예: 다양한 종류의 결과 값, 이벤트 등). 각 상태나 데이터 타입에 대해 다른 속성이나 메서드를 가질 때. 더 복잡한 데이터 모델을 필요로 할 때.

예제

kotlin
sealed class Result {
    data class Success(val data: String) : Result()
    data class Error(val exception: Exception) : Result()
    object Loading : Result()
}

결론

Enum Class는 미리 정의된 상수 값들의 집합을 표현하는 데 적합합니다. _Sealed Class_는 더 복잡한 데이터 구조나 계층을 표현하고, 패턴 매칭을 안전하게 수행하는 데 유리합니다. 따라서, 상황에 따라 두 가지 중 적합한 것을 선택하면 됩니다. 간단한 상수 집합이라면 Enum Class를, 복잡한 데이터 구조와 패턴 매칭이 필요하다면 Sealed Class를 사용하는 것이 좋습니다.

토이프로젝트를 진행중 빌드 후 문제가 발생하였습니다

에러의 내용을 살펴보면

PendingIntent_를 생성할 때 FLAG_IMMUTABLE 또는 FLAG_MUTABLE 중 하나를 명시적으로 지정해야 합니다. 일반적으로는 FLAG_IMMUTABLE을 사용하는 것이 **_권장** 되며, PendingIntent가 변경 가능해야 하는 경우 (예: 인라인 답장이나 버블과 같이 사용해야 하는 경우)에만 FLAG_MUTABLE을 사용합니다.

라고 하는데 프로젝트에는 눈씻고 찾아봐도 pendingIntent 를 사용한 곳이 없습니다.

당연하죠, pendingIntent 를 사용 안했으니까요..

..? 그럼 뭐때문에 저 에러를 내면서 앱이 죽은거에요..? ㅇㅁㄴㅇㅁㄴㅇㅁㄴㅁ

해결과정

자료를 찾아보던 중 androidx.work 라이브러리의 버전이 낮으면 같이 이슈가 발생할 수 도 있다고 나와 있습니다.. ㅎㅎ! 버전을 아무거나 찾아서 넣어 빌드해보니 실패..!

그렇기에 설마 하며 최신 버전의 라이브러리를 implements를 해주니 정상작동하는걸 확인했습니다. 해결 ~!

기존 방식

• 테스트 진행시 구두 OR 슬랙으로 공지 및 전달사항 공유
• 테스트 진행
  • USB 연결 후 빌드 → 테스트 진행 → 수정 → USB 연결 후 빌드 반복
  • PlayStore 내부 테스트를 이용하여 실제 배포와 동일하게 진행 → 스토어 반영 시간 (1~2시간) → 다운로드 → 테스트 진행
• 테스트 완료 후 안드로이드 스튜디오 빌드 진행 → .apk / .aab 테스트폰에 각각 설치 후 최종 테스트
• .aab(bundle) 파일을 가지고 스토어에 직접 수기로 심사 및 배포 진행
  • .aab 파일이 이전버전이 아닌지 확인 해야하며, 관리 차원에서 휴먼 에러가 발생할 수 있다.

1. 테스트앱을 제공하는데 너무 많은 시간이 걸린다.

개발이 완료되면 앱을 빌드한뒤 업로드해야합니다. 우선 PlayStore에 2차 인증을 거친 로그인을 해야하고 , 적당한 릴리즈노트와 함께 앱을 업로드하면, 앱파일을 첨부하는데 일정 시간을 소요한뒤에 앱을 제출할 수 있습니다. 업로드가 완료되면 바로 제공되는 것도 아닙니다. 약 30분의 '출시준비중' 단계를 대기한 후에 테스터들에게 앱이 제공됩니다.

2. 앱이 제공되고나면 QA엔지니어에게 직접 알려야한다.

• 앱이 제공되고나면 QA엔지니어에겐 누가 알려줄까요?
  • 개발자가 직접 구두 OR 채널
• 앱 업로드 후 30분~1시간 가량 '출시준비중' 상태를 뺑글뺑글 도는 것을 지켜보다가, 출시가 완료되면 QA엔지니어에게 알려주어야 합니다.

3. 테스터가 추가될때마다 일일이 추가해야하고, 오랫동안 기다려야한다.

신규 테스터를 추가하기 위해서는

(1) 플레이스토어 계정을 전달받아야하고

(2) 전달받은 계정에 수기로 권한을 등록해야합니다.

(3) 테스터가 정상적으로 권한을 획득했는지 확인해야하며,

(4) 권한을 획득한 테스터는 플레이스토어에서 '베타 참여하기' 버튼을 누른 뒤

(5) 약 1~2 시간을 많게는 3시간 이상을 기다려야 테스트앱을 다운받을 수 있습니다.

4. 이전 버전을 테스트할 수 없다. 한번에 1개의 버전만 테스트가 가능하다. (OS별 테스트시)

그나마 TestFlight는 '이전 빌드 보기'통해 과거 버전의 앱도 설치할 수 있어서, iOS는 이 방법으로 기능별 버전을 분리해서 QA를 진행할 수 있습니다. 그러나 플레이스토어는 가장 최신 버전의 앱만 제공할 수 있어 동시다발적으로 여러개의 QA를 태울땐 항상 난감합니다. 또 프로덕트에 앱이 출시되고나면, 자연스레 Beta에 등록된 앱이 이전 버전이 되면서 무효화 되기 때문에 Beta앱을 또 다시 빌드해서 등록해주어야합니다. 이는 배포역시 또 하나의 테스크로 변질되어진다.

아래의 과정이 명령어 한줄이면 가능하다.

1. Fastlane(Build)
2. Firebase App Distribution(테스트 모드) / 슬랙 알림 (테스트모드)
3. 테스트 진행
4. Main PR (merge) 완료 → 심사 & 배포 진행 → 슬랙 알림 (릴리즈 모드)
5. 완료

1. Fastlane 에서 명령어로 빌드를 진행한다.

• 명령어와 Fastlane 환경 셋팅에 따라 .dev / .stage / .release 로 활용 가능하다.

2. 테스트 기기에서 전달 받은 초대 링크를 받는다 ( 최초 1회 )

• 앱을 다운받아 테스트 진행 ( Firebase 에서 다운받는 형식 )
• 슬랙을 통하여 알림 ( 이부분은 슬랙 환경 설정에 따라 릴리즈에서만 채널에 알림을 보내는것도 가능 )

3. 테스트 완료 후 Main PR 완료 되면 PlayStore로 심사 등록 진행

필수 등록 사항 리스트

1. Google Cloude Platform 설정 ( Firebase와 PlayStore 앱 연결 을 위하여 셋팅 )
2. Firebase App Distributuin 설정
   1. 테스터 설정 ( 이메일 초대 )
3. Fastlane 환경 설정 셋팅
4. JAVA Version Upgrade (1.7 → 17)

참고 기술 블로그

[Android] Fastlane으로 App Distribution & PlayStore에 배포하기

Composition, ReComposition

위 링크에서 언급한대로 Composition은 UI를 기술하는 컴포저블의 트리 구조입니다.

Compose 최초 Composition 시의 순서입니다.

1) 처음으로 컴포저블을 실행

2) UI를 기술하기 위해 호출하는 컴포저블을 추적

3) 앱 상태가 변경되면 Jetpack Compose는 recomposition을 예약

4) recompostion은 Compose가 상태 변경사항에 따라 Composable을 다시 실행해서 컴포지션을 업데이트

• composition은 초기 composition을 통해서만 생성, recomposition을 통해서만 업데이트 가능*

1. Composable Lifecycle

Composable의 라이프 사이클은

컴포지션 시작, 0회 이상 recomposition 및 컴포지션 종료 이벤트로 정의

순서: Composable이 Composition을 시작 ->

0회 이상 recomposition ->

comosition을 종료

1)

Composable 의 Lifecycle는 View, Activity 및 Fragment의 Lifecycle보다 간단합니다.

Composable 은 Lifecycle 이 더 복잡한 외부 리소스를 관리하거나 이와 상호작용해야 하는 경우 효과를 사용 해야함

2)

Composable이 여러 번 호출되면 Composition에 여러 인스턴스가 배치됩니다.

Composition 각 호출에는 자체 Lifecycle가 있습니다.

@Composable
fun MyComposable() {
    Column {
        Text("Hello")
        Text("World")
    }
}

3)

recomposition은 일반적으로 State 객체가 변경되면 트리거됩니다.

Compose는 이러한 객체를 추적합니다.

아래 두개중에 건너뛸 수 없는 모든 컴포저블을 실행

(1)Composition에서 특정 State를 읽는 모든 Composable

(2)호출하는 Composable

2. 컴포지션 내 컴포저블의 분석

• 호출 사이트는 컴포저블이 호출되는 소스 코드 위치*
• Composition 내 composable 의 인스턴스는 호출 사이트로 식별
• Compose 컴파일러는 각 호출 사이트를 고유한 것으로 간주
• 여러 호출 사이트에서 컴포저블을 호출하면 컴포지션에 컴포저블의 여러 인스턴스가 생성

하지만..

recompostion 시 composable이 이전 recomposition 시 호출한 것과 다른 composable을 호출하는 경우

1) Compose는 호출되거나 호출되지 않은 composable을 식별

2) 두 Compostion 모두에서 호출된 composable의 경우 입력이 변경되지 않은 경우 recomposition 하지않음

부수 효과를 composable과 연결하기 위해서는 ID를 유지하는 것이 중요함

(recomposition마다 다시 시작하는 대신 완료할 수 있도록)

예제

@Composable
fun LoginScreen(showError: Boolean) {
    if (showError) {
        LoginError()
    }
    LoginInput() // This call site affects where LoginInput is placed in Composition
}

@Composable
fun LoginInput() { /* ... */ }

위 예제에서 LoginScreen은 LoginError Composable을 조건부로 호출하며

항상 LoginInput Composable을 호출합니다.

각 호출에는 고유한 호출 사이트 및 컴파일러가 호출을 고유하게 식별하는 데

사용하는 소스 위치가 있습니다.

상태가 변경되고 recomposition이 발생할 때 composition 내 LoginScreen의 표현.

(색상이 동일하면 recomposition되지 않았음을 의미합니다.)

LoginInput이 첫 번째로 호출되었다가 두 번째로 호출되었지만

LoginInput 인스턴스는 여러 recomposition에 걸쳐 유지됩니다.

또한 LoginInput에는 recomposition 간에 변경된 매개변수가 없으므로

Compose가 LoginInput 호출을 건너뜁니다.

2-1.스마트 recomposition에 도움이 되는 정보 추가

• 동일한 호출 사이트에서 composable을 여러 번 호출하는 경우 Compose가 인스턴스를 구분하기 위해 호출 사이트 외에 실행 순서가 사용됨
• 호출 사이트 외에 실행순서가 필요한 경우도 있지만 경우에 따라 원치 않는 동작이 발생할 수 있음

예제.

@Composable
fun MoviesScreen(movies: List<Movie>) {
    Column {
        for (movie in movies) {
            // MovieOverview composables are placed in Composition given its
            // index position in the for loop
            MovieOverview(movie)
        }
    }
}

위 예에서 Compose는 호출 사이트 외에 실행 순서를 사용하여

Composition 에서 인스턴스를 구분합니다.

새 movie가 리스트의 하단에 추가된 경우

ex: list.add(movie)

Compose는 인스턴스의 리스트내

위치가 변경되지 않았고

인스턴스의 movie 입력이 동일하므로

컴포지션에 이미 있는 인스턴스를 재사용할 수 있습니다.

(ex: {1,2,3}일때 list.add(4) 를 하면  {1,2,3,4} 라서

이전과 비교해서 4를 제외한 1,2,3 값과 index 위치가 그대로 있는거라면 )

위 그림처럼 composition 의 MovieOverview Composable은 재사용이 됩니다.

(색상이 동일하면 recomposition되지 않았음을 의미합니다.)

하지만....

리스트의 상단 아이템 추가, 리스트의 가운데 아이템 추가, 항목을 삭제, 재정렬 등등

movies 목록이 변경되면 목록에서 입력 매개변수의 위치가

변경된 모든 MovieOverview Composable 호출에서 recomposition이 발생합니다.

예를 들어 MovieOverview가 부수 효과를 사용하여 네트워크에서 이미지를 가져오는 경우 매우 중요합니다.

효과가 적용되는 동안 recomposition 이 발생하면 효과가 취소되고 다시 시작됩니다.

예제

@Composable
fun MovieOverview(movie: Movie) {
    Column {
        // Side effect explained later in the docs. If MovieOverview
        // recomposes, while fetching the image is in progress,
        // it is cancelled and restarted.
        val image = loadNetworkImage(movie.url)
        MovieHeader(image)

        /* ... */
    }
}

위 그림은 ex:list.add(0,movie) 를 했을때의 예시입니다.

(색상이 동일하지 않으면 recomposition 되었음을 의미합니다.)

• 재사용 없이 다시 recompostion이 됨
• 모든 부수효과가 다시 시작됨

그렇다면 위와 상황에서 recomposition 없이 재사용을 사용할려면

이상적으로 MovieOverview 인스턴스의 ID는

인스턴스에 전달된 movie의 ID에 연결되는것이 좋습니다.

Compose에서 런타임에 트리의 특정 부분을

식별하는 데 사용할 Key를 지정할 수 있습니다.

key 값은 전체적으로 고유하지 않아도 되며

호출 사이트에서의 Composable 호출 간에만 고유하면 됩니다.

(앱의 다른 위치에 있는 다른 Composable과 이 key를 공유하는 것은 괜찮습니다.)

예제

@Composable
fun MoviesScreen(movies: List<Movie>) {
    Column {
        for (movie in movies) {
            key(movie.id) { // Unique ID for this movie
                MovieOverview(movie)
            }
        }
    }
}

movies의 요소가 변경되더라도 Compose는

key별로 MovieOverview() 호출을 인식하고 재사용할 수 있습니다.

Key를 사용했기 때문에 고유 식별자가 생겨서 recomposition 없이 재사용이 가능해집니다.

(색상이 동일하면 recomposition되지 않았음을 의미합니다.)

일부 Composable에는 key Composable 지원 기능이 내장되어 있습니다.

예제

@Composable
fun MoviesScreen(movies: List<Movie>) {
    LazyColumn {
        items(movies, key = { movie -> movie.id }) { movie ->
            MovieOverview(movie)
        }
    }
}

예를 들어 LazyColumn의 경우 items DSL에 맞춤 key를 지정할 수 있습니다.

2-2.입력이 변경되지 않은 경우 건너뛰기

Composition에 이미 Composable이 있는 경우 모든 input이 안정적이고 변경되지 않았으면

recompostion을 건너뛸 수 있습니다.

Stable 타입은 다음을 준수해야 합니다.

1) 두 인스턴스의 equals 결과가 동일한 두 인스턴스의 경우 항상 동일

2) 타입의 Public 속성이 변경되면 Composition에 알림이 전송

3) 모든 Public 속성 유형도 안정적

예외로 안정적이지만 변경할 수 있는 한 가지 중요한 타입은 Compose의 MutableState

value가 MutableState로 유지되는 경우 State의 .value 속성이 변경되면 Compose에 알림이 전송합니다.

그래서 상태 객체는 안정적인 것으로 간주됩니다.

Composable에 매개변수로 전달된 모든 타입이이 안정적인 경우

UI 트리 내 Composition 위치를 기반으로 매개변수 값이 동일한지 비교합니다.

(이전 호출 이후 모든 값이 변경되지 않은 경우 recompostion 을 건너뜀)

@Stable

Compose는 증명할 수 있는 경우에만 유형을 안정적인 것으로 취급

(ex: 인터페이스는 일반적으로 안정적이지 않은 것 취급되며 구현을

변경할 수 없고 변경할 수 있는  속성이 있는 유형도 안정적이지 않음)

Compose가 유형이 안정적이라고 추론할 수 없을때,

안정적인 것으로 간주하도록 하려면 @Stable 주석으로 표시하면 됨

예제.

// Marking the type as stable to favor skipping and smart recompositions.
@Stable
interface UiState<T : Result<T>> {
    val value: T?
    val exception: Throwable?

    val hasError: Boolean
        get() = exception != null
}

인터페이스는 이 타입을 안정적이지 않은 것으로 간주함

하지만 @Stable 주석을 추가하면 Compose가 이 유형이 안정적임을 알게 되고 스마트 recomposition을

선호하게 됨

인터페이스가 매개변수 유형으로 사용되는 경우

Compose가 모든 구현을 안정적인 것으로 간주함

@Stable 주석을 사용하여 안정적이라고 명시되지 않더라도

Compose 컴파일러가 안정적인 것으로 간주하며 이 계약에 포함되는 중요한 일반 타입이 있습니다.

1) 모든 원시 값 타입: Boolean, Int, Long, Float, Char 등

2) 문자열

3) 모든 함수 타입(람다)

• 이 타입은 모두 변경할 수 없으므로 stable 계약을 준수함
• 변경할 수 없는 유형은 절대 변경되지 않으므로 Composition에 변경사항을 알리지 않아도 됨

Jetpack Compose 도입 배경에는 여러 가지 이유가 있습니다. 안드로이드 개발팀과 커뮤니티는 기존의 UI 개발 방식에서 나타나는 문제들을 해결하고, 더 나은 개발 경험을 제공하기 위해 Compose를 설계했습니다. 주요 도입 배경은 다음과 같습니다

1. 기존 XML 기반 UI의 복잡성

XML 기반 UI 개발은 다음과 같은 단점이 있습니다:

• 이원화된 코드 구조: UI 레이아웃은 XML 파일에서 정의되고, 동작은 Kotlin/Java 파일에서 정의되어야 합니다. 이는 코드의 일관성을 떨어뜨리고 유지보수를 어렵게 만듭니다.
• 복잡한 상태 관리: UI 컴포넌트의 상태를 변경하고 업데이트하는 과정이 복잡하며, 종종 버그를 유발합니다.
• 보일러플레이트 코드: 많은 양의 보일러플레이트 코드가 필요하여 생산성이 저하됩니다.

2. 현대적인 UI 개발 패러다임

기존의 명령형 프로그래밍 방식 대신 선언형 프로그래밍 방식이 각광받기 시작하면서, React(웹 개발)와 Flutter(크로스플랫폼 모바일 개발)와 같은 프레임워크들이 인기를 끌었습니다. 이러한 트렌드에 맞추어 안드로이드 개발팀도 Jetpack Compose를 도입하게 되었습니다:

• 선언형 프로그래밍: UI 상태를 기반으로 UI를 선언적으로 정의하여, 코드의 가독성과 유지보수성을 높입니다.
• 반응형 UI 업데이트: 상태 변경에 따라 자동으로 UI를 업데이트하여 개발자가 상태와 UI 동기화를 일일이 관리할 필요가 없습니다.

3. 개발 생산성 향상

Jetpack Compose는 개발자의 생산성을 높이기 위해 다음과 같은 기능을 제공합니다:

• 간결한 코드: XML과 뷰 바인딩 코드를 없애고, 하나의 Kotlin 파일에서 모든 UI를 정의할 수 있습니다.
• 재사용 가능한 컴포넌트: Composable 함수를 사용하여 UI 컴포넌트를 모듈화하고 재사용성을 극대화합니다.
• 강력한 툴링 지원: Android Studio는 Compose를 위한 실시간 미리보기, 코드 완성, 리팩토링 도구 등을 제공하여 개발 효율성을 높입니다.

4. 성능 개선

Jetpack Compose는 성능 면에서도 이점을 제공합니다:

• 효율적인 리컴포지션: 상태 변경 시 필요한 부분만 다시 렌더링하여 성능을 최적화합니다.
• 최소화된 메모리 사용: 필요한 UI 컴포넌트만 메모리에 로드하여 메모리 사용량을 줄입니다.

5. 커뮤니티와 생태계의 발전

Jetpack Compose는 구글의 지원 아래 적극적으로 발전하고 있으며, 커뮤니티의 피드백을 반영하여 지속적으로 개선되고 있습니다. 이는 안드로이드 개발 생태계를 더욱 강화하고, 개발자들이 최신 기술을 사용할 수 있도록 돕습니다.

결론

• Jetpack Compose 도입 배경은 기존의 XML 기반 UI 개발 방식의 단점을 극복하고, 선언형 프로그래밍 패러다임을 통해 더 나은 개발 생산성과 성능을 제공하기 위함입니다. 현대적인 UI 개발 트렌드에 맞추어, 안드로이드 개발자들이 더 간편하고 효율적으로 UI를 작성하고 유지보수할 수 있도록 설계된 것이 Compose의 주요 도입 배경입니다.

$ brew update
$ brew install rabbitmq
$ ~/.zshrc

* path 입력 후 저장
$ export PATH=$PATH:/usr/local/sbin
$ source ~/.zsrhc

해당 경로로 진입하여 rabbitmq 서버를 로컬로 실행한다.
$ cd /opt/homebrew/opt/rabbitmq/sbin/
$ ./rabbitmq-server

서버 실행이 에러날 경우
ERROR: could not bind to distribution port 25672, it is in use by another node: rabbit@localhost

$ sudo lsof -i :25672 ( 해당 명령어 실행 후 pid 확인 )
$ sudo kill <PID>
$ ./rabbitmq-server

에러 발생시 서버를 죽이고 다시 실행한다.

아래 사진은 ./ rabbitmq-server 명령어 실행시 완료 화면

chrom 에서 해당 로컬서버로 http://localhost:15672 접속

id : guest
pw : guest
처음엔 default 인 guest / guest 으로 되어있음

추후 계정 생성시 아래 명령어 참고
./rabbitmqctl add_user rabbitmq {id} {pw} -- 계정 생성
./rabbitmqctl set_user_tags {id} administrator -- 계정 어드민 권한 부여

$ expo init client
$ npm install amqplib
$ cd client

* 테스트용 프로젝트
Project_Name : client

$ cd /Users/{name}/Desktop/client/src
$ ls
$ sendMessage.js / receiveMessage.js

메시지 보낼때 
$ node sendMessage.js -- 실행

메시지 받을때
$ node receiveMessage.js -- 실행

해당 경로 참고

sendMessage.js

/*
 * npm install amqplib
 */

const { execSync } = require("child_process");
const amqp = require('amqplib/callback_api');

// amqp 예시
//amqp://admin:admin@localhost admin:admin = rabbitmq 계정:암호

const prod = 'amqp://{name}:vlTmRun1214!@101.79.9.43:5672';
const local = 'amqp://guest:guest@localhost';

amqp.connect(local, function (error0, connection) {
    if (error0) {
        throw error0;
    }

    connection.createChannel(function (error1, channel) {
        if (error1) {
            throw error1;
        }

        //queue name
        var queue = 'test';

        /*
        * queue가 없으면 만들어줌
        * durable : true -> queue 데이터를  rabbitmq가 재시작해도 가지고 있음(소비하기전까지)
        */
        channel.assertQueue(queue, {
            durable: false,
            exclusive: false,
            autoDelete: false,
            arguments: null,
        });
        setInterval(sendToQueue, 1000, channel, queue)
    });

    setTimeout(function () {
        connection.close();
        process.exit(0);
    }, 10000);
});

function sendToQueue(channel, queue) {
       var msg = 'Hello World! transDate:' + new Date();
       channel.sendToQueue(queue, Buffer.from(msg));

    //json 데이터 보내기 (receive 에서 아래 포맷형식으로 보내지 않으면 메시지를 받을 수 없다...)
    // var msg = '{"test":"테스트 입니다", "name":"테스트에용", "title":1111}';
    // channel.sendToQueue(queue, Buffer.from(JSON.stringify(msg)));

    console.log(" [x] Sent %s", msg);
}

receiveMessage.js

/*
 * npm install amqplib
 */
const { execSync } = require("child_process");
const amqp = require('amqplib/callback_api');

// amqp 예시
//amqp://admin:admin@localhost admin:admin = rabbitmq 계정:암호

const prod = 'amqp://piece:vlTmRun1214!@101.79.9.43:5672';
const local = 'amqp://guest:guest@localhost';

amqp.connect(local, function (error0, connection) {
    if (error0) {
        throw error0;
    }

    connection.createChannel(function (error1, channel) {
        if (error1) {
            throw error1;
        }

        //queue name
        var queue = 'test';

        /*
        * queue가 없으면 만들어줌
        * durable : true -> queue 데이터를  rabbitmq가 재시작해도 가지고 있음(소비하기전까지)
        */
        channel.assertQueue(queue, {
            durable: false,
            exclusive: false,
            autoDelete: false,
            arguments: null,
        });

        console.log(" [*] Waiting for messages in %s. To exit press CTRL+C", queue);

        //prefetch를 설정해두면 큐에서 최대 10개만 가져감.
        channel.prefetch(10);
        channel.consume(queue, function (msg) {
            console.log(" [x] Received %s", msg.content.toString());

            // json 데이터 받기
            // var result = JSON.parse(msg.content.toString());
            // console.log(result.testVal1, result.testVal2, result.testVal3);

            //Ack 메세지를 보내야 큐에서 제거함
            channel.ack(msg);
            //channel.nack(msg);
        }, {
            //noAck: true 이면 queue에서 데이터를 가져간다음 Ack를 바로 반환함으로 가져가자마자 queue에서 지워버림, ack를 받았을 경우만 큐에서 제거하기 위해 false로 설정
            noAck: false
        });
    });
    setTimeout(function () {
        connection.close();
        process.exit(0);
    }, 10000);
});

$ npm install -g sharp-cli

or

$ npx expo-optimize [options]

• options [ jpegoptim , guetzli , pngcrush , optipng , imagemin ]

1. App.js 추가

{
    "expo": {
        "jsEngine": "hermes"
    }
}

예시
{
  "expo": {
    "name": "client",
    "slug": "client",
    **"jsEngine" : "hermes", <-- 추가**
    "version": "1.0.0",
    "orientation": "portrait",
    "icon": "./assets/icon.png",
    "splash": {
      "image": "./assets/splash.png",
      "resizeMode": "contain",
      "backgroundColor": "#ffffff"
    },
    "updates": {
      "fallbackToCacheTimeout": 0
    },
    "assetBundlePatterns": [
      "**/*"
    ],
    "ios": {
      "bundleIdentifier": "com.rabbit.testApp",
      "supportsTablet": true,
      "buildNumber": "1.0.0"
    },
    "android": {
      "package": "com.rabbit.testApp",
      "versionCode": 1 ,
      "adaptiveIcon": {
        "foregroundImage": "./assets/adaptive-icon.png",
        "backgroundColor": "#FFFFFF"
      }
    },
    "web": {
      "favicon": "./assets/favicon.png"
    }
  }
}

2. Command Insert
* 해당 프로젝트에 진입 후 아래 명령어 실행 

$ npm install -g eas-cli
$ npm install -g eas-cli-local-build-plugin

😮‍💨  M1 Mac

iOS용 Hermes를 사용할 때 시뮬레이터용으로 빌드할 때 다음 오류가 발생할 수 있습니다.

--- a/ios/Podfile
+++ b/ios/Podfile
@@ -25,6 +25,22 @@ target 'HelloWorld' do
   post_install do |installer|
     react_native_post_install(installer)

+    # Workaround simulator build error for hermes with react-native 0.64 on mac m1 devices
+    arm_value = `/usr/sbin/sysctl -n hw.optional.arm64 2>&1`.to_i
+    has_hermes = has_pod(installer, 'hermes-engine')
+    if arm_value == 1 && has_hermes
+      projects = installer.aggregate_targets
+        .map{ |t| t.user_project }
+        .uniq{ |p| p.path }
+        .push(installer.pods_project)
+      projects.each do |project|
+        project.build_configurations.each do |config|
+          config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] + ' arm64'
+        end
+        project.save()
+      end
+    end
+
     # Workaround `Cycle inside FBReactNativeSpec` error for react-native 0.64
     # Reference: https://github.com/software-mansion/react-native-screens/issues/842#issuecomment-812543933
     installer.pods_project.targets.each do |target|

// 해결 방법
Pod를 다시 설치하고 Xcode 빌드 캐시를 정리합니다.

$ npx pod-install
$ xcodebuild clean -workspace ios/{projectName}.xcworkspace -scheme {projectName}

Android build Test Result

최적화 전 빌드 진행

최적화 후 빌드 진행

$ npm install -g eas-cli
$ npm install -g eas-cli-local-build-plugin

$ expo init <test>
$ cd <test>

$ eas login
Log in to EAS
Email or username : <expo account id>
Password : <expo account pw>

eas.json

{
  "cli": {
    "version": ">= 0.50.0"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  },
  "submit": {
    "production": {}
  }
}

$ expo build:android
$ expo build:ios

$ expo build:android --type app-bundle
$ expo build:android -t app-bundle

아래 선택지중 택 1
> npm install -g eas-cli
> eas build -p android 

https://developer.android.com/training/sign-in/biometric-auth?hl=ko

$ npm i --save react-native-touch-id

or

$ yarn add react-native-touch-id

===> 해당 라이브러리 확인 결과 업데이트가 19년 이후로 없어서 Android 10 이상에서 지원 **불가**

===========================================================================

Android SDK 10 이상 지원 가능
Expo SDK 40 부터 지원 가능

$ expo install expo-local-authentication

// Expo 공식 문서 가이드
https://docs.expo.dev/versions/latest/sdk/local-authentication/

// Github 참고 가이드
https://github.com/expo/expo/tree/main/packages/expo-local-authentication

SecurityLevel {
    NONE ,      # 등록된 지문 없음
    SECRET ,    # 비 생체 인증 (ex. PIN , 패턴 )
    BIOMETRIC   # 생체 인증
}
NONE = 0 , SECRET = 1 , BIOMETRIC = 2

AuthenticationType { 
    FINGERPRINT ,      # 지문
    RECOGNITION ,      # 얼굴인식
    IRIS (Android 전용) # 홍채인식
}

FINGERPRINT = 1 , RECOGNITION = 2 , IRIS = 3

// 생체인증 참고 레퍼런스
https://dev.to/bionicjulia/biometric-authentication-in-react-native-with-expo-3l20

// 최근 업데이트 기준 npm
https://www.npmjs.com/package/expo-local-authentication

// React-Native Auth 참고 레퍼런스
https://medium.com/swlh/how-to-use-face-id-with-react-native-or-expo-134231a25fe4

이전에 공부하였던 자료를 옮겨 놓기 위하여 기록합니다.

React-Native Expo Build

로컬 개발 환경 버전 (Dev .ver)

MacOS Monterey 12.3.1
Xcode 13.2.1

brew 3.4.6
node 16.6.2
npm 7.20.3
watchman 2022.03.21.00
expo-cli 5.3.1
pod 1.11.3
openjdk 11.0.14.1
javac 11.0.14.1

🧭 개발 환경 가이드

M1: Homebrew 설치