멋있게걷는방법

가장 큰 차이는 참조 카운팅 시점. GC 런타임 중에 메모리 해제 시점을 결정함. - 이미 할당된 메모리에서 더 이상 사용하지 않는 메모리를 해제하는 기술. 런타임에 동작. 백그라운드에서 실행. 불확실한 간격으로 발생하기 때문에, 객체가 더 이상 사용되지 않는 정확한 순간에 무조건 해제되는 건 아님. 발생시점 각 영역에 할당된 크기의 메모리가 허용치를 넘을 때 수행됨. ⇒ 개발자가 컨트롤할 수 없다. 왜? ⇒ 강제로 GC를 수행시키면 GC를 실행하는 동안 해당 스레드를 제외하고 모든 스레드가 멈춰서 성능에 영향을 줄 수 있다. 성능 저하가 발생할 수 있음. 런타임에 계속해서 메모리를 감시하다가 해제하기 때문이다. 순환참조 발생 X 계속해서 메모리를 감시하기 때문에 인스턴스가 해제될 가능성이 더 높다. 장..

기본적으로 super 키워드는 상위 뷰를 호출합니다. 예를 들어볼게요. class A: UITableViewCell { override func layoutSubviews() { super.layoutSubviews() } } 만약 제가 UITableViewCell을 상속하고 있는 A라는 클래스에 있는 layoutSubview override 함수에서 super를 통해 super.layoutSubviews()를 호출했다면 어떤 뷰가 실행될까요? super는 상위 뷰를 호출한다고 했죠? 현재 상속 중인 클래스는 UITableViewCell입니다. 그럼 호출되는 건 UITableView의 상위 뷰인 UIView의 layoutSubviews가 호출되겠죠! super 가 뭘 하는 녀석인 줄은 알고 있었지만 이렇..

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 이면 성공. 와 같은 로직을 작성해야 한다. 서버에서 이러한 로직이 있다면, 앱 심사 정보 메모에..

저의 두 번째 프로젝트를 개발, 출시하며 들었던 생각과 고민들에 대해 적어보려고 합니다. 이 프로젝트는 원래는 한 달짜리 프로젝트였지만, TestFlight를 통해 팀원끼리 테스트도 하며 피드백을 통해 요구사항을 추가됐고, 디자인도 변경되면서 기간이 길어졌습니다. 팀원들은 '일단 배포하고 v2에서 고치자~'라는 말을 자주 했는데요. 사실 이 말이 어쩌면 맞을지도 모릅니다. 빠른 앱 출시를 시도한다면, 앱스토어 배포 과정에서도 reject 사유를 알 수 있고, 또 만약 reject 없이 바로 앱이 출시된다 하더라도 사용자들로부터 얻는 피드백을 통해 앱의 퀄리티를 높일 수도 있겠죠. (reject 사유를 알 수 있다는 건 큰 이점이란 걸 이번에 reject을 4번 당하면서 깨달았습니다. ㅎㅎ) 그러나 제 생..

프로젝트에 단순 데이터를 불러오는 게 아닌, page 단위로 불러오면 메모리 효율을 아낄 수 있는데요, 이게 바로 Pagination 입니다. 무한스크롤이라고도 하죠. Pagination 은 메모리 효율을 아낄 수 있다고 했는데, 그 이유는 뭘까요? 들어가기 전에, tableView의 delegate, datasource로 tableView를 구성했다면 대부분 dequeueReusableCell를 이용해 재사용 셀을 구성했을 겁니다. 만약 Rx를 쓴다면? .drive(postTableView.rx.items(cellIdentifier: PostCell.identifier, cellType: PostCell.self)) { (row, data, cell) in 이런 식으로 쉽게 구현할 수 있었을 것입니다...

기존에 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 -p..

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 - 등록된 이메일이다? = ..

이걸로 하루의 절반을 날렸습니다.. 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 를 시..