멋있게걷는방법

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

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

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

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