멋있게걷는방법

[Flutter] 출시 시 firebase 로그인 안 될 때

도현D — Wed, 24 Jul 2024 19:28:45 +0900

출시는 성공했지만 firebase 로그인이 되지 않을 때!

많이들 sha키를 제대로 확인하라고 하지만, 만약 처음 앱을 올리는 게 아니라 이미 앱이 배포되어 있고 두 번째 시도일 때는 이유가 다릅니다.

안드로이드는 한 번 출시하면 두 번째부터는 추가해줘야하는 sha 키가 있는데 이걸 firebase에 추가해 줘야 로그인이 가능합니다.

1. 먼저 google play console에 가셔서

2. 설정 -> 앱서명 으로 이동하면

앱 서명 키 인증서 섹션에 보시면 SHA-1 인증서 지문과 SHA-256 지문이 있을 거예요.

이걸 firebase -> 프로젝트 설정 -> 내 앱 -> android -> 디지털 지문 추가에

추가해 주시고 google-services.json을 다시 다운로드한 후 프로젝트에 적용시키면 로그인이 성공하는 걸 볼 수 있습니다.

[Swift] GC vs ARC (with. Retain Cycle)

도현D — Tue, 24 Oct 2023 15:54:48 +0900

가장 큰 차이는 참조 카운팅 시점.

GC

런타임 중에 메모리 해제 시점을 결정함.

- 이미 할당된 메모리에서 더 이상 사용하지 않는 메모리를 해제하는 기술.

런타임에 동작.
백그라운드에서 실행.
불확실한 간격으로 발생하기 때문에, 객체가 더 이상 사용되지 않는 정확한 순간에 무조건 해제되는 건 아님.

발생시점

각 영역에 할당된 크기의 메모리가 허용치를 넘을 때 수행됨.

⇒ 개발자가 컨트롤할 수 없다.

왜?

⇒ 강제로 GC를 수행시키면 GC를 실행하는 동안 해당 스레드를 제외하고 모든 스레드가 멈춰서 성능에 영향을 줄 수 있다.

성능 저하가 발생할 수 있음.

런타임에 계속해서 메모리를 감시하다가 해제하기 때문이다.

순환참조 발생 X

계속해서 메모리를 감시하기 때문에 인스턴스가 해제될 가능성이 더 높다.

장점

retain cycle 관리 가능.
백그라운드에서 발생하므로 일반 애플리케이션 흐름의 일부로 수행되는 메모리 작업이 줄어든다. (메모리 성능상 이점)

단점

객체의 정확한 release 시점을 알 수 없다.
런타임에서 인스턴스를 추적하기 때문에 추적, 해제하는 과정에서 오버헤드가 발생.

ARC

(automatic reference count)

컴파일 시점에 인스턴스 해제 시점이 결정되어 있다.

성능 저하가 발생하지 않음.

컴파일 시점에서 인스턴스 해제 시점이 결정되어 있기 때문이다.

순환참조

순환참조가 발생하면 인스턴스가 메모리에서 영원히 해제되지 않아, 쌓이게 되면 앱이 터질 수 있음. 개발자의 명시적인 설계가 필요함. 이를 위해 (strong, weak, unowned 같은 걸 도입함.)

장점

참조 횟수를 추적해 더 이상 참조되지 않는 인스턴스를 메모리에서 해제한다.
(retain, release를 해 retain count(reference count)가 0이 되면 해제)
런타임 시점에 추가 리소스가 발생하지 않음. (컴파일 시점에 인스턴스 해제 시점을 결정하기 때문)
백그라운드 처리가 없기 때문에 모바일 장치와 같은 저전력 시스템에 더 효율적이다.

단점

순환참조 문제
Retain cycle 자동 처리 불가능. (개발자가 명시적으로 설계해야 함.)

Retain Cycle 자동 처리 불가?

GC는 계속 메모리를 감시한다. 객체에 외부 참조가 존재하지 않는 것을 감지하면, 서로를 참조하는 객체 그래프 전체를 버린다. 때문에 순환참조가 발생하지 않음.

근데, ARC는. 참조 수를 기반으로 생명 주기를 관리한다. 때문에 retain cycle을 자동으로 처리할 수 없고, 결과적으로 순환참조가 발생할 수 있음.

외부 참조가 없다?

만약 이런 상황일 때,

두 인스턴스가 해제(nil) 된다면? (외부 참조가 없어진다면)

프로퍼티인 child만 남게 되는데 이 둘은 해제되지 않고 영원히 해제되지 않고 남아있게 된다.

ARC의 경우에는

var a = A()
var b = B()

객체를 생성할 때 retain(+1) 되면서 Retain Count(reference count)가 +1 되고, (현재 1)

a.child = b
b.child = a

다른 인스턴스를 대입할 때 또 +1 되면서 Retain Count(reference count)가 +1 된다. (현재 2)

인스턴스를 nil로 바꾸면서 release(-1) 되면서 Retain Count(reference count)가 1이 된다. (현재 1)

Retain Count(reference count)가 0이 될 때 메모리가 전부 해제되니까. 순환참조 발생.

중요!!!

그니까 GC는 이런 상황일 때 참조 객체 그래프 전체를 버려버리니까 순환참조가 발생하지 않고,

ARC는 참조수로 생명 주기를 관리하기 때문에 순환참조가 발생하는 것. → 때문에 weak, unkowned로 관리하는 것.

[Tuist] Firebase 에러 해결(with. _OBJC_CLASS_$_JSContext)

도현D — Thu, 21 Sep 2023 09:57:42 +0900

해당 문제는 Tuist를 이용해 SPM을 사용하면서, Firebase SDK Library를 추가하면서 생긴 에러입니다.

해결법

일단 가장 간단한 방법은

Targets -> Build Phases -> Link Binary With Libraries에JavaScriptCore.framework를 추가하면 해결됩니다.

일단 저의 경우는 Tuist를 쓰고 있기 추가했더라도 generate를 하게 되면JavaScriptCore.framework가 다시 사라져 근본적으로 해결할 순 없습니다.

Tuist에 추가하기

현재 Library를 추가하려는 모듈에서, dependency에 추가해야 합니다.
아래와 같이 TargetDepency의 sdk를 사용해 추가하면 됩니다.

주의

type을 framework로 지정해 주면 자동으로 name 뒤에. framework가 붙기 때문에

JavaScriptCore.framework로 쓰면 에러가 발생합니다. (생성 시 JavaScriptCore.framework.framework로 생기게 됨)

- 따라서 name엔 JavaScriptCore만 써주면 됩니다.

[Swift] Override함수에서 Super는 필수일까? (with. layoutSubViews)

도현D — Sun, 2 Jul 2023 02:28:54 +0900

기본적으로 super 키워드는 상위 뷰를 호출합니다.

예를 들어볼게요.

class A: UITableViewCell {
    override func layoutSubviews() {
        super.layoutSubviews()
	}
}

만약 제가 UITableViewCell을 상속하고 있는 A라는 클래스에 있는 layoutSubview override 함수에서 super를 통해 super.layoutSubviews()를 호출했다면 어떤 뷰가 실행될까요?

super는 상위 뷰를 호출한다고 했죠?
현재 상속 중인 클래스는 UITableViewCell입니다.
그럼 호출되는 건 UITableView의 상위 뷰인 UIView의 layoutSubviews가 호출되겠죠!

super 가 뭘 하는 녀석인 줄은 알고 있었지만 이렇게 자세히 파본건 처음입니다..

여기서부턴 제 경험에 대한 얘기입니다.

이렇게 글을 쓰게 된 이유는 프로젝트를 하면서 contentView의 inset을 변경해야 하는 일이 있었습니다.

대부분 아래와 같은 코드로 변경하셨을 겁니다!

    override func layoutSubviews() {
        super.layoutSubviews()
        contentView.frame = contentView.frame.inset(by: UIEdgeInsets(top: 0, left: 15, bottom: 16, right: 15))
    }

저는.. super.layoutSubviews()를 적지 않아서 며칠 동안 고생했습니다..

하지만 오히려 문제를 분석해 볼 수 있었습니다.

먼저 문제는 TableViewCell을 만질 때마다 cell 이 움직이는 문제가 있었습니다.

Simulator_Screen_Recording_-_iPhone_14_Pro_-_2023-06-30_at_12.19.22 (1).mp4

3.49MB

    override func layoutSubviews() {
        contentView.frame = contentView.frame.inset(by: UIEdgeInsets(top: 0, left: 15, bottom: 16, right: 15))
    }

제 코드는 super를 통해 상위 뷰를 호출하지 않은 위와 같은 코드였습니다.

원인은 이러했습니다.

layoutSubviews는 layout이 변경될 때마다 호출되는데
제가 아까 `cell을 만질 때마다`라고 했던 말은 cell을 스와이프 하거나 등의 동작을 얘기합니다.

즉. contentView에 inset을 계속해서 더해준 거죠.. 아래는 contentView.frame입니다.

이렇게 해결했습니다.

여기서 super의 개념을 적용시켰습니다.

먼저 layoutSubviews는 공식 문서에 의하면 이러한 일을 합니다.

the default implementation uses any constraints you have set to determine the size and position of any subviews.

- 기본 구현에서는 사용자가 설정한 제약 조건을 사용하여 하위 보기의 크기와 위치를 결정합니다.

그니까. super.layoutSubviews()를 호출하고 -> content inset을 변경해 주면,

기본적으로 설정했던 layout으로 초기화되고 -> content inset 이 변경된다!

라고 이해했습니다.

아래는 문제를 해결한 후 contentView.frame입니다.

혹시나 틀린 부분이 있다면 알려주세요!! 제발

마무리.

많은 삽질을 했지만, 결국은 기본적인 실수였고, 하지만 그 과정에서 오늘도 배운 점이 있었습니다.

발생한 이슈를 근본적 원인을 찾고 분석하면서 해결해 나가는 과정은 늘 새롭고 재밌는 것 같습니다.

이런 과정들이 쌓인다면 분명 좋은 개발자가 될 수 있지 않을까 기대해 봅니다.

읽어주셔서 감사합니다.

App Store 배포 리젝 사유 회고 2.1 , 1.2

도현D — Tue, 27 Jun 2023 16:18:34 +0900

Guideline 2.1 - Information Needed

In addition to the demo account you provided, we still need a demo phone number and authentication code to verify the registration process in your app.

해당 리젝 사유는 한 마디로

'나 회원가입 테스트할 건데 테스트용 전화번호랑 인증코드 줘'라는 의미입니다.

따라서 서버에서 테스트용 전화번호와 해당 전화번호일 때 성공할 수 있는 인증번호를 임의로 설정해야 합니다.

ex) 전화번호가 01011110000 일 때 인증번호가 0000 이면 성공. 와 같은 로직을 작성해야 한다.

서버에서 이러한 로직이 있다면, 앱 심사 정보 메모에 테스트용 전화번호와 인증번호를 명시해 주면 리젝을 해결할 수 있습니다.

Guideline 1.2 - Safety - User Generated Content

We found that your app includes user-generated content but does not have all the required precautions.

Next Steps

To resolve this issue, please revise your app to implement the following precautions:

- Require that users agree to terms (EULA) and these terms must make it clear that there is no tolerance for objectionable content or abusive users

해당 리젝 사유는 마지막 줄

'사용자가 약관(EULA)에 동의하도록 요구하고 이러한 약관은 불쾌한 콘텐츠나 악의적인 사용자를 용납하지 않는다는 점을 명확히 해야 합니다.' 입니다.

즉 약관을 동의할 수 있도록 기능을 구현하고, 약관 동의를 작성한 페이지에 '불쾌한 콘텐츠나 악의적인 사용자는 제재를 받을 수 있다. '와 같은 내용을 포함시켜 주면 해결할 수 있습니다.

App Store 배포 회고(with. 개발 & 책임)

도현D — Sun, 25 Jun 2023 22:39:34 +0900

저의 두 번째 프로젝트를 개발, 출시하며 들었던 생각과 고민들에 대해 적어보려고 합니다.

이 프로젝트는 원래는 한 달짜리 프로젝트였지만, TestFlight를 통해 팀원끼리 테스트도 하며 피드백을 통해 요구사항을 추가됐고, 디자인도 변경되면서 기간이 길어졌습니다.
팀원들은 '일단 배포하고 v2에서 고치자~'라는 말을 자주 했는데요. 사실 이 말이 어쩌면 맞을지도 모릅니다.

빠른 앱 출시를 시도한다면, 앱스토어 배포 과정에서도 reject 사유를 알 수 있고, 또 만약 reject 없이 바로 앱이 출시된다 하더라도
사용자들로부터 얻는 피드백을 통해 앱의 퀄리티를 높일 수도 있겠죠.
(reject 사유를 알 수 있다는 건 큰 이점이란 걸 이번에 reject을 4번 당하면서 깨달았습니다. ㅎㅎ)

그러나 제 생각은 달랐습니다. '낮은 퀄리티의 앱을 굳이 배포해서 사용자들에게 보여줄 필요가 있는가?'였습니다. 물론 많은 사용자가 저희의 프로젝트를 사용하지 않을 수도 있죠. 또 그 과정에서 얻는 피드백 등으로 성장할 수 있습니다.
그렇지만 과연 좋지 못 한 경험을 사용자에게 주는 건 책임자로서의 역할이 맞을까?라는 고민을 했습니다.

다양한 앱을 사용해 보면서 제가 느낀 점은 사용자는 다음 버전을 기다리지 않습니다. 즉 사용자에게 처음부터 좋은 경험을 줘야 앱을 오래 사용할 것이고, 유저 리텐션도 높아질 것입니다. 완성에만 급급했던 기존의 생각을 떨쳐낼 수 있는 시간이었던 것 같습니다.

마지막으로..

현재 프로젝트에선 유저 리텐션 같은 개발 외적인 부분은 고민해보지 않고 프로젝트를 진행했던 게 아쉬움이 남습니다. 하지만, 앞으로의 프로젝트에선 나의 책무가 무엇인지 더 고민해 보고 프로젝트 전반에 대해 깊게 고민해 볼 수 있을 것 같습니다. 개발을 하는 것도 중요하지만 너무 나무만 보고 있던 게 아니었나 싶습니다.. 고려해야 할 부분들이 많더라고요(유저 리텐션 늘리기, 피드백 유도...) 이제는 숲을 보는 넓은 시선으로 개발뿐만 아니라 다른 곳에도 신경 써서 더 높은 퀄리티의 제품을 만들어내고 싶습니다. 너무 뿌듯했고, 기대됩니다. 다른 분들도 이런 부분에서 고민해 보면 좋을 것 같아요.

생각나는 대로 적은 거라 이 글은 언제든 추가/수정이 있을 수 있습니다!

[Swift] 지금 바로 Pagination 을 적용해야 하는 이유

도현D — Thu, 8 Jun 2023 01:28:21 +0900

프로젝트에 단순 데이터를 불러오는 게 아닌, page 단위로 불러오면 메모리 효율을 아낄 수 있는데요,

이게 바로 Pagination 입니다. 무한스크롤이라고도 하죠.

Pagination 은 메모리 효율을 아낄 수 있다고 했는데, 그 이유는 뭘까요?

들어가기 전에,

tableView의 delegate, datasource로 tableView를 구성했다면 대부분
dequeueReusableCell를 이용해 재사용 셀을 구성했을 겁니다.

만약 Rx를 쓴다면?

.drive(postTableView.rx.items(cellIdentifier: PostCell.identifier,
                              cellType: PostCell.self)) { (row, data, cell) in

이런 식으로 쉽게 구현할 수 있었을 것입니다.

그럼 본론으로 들어가서,

Pagination을 사용하면 얻는 장점

(대부분 일정 범위까지의 데이터만 로드하기 때문에 얻는 장점입니다.)

1. 효율적인 데이터 로딩

기존엔 모든 데이터를 불러왔다면 Pagination 을 적용하면 현재 보이는, 또는 일정 범위까지의 데이터만

로드하기 때문에 로딩 시간을 크게 줄일 수 있습니다. 예를 들어 인터넷이 느리거나 규모가 큰 대량의 데이터를 다룰 때 유용합니다.

2. 메모리 관리

tableView를 띄운다면 내가 볼 수 없는 곳까지의 데이터를 굳이 불러오는 건 메모리 낭비겠죠? Pagination을 사용하면 필요한 페이지만 로드하여 메모리 사용을 최적화할 수 있습니다. 또한 필요하지 않은 데이터를 메모리에 유지하지 않아도 되므로 앱의 메모리 사용량을 줄일 수 있습니다.

3. 캐싱 & 재사용

pagination 은 페이지 단위로 데이터를 처리하기 때문에 각 페이지를 캐싱하고 재사용할 수 있습니다.

예를 들어 첫 번째 페이지를 로딩을 완료했는데 네트워크 연결이 끊어졌다면,
첫 번째 페이지의 데이터는 캐싱된 메모리를 통해 보일 수 있습니다.

아래는 제가 직접 프로젝트에 Pagination을 적용시키면서 확인한 메모리 사용량 비교입니다.

(response는 title, content, image1, image 2, voteCount, commentCount 이렇게 구성되어 있습니다.

image의 종류에 따라 메모리가 크게 변할 수 있음.)

(Before, After는 서로 비슷한 환경에서 테스트함.)

Before

After

적용 전엔 메모리 사용량이 점점 증가했다면, 적용 후엔 오히려 감소하는 걸 볼 수 있습니다.

(테스트 당시에 데이터 개수가 많지는 않았습니다.)

좀 더 많은 데이터를 갖고 체크해 봤습니다.

(Before, After와 다른 환경입니다. (데이터 크기, 내용..))

데이터가 많아도 한 번에 모든 데이터를 로드하지 않고,

정해진 범위 내의 데이터만 로드하기 때문에 효율적으로 메모리를 관리할 수 있는 것 같습니다!

추가로 참고하면 좋은 것

- 애플 기본 갤러리에 있는 이미지는 생각보다 많은 메모리를 차지한다.

- 스크롤 속도에 따라 그래프 모양은 달라질 수 있으니 참고하시길..

[Tuist] Tuist Action 사용하기 [with. fetch Error]

도현D — Mon, 1 May 2023 09:30:47 +0900

기존에 Github Action으로 CI를 구축할 땐 아래처럼 yml을 작성했습니다.

name: Swift

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: macos-latest

    steps:
    - uses: actions/checkout@v3
      with:
        xcode-version: latest
    - name: install tuist
      run: curl -Ls https://install.tuist.io | bash
    - name: project Generate
      run: |
        rm -rf .package.resolved
        tuist generate
    - name: Build
      run: |
        xcodebuild -project Choice.xcodeproj -scheme Choice -destination 'platform=iOS Simulator,name=iPhone 11 Pro,OS=latest'

하지만 Tuist 에선 Tuist Action 이라는 것을 지원하는데요,

Tuist Action 을 사용하면 더욱 간결한 코드를 아래와 같이 작성할 수 있습니다.

name: Swift

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:
    name: Build
    runs-on: macos-latest
    steps:
        - uses: actions/checkout@v3
        - uses: tuist/tuist-action@0.13.0
          with:
            command: 'fetch'
            arguments: ''
        - uses: tuist/tuist-action@0.13.0
          with:
            command: 'build'
            arguments: ''

actions/checkout@v3

checkout 은 Github 에 올라가 있는 코드를 CI 서버로 내려받는 것이라고 이해할 수 있습니다.

즉 Github Action 을 쓸 때 이 checkout 명령어는 필수적이다라고 생각하면 될 것 같습니다.

뒤에 @v3 는 버전이므로 되도록 최신버전에 맞추는 것을 추천드립니다.

(Tuist 는 버전이 자주 바뀌어서 팀원들과 맞추는 게 좋다고 하네요)

tuist/tuist-action@0.13.0

이 액션을 사용하면 프로젝트를 빌드, 배포하기 위해 필요한 구성을 직접 할 필요가 없습니다.

기존 yml처럼 tuist 를 설치하고 generate 하고 어떻게 run 할 건지 직접 할 필요가 없는 것입니다!

- fetch

외부 Dependency 를 불러오는 작업입니다.

- build

프로젝트를 빌드합니다.

build 과정에선 코드의 warning과 Error에 대한 설명을 해주는 것 같습니다.

이렇게 따라해도 몇몇 분들은 에러가 나실 텐데..

만약,

Error: command failed: /Users/runner/work/Project_name/tuistexec fetch

와 같은 fetch 과정에서 에러가 난다면

현재 tuist version을 확인해야 합니다.

1. tuist local

명령어를 통해 로컬 환경 버전을 찾습니다.

2. tuist local 최신버전

명령어를 통해 local version을. tuist-version에 생성해 줍니다.

이렇게 해주면. tuist-version 파일이 생기고 내부에는 위에서 설정해 준 local version 이 쓰여있습니다.

이제 이걸 commit -> push 해주면 CI 가 다시 실행되면서 에러가 해결됩니다!

ref.

https://github.com/tuist/tuist-action/issues/6

https://docs.tuist.io/guides/continuous-integration/#github-actions

[Swift] firebase - 이메일 중복 검사

도현D — Wed, 12 Apr 2023 12:04:58 +0900

firebase에서 이메일 중복을 검사하는 메서는 따로 없는 것 같더라고요..

그래서,

이렇게 해봤습니다.

먼저 FirebaseAuth를 import 해야겠죠?

그다음 아래와 같은 코드를 작성합니다.

forEmail에 검사하고 싶은 email(String type)을 넣습니다.

Auth.auth().fetchSignInMethods(forEmail: "test_email") { arg, error in
    if let arg = arg {
        print("등록됨")
    } else {
        print("등록 안 됨")
    }
}

Authentication에 등록된 이메일이라면 if, 등록되지 않았다면 (사용가능) else가 실행됩니다.

arg를 출력해 보면

- 등록된 이메일이 아니다? = nil

- 등록된 이메일이다? = Optional(["password"])

가 출력됩니다.

[UITest] password textFiled 에 tap 이 안 될 때?

도현D — Tue, 4 Apr 2023 17:57:13 +0900

이걸로 하루의 절반을 날렸습니다..

    private let inputPasswordTextField = UITextField().then {
        $0.accessibilityIdentifier = "inputPasswordTextField"
        $0.placeholder = "비밀번호"
        $0.layer.borderColor = UIColor.clear.cgColor
        $0.layer.borderWidth = 1
        $0.setPlaceholder(color: UIColor.gray)
        $0.layer.cornerRadius = 8
        $0.isSecureTextEntry = true
        $0.backgroundColor = .blue
    }

현재 제 passwordTextField 는 이렇습니다.

이를 바탕으로 UITest 를 시도했습니다.

    override func setUpWithError() throws {
        // Put setup code here. This method is called before the invocation of each test method in the class.

        // In UI tests it is usually best to stop immediately when a failure occurs.
        continueAfterFailure = false
        
        app = XCUIApplication()
        app.launch()

        skipButton = app.buttons["Skip"]
        emailTF = app.textFields["inputEmailTextField"]
        passwordTF = app.textFields["inputPasswordTextField"]
        signInButton = app.buttons["signInButton"]
    }

    func testSignInViewController_notRegistedUser_isVisibleWarningLabel() {
        skipButton.tap()
        emailTF.tap()
        emailTF.typeText("asdf123@naver.com")
        app.tap()
        
        passwordTF.tap()
        passwordTF.typeText("12345678")

        XCTAssertEqual(signInButton.isEnabled, true)
    }

하지만 이러한 에러를 마주했습니다ㅠㅠ..

이유는..

inputPasswordTextField 의 isSecureTextEntry 가 True 이기 때문입니다.

해결 방법은

passwordTF = app.secureTextFields["inputPasswordTextField"]

이렇게 isSecureTextEntry 가 True 라면 secureTextFields 로 설정해주면 에러를 해결할 수 있습니다.

이런걸로 삽질했다는게 너무 허무하네요..