앱 개발시 유닛테스트에 대한 생각과 경험

Fri, 09 May 2025 00:00:00 +0900

앱 개발시 유닛테스트에 대해 제 경험과 생각을 공유 드립니다. 유닛테스트를 언제, 어떻게 사용할지 감을 잡으시는데 도움이 되면 좋겠습니다.

1. 유닛테스트, 통합 테스트, UI 테스트 사용 경험은? → 유닛테스트만 사용해봤습니다.

2. 유닛테스트는 꼭 써야 할까? → No!. 필요한 경우에 한해 사용하는 것이 합리적이라고 봅니다. 그동안 다양한 개발자들과 일했는데, 유닛테스트를 사용하는 개발자는 저 포함 10% 이하 였습니다.

3. 유닛테스트를 사용하지 않는 이유는?

테스트 코드 작성 대비 효율이 낮음
테스트를 위해 아키텍처나 코드를 변경해야 하는 경우가 많음
비즈니스 가치 증대를 위해 코드를 작성하는게 아니라 테스트 코드 작성을 위해 코드를 변경해야 한다고? 주객이 전도 된건 아닐까?
유닛테스트 유지보수 투여되는 자원이 부담됨
코드를 변경하면 많은 경우 유닛테스트가 에러나서 유닛테스트 코드도 함께 변경해야 함
테스크 코드 작성을 위해 앱 구조를 바꾸더라도 테스트하기 어려운 케이스는 여전히 존재함
결국 사람이 손으로 테스트해야 하는 상황은 피할 수 없음

종합: 작성에 시간이 많이 들고, 유지보수에 노력이 들고, 어떤 경우 테스트 코드 작성이 매우 어려움. -> 그래서 저는 필요한 경우에만 사용했습니다.

4. 테스트 커버리지는 몇 %가 적당할까? → 특정 퍼센트를 목표로 하기보다는 필요한 부분에만 적용하면 된다고 생각합니다. 예를 들어, 전체 코드 중 5%만 테스트가 필요하다면 그 5%만 테스트해도 충분하다고 봅니다.

5. 유닛테스트가 필요한 경우는 언제일까? (feat: 나는 언제 유닛테스트를 사용했나?) → 중요한 로직이면서 테스트 해야하는 케이스가 많고, 테스트가 비교적 쉬운 경우에 유용하다고 생각합니다. 저는 다양한 입력 조합에 따라 결과가 달라지는 중요한 로직의 검증에 유닛테스트를 활용했습니다. 회사 근무 마지막 5년 동안 유닛테스트를 사용했던 경우는 세 번 있었습니다. 그 사례는 아래와 같습니다.

(사례1) 예약서비스 날짜/시간 표시 로직 검증 예약 서비스 개발 시 날짜는 사용자가 정확한 이용 시점을 인지하는 데 중요한 정보입니다. 비즈니스 요구 사항은 날짜를 오늘을 기준으로 조건에 따라 “상대적인 날짜 혹은 절대적인 날짜로 표시해 달라”였습니다. 이 조건을 충족시키기 위해 유닛테스트를 사용해 구현한 코드의 로직을 검증했습니다. [사례]

오늘을 기준으로 2일 이하 차이 나는 경우 -> 상대적인 날짜로 표시
- 어제, 그제, 오늘, 내일, 모레
오늘을 기준으로 2일을 초과해 차이 나는 경우 -> 절대적인 날짜로 표시
- 2050년 5월 20일, 2050년 5월 19일

(사례2) 이동 예상 요금 계산 로직 리팩토링 후 검증 이동 서비스(예: 택시)의 예상 요금은 사용자에게 중요한 정보입니다. 요금에 따라 이동 수단을 선택하기도 하고, 예상 요금과 실제 청구된 요금이 차이가 크면 컴플레인을 하거나 서비스에 대한 신뢰가 떨어질 수 있습니다.

예상 요금을 계산하는 로직에 다양한 조건이 지속적으로 추가되면서 요금 계산 로직이 점점 복잡해졌습니다. 결국 요금 계산 코드를 정리하는 리팩토링을 진행했고 코드 변경 후 기존 로직과 동일한 결과를 보장하기 위해 유닛테스트를 수행해 검증했습니다.

[예상 요금 계산 시 고려된 요소들]

호출비 (이용하는 이동 수단의 종류에 따라 다름, 할인/무료일 수도 있음)
운행 요금 (일반, 할증)
통행료
쿠폰 (정액, 정률)
기타 다양한 조건

유닛테스트 없이 리팩토링을 진행했다면 50개가 넘는 조합이 만들어지는 예상 요금 계산 코드를 올바르게 작성했는지 확신하기 어려웠을 것입니다. 하지만 유닛테스트를 통해 결과 값을 검증할 수 있었기 때문에 안심하고 리팩토링을 마무리할 수 있었습니다.

(사례3) 광고 코드 생성 로직 특정 화면에서 이용 중인 이동 수단과 결제 수단에 따라 배너 광고를 다르게 노출해달라는 요청이 있었습니다. 광고는 회사의 주요 수익원 중 하나였고, 잘못 노출될 경우 광고팀은 물론 광고를 의뢰한 외부 클라이언트에게도 소명을 해야하는 번거로운 상황이 생길 수 있었기 때문에, 오류 없이 정확하게 처리하는 것이 중요했습니다.

광고 배너를 노출하기 위해서는 서버로부터 배너 코드를 수신해야 했는데, 이를 위해 이동 수단과 결제 수단의 종류, 알파/리얼 환경 여부를 파라미터로 전달해야 했습니다. 이렇게 생성 가능한 파마미터의 조합 많아지는 상황이었기 때문에, 조건에 따라 올바른 광고 배너 코드가 생성되는지 검증하는 일이 중요했습니다.

테스트한 조건 예시:

이동수단A/결제타입1/알파
이동수단A/결제타입1/리얼
이동수단A/결제타입2/알파
이동수단A/결제타입2/리얼
이동수단B/결제타입1/알파
이동수단B/결제타입1/리얼
…

이러한 로직은 유닛 테스트를 활용하면 안정적으로 검증할 수 있을 것이라 판단했고, 실제로 다양한 조건에 대해 테스트를 수행해 광고 코드가 정확하게 생성되는 것을 확인할 수 있었습니다.

6. 개인 프로젝트에서의 유닛테스트 경험 API EndPoint가 30개 이상이고 데이터 모델도 많은 개인 프로젝트를 진행하면서, QA 시간을 줄이고 안정성을 확보하고자 테스트 커버리지가 80% 이상이 될 정도로 많은 테스트 코드를 작성했습니다. 이렇게 테스트 작성에 시간을 많이 들였는데, 프로젝트는 결국 성공하지 못했습니다. 만약 지금 다시 한다면, 유닛테스트 작성은 줄이고 필요한 부분에만 최소한으로 작성했을 것 같습니다.

결 론

유닛테스트는 필요할 때 적절히 사용하면 매우 유익한 도구라고 생각합니다. 이상으로 저의 앱 개발시 유닛테스트에 대한 생각과 경험이었습니다.

즐코하세요~ 😄

SwiftData에서 모델링 시 왜 struct가 아닌 class를 사용할까?

Fri, 09 May 2025 00:00:00 +0900

SwiftData에서 모델링은 왜 struct를 사용하지 않고 class를 사용할까요? 간단하게 정리하면 SwiftData 모델은 데이터의 동일성과 상태 추적을 위해 class를 사용합니다. 자세한 내용은 아래와 같습니다.

SwiftData에서 모델링에 `struct`가 아닌 `class`를 사용하는 이유

1. 한 곳에서 데이터를 변경하면 변경이 데이터가 사용되는 모든 곳에 반영되도록 하기 위해

클래스를 사용하면 뷰가 데이터가 어디에서 왔는지, 데이터를 어디로 보내야하는지, 데이터를 동기화 해야하는지 알 필요 없음 (값 타입이 아니라 참조를 사용하기 때문)
구조체(값 타입)를 사용하는 경우 데이터를 받은 뷰가 변경된 데이터를 원래 위치로 다시보내거나, 데이터를 소유자가 보냈던 데이터를 뷰로 다시 가져와야 함.
ObservableObject 과 @Observable 타입도 같은 이유로 클래스를 사용함

2. 모델은 다른 모델과 관계(relationship)를 가짐

만약 구조체(값 타입)를 사용하게 되면 어떤 모델을 가져올 때 관계도 값으로 같이 복사해서 가져와야 함
- (예) Employee 구조체가 Manager혹은 다른 Empolyee와 연결돼 있다면 Employee 하나를 가져오기 위해 연결된 Manager나 Manager의 다른 관계를 전부 복사해야 할 수도 있음
- 관계가 얽인 구조체 하나를 완성하려면, 전체 데이터베이스를 복사해서 스냅샷처럼 만들어야할 수도 있음

참고

[책 소개] 토미의 Git with 소스트리

Sun, 01 May 2022 00:00:00 +0900

토미의 Git with 소스트리

[책 구매 링크]

종이책
- 알라딘
- YES24
- 부크크
- 교보
전자책

목 차

1. 페이지 소개

이 페이지에서는 책 내용 중 1. 이 책의 대상 독자, 2. 목차, 3. 샘플 챕터 미리 보기를 제공합니다. Full 버전의 미리보기를 보고 싶으신 분은 토미의 Git with 소스트리 (미리보기) 를 다운로드 해서 보시기 바랍니다.

토미의 Git with 소스트리 (미리보기).pdf

2. 이 책의 대상 독자

이 책은 다음에 해당하는 분들을 위해 쓰여졌습니다.

Git을 처음 접하시는 분
Git을 제대로 알고 싶으신 분
- 브랜치의 정의
- 머지와 리베이스의 차이
- 리셋과 리버트의 차이
- 머지시 충돌 발생 이유와 해결 방법
- 로컬저장소와 원격저장소
- 원격저장소 추적 브랜치
- 잃어버린 커밋 복원하기
Git의 내부 구조를 알고 싶으신 분
- Git이 어떤 객체로 구성돼 있는지
- 저장소의 구조와 역할
- 커밋의 해시는 어떻게 생성되는지
Git을 더 잘 활용하고 싶으신 분
- 레프로그
- 리베이스를 사용한 풀 - 패치
- 어멘드

3. 목차

Part I. Git 개념 이해하기 (Understanding Git Concepts)

1) 버전 관리 시스템의 역사 (History of Version Control System)

2) 델타 모델과 스냅샷 모델 (Delta Model and Snapshot Model)

3) Git의 객체 (Git Object Types)

4) 저장소 구조 (Repository Structure)

Part II. Git 사용 하기 (Using Git)

5) Git 사용 환경 (Environment for Git)

6) 브랜치 (Branch)

7) 변경 사항 되돌리기 (Undoing Changes)

8) 머지 (Merge)

9) 충돌처리 (Resolve Conflicts)

10) 리베이스 (Rebase)

11) 원격저장소 (Remote Repository)

12) 잃어버린 커밋 복원하기 (Reflog)

13) 팁 & 트릭 (Tip & Trick)

4. 샘플 챕터(리베이스)

“토미~ 안녕하세요?”

“네~ 안녕하세요?”

“다음 배포 때, 그동안 개발했던 자율주행 이동 수단을 포함해 나갈 수 있을까요?”

“자율주행 이동 수단이라면 택시, 버스, 배, 비행기, 자전거 말씀하시는 거죠?”

“네 맞아요. 모든 이동 수단을 사용할 수 있도록 서비스에 반영하고 싶어요. 가능할까요?”

“네~ 물론이죠.”

토미는 이동 수단별로 각기 다른 브랜치에서 개발했기 때문에 배포시 필요에 따라 모든 기능을 포함시키거나 일부만 포함시킬 수 있었습니다.

‘자~ 그럼 각 기능 브랜치를 배포할 브랜치에 머지 해볼까?’

‘짜잔~ 머지 완료! 이렇게 배포할 브랜치에 머지가 끝났으니 배포 준비 완료됐네?’

‘역시! 나 토미야! ᄏ’

토미는 스스로 대견해하며 만족스러운 미소를 띠었습니다. 하지만 이내 한 가지가 눈에 들어 왔습니다.

‘가만있자! 이거 기능적으로는 문제가 없는데, 여러 브랜치가 하나의 브랜치에 머지되니 히스토리가 복잡해 보이네. 이걸 개선할 수 있는 방법은 없을까?’

토미는 성공적으로 각 기능을 배포 브랜치에 머지 했지만, 머지된 후 Git의 커밋 히스토리가 마음에 들지 않았습니다.

‘아… 이거 보면 볼수록 복잡해 보인다. 정리하고 싶은데, 이것도 무슨 방법이 있겠지? 어떤 방법이 있는지 한번 알아봐야겠다.’

10.1 개요

챕터 8에서 브랜치를 합치는 방법 중 하나인 머지에 대해 살펴보았습니다. 때때로 브랜치를 합칠 때 머지 대신 다른 방법을 사용해야할 때가 있습니다. 이번 챕터에서는 리베이스에 대해 살펴보겠습니다. 앞에서 토미가 겪었던 상황을 예를들어 보겠습니다.

아래 [그림 10-1]과 같이 머지 시킬 브랜치(develop)와 이 브랜치에 여러 기능을 포함시키기 위해 머지할 FeatureA, FeatureB, FeatureC 세 개의 브랜치가 있습니다.

[그림 10-1] develop에 머지 할 세개의 Feature 브랜치

FeatureA, FeatureB, FeatureC 브랜치를 각각 순서대로 develop 브랜치에 머지시키면 Git 의 커밋 히스토리는 [그림 10-2]와 같은 모습이 됩니다.

[그림 10-2] develop에 세 개의 Feature 브랜치를 머지한 후 커밋 히스토리

develop 브랜치에는 FeatureA, FeatureB, FeatureC 각 브랜치의 변경사항이 반영된 상태입니다. 그래서 기능상으로는 문제가 없습니다. 하지만 히스토리가 조금 복잡해 보입니다. 만약 develop에 머지된 브랜치가 3개가 아니라 5개 혹은 10개라면 히스토리는 훨씬 더 복 잡하게 보일 것입니다.

이런 상황에서 머지대신 리베이스를 사용하면 아래 [그림 10-3]과 같이 브랜치를 머지커밋 생성없이 일렬로 된 형태로 브랜치를 합칠 수 있어서 Git의 커밋 히스토리를 간결하게 관리 할 수 있습니다.

[그림 10-3] 세 개의 Feature 브랜치를 develop 브랜치에 리베이스로 반영 후 커밋 히스토리

이번 챕터에서는 이 리베이스에 대해 알아 보겠습니다.

10.2 리베이스란?

일반적으로 브랜치는 브랜치의 시작점이 되는 base(부모)가 존재 합니다. 리베이스는 브랜치의 base를 변경해 브랜치를 합치는 방법입니다.

[그림 10-4] 리베이스 전/후 커밋 히스토리

위 [그림 10-4]의 왼쪽 리베이스 전 그림에서 Feature 브랜치의 base는 C1 커밋입니다. Feature를 develop와 합치기 위해 리베이스를 수행합니다. 리베이스를 하면 [그림 10-5]의 오른쪽 그림 같이 Feature의 base가 C1에서 C7로 변경되고 두 브랜치가 일렬로된 형태로 합쳐집니다.

10.3 리베이스의 동작

리베이스를 수행하면 내부적으로는 각 커밋별로 패치를 생성해 순서대로 다른 브랜치에 적용합니다. 리베이스 후 마치 커밋이 원본 브랜치에서 다른 브랜치로 base만 바뀌어서 이동 한 것 처럼 보이지만 실제로는 같은 메시지와 변경사항을 포함한 새로운 커밋이 생성돼 재적용된 것입니다.

[그림 10-5] 리베이스의 동작 과정

위 [그림 10-5]는 Feature 브랜치를 develop 에 리베이스하는 과정입니다. Feature 브랜치를 develop에 리베이스 해서 C2, C3, C4 커밋이 develop 에 적용됐습니다. 여기서 주의깊게 보실 것은 C2, C3, C4 커밋이 develop에 그대로 옮겨진 것이 아니라 각각 C2’, C3’, C4’ 로 변경됐다는 것입니다.

앞서 설명드린바와 같이 리베이스를 수행하면 커밋이 그대로 이동하는 것이 아니라 새로 생성됩니다. 그렇기 때문에 리베이스로 생성된 커밋은 원본 커밋과 해시가 다른 커밋이 됩니다. 커밋의 해시가 다르기 때문에 Git이 봤을때 C2, C3, C4는 C2’, C3’, C4’와 각각 다른 커밋 입니다. 커밋을 새로 생성하면 왜 다른 커밋이 되는걸까요? 커밋 메시지나, 커밋 작성자 등 정보는 동일한데 말이죠?

앞의 챕터3.6에서 커밋의 아이디인 SHA-1가 어떻게 만들어지는지 살펴봤었습니다. Git은 커밋을 SHA-1로 구분하는데 커밋의 SHA-1을 생성하는데 사용하는 요소에 커밋 생성시간과 부모 커밋이 포함된다고 말씀드렸습니다. 위 [그림 10-5] 에서는 리베이스를 수행해서 커밋이 재생성됐는데 커밋을 재생성 했기 때문에 커밋 생성시간이 변경 되었고, base가 변경 됐기 때문에 C2, C3, C4 커밋의 부모 커밋도 각각 C1, C2, C3에서 C7, C2’, C3’ 으로 바뀌었습니다. 리베이스 되면서 커밋의 두 가지 정보가 변경 됐기 때문에 리베이스 된 커밋은 이전 커밋과 SHA-1가 다른 완전히 다른 커밋입니다.

10.4 리베이스시 주의사항

리베이스시 원본 커밋이 버려지고 새로운 커밋이 생성되기 때문에 리베이스는 일반적으로 개인저장소에서만 수행해야 합니다. 만약 다른 팀원과 함께 사용하는 공용저장소의 커밋을 리베이스하면 공용저장소의 커밋 히스토리가 꼬이게 됩니다.

A라는 사람은 리베이스 전의 커밋에 이어서 커밋을 생성하고, B라는 사람은 리베이스 후의 커밋에 이어서 작업을 했다면 나중에 두 커밋 히스토리는 일반적인 방법으로는 합칠 수 없는 상태가 돼 버립니다. 그렇기 때문에 리베이스는 공용저장소에 푸시된 적이 없는 커밋에만 사용해야 합니다. 그렇다면 공용저장소에 푸시된 커밋은 절대 리베이스를 하면 안되는걸 까요?

꼭 그렇지는 않습니다. 여럿이 협업을 하다보면 공용저장소의 내용을 리베이스 하고 싶을 때 가 생기는데 그때는 먼저 동료들에게 리베이스할 브랜치에 아직 푸시하지 않은 내용이 있다면 푸시해 달라고 요청합니다. 그 후 리베이스를 완료하기 전에 그 브랜치에 새로운 커밋을 푸시하지 말라고 요청합니다. 이렇게 서로 합의를 한 후 리베이스를 진행하고, 리베이스가 완료되면 공용저장소에 푸시를 하고 동료들에게 리베이스가 완료됐다고 상황을 공유합니 다. 이 후 다른 동료들은 해당 브랜치를 로컬에서 삭제 후 다시 체크아웃해서 사용하면 됩니다.

비록 이렇게 공용저장소에 반영된 커밋을 리베이스 할 수 있지만, 특수한 상황을 제외하고 리베이스는 공용저장소에 푸시된 적이 없는 커밋에 대해서만 수행해야 합니다.

10.5 머지와 리베이스의 차이점

머지와 리베이스 두 명령 모두 결국 브랜치를 합치는 일을 하는 것인데, 두 명령어는 어떤 차이가 있을까요?

첫째, 머지는 커밋 히스토리를 변경하지 않습니다. Fast Forward 머지인 경우 커밋을 변경 하거나 새로운 커밋을 추가하지 않습니다. Three Way 머지는 새로운 커밋을 추가하지만 이전 커밋을 변경하지는 않기 때문에 언제든 예전 커밋의 상태로 돌아갈 수 있습니다. 반면 리베이스는 옛날 커밋을 버리고 새로운 커밋을 생성하기 때문에 일반적인 방법으로는 예전의 커밋으로 되돌아 갈 수 없습니다

둘째, 머지는 한번에 수행되는 명령입니다. 그래서 머지 중 충돌이 발생한 경우 한번의 처리로 충돌 해결이 가능합니다. 반면 리베이스는 리베이스 되는 커밋을 각각 재생성해 적용하기 때문에 리베이스시 충돌이 발생한 경우 충돌 처리를 여러번에 걸쳐 나눠서 처리해야 하는 상황이 발생할 수 있습니다.

셋째, Three Way 머지를 사용하는 경우 리베이스를 했을 때 보다 커밋 히스토리가 복잡합니다. 이 점이 보통 브랜치를 합칠 때 머지 대신 리베이스를 사용하는 가장 큰 이유입니다.

10.6 리베이스의 활용 (Interactive Rebase)

(이후 생략…)

5. 책 구매 링크

종이책
- 알라딘
- YES24
- 부크크
- 교보
전자책

[Swift] @autoclosure란?

Sat, 06 Feb 2021 00:00:00 +0900

정의

@autoclosure는 함수의 인자로 전달되는 코드를 감싸서 자동으로 클로저로 만들어 줍니다. 다시말해 일반 표현의 코드를 클로저 표현의 코드로 만들어 주는 역할을 합니다.

이때 사용되는 클로저는 인자가 없고 리턴값만 존재해야 합니다.

@autoclosure는 기본적으로 non-escaping 클로저로써 만약 여기에 사용되는 클로저가 escaping 클로저라면 @escaping을 함께 붙여줘야합니다.

예제 코드

`@autoclosure`를 사용하지 않은 경우

다음 코드는 클로저를 인자로 받는 함수에 @autoclosure를 사용하지 않은 경우입니다.

func normalPrint(_ closure: () -> Void) {
    closure()
}

normalPrint({ print("I'm Normal Expression") })

이 함수를 호출할 때 클로저 부분은 다음과 같이 대괄호 {...}로 묶어서 인자를 넣어야 합니다.

normalPrint({ print("I'm Normal Expression") })

`@autoclosure`를 사용한 경우

@autoclosure를 이용하면 함수에 클로저를 인자로 사용할때 일반 표현을 사용할 수 있습니다.

func autoClosurePrint(_ closure: @autoclosure () -> Void) {
    closure()
}

autoClosurePrint(print("I'm AutoClosure Expression"))

위에 @autoclosure를 사용하지 않은 코드보다 함수에 클로저를 인자로 넣는 코드가 간결해 졌음을 확인할 수 있습니다.

autoClosurePrint(print("I'm AutoClosure Expression"))

`@autoclosure`의 사용 예

Swift에서 @autoclosure를 사용하는 대표적인 예로 assert()함수가 있습니다.

assert() 함수는 대략 다음과 같이 정의 돼 있는데요. (@autoclosure와 상관없는 코드는 생략)

public func assert(_ condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = String())

assert() 함수는 다음과 같이 호출합니다.

assert(false, "Error Occurred!")
assert(0 < 1, "Error Occurred!")
assert(false, (statusCode == .fileNotFound) ? "File Not Found!" : "Something going wrong!")

이 코드에서 @autoclsoure 를 제거해 보겠습니다.

func assert(_ condition: () -> Bool, _ message: String = String()) { }

그리고 똑같이 위에서 호출한 assert()함수를 모두 호출해 보겠습니다.

assert({ false }, { "Error Occurred!" })
assert({ 0 < 1 }, { "Error Occurred!" })
assert({ false }, {(statusCode == .fileNotFound) ? "File Not Found!" : "Something going wrong!"})

호출 부분의 코드가 좀 더 복잡해진 것을 확인할 수 있습니다.

이렇듯 @autoclosure는 일반 표현의 코드를 클로저 표현의 코드로 변환해서 함수에서 클로저를 인자로 사용할때 보다 쉬운 표현으로 클로저를 사용할 수 있게 해줍니다.

`@autoclosure`의 다양한 활용

다음은 @autoclosure를 이용해 코드를 간결하게 만든 (예) 입니다.

1. `UIView.animate`

@autoclosure 사용전

UIView.animate(withDuration: 0.5) {
   self.view.frame.origin.x = 200
}

@autoclosure 사용하는 UIView를 animate 하는 함수 구현

func animate(_ animation: @autoclosure @escaping () -> Void, duration: TimeInterval = 0.5) {
   UIView.animate(withDuration: duration, animations: animation)
}

이 함수를 사용하면 {...} 구문 없이 같은 에니메이션 코드를 수행할 수 있습니다.

animate(self.view.frame.origin.x = 200)

2. `Dictionary`

다음과 같은 dictionary가 있다고 했을 때

let fruits = ["Apple": 20, "Banana": 30, "Orange": 40]

Apple의 갯수를 얻고자 한다면 dictionary에서 특정 key에 대한 값이 없을 수 있기 때문에 Optional로 반환됩니다. 옵셔널인 Int? 대신 Int로 값을 저장하고 싶다면 ??을 사용해 옵셔널일때의 값을 지정해야 합니다.

let apple = (fruits["Apple"]) ?? 0

코드가 좀 장황해 보입니다. 이 부분을 @autoclosure 사용해 개선할 수 있습니다. 다음과 같은 익스텐션을 생성합니다.

[Int 버전]

extension Dictionary where Value == Int {
    func value(forKey key: Key, defaultValue: @autoclosure () -> Int) -> Int {
        guard let value = self[key] else { return defaultValue() }

        return value
    }
}

[Generic 버전]

extension Dictionary {
    func value<T>(forKey key: Key, defaultValue: @autoclosure () -> T) -> T {
        guard let value = self[key] as? T else { return defaultValue() }

        return value
    }
}

이 익스텐션을 사용하면 위의 Dictionary에서 특정 키값에 접근하고, 키값이 없을시 기본 값을 갖는 코드를 다음과 같이 표현할 수 있습니다.

let apple = fruits.value(forKey: "Apple", defaultValue: 0)

정리

@autoclosure를 사용하면 장황해 보이는 코드를 보다 간결하게 보이도록 만들 수 있습니다. 하지만 남용하면 오히려 코드의 가독성을 해칠 수 있기 때문에 꼭 필요한 곳에 적절히 사용하는 것이 좋습니다.

이상으로 @autoclosure에 대해 살펴봤습니다.

👨🏻‍💻지식이 +2 늘었다. 다음 포스트에서 또 만나요 🚀😄

[참 고]

[Swift] Escaping 클로저 (@escaping)

Sun, 31 Jan 2021 00:00:00 +0900

정의

Escaping 클로저는 클로저가 함수의 인자로 전달됐을 때, 함수의 실행이 종료된 후 실행되는 클로저 입니다. Non-Escaping 클로저는 이와 반대로 함수의 실행이 종료되기 전에 실행되는 클로저 입니다.

Non-Escaping Closure

그럼 이 클로저(closure)는 어떤 클로저 일까요?

func runClosure(closure: () -> Void) {
 closure()
}

클로저가 실행되는 순서를 보면

클로저가 runClosure() 함수의 closure 인자로 전달됨
함수 안에서 closure() 가 실행됨
runClosure() 함수가 값을 반환하고 종료됨

이렇게 클로저가 함수가 종료되기 전에 실행되기 때문에 closure는 Non-Escaping 클로저 입니다.

Escaping Closure

이 경우는 어떨까요?

class ViewModel {
    var completionhandler: (() -> Void)? = nil
    
    func fetchData(completion: @escaping () -> Void) {
        completionhandler = completion
    }
}

클로저가 실행되는 순서를 보면

클로저가 fetchData() 함수의 completion 인자로 전달됨
클로저 completion이 completionhandler 변수에 저장됨
fetchData() 함수가 값을 반환하고 종료됨
클로저 completion은 아직 실행되지 않음

completion은 함수의 실행이 종료되기 전에 실행되지 않기 때문에 escaping 클로저, 다시말해 함수 밖(escaping)에서 실행되는 클로저 입니다.

escaping 클로저가 사용되는 흔한 예로는 비동기로 실행되는 HTTP Request CompletionHandler이 있습니다.

func makeRequest(_ completion: @escaping (Result<(Data, URLResponse), Error>) -> Void) {
  URLSession.shared.dataTask(with: URL(string: "http://jusung.github.io/")!) { data, response, error in
    if let error = error {
      completion(.failure(error))
    } else if let data = data, let response = response {
      completion(.success((data, response)))
    }
  }
}

makeRequest() 함수에서 사용되는 completion 클로저는 함수 실행 중에 즉시 실행되지 않고, URL 요청이 끝난 후 비동기로 실행 됩니다. 이 경우에도 completion의 타입에 @escaping 을 붙여서 escaping 클로저라는 것을 명시해줘야 합니다.

보통 클로저가 다른 변수에 저장되어 나중에 실행되거나 비동기로 실행될 때 escaping 클로저가 사용됩니다.

Non-Escaping Closure 와 Escaping Closure

그럼 함수에 @escaping 가 붙은 클로저에는 반드시 escaping 클로저만 인자로 사용해야 할까요?

그렇지는 않습니다. @escaping이 붙어 있어도 다음과 같이 non-escaping 클로저를 인자로 넣을 수 있습니다.

func runClosure(closure: @escaping () -> Void) {
 closure()  // ✅ closure는 non-escaping 클로저이지만 @escaping 사용 가능
}

반대로 escaping 클로저를 @escaping 없이 사용할 수 없습니다.

class ViewModel {
    var completionhandler: (() -> Void)? = nil
    
    func fetchData(completion: () -> Void) { // ❗️@escaping 누락으로 컴파일 에러 발생!
        completionhandler = completion
    }
}

그렇다면 여기서 한가지 궁금한점이 생깁니다. 🤔

클로저 파라미터 타입에 @escaping을 명시하면 escaping 클로저와 non-escaping 클로저를 모두 사용할 수 있는데, 그러면 그냥 모든 클로저 파라미터 타입에 @escaping 를 붙여서 사용하면 되지 않나?

아니 한걸음 더 나가서 복잡하게 non-escaping, escaping 나누지 말고 전부 escaping으로 통일시키고 따로 @escaping을 명시 하지 않아도 Swift에서 모든 클로저의 파라미터 타입을 escaping으로 간주해서 처리하면 될 것 같은데. 뭐하러 escaping, non-escaping을 나누는거지?

이렇게 escaping, non-escaping 클로저를 나눠서 사용하는 이유는 컴파일러의 퍼포먼스와 최적화 때문입니다.

non-escaping 클로저는 컴파일러가 클로저의 실행이 언제 종료되는지 알기 때문에, 때에 따라 클로저에서 사용하는 특정 객체에 대한 retain, release 등의 처리를 생략해 객체의 라이프싸이클(life-cycle)을 효율적으로 관리할 수 있습니다.

반면 esacping 클로저는 함수 밖에서 실행되기 때문에 클로저가 함수 밖에서도 적절히 실행되는 것을 보장하기 위해, 클로저에서 사용하는 객체에 대한 추가적인 참조싸이클(reference cycles) 관리 등을 해줘야 합니다. 이 부분이 컴파일러의 퍼포먼스와 최적화에 영향을 끼치기 때문에 Swift에서는 필요할 때만 escaping 클로저를 사용하도록 구분해 두었습니다.

정리

이번 포스트에서는 “Escaping 클로저 (@escaping)” 에 대해 살펴봤습니다.

👨🏻‍💻지식이 +3 늘었다. 다음 포스트에서 또 만나요 🚀😄

[참 고]

팀에서 사용 중인 Swift Style Guide (코드 컨벤션)

Sun, 24 Jan 2021 00:00:00 +0900

코드 컨벤션이 있으면 협업시 일관성있는 코드를 작성할 수 있어서 코드의 일관성 유지에 좋습니다. 또 다른 사람이 작성한 코드를 읽을 때 코드의 문법보다 로직에 집중할 수 있는 장점이 있습니다.

다음은 저희팀에서 사용 중인 Swift Style Guide입니다. 코드 컨벤션 결정시 참조하시면 좋을 것 같습니다.

이 코드 컨벤션 작성시 다음과 같은 다른 컨벤션을 참조했습니다.

Swift Style Guide

[1. 코드 포매팅]

1.1 임포트

모듈 임포트는 알파벳 순으로 정렬합니다. 내장 프레임워크를 먼저 임포트하고, 빈 줄로 구분해 3rd-party프레임워크를 임포트 합니다.

import UIKit

import SwiftyColor
import SwiftyImage
import Then
import URLNavigator

파일이 필요로하는 최소의 모듈만 임포트 합니다. 예를들어, Foundation으로 충분하면 UIKit은 임포트 하지 않습니다.

✅ Preferred

import UIKit

var view: UIView
var deviceModels: [String]

✅ Preferred

import Foundation

var deviceModels: [String]

⛔️ Not Preferred

import UIKit
import Foundation

var view: UIView
var deviceModels: [String]

⛔️ Not Preferred

import UIKit

var deviceModels: [String]

모듈의 상세까지 지정할 수 있으면 지정합니다.

✅ Preferred

import struct SwiftyJSON.JSON
import struct CoreLocation.CLLocation.CLLocationCoordinate2D

⛔️ Not Preferred

import SwiftyJSON
import CoreLocation

1.2 빈줄

빈 줄에는 공백이 포함되지 않도록 합니다.
모든 파일은 빈 줄로 끝나도록 합니다.

1.3 들여쓰기

탭을 눌렀을시 4개의 space를 사용합니다.
들여쓰기는 Xcode에서 제공하는 ^ + i 를 눌렀을 때, 적용되는 space를 사용합니다.
최대 가로 길이는 100 characters를 사용합니다.

1.4 띄어쓰기

콜론(:)을 사용할때는 콜론의 오른쪽에만 공백을 둡니다.

[상수]

✅ Preferred

let names: [String: String]?

⛔️ Not Preferred

let names: [String:String]?
let names: [String : String]?

[클래스]

✅ Preferred

class MyClass: SuperClass {
  // ...
}

⛔️ Not Preferred

class MyClass : SuperClass {
  // ...
}

삼항연산자의 경우 콜론 앞뒤로 띄웁니다.

✅ Preferred

func application(_ application: UIApplication, supportedInterfaceOrientationsFor window: UIWindow?) -> UIInterfaceOrientationMask {
	return shouldRotate ? .allButUpsideDown : .portrait
}

⛔️ Not Preferred

func application(_ application: UIApplication, supportedInterfaceOrientationsFor window: UIWindow?) -> UIInterfaceOrientationMask {
	return shouldRotate ? .allButUpsideDown: .portrait
}

[기타]

✅ Preferred

// specifying type
let pirateViewController: PirateViewController

// dictionary syntax (note that we left-align as opposed to aligning colons)
let ninjaDictionary: [String: AnyObject] = [
    "fightLikeDairyFarmer": false,
    "disgusting": true
]

// declaring a function
func myFunction<T, U: SomeProtocol>(firstArgument: U, secondArgument: T) where T.RelatedType == U {
    /* ... */
}

// calling a function
someFunction(someArgument: "Kitten")

// superclasses
class PirateViewController: UIViewController {
    /* ... */
}

// protocols
extension PirateViewController: UITableViewDataSource {
    /* ... */
}

if let, guard let 구문이 긴 경우에는 줄바꿈하고 한 칸 들여씁니다.

✅ Preferred

if let user = self.veryLongFunctionNameWhichReturnOptionalUser(),
 let name = user.veryLongFunctionNameWhichReturnsOptionlName(),
 user.gender == .female {
//  ...
 }

guard let user = self.veryLongFunctionNameWhichReturnsOptionalUser(),
  let name = user.veryLongFunctionNameWhichReturnsOptionalName(),
  user.gender == .female else {
  return
}

일반적으로 콤마(,) 뒤에는 공백을 추가합니다.

✅ Preferred

let myArray = [1, 2, 3, 4, 5]

⛔️ Not Preferred

let myArray = [1,2,3,4,5]

연산자 앞뒤로 공백을 추가합니다.

✅ Preferred

let myValue = 20 + (30 / 2) * 3

⛔️ Not Preferred

let myValue = 20+(30/2)*3

화살표 양쪽에 가독성을 위해 빈 공백을 추가합니다.

[함수 리턴 타입]

✅ Preferred

func doSomething() -> String {
  // ...
}

⛔️ Not Preferred

func doSomething()->String {
  // ...
}

[클로저 리턴 타입]

✅ Preferred

func doSomething(completion: () -> Void) {
  // ...
}

⛔️ Not Preferred

func doSomething(completion: ()->Void) {
  // ...
}

[Rx]

✅ Preferred

.map { $0.call.farePaymentType }
.map { method -> String? in
    guard let name = method.name else { return nil }
    return Local.Taxi.taxiDispatchingPaidItemApply.string.phrase(["item_name": name])
}

⛔️ Not Preferred

.map {$0.call.farePaymentType}
.map {method -> String? in
    guard let name = method.name else { return nil }
    return Local.Taxi.taxiDispatchingPaidItemApply.string.phrase(["item_name": name])
}

✅ Preferred

var bizGroupHidden: Driver<Bool> {
    return self.callInfo.asObservable()
        .map { $0.call.bizGroup }
        .map { $0 == nil }
        .asDriverJustComplete()
}

⛔️ Not Preferred

var bizGroupHidden:Driver<Bool> {
    return self.callInfo.asObservable()
        .map { $0.call.bizGroup }
        .map { $0 == nil }
        .asDriverJustComplete()
}

1.5 기타

불필요한 괄호는 생략합니다.

✅ Preferred

if userCount > 0 { ... }
switch someValue { ... }
let evens = userCounts.filter { number in number % 2 == 0 }
let squares = userCounts.map { $0 * $0 }

⛔️ Not Preferred

if (userCount > 0) { ... }
switch (someValue) { ... }
let evens = userCounts.filter { (number) in number % 2 == 0 }
let squares = userCounts.map() { $0 * $0 }

enum의 연관값을 사용하지 않는 경우는 생략합니다.

✅ Preferred

if case .done = result { ... }

switch animal {
case .dog:
  ...
}

⛔️ Not Preferred

if case .done(_) = result { ... }

switch animal {
case .dog(_, _, _):
  ...
}

2. 네이밍

묘사를 잘하고 일관된 네이밍은 코드를 읽고 이해하기 쉽게 해줍니다. 네이밍은 Apple의 API Design Guidelines을 따릅니다.
클래스(타입, 프로토콜 이름 포함) 이름에는 UpperCamelCase(첫 문자를 대문자로 시작하는 camel표기법), 함수 이름에는 camelCase를 사용합니다.

2.1 일반

[일반]

✅ Preferred

protocol SpaceThing {
  // ...
}

class SpaceFleet: SpaceThing {

  enum Formation {
    // ...
  }

  class Spaceship {
    // ...
  }

  var ships: [Spaceship] = []
  static let worldName: String = "Earth"

  func addShip(_ ship: Spaceship) {
    // ...
  }
}

let myFleet = SpaceFleet()

[변수/상수]

일반변수 / 상수인 경우 따로 접두사를 붙이지 않습니다.

✅ Preferred

let maximumNumberOfLines = 3

⛔️ Not Preferred

let kMaximumNumberOfLines = 3
let MAX_LINES = 3

static 상수인 경우 앞에 k를 붙여줍니다.

✅ Preferred

static let kMaximumNumberOfLines = 3

⛔️ Not Preferred

static let maximumNumberOfLines = 3

[열거형]

✅ Preferred

enum Result {
  case success
  case failure
}

⛔️ Not Preferred

enum Result {
  case Success
  case Failure
}

[RxSwift]

RxSwift의 Subject, Driver, ControlerProperty, ControlEvent 등은 따로 접미사를 붙이지 않습니다.

✅ Preferred

let recommendItem = BehaviorRelay<RecommendRideItem?>(value: nil)
let optionSwitch = PublishSubject<Void>()
let showRideSuggestion = PublishSubject<Void>()

⛔️ Not Preferred

let recommendItem = BehaviorRelay<RecommendRideItem?>(value: nil)
let optionSwitchSignal = PublishSubject<Void>()
let showRideSuggestionPS = PublishSubject<Void>()

일반적인 부분이 앞에두고 구체적인 부분을 뒤에 둡니다.

✅ Preferred

let titleMarginRight: CGFloat
let titleMarginLeft: CGFloat
let bodyMarginRight: CGFloat
let bodyMarginLeft: CGFloat

⛔️ Not Preferred

let rightTitleMargin: CGFloat
let leftTitleMargin: CGFloat
let bodyRightMargin: CGFloat
let bodyLeftMargin: CGFloat

생략시 사용이 모호해지는 타입은 이름에 타입에 대한 힌트를 포함시킵니다.

✅ Preferred

let titleText: String
let cancelButton: UIButton

⛔️ Not Preferred

let title: String
let cancel: UIButton

2.2 클래스

함수 이름에는 되도록 get을 붙이지 않습니다.

✅ Preferred

func name(for user: User) -> String?

⛔️ Not Preferred

func getName(for user: User) -> String?

2.3 함수

액션 함수의 네이밍은 ‘주어 + 동사 + 목적어’ 형태를 사용합니다.
- will은 특정 행위가 일어나기 직전이고, did는 특정 행위가 일어난 직후입니다.

✅ Preferred

func backButtonDidTap() {
  // ...
}

⛔️ Not Preferred

func back() {
  // ...
}

func pressBack() {
  // ...
}

2.4 약어

약어로 시작하는 경우 소문자로 표기하고, 그 외 경우에는 항상 대문자로 표기합니다.

[예1]

✅ Preferred

  let userID: Int?
  let html: String?
  let websiteURL: URL?
  let urlString: String?

⛔️ Not Preferred

let userId: Int?
 let HTML: String?
 let websiteUrl: NSURL?
 let URLString: String?

[예2]

✅ Preferred

class URLValidator {

  func isValidURL(_ url: URL) -> Bool {
    // ...
  }

  func isProfileURL(_ url: URL, for userID: String) -> Bool {
    // ...
  }
}

let urlValidator = URLValidator()
let isProfile = urlValidator.isProfileUrl(urlToTest, userID: idOfUser)

⛔️ Not Preferred

class UrlValidator {

  func isValidUrl(_ URL: URL) -> Bool {
    // ...
  }

  func isProfileUrl(_ URL: URL, for userId: String) -> Bool {
    // ...
  }
}

let URLValidator = UrlValidator()
let isProfile = URLValidator.isProfileUrl(URLToTest, userId: IDOfUser)

3. 기타

3.1 클로저

파라미터와 리턴 타입이 없는 클로저 정의시에는 () -> Void 를 사용합니다.

✅ Preferred

let completionBlock: (() -> Void)?

⛔️ Not Preferred

let completionBlock: (() -> ())?
let completionBlock: ((Void) -> (Void))?

클로저 정의시 파라미터에는 괄호를 사용하지 않습니다.

✅ Preferred

{ operation, responseObject in
  // doSomething()
}

⛔️ Not Preferred

{ (operation, responseObject) in
  // doSomething()
}

클로저 정의시 가능한 경우 타입 정의를 생략합니다.

✅ Preferred

completion: { finished in
  // doSomething()
}

⛔️ Not Preferred

completion: { (finished: Bool) -> Void in
  // doSomething()
}

클로저 호출시 또 다른 유일한 클로저를 마지막 파라미터로 받는 경우, 파라미터 이름을 생략합니다.

✅ Preferred

UIView.animate(withDuration: 0.5) {
  // doSomething()
}

⛔️ Not Preferred

UIView.animate(withDuration: 0.5, animations: { () -> Void in
  // doSomething()
})

사용하지 않는 파라미터는 _를 사용해 표시합니다.

✅ Preferred

someAsyncThing() { _, _, argument3 in
  print(argument3)
}

⛔️ Not Preferred

// WRONG
someAsyncThing() { argument1, argument2, argument3 in
  print(argument3)
}

한줄 클로저는 반드시 각 괄호 양쪽을 공백을 추가해야 합니다.

✅ Preferred

let evenSquares = numbers.filter { $0 % 2 == 0 }.map { $0 * $0 }

⛔️ Not Preferred

let evenSquares = numbers.filter {$0 % 2 == 0}.map {  $0 * $0  }

3.2 클래스와 구조체

구조체를 생성할 때는 Swift 구조체 생성자를 사용합니다.

✅ Preferred

let frame = CGRect(x: 0, y: 0, width: 100, height: 100)

⛔️ Not Preferred

let frame = CGRectMake(0, 0, 100, 100)

3.3 타입

Array<T>와, Dictionary<T: U> 보다는 [T], [T: U]를 사용합니다.

✅ Preferred

var messages: [String]?
var names: [Int: String]?

⛔️ Not Preferred

var messages: Array<String>?
var names: Dictionary<Int, String>?

3.4 타입추론 사용

컴파일러가 문맥속에서 타입을 추론할 수 있으면 더 간결한 코드를 위해 타입을 생략합니다.

✅ Preferred

let selector = #selector(viewDidLoad)
view.backgroundColor = .red
let toView = context.view(forKey: .to)
let view = UIView(frame: .zero)

⛔️ Not Preferred

let selector = #selector(ViewController.viewDidLoad)
view.backgroundColor = UIColor.red
let toView = context.view(forKey: UITransitionContextViewKey.to)
let view = UIView(frame: CGRect.zero)

3.5 self

문법의 모호함을 제거하기 위해 언어에서 필수로 요구하지 않는 이상 self는 사용하지 않습니다.

final class Listing {
  private let isFamilyFriendly: Bool
  private var capacity: Int
  
  init(capacity: Int, allowsPets: Bool) {
    ✅ Preferred 
    self.capacity = capacity
    isFamilyFriendly = !allowsPets

    ⛔️ Not Preferred 
    self.capacity = capacity
    self.isFamilyFriendly = !allowsPets // `self.` not required here
  }

  private func increaseCapacity(by amount: Int) {
    ✅ Preferred 
    capacity += amount

    ⛔️ Not Preferred 
    self.capacity += amount

    ✅ Preferred 
    save()
    
    ⛔️ Not Preferred 
    self.save()
  }
}

✅ Preferred

TaxiPush.progressing.asPushActionObservable(callInfo.value.call.id)
            .map { $0.progressing }.unwrap()
            .map { $0/60 }
            .bind(to: timeRadius)
            .disposed(by: disposeBag)

⛔️ Not Preferred

TaxiPush.progressing.asPushActionObservable(callInfo.value.call.id)
            .map { $0.progressing }.unwrap()
            .map { $0/60 }
            .bind(to: self.timeRadius)
            .disposed(by: self.disposeBag)

3.6 튜플

튜플의 맴버에는 명확성을 위해 이름을 붙여줍니다. 만약 필드가 3개를 넘는 경우 struct를 사용을 고려해보는 것을 권장합니다.

✅ Preferred

func whatever() -> (x: Int, y: Int) {
  return (x: 4, y: 4)
}

⛔️ Not Preferred

func whatever() -> (Int, Int) {
  return (4, 4)
}
let thing = whatever()
print(thing.0)

✅ Okay

func whatever2() -> (x: Int, y: Int) {
  let x = 4
  let y = 4
  return (x, y)
}

let coord = whatever()
coord.x
coord.y

✅ Preferred

.map{($0.coord, nil, false)}
.withLatestFrom(viewModel.swapController) { (mapInfo: $0, swapController: $1) }
.filter { guard case .search = $0.swapController else { return false}; return true }
.map{$0.0},

⛔️ Not Preferred

.map{($0.coord, nil, false)}
.withLatestFrom(viewModel.swapController) {($0, $1)}
.filter{guard case .search = $0.1 else {return false}; return true}
.map{$0.0},

3.7 패턴

프로퍼티의 초기화는 가능하면 init에서하고 가능하면 unwrapped Optionl의 사용을 지양합니다.

✅ Preferred

class MyClass: NSObject {

  init() {
    someValue = 0
    super.init()
  }

  var someValue: Int
}

⛔️ Not Preferred

class MyClass: NSObject {

  init() {
    super.init()
  }

  var someValue: Int?
}

3.8 제네릭

제네릭 타입 파라미터는 대문자를 사용하고 묘사적이어야 합니다. 타입 이름이 의미있는 관계나 역할을 갖지 않는 경우에만 T, U 혹은 V 같은 전형적인 단일 대문자를 사용하고 그 외에는 의미있는 이름을 사용합니다.

✅ Preferred

struct Stack<Element> { ... }
func write<Target: OutputStream>(to target: inout Target)
func swap<T>(_ a: inout T, _ b: inout T)

⛔️ Not Preferred

struct Stack<T> { ... }
func write<target: OutputStream>(to target: inout target)
func swap<Thing>(_ a: inout Thing, _ b: inout Thing)

3.9 static

디폴트 타입 매소드는 static을 사용합니다.

✅ Preferred

class Fruit {
  static func eatFruits(_ fruits: [Fruit]) { ... }
}

⛔️ Not Preferred

class Fruit {
  class func eatFruits(_ fruits: [Fruit]) { ... }
}

3.10 final

더 이상 상속이 발생하지 않는 클래스는 항상 final 키워드로 선언합니다.

✅ Preferred

final class SettingsRepository {
  // ...
}

⛔️ Not Preferred

class SettingsRepository {
  // ...
}

3.11 프로토콜 extension

프로토콜을 적용할 때는 extension을 만들어서 관련된 매소드를 모아둡니다.

✅ Preferred

final class MyViewController: UIViewController {
  // ...
}

// MARK: - UITableViewDataSource

extension MyViewController: UITableViewDataSource {
  // ...
}

// MARK: - UITableViewDelegate

extension MyViewController: UITableViewDelegate {
  // ...
}

⛔️ Not Preferred

final class MyViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
  // ...
}

3.12 switch-case

switch-case에서 가능한 경우 default를 사용하지 않습니다.
새로운 case가 생성됐을때 인지하지 못한 상태에서 default로 처리되지 않고 의도적으로 처리를 지정해 주기 위함입니다.

✅ Preferred

switch anEnum {
case .a:
  // Do something
case .b, .c:
  // Do something else.
}

⛔️ Not Preferred

switch anEnum {
case .a:
  // Do something
default:
  // Do something else.
}

3.13 return

return은 생략하지 않습니다.

✅ Preferred

["1", "2", "3"].compactMap { return Int($0) }

var size: CGSize {
  return CGSize(
    width: 100.0,
    height: 100.0)
}

func makeInfoAlert(message: String) -> UIAlertController {
  return UIAlertController(
    title: "ℹ️ Info",
    message: message,
    preferredStyle: .alert)
}

⛔️ Not Preferred

["1", "2", "3"].compactMap { Int($0) }

var size: CGSize {
  CGSize(
    width: 100.0,
    height: 100.0)
}

func makeInfoAlert(message: String) -> UIAlertController {
  UIAlertController(
    title: "ℹ️ Info",
    message: message,
    preferredStyle: .alert)
}

3.14 사용하지 않는 코드

Xcode가 자동으로 생성한 템플릿을 포함한 사용하지 않는 코드는 placeholder 코멘트를 포함해 모두 제거합니다.

✅ Preferred

override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
  return Database.contacts.count
}

⛔️ Not Preferred

override func didReceiveMemoryWarning() {
  super.didReceiveMemoryWarning()
  // Dispose of any resources that can be recreated.
}

override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
  // #warning Incomplete implementation, return the number of rows
  return Database.contacts.count
}

[Basic] 정적타입 언어와 동적타입 언어

Sun, 17 Jan 2021 00:00:00 +0900

정의

정적타입(Static Typed) 언어와 동적타입 언어( Dynamic Typed)를 구분하는 기준은 코드의 상수, 변수, 함수 등에 대한 타입을 언제 확인하는지입니다. 타입을 컴파일 타임에 확인하는 언어를 정적타입 언어라 하고 런타임에 확인하는 언어를 동적타입 언어라 합니다.

그럼 Swift는 어떤 타입의 언어일까요?

Swift는 정적타입 언어입니다. 컴파일 시점에 코드의 타입을 검사해 타입이 맞지 않는 경우 컴파일러가 에러를 발생시킴니다.

각 타입의 장단점

두 타입을 구분짓는 요소인 타입을 어느 시점에 확인하느냐에 따라 각 타입의 장단점이 나뉩니다. 아래 코드는 동적타입 언어 사용의 예입니다.

var x = [1, 2, 3] // Array
x = True      // Bool
x = "Hello"   // String
x = 100       // Int

변수 x의 타입은 런타임에 확인하기 때문에 최초 x에 배열을 넣은 후 Bool, String, Int등으로 변환해 사용해도 아무 문제가 없습니다.

정적타입 언어는 이와 반대입니다.

// 1.컴파일 에러발생!
var x = [1, 2, 3] 
x = true ❌
x = "Hello" ❌
x = 100 ❌

// 2.에러발생하지 않음
var x = [1, 2, 3]
var y: Bool = true
var z: String = "Hello" 
var a = 100 

정적타입 언어는 타입이 한번 결정되면 변하지 않고, 컴파일시 타입을 확인하기 때문에 동적타입 언어처럼 사용할 수 없습니다.

정적타입 언어의 장점

이처럼 정적타입 언어는 컴파일시 타입에 대해 미리 확인하기 때문에 타입 관련한 런타임 오류를 방지할 수 있습니다. 특히 사용자에게 배포되는 앱의 경우 타입 관련한 검증을 컴파일타임에 하지않고 런타임에 하게 되면 앱사용시 타입 불일치로 인한 크래시가 발생 위험이 높아집니다.

정적타입 언어의 또 다른 장점은 코드의 가독성 입니다. 타입이 명시적으로 지정돼 있기 때문에 타입을 머리로 계산해 읽어야 하는 동적타입 언어에 비해 코드의 가독성이 좋습니다. 그래서 다수의 협업이나 프로젝트의 장기개발 및 유지보수에 유리합니다.

동적타입 언어의 장점

그럼 동적타입 언어는 단점만 있을까요? 당연히 그렇지 않습니다.

정적타입 언어는 사용하기 위해 알아야 할 타입 관련한 BoilerPlate코드와 지켜야할 규칙이 많습니다. 그래서 코드가 동적타입 언어에 비해 상대적으로 길어질 수 있습니다. 반면 동적타입언어는 사용하기 위해 지켜야할 규칙이 적기 때문에 상대적으로 코드가 짧고 Learning-Curve가 낮습니다.

정리

이상으로 정적타입 언어와 동적타입 언어에 대해 알아 보았습니다.

👨🏻‍💻지식이 +1 늘었다. 다음 포스트에서 또 만나요 🚀😄

[참 고]

[Swift] Codable을 사용해 json 데이터를 디코딩하는 3가지 방법

Sun, 10 Jan 2021 00:00:00 +0900

RESTful API를 사용하는 앱 개발시 가장 흔하게 하는 작업 중 하나는 서버에서 내려주는 json 데이터를 디코딩하는 일입니다. Swift 4에서 지원하기 시작한 Codable 프로토콜을 사용하면 json 데이터를 쉽게 디코딩 할 수 있습니다.

이번 포스트에서는 Codable(Decodable)을 사용해 json 데이터를 디코딩하는 3가지 방법에 대해 알아 보겠습니다.

1. 기본적인 방법

Decodable을 사용해 json 데이터를 디코딩 하는 가장 기본적인 방법은 다음과 같이 모델 정의시 json 데이터의 key와 이름이 같고 value와 타입이 같은 프로퍼티를 선언하는 것입니다.

[json data]

{
    "name": "tommy's blog",
    "postsCount": 20,
    "imageUrl": "https://jusung.github.io",
    "views": 1000,
    "tagLine": "Happy Swift Coding"
}

[모델]

struct Blog: {
    let name: String
    let postsCount: Int
    let imageUrl: URL
    let views: Int
    let tagLine: String
}

선언한 모델을 보면 json의 key와 모델의 프로퍼티 이름이 일치하고 json value의 타입과 프로퍼티의 type이 일치하를 것을 확인할 수 있습니다.

이제 Blog모델이 Decodable 프로토콜을 준수(conform)하도록 지정하고 디코딩을 수행합니다.

[코드]

// json 데이터
let json = """
{
    "name": "tommy's blog",
    "postsCount": 20,
    "imageUrl": "https://jusung.github.io",
    "views": 1000,
    "tagLine": "Happy Swift Coding"
}
""".data(using: .utf8)!

// 모델이 Decodable을 준수하도록 지정
struct Blog: Decodable {
    let name: String
    let postsCount: Int
    let imageUrl: URL
    let views: Int
    let tagLine: String
}

// 디코딩
let blog: Blog = JSONDecoder().decode(Blog.self, from: json)

[실행결과]

Blog(name: "tommy\'s blog", postsCount: 20, imageUrl: https://jusung.github.io, views: 1000, tagLine: "Happy Swift Coding")

결과를 확인하면 json 데이터대로 Blog모델이 잘 생성 됐음을 확인할 수 있습니다.

2. 수동으로 key를 지정하는 방법

Swift에서는 코딩 네임 컨벤션을 Apple이 권장(Swift API Design Guide)하는 camel-case를 사용합니다. 앞서 살펴본 예제에서는 json 데이터의 key가 camel-case로 돼 있어서 프로퍼티 이름을 camel-case 형태로 유지한채 디코딩을 할 수 있었습니다.

하지만 만약 json 데이터의 key가 camel-case가 아닌 다른 형태로 돼 있다면 어떻게 할까요?

예를 들어, json 데이터가 snake-case로 돼 있다고 한번 해보죠.

{
    "name": "tommy's blog",
    "posts_count": 20,
    "image_url": "https://jusung.github.io",
    "views": 1000,
    "tag_kine": "Happy Swift Coding"
}

이 경우에는 앞에서 살펴본 1번 방법으로 디코딩을 하기 위해서는 모델을 snake-case로 수정해야합니다.

struct Blog: Decodable {
    let name: String
    let posts_count: Int
    let image_url: URL
    let views: Int
    let tag_line: String
}

하지만 이렇게 되면 일관된 코딩 컨밴션을 깨드리게 됩니다. 이건 저희가 원하는 방법이 아닙니다.

Codable 프로토콜을 준수하는 타입은 다음과 같이 String과 CodingKey를 준수하는 CodingKey라는 enum을 선언할 수 있습니다. 이 방법을 사용하면 수동으로 모델의 프로퍼티와 json 데이터의 key/value를 매핑시켜 디코딩을 할 수 있습니다.

 enum CodingKeys: String, CodingKey {
    case name
    case postsCount = "posts_count"
    case imageUrl = "image_url"
    case views
    case tagLine = "tag_line"
}

CodingKeys를 선언하고 디코딩을 수행합니다.

[코드]

let json = """
{
    "name": "tommy's blog",
    "posts_count": 20,
    "image_url": "https://jusung.github.io",
    "views": 1000,
    "tag_line": "Happy Swift Coding"
}
""".data(using: .utf8)!

struct Blog: Decodable {
    let name: String
    let postsCount: Int
    let imageUrl: URL
    let views: Int
    let tagLine: String

    enum CodingKeys: String, CodingKey {
        case name
        case postsCount = "posts_count"
        case imageUrl = "image_url"
        case views
        case tagLine = "tag_line"
    }
}

let blog: Blog = JSONDecoder().decode(Blog.self, from: json)

[실행결과]

Blog(name: "tommy\'s blog", postsCount: 20, imageUrl: https://jusung.github.io, views: 1000, tagLine: "Happy Swift Coding")

snake-case로 돼 있는 json도 camel-case형태로 잘 디코딩 된 것을 확인할 수 있습니다.

3. Decoder에 Stratege를 사용하는 방법 (snake-case를 camel-case로 자동으로 변환하는 방법)

앞서 살펴본 “2. 수동으로 key를 지정하는 방법” 을 사용하면 어떠한 형태의 json 데이터가 들어와도 디코딩하는데는 지장이 없습니다. 만약 서버에서 내려준 snake-case 형태의 json 데이터의 key/value가 30개 인 경우는 어떨까요?

2번 방법으로 디코딩을 하기 위해서는 개발자가 일일이 snake-case를 camel-case로 매핑해주기 위해 CodingKey를 구현해야합니다. 휴… 생각만해도 끔찍합니다.

서버에서 내려주는 데이터가 snake-case로 일관성이 있는데, 이 부분을 어떻게 자동화 할 수 없을까요?

네! 있습니다. 😉

JSONDecoder에 keyDecodingStrategy를 지정하면 자동으로 snake-case를 camel-case로(혹은 그 반대인 camel-case를 snake-case로) 매핑시켜 디코딩을 할 수 있습니다. keyDecodingStrategy로.convertFromSnakeCase를 사용하면 각 데이터는 다음과 같이 변경됩니다.

원본: fee_fi_fo_fum
변경: feeFiFoFum 

원본: feeFiFoFum
변경: feeFiFoFum 

원본: base_uri
변경: baseUri

JSONDecoder에 keyDecodingStrategy를 .convertFromSnakeCase로 지정 후 디코딩을 수행합니다.

[코드]

let json = """
{
    "name": "tommy's blog",
    "posts_count": 20,
    "image_url": "https://jusung.github.io",
    "views": 1000,
    "tag_line": "Happy Swift Coding"
}
""".data(using: .utf8)!

struct Blog: Decodable {
    let name: String
    let postsCount: Int
    let imageUrl: URL
    let views: Int
    let tagLine: String
}

let decoder = JSONDecoder()  
decoder.keyDecodingStrategy = .convertFromSnakeCase // keyDecodingStrategy를 지정
let blog: Blog = try decoder.decode(Blog.self, from: json)

[실행결과]

Blog(name: "tommy\'s blog", postsCount: 20, imageUrl: https://jusung.github.io, views: 1000, tagLine: "Happy Swift Coding")

decoder.keyDecodingStrategy를 지정하면 CodingKey 선언 없이도 snake-case 데이터를 camel-case로 디코딩 가능한 것을 확인할 수 있습니다.

정리

이번 포스트에서는 “Codable을 사용해 json 데이터를 디코딩하는 3가지 방법” 에 대해 살펴보았습니다.

서버에서 내려주는 json의 형태과 개수에 따라서 1, 2, 3의 방법 중에 하나를 적절히 선택해서 디코딩하면 됩니다. 특히 snake-case로 내려오는 경우에 디코더에 stratege를 지정해 사용하는 것을 추천드립니다.

👨🏻‍💻지식이 +1 늘었다. 다음 포스트에서 또 만나요 🚀😄

RxSwift 6의 변경사항 (What’s new in RxSwift 6)

Mon, 04 Jan 2021 00:00:00 +0900

RxSwift 6이 릴리스 됐습니다. 이번 포스트에서는 RxSwift 6의 변경사항에 대해 살펴보겠습니다. 내용은 원문인 이 포스트를 번역했습니다.

내용이 좀 많은데요. 개인적으로 가장 유용하다고 생각하는 기능 두 개를 목차에서 별⭐️로 표시해 두었습니다. 바쁘신 분들은 이 두 기능만은 꼭 확인하시길 추천드립니다.

새 로고
Binder가 RxCocoa에서 RxSwift로 이동
withUnretained 추가 (⭐️)
@dynamicMemberLookup을 사용한 Binder의 자동 합성 (⭐️)
Infallible
Observable<Data>를 위한 decode(type:decoder:)연산자 제공
driver(), emit()에 다중 바인딩 제공
Single의 구현을 Swift의 Result를 사용하도록 변경
distinctUntilChange(at:)연산자에서 Key Path 지원
ReplayRelay 연산자 추가
DisposeBag 함수 빌더 추가
여러 연산자의 이름이 변경 됨
XCFrameworks 지원 개선

1. 새 로고

로고가 좀 더 귀엽게 변경됐습니다. ☺️

2. `Binder`가 RxCocoa에서 RxSwift로 이동

viewModel.isButtonEnable.bind(to: myButton.rx.isEnabled)

Binder는 이름 그대로 input이나 output을 Binding하기 위해 사용하는데요. 그동안에는 Binder를 사용하기 위해 RxCocoa 모듈을 import 해야만 했습니다.

커뮤니티의 많은 요청에 따라 RxCocoa 모듈에 있던 Binder를 RxSwift로 이동했습니다. RxSwift 6부터는 더 이상 Binder를 사용하기 위해 RxCocoa 모듈을 import할 필요가 없습니다.

3. `withUnretained` 추가 (⭐️)

클로저에서 self에 대한 약한 참조를 하고 클로저 안의 코드가 끝까지 실행되는 것을 보장하기 위해 보통 다음과 같은 코드를 사용합니다.

viewModel.importantInfo
    .subscribe(onNext: { [weak self] info in 
        guard let self = self else { return }
        self.doImportantTask(with: info)
    })
    .disposed(on: disposeBag)

이런 코드를 한번만 작성하는 것이라면 괜찮겠지만, 실제로는 여러번 작성해야하기 때문에 코딩시 가독성과 효율성이 떨어집니다.

RxSwiftExt(RxSwift에 없는 연산자를 추가로 구현한 오픈소스) 라는 익스텐션에 withUnretained 라는 연산자가 있는데, 이 연산자의 인기가 계속 올라감에 따라 이 연산자를 RxSwift에 공식적으로 포함시켰습니다.

RxSwift 6부터는 위 코드를 withUnretained를 사용해 다음과 같이 작성할 수 있습니다.

viewModel.importantInfo
  .withUnretained(self) // (Object, Element) 듀플 반환
  .subscribe(onNext: { owner, info in 
    owner.doImportantTask(with: info)
  })
  .disposed(by: disposeBag)

코드가 훨씬 깔끔해 졌습니다.

4. `@dynamicMemberLookup`을 사용한 `Binder`의 자동 합성 (⭐️)

RxSwift 에서는 특정 객체의 프로퍼티에 Binding 하기 위해 .rx라는 네임스페이스를 사용합니다.

예를들어, 만약 다음과 같은 MyView 경우

class MyView: UIView { 
    var title: String
    var subtitle: String?
    var icon: UIImage?
}

프로퍼티에 Binding할 수 있도록 위해 일반적으로 이렇게 Reactive extension을 구현합니다.

extension Reactive where Base: MyView {
    var title: Binder<String> {
       Binder(base) { base, title in 
           base.title = title
       }
    }

    var subtitle: Binder<String?> {
       Binder(base) { base, subtitle in 
           base.subtitle = subtitle
       }
    }

    var icon: Binder<UIImage?> {
       Binder(base) { base, icon in 
           base.icon = icon
       }
    }

다음은 프로퍼티를 binding하는 코드입니다.

viewModel.title.bind(to: myView.rx.title)
viewModel.subtitle.bind(to: myView.rx.subtitle)
viewModel.icon.drive(myView.rx.icon)

프로퍼티에 Binding을 지원하기 위해 Base의 모든 프로퍼티에 대해 Reactive extension을 만드는 것은 매우 반복적인 비효율적인 작업이 아닐 수 없습니다.

행복하게도 Swift 5.1 부터 이 문제 해결을 위한 @dynamicMemberLookup을 제공해 줍니다.

RxSwift 6에서는 어떤 클래스든 모든 프로퍼티를 자동으로 합성해 Binding이 가능한 Reactive extension을 제공해줍니다. 👍

이제 프로퍼티를 Binding하기 위해 생성한 Reactive extension을 코드에서 완전히 제거 할 수 있습니다.

앞으로 Xcode에서AnyObject를 상속하는 어떤 클래스에서든 .rx를 입력만 하면 즉각 자동으로 합성된 모든 프로퍼티의 Binder를 보실 수 있을 것입니다. 😆

참고로 이미 선언돼 있는 Reactive extension은 자동으로 합성되어 생성되는 Reactive extension보다 우선해서 실행됩니다. 그렇기 때문에 커스텀하게 구현한 Reactive extension이 자동으로 생성된 Reactive extension에 의해 오버라이딩 되지 않을까 걱정하지 않으셔도 됩니다.

5. `Infallible`

Infallible는 Observable과 한가지가 다른 새로운 타입입니다. Infallible는 실패하지 않습니다. 다시 말하면 .error 이벤트를 방출(emit)하지 않습니다.

예를들어, Observable.create와 유사하게 Infallible.create를 다음과 같이 생성할 수 있습니다.

Infallible<String>.create { observer in
    observer(.next("Hello"))
    observer(.next("World"))
    observer(.completed)
    // 여기에서 .error를 방출할 수 없습니다.

    return Disposables.create {
        // Clean-up
    }
}

Infallible에서는 .next(Element) 혹은 .completed 이벤트만 전달할 수 있습니다.

RxCocoa를 사용해 보셨다면 “그럼 Driver나 Signal과 차이점이 뭐지?” 라고 의아해 하실 수 있는데요.

우선 Driver나 Signal은 RxCocoa에 포함돼 있는 반면Infallible는 RxSwift에 포함돼 있습니다. 더 중요한 차이는Driver나 Signal는 항상 MainScheduler를 사용하고 share()를 사용해 자원을 공유합니다. 반면 Infallible는 이 경우에 해당하지 않는 완전히 새로운 타입의 기본 Observable입니다.

6. `Observable<Data>`를 위한 `decode(type:decoder:)`연산자 제공

RxSwift 6에서는 Data를 방출하는 Observable에서 동작하는 Combine과 유사한 decode 연산자를 제공합니다.

service.rx
       .fetchJSONUsers() // Observable<Data> 반환
       .decode(type: [User].self, decoder: JSONDecoder()) // Observable<[User]> 반환

7. `driver()`, `emit()`에 다중 바인딩 제공

RxSwift 5에서 처음으로 Binder에 다중 바인딩이 제공 됐습니다.

viewModel.string.bind(to: input1, input2, input3)

RxSwift 6에서는 같은 다중 바인딩을 Driver와 Signal에도 제공합니다.

viewModel.string.drive(input1, input2, input3)
viewModel.number.emit(input4, input5)

8. `Single`의 구현을 `Swift`의 `Result`를 사용하도록 변경

RxSwift 5까지 Single은 커스텀 이벤트를 사용했습니다.

public enum SingleEvent<Element> {
    case success(Element)
    case error(Swift.Error)
}

RxSwift 6 부터 커스텀 이벤트 대신 Swift의 Result<Element, SwiftError>를 사용합니다. SingleEvent는 Result<Element, SwiftError> 의 별칭(alias)일 뿐입니다.

이런 변화는 subscribe같은 다른 API의 사용에도 반영이 되었습니다.

// RxSwift 5
single.subscribe(
    onSuccess: { value in
        print("Got a value: \(value)")
    },
    onError: { error in   // onError사용
        print("Something went wrong: \(error)")
    }
)

// RxSwift 6
single.subscribe(
    onSuccess: { value in
        print("Got a value: \(value)")
    },
    onFailure: { error in // onFailure 사용
        print("Something went wrong: \(error)")
    }
)

9. `distinctUntilChange(at:)`연산자에서 Key Path 지원

distinctUntilChange는 비효율적인 중복작업을 피할 수 있게 해주는 매우 유용한 연산자 입니다. 이 연산자를 RxSwift 5까지는 이렇게 사용했습니다.

myStream.distinctUntilChanged { $0.searchTerm == $1.searchTerm }

RxSwift 6부터는 추가적으로 Key Path를 이용해 보다 간략하게 코드를 작성할 수 있습니다.

myStream.distinctUntilChanged(at: \.searchTerm)

10. `ReplayRelay` 연산자 추가

Relay는 Subject의 wrapper로 스트림이 절대 실패(fail)하거나 종료(complete)되지 않는 것을 보장합니다. RxSwift 6에서는 ReplaySubject를 wrapping한 ReplayRelay를 기존의 BehaviorRelay와 PublishRelay에 추가했습니다.

ReplayRelay를 생성하는 방법은 ReplaySubject를 생성하는 방법과 완전히 동일합니다.

// Subject
ReplaySubject<Int>.create(bufferSize: 3)

// Relay
ReplayRelay<Int>.create(bufferSize: 3)

11. `DisposeBag` 함수 빌더 추가

RxSwift 6 에서는 DisposeBag에 SwiftUI 같이 콤마(,)가 없는 함수 빌더가 추가 되었습니다.

var disposeBag = DisposeBag { 
    observable1.bind(to: input1)

    observable2.drive(input2)

    observable3.subscribe(onNext: { val in 
        print("Got \(val)")
    })
}

// disposeBag의 insert에도 사용 가능합니다.
disposeBag.insert {
    observable4.subscribe()

    observable5.bind(to: input5)
}

12. 여러 연산자의 이름이 변경 됨

RxSwift 6에서는 많은 연산자의 이름을 Swift의 코드 가이드라인에 따라 변경했습니다.

변경된 이름은 다음과 같습니다. (여기에 명시되지 않은 연산자가 있을 수 있습니다.)

RxSwift 5	RxSwift 6
catchError(_:)	catch(_:)
catchErrorJustReturn(_:)	catchAndReturn(_:)
elementAt(_:)	element(at:)
retryWhen(_:)	retry(when:)
takeUntil(_:)	take(until:)
takeUntil(behavior:_:)	take(until:behavior:)
takeWhile(_:)	take(while:)
takeWhile(behavior:_:)	take(while:behavior:)
take(.seconds(3))	take(for: .seconds(3))
skipWhile(_:)	skip(while:)
takeUntil(_:)	take(until:)
observeOn(_:)	observe(on:)
subscribeOn(_:)	subscribe(on:)

13. XCFrameworks 지원 개선

RxSwift 6의 모든 릴리스는 앞으로 XCFramework 번들로도 제공됩니다.

정리

RxSwift 6에서는 이와 같이 많은 기능이 추가되거나 변경 됐는데요. 이 포스트에서 소개하지 않은 소소한 개선사항이나 버그 수정도 있습니다. 더 자세한 내용은 여기에서 확인 가능합니다.

RxSwift 6를 확인하고 느낀점은 Combine이 있지만, RxSwift를 이렇게 계속 보완/발전시키는걸 봐서는 RxSwift가 쉽게 Combine으로 대체되진 않을꺼란 생각이 드네요.

또 RxSwift의 main 메인테이너인 Shai Mishali 이분은 RxSwift뿐만아니라 Swift, Combine도 잘 하시는데, ‘역시 다른 언어를 잘하니 거기에서 이렇게 차용해 올 수 있구나?’ 라는 생각도 했습니다. 너무 당연한 얘기지만요. 공부를 더 해야합니다. 😅

이상 포스트를 마치겠습니다.

👨🏻‍💻지식이 +5 늘었다. 다음 포스트에서 또 만나요 🚀😄

[Xcode] Xcode12에서 시뮬레이터 빌드 오류 원인 및 해결방법

Wed, 07 Oct 2020 00:00:00 +0900

이번 포스트에서는 Xcode12에서 시뮬레이터에 빌드시 오류가 발생하는 원인과 해결방법에 대해 알아 보겠습니다. 포스트가 제법 깁니다. 😅

간단히 알고 넘어가실 분은 TL;DR만 읽으셔도 됩니다.

빌드 오류 원인

Xcode12에서 ARM기반 맥(애플실리콘)을 지원함에 따라 아이폰 시뮬레이터에 ARM용 아키텍쳐 arm64가 추가돼 발생

해결 방법

Build Setting에

EXCLUDED_ARCHS에 arm64를 추가
VALID_ARCHS 제거

여기까지가 간단한 문제 원인과 해결방법입니다. 다음 내용부터는 보다 자세한 내용입니다.

❗️주의 : 내용 중 틀린 내용이 있을 수 있습니다. 발견하신 분은 바로잡아 주시면 감사드리겠습니다.

문제 원인 자세히 살펴보기

문제의 원인을 살펴보기전에 우선 Xcode에서 빌드와 관련해 알아야 할 내용이 두 가지 있습니다.

첫째, 아이폰은 기종에 따라 각기 다른 아키텍쳐의 CPU를 사용한다.

- arm64 : 아이폰 5S 및 이후 기종 (6, 6S, SE, 7…)
- arm7s : 아이폰 5, 5C
- arm7 : iOS7 지원 옛날 기기

아이폰 기기별 사용 아키텍쳐

둘째, 빌드시 바이너리가 생성되는데, 이 바이너리는 각 CPU 아키텍쳐에 맞게 생성해야 한다. (아키텍쳐별로 기계어 명령어 셋 등이 다름)

이제 본격적으로 설명을 시작하겠습니다.

앱을 하나 만들었는데, 이 앱을 아이폰 4S에서부터 최신기기인 iPhone 11까지 동작하도록 하려면 어떻게 빌드해야 할까요?

이 조건을 만족시키기 위해서는 arm64 바이너리 하나만 생성하면 안되고 arm64, arm7, arm7s 바이너리를 각각 생성해 원하는 모든 기기에서 동작할 수 있도록 해야합니다.

Xcode에서 이와 관련해 설정하는 부분은 Build Setting -> Valid Architectures 에 있었습니다.

Valid Architectures 설정(Xcode11)

이렇게 설정하면 빌드시 Valid Architectures로 지정한 모든 아키텍쳐 바이너리를 생성해 앱이 각 아키텍쳐를 사용하는 모든 기기에서 동작할수 있도록 할 수 있습니다.

여기서 질문! ✋

그렇다면 아이폰 시뮬레이터는 어떤 아키텍쳐를 사용할까요? 아이폰5 시뮬레이터면 arm7을 아이폰11시뮬레이터면 arm64를 사용할까요?

아닙니다!

아이폰 시뮬레이터는 맥에서 동작합니다. 그래서 아이폰 시뮬레이터는 맥 CPU의 아키텍쳐를 따릅니다. 요즘 맥은 core i5, i7 등의 인텔 CPU를 사용하고 있는데 이 CPU는 x86_64라는 아키텍쳐를 사용합니다. 그래서 시뮬레이터는 x86_64 아키텍쳐를 사용합니다.

다음 위치에 SKDSetting 파일에서 시뮬레이터 아키텍쳐 정보가 x86_64라는 것을 확인할 수 있습니다.

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/SDKSettings.json

Xcode 11 시뮬레이터의 아키텍쳐 : x86_64

Xcode에 아이폰11 기기를 연결하고 debug 설정으로 Run을 실행하면 어떤 일이 발생할까요?

앞에서 살펴본대로 Valid Architecture에 지정한 arm64, arm7, arm7s 용 빌드를 생성해 기기에 심습니다. 그런데 여기서 한가지 의문이 생깁니다.

아이폰11은 arm64 아키텍쳐를 사용하는데, 아이폰 11에다가 빌드하면 arm64 바이너리만 만들면 되지 굳이 arm7, arm7s 바이너리까지 만들 필요가 있을까?

맞습니다. 이럴때 사용하기 위한 옵션이 Build Active Architecture Only입니다.

Build Setting의 이 옵션을 활성화 시키면 Xcode에서 빌드시 Valid Architectures를 참조하지 않고, 현재 연결된 기기를 감지해 그 기기에 맞는 아키텍쳐용 빌드만 생성합니다. 다시말해 이 옵션을 활성화하고 아이폰11에 빌드를 하면 arm64용 바이너리만 빌드가 되는 것이죠.

시뮬레이터도 마찬가지 입니다. Run Destination을 시뮬레이터으로 선택해 Run을 수행하면 시뮬레이터 아키텍쳐를 감지해 해당하는 아키텍쳐 바이너리를 생성해 심습니다. 이 경우에는 x86_64 아키텍쳐 용 바이너리를 만듭니다.

이 옵션을 왜 debug 설정에서만 true로 설정해 사용하는지는 이제 이해가 되시죠?

여기까지가 Xcode12 이전에 빌드 수행시 기기 및 시뮬레이터에서 동작하던 방식입니다. 이제 Xcode12에서 달라진 동작에 대해 알아보겠습니다.

Xcode12 에서 동작하는 방식

먼저 Xcode12의 Release Note를 살펴보겠습니다.

Xcode12의 Release Note 내용의 일부

관련해서 얘기하고 있는 것은 크게 세 가지 입니다.

Build Setting에 Valid Architectures(VALID_ARCHS)가 더 이상 포함되지 않음 (이 설정을 사용하는 것을 장려하지 않음)
Valid Architectures 설정 대신 EXCLUDED_ARCHS 설정이 생김
기존 Valid Architectures 내용은 사용자 정의 섹션(User-Defined)에 노출됨

Valid Architectures(VALID_ARCHS) 설정이 더 이상 Architectures섹션에 있지않고 User-Defined섹션에 노출된 것을 확인하실 수 있습니다

정리하자면 기존에는 빌드시 원하는 아키텍쳐를 지정하는 방식을 사용했는데,

Xcode12에서는 반대로 빌드시 제외시킬 아키텍쳐를 지정하는 방식을 사용(필수x, 권장하는 부분)하는 쪽으로 바꼈습니다.

Xcode12에서 왜 이렇게 변경한걸까요?

그 이유는 바로 앞으로 출시될 ARM기반 맥북 때문입니다.

애플에서 머지않아 ARM기반 맥이 출시됩니다. 그동안 맥은 인텔 CPU기반이었습니다.(더 거슬러 올라가면 PowerPC) 하지만 곧 ARM용 맥도 출시가 돼서 앞으로는 인텔 CPU 기반 맥과 ARM기반 맥이 공존하는 상황이 됐습니다.

앞서 언급드린것처럼 아이폰 시뮬레이터는 맥의 아키텍쳐를 따릅니다. 현재 아이폰 시뮬레이터의 아키텍쳐는 x86_64입니다. ARM기반 맥은 arm64구조를 사용합니다.

Xcode12는 인텔 CPU 맥에서 ARM용 맥으로 넘어가는 과도기에 있는 앱으로, 두개 아키텍쳐를 모두 지원합니다. 다시말해 현재 사용 중인 x86_64 아이폰 시뮬레이터를 지원하고 앞으로 나올 arm64도 지원합니다.

바로 이 지점에서 시뮬레이터 호환성 이슈가 발생합니다.

전에는 시뮬레이터를 선택 후 빌드를 하면 x86_64용 빌드만 했는데, Xcode 12에서 시뮬레이터는 x86_64, arm64를 다 지원하기때문에 x86_64용과, arm64용으로 빌드를 수행합니다. 이 과정에서 현재 맥은 x86_64용 맥이기 때문에 arm64용 빌드 수행시 에러가 발생합니다.

다음 위치에 SKDSetting 파일에 Xcode12용 시뮬레이터의 아키텍쳐 정보가 x86_64, arm64라는 것을 확인할 수 있습니다.

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/SDKSettings.json

새로운 시뮬레이터의 아키텍쳐 : arm64, x86_64

빌드시 이 에러를 막기 위해서는 어떻게 해야할까요? 그렇습니다. 현재는 arm64용 맥북이 출시되지 않았기 때문에 시뮬레이터 빌드시 arm64용 빌드를 진행하지 않도록 해야합니다.

이 설정을 Xcode12 에서 새롭게 추가된 EXCLUDED_ARCHS에 설정할 수 있습니다.

EXCLUDED_ARCHS 변수를 설정하면 Xcode에서 Excluded Architectures 섹션에 노출됩니다.

Build Setting에 EXCLUDED_ARCHS 항목에

빌드를 시뮬레이터에 하는 경우에는 arm64 바이너리용 빌드는 하지 말아줘.

라고 지정을 하면 빌드시 arm64 빌드를 수행하지 않아 에러가 발생하지 않습니다.

이것이 이번 Xcode12에서 모든 아이폰 개발자를 힘들게 만든 원인 입니다.

해결하지 못한 내용

참고로 Xcode12 에서 시뮬레이터 빌드 오류를 수정하려면 기존에 VALID_ARCH 설정도 함께 지워야하는데, 이 부분은 애플에서 사용하지 않는 것이 좋다라고 언급한 내용 정도만 확인하고, 정확히 빌드오류 해결과 어떤 연관이 있는지는 확인하지 못하였습니다.

기존의 방식에 따르면 BUILD ACTIVE ARCHITECTURE ONLY를 세팅하면 위 설정은 참고하지 않는데… 왜 설정이 있다고 오류가 나는지는 잘 모르겠네요. 아시는분 알려주시면 감사드리겠습니다.

이상 Xcode12에서 시뮬레이터 빌드 오류 원인 및 해결방법에 대해 살펴봤습니다.

(👨🏻‍💻지식이 +10 늘었다. 이번 포스트는 지식+10 정도 되쥬? 인정이쥬? 🤣)

다음 포스트에서 또 만나요~ 🚀😄 (아마도 내년에~~)

[참 고]

[RxSwift] Scan

Mon, 06 Apr 2020 00:00:00 +0900

Scan 연산자는 상태를 다루는데 유용한 연산자입니다. 이번 포스트에서는 Scan 연산자의 동작과 활용에 대해 살펴보도록 하겠습니다.

역할

이전에 방출된 아이템과 새로 방출된 아이템을 결합해 현재 아이템을 생성합니다.

값을 계속 누적시킬 수 있기 때문에 누산기(accumulator)라고 부르기도 합니다. 무슨 뜻인지 이해가 잘 안되신다구요? 괜찮습니다. 예제를 살펴 보면 이해가 되실 겁니다.

예제

scan이 실행되는 구체적인 과정은 다음과 같습니다.

[코드]

Observable.of(1,2,3,4,5)
   .scan(0) { (prevValue, newValue) in
      return prevValue + newValue
   }
   .subscribe(onNext: { print($0) })
   .disposed(by: disposeBag)

[실행 결과]

scan은 2개의 인자를 사용합니다.

초기값 : scan은 새 아이템이 방출될때마다 이전 값을 사용하는데, 최초 실행시에는 이전 값이 없습니다. 그래서 최초에 사용할 이전 값(마지막 값)을 초기값으로 지정합니다.

closure(prevValue, newValue) : scan이 실행 될때마다 이 클로저를 실행해 마지막 값과 현재 방출된 값을 인자로 넣어 사용합니다.

대략 감이 오셨나요? 이제부터가 더 흥미로운 내용입니다.

활용

scan을 여러가지 상태처리에 활용할 수 있습니다.

1. 버튼의 선택 상태변경

버튼을 누를때마다 버튼의 상태가 selected <-> deselected로 번갈아가며 전환됩니다.

[코드]

myButton.rx.tap
   .scan(false) { (lastState, newValue) in
      !lastState
   }
   .bind(to: requestMoreButton.rx.isSelected)
   .disposed(by: disposeBag)

2. 카운터

버튼을 누를때마다 값을 누적합니다.

[코드]

myButton.rx.tap
   .scan(0) { (lastCount, newValue) in
      lastCount + 1
   }
   .subscribe(onNext: { print("taps: \($0)") })
   .disposed(by: disposeBag)

[실행 결과]

taps: 1
taps: 2
taps: 3
taps: 4
taps: 5

3. 텍스트 입력값 종류 제한

TextField나 TextView에 특정한 문자형태만 입력할 수 있도록 제한하는데 사용할 수 있습니다. TextField에 숫자만 입력 가능하도록 scan을 사용해 다음과 같이 구현할 수 있습니다.

[코드]

myTextField.rx.text.orEmpty.asObservable()
   .scan("") { (oldValue, newValue) in
      return newValue.isNumber ? newValue : oldValue
   }
   .bind(to: myTextField.rx.text)
   .disposed(by: disposeBag)

extension String {
   var isNumber: Bool {
   do {
      let regex = try NSRegularExpression(pattern: "^[0-9]+$", options: .caseInsensitive)
      if let _ = regex.firstMatch(in: self, options: .reportCompletion, range: NSMakeRange(0, count)) { return true }
      } catch { return false }
      return false
   }
}

TextField의 text가 변경될때마다 이전 text화 변경된 text를 비교하는데, 만약 새로 입력된 문자가 숫자면 새로운 입력을 TextField에 적용하고, 숫자가 아니면 새로운 입력을 무시하고 이전값을 유지하게 됩니다.

TextField에 12ab3을 차례로 입력해 보겠습니다.

[실행 결과]

Event next(1)
text: 1
Event next(12)
text: 12
Event next(12a)
text: 12
Event next(12b)
text: 12
Event next(123)
text: 123

12ab3을 입력했지만 TextField에는 123만이 입력된 것을 확인할 수 있습니다.

4. 화면상태 처리

화면의 상태를 처리하기 위해 scan을 사용할 수 있습니다. 화면이 A, B, C 세개가 있고 화면은 A -> B -> C 로 이동하는데 뒤로가기도 할 수 있어서 C -> B -> A로도 이동가능하다고 가정해보죠.

만약 B화면이 보여졌는데 A -> B로 이동해서 보여진 경우와 C -> B로 뒤로가기로 이동해 보여진 B화면을 각각 다르게 처리하기 위해 scan을 사용할 수있습니다.

[코드]

enum SceneState {
   case initial
   case sceneA
   case sceneB
   case sceneC
}

let sceneState: BehaviorRelay<SceneState> = BehaviorRelay(value: .initial)
        
sceneState.asObservable()
   scan(.initial) { (prev, current) in
      switch (prev, current) {
      case (.sceneA, .sceneB)
         // 화면이 A -> B로 이동했을 경우 처리
      case (.sceneC, .sceneB)
         // 화면이 C -> B로 이동했을 경우 처리
      }
}

이상으로 scan 연산자에 대해 살펴봤습니다. 상태 관련해 뭔가를 처리해야 한다면 scan을 사용하는 것을 먼저 생각해보세요.

이 포스트에서 제공한 예제 말고도 다양하게 응용해서 활용할 수 있습니다. (👨🏻‍💻지식이 +3늘었다.)

다음 포스트에서 또 만나요~ 🚀😄

[참 고]

[Swift] Int타입의 Enum에서 String case 얻기

Sat, 04 Apr 2020 00:00:00 +0900

만약 다음과 같은 Int타입의 Enum에서 각 case를 String으로 얻고 싶다면 어떻게 할 수 있을까요?

enum Vehicles: Int {
    case car
    case bus
    case taxi
}

일감으로 떠오르는 방법은 각 case 별로 String값을 반환하는 프로퍼티를 하나 만드는 것일 겁니다.

enum Vehicles: Int {
    case car
    case bus
    case taxi
    
    var kind: String {
        switch self {
        case .car:
            return "car"
        case .bus:
            return "bus"
        case .taxi:
            return "taxi"
        }
    }

하지만 이 방법은 좋지 않은 방법입니다. 이유는 case가 변경될때마다 프로퍼티를 변경해줘야 하기 때문입니다. 보다 간단한 방법은 없을까요? 있습니다. String(describing: self)를 사용하는 것입니다.

enum Vehicles: Int {
    case car
    case bus
    case taxi
    
    var kind: String {
        String(describing: self)
    }
}

String(describing: Subject)는 입력한 인스턴스에 대해 그것을 표현하는 String 을 반환합니다.

Swift 표준라이브러리에서는 enum에 대한 String(describing: Subject)값으로 그 case의 이름을 값을 반환하도록 정의돼 있습니다. 각 case의 kind를 출력하면 기대했던 값이 나오는 것을 확인할 수 있습니다.

[코드]

enum Vehicles: Int, CaseIterable {
    case car
    case bus
    case taxi
    
    var kind: String {
        String(describing: self)
    }
}

Vehicles.allCases.forEach {
    print($0.kind)
}

[실행결과]

car
bus
taxi

이상 Int Enum 에서 case String 얻는 방법에 대해 알아보았습니다. (👨🏻‍💻지식이 +0.1 늘었다.)

다음 포스트에서 또 만나요~ 🚀😄

[RxSwift] Share(replay:)

Mon, 30 Mar 2020 00:00:00 +0900

anObservable.share(replay:1) 같은 코드를 보신적 있으실 겁니다. Share 연산자는 언제 써야하는 걸까요?

이 연산자를 알아 보기에 앞서 Observable의 특징 하나를 살펴보겠습니다.

Observable의 특징

Observable은 매우 게으른 pull-driven 시퀀스 입니다. 무슨 뜻이냐구요? Observable에 아무리 여러 연산자를 호출해도 subscribe() 가 호출되기 전까진 아무 동작도 하지 않습니다. 진짜냐구요?

예제를 보시죠.

[코드]

let numObservable = Observable.of(1,2,3,4,5).debug()    
numObservable
    .map { $0 + 1 }

[실행결과]

// 아무것도 출력되지 않음

Observable에 debug()를 걸어 두었지만 시퀀스에서 아무런 아이템도 방출되지 않는걸 확인할 수 있습니다.

이제 Observable의 연산자 뒤에 subscribe()를 호출해보겠습니다.

[코드]

let disposeBag = DisposeBag()    
let numObservable = Observable.of(1,2,3,4,5).debug("")    
numObservable
    .map { $0 + 1 }
    .subscribe()  // subscribe()를 호출
    .disposed(by: disposeBag)

[실행결과]

-> subscribed
-> Event next(1)
-> Event next(2)
-> Event next(3)
-> Event next(4)
-> Event next(5)
-> Event completed
-> isDisposed

이제서야 Observable의 시퀀스에서 아이템이 방출되는 것을 확인할 수 있습니다.

Observable은 subscribe 될때마다 create 클로저를 호출해 Observable을 생성합니다. (참고 : Subscribe) 다시말하면 Observable에 Subscribe를 한 횟수만큼 Observable이 생성됩니다.

Observable을 Subscribe할때마다 새로운 Observable시퀀스가 생성된다.

자 이제 이 사실을 기억하고 share()연산자를 살펴보겠습니다.

다음과 같은 코드가 있습니다.

[코드]

class ViewController: UIViewController {
    @IBOutlet weak var requestMoreButton: UIButton!
    @IBOutlet weak var remainCountLabel: UILabel!
    
    let disposeBag = DisposeBag()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        bind()
    }
    
    private func bind() {
        // 서버에 API를 요청해 결과를 반환하는 시퀀스라 가정
        let networkRequestAPI = Observable.of(100).debug("networkRequestAPI")

        let result = requestMoreButton.rx.tap
            .flatMap { networkRequestAPI }
        
        result
            .map { $0 > 0 }
            .bind(to: requestMoreButton.rx.isHidden)
            .disposed(by: disposeBag)

        // bind(to:)는subscribe()의 별칭(Alias)으로 Subscribe()를 호출한 것과 동일
        result
            .map { "Count:\($0)" }
            .bind(to: remainCountLabel.rx.text)
            .disposed(by: disposeBag)
    }
}

버튼을 누르면 서버에 API 요청을 보내 결과를 받고, 그 결과를 사용해 버튼을 보여주거나 감추고 문구를 표시합니다. 혹시 위 코드에서 문제점을 발견하셨나요?

코드를 실행해서 버튼을 누르면 다음과 같은 결과를 확인할 수 있습니다.

[실행결과]

networkRequestAPI -> subscribed
networkRequestAPI -> Event next(100)
networkRequestAPI -> Event completed
networkRequestAPI -> isDisposed
networkRequestAPI -> subscribed
networkRequestAPI -> Event next(100)
networkRequestAPI -> Event completed
networkRequestAPI -> isDisposed

보시다시피 서버에 API를 두번 요청해 결과를 받아왔습니다. 만약 이 API 요청의 결과를 Subscribe()해 사용하는 곳의 갯수가 10개가 더 늘어난다면 어떻게 될까요? 서버에 API를 12번 요청하게 됩니다. 😰

이건 저희가 기대하는 동작은 아닐 것입니다. 이 문제를 해결하기 위해 share() 연산자를 사용합니다.

share() 연산자를 사용하면 Subscribe()할때마다 새로운 Observable 시퀀스가 생성되지 않고, 하나의 시퀀스에서 방출되는 아이템을 공유해 사용할 수 있습니다.

위 예제 코드에 다음과 같이 .share()를 추가하고 코드를 다시 실행해보도록 하겠습니다.

[코드]

let result = requestMoreButton.rx.tap
	.flatMap { networkRequestAPI }
	.share() // result 시퀀스를 공유하도록 처리

[실행결과]

networkRequestAPI -> subscribed
networkRequestAPI -> Event next(100)
networkRequestAPI -> Event completed
networkRequestAPI -> isDisposed

저희가 기대한대로 단 한번의 API 호출이 이루어졌음을 확인할 수 있습니다.

share()는 subscribe()가 처음 호출될 때 (Subscriptoin횟수가 0 -> 1 일때)만 Subscription을 생성하고, 이후 두번째 세번째로 subscribe()가 호출되면 새로운 Subscription을 생성하는 것 대신 이미 만들어진 Subscription을 이후 subscribe()를 호출한 곳에 공유해 사용합니다.

만약 share()에 subscribe()한 Subscription이 모두 disposed 되면 share()는 공유했던 Subscription을 dispose 시킵니다.

이후 다른 subscribe()가 호출되면 share()는 새로운 Subscription을 생성합니다. 그렇기 때문에 share()는 completed 되지 않는 Observable에 사용하는 것이 안전합니다. 혹은 공유하는 시퀀스가 completed 된 후 새로운 Observable이 생성되지 않는다고 확신할 때 사용해야합니다.

Replay

share(replay: 1)에서 replay에 넣는 인자는 버퍼의 크기를 의미합니다.

다른 시퀀스에서 share()된 Observable을 구독했을 때, 가장 최근 방출했던 아이템을 버퍼의 크기만큼 새로운 구독 시퀀스에 전달해줍니다. share()연산자의 선언을 살펴보면 다음과 같습니다.

[RxSwift/SubjectLifetimeScope.swift]

public func share(replay: Int = 0, scope: SubjectLifetimeScope = .whileConnected)

replay외에 scope이라는 인자가 있는데 이 값은 버퍼의 생명주기에 관한 것입니다. 입니다. .forever와 .whileConnected를 선택할 수 있고 아무값도 설정하지 않으면 .whileConnected를 기본값으로 사용합니다.

.forever : Subscription이 0이 되더라도 버퍼가 유지 됩니다. 그래서 새로운 Subscription은 Subscribe() 를 하면 마지막에 버퍼에 남아있던 replay개수 만큼의 값을 수신하게 됩니다.
.whileConnected : 1개 이상의 Subscriber가 존재하는 동안만 버퍼가 유지 됩니다. Subscription이 0이 되면 버퍼가 비워지고 새로운 Subscription은 버퍼에 남아 있던 값이 없으므로 replay시 새 값을 요청해 수신하게 됩니다.

한걸음 더 들어가기

사실 share()에 대해 여기까지만 알아도 사용하는데는 지장이 없습니다. 하지만 share()가 어떻게 동작하는지 좀 더 알고 싶으신 분은 위해 좀 더 깊이 들어가 보겠습니다.

앞서 살펴봤던 share()함수의 정의를 구현부까지 살펴보죠.

[RxSwift/SubjectLifetimeScope.swift]

public func share(replay: Int = 0, scope: SubjectLifetimeScope = .whileConnected)
        -> Observable<Element> {
        switch scope {
        case .forever:
            switch replay {
            case 0: return self.multicast(PublishSubject()).refCount()
            default: return self.multicast(ReplaySubject.create(bufferSize: replay)).refCount()
            }
        case .whileConnected:
            switch replay {
            case 0: return ShareWhileConnected(source: self.asObservable())
            case 1: return ShareReplay1WhileConnected(source: self.asObservable())
            default: return self.multicast(makeSubject: { ReplaySubject.create(bufferSize: replay) }).refCount()
            }
        }
    }

코드를 보면 share(replay)를 하면 scope가 .forever 이거나 .whileConnected 상관없이 모두 return self.multicast(makeSubject: { ReplaySubject.create(bufferSize: replay) }).refCount() 를 반환하는 것을 확인할 수 있습니다.

네 그렇습니다. 사실 anObservable.share()는 anObservable.publish().refCount()입니다.

다음 그림과 이후 설명을 보면 앞에 설명한 share()의 동작이 좀 더 이해 되실 겁니다. 더 자세한 설명은 생략합니다. 🙂

publish() : 이 연산자는 보통의 Observable을 ConnectableObservable로 변환해 줍니다.
ConnectableObservable : ConnectableObservable은 Subscriber가 있어도 connect()를 호출하기 전까지는 아이템을 방출하지 않습니다. connect()를 호출하고 나서야 아이템을 방출하기 시작합니다.
refcount() : refcount() 는 ConnectableObservable에 Connect와 Disconnect를 자동으로 담당하고, ConnectableObservable을 보통의 Observable처럼 사용할 수 있게 해줍니다. 다시말해 Subscription count를 계속 세고 있다가 Subscription의 개수가 0 -> 1 개가 되는 시점에 connect()를 수행하고 Subscription이 0이 되면 disconnect()를 수행합니다.

결론

여러 시퀀스에서 사용하게 되는 Observable은 Subscribe() 할때마다 subscription이 생성되니 share()해서 사용해야 한다. 보통 share(replay: 1) 형태로 사용한다.

라는게 이번 포스트의 결론입니다.

이상 Share(replay:)에 대해 대해 알아 보았습니다. (👨🏻‍💻지식이 +5 늘었다.)

다음 포스트에서 또 만나요~ 🚀😄

[참고]

[Swift] 관련 값이 있는 Enum Case 비교하기

Sun, 29 Mar 2020 00:00:00 +0900

Swift에서 Enum은 상태를 관리하기에 유용한 타입입니다. Enum의 case에 관련 값(Associated Value)을 사용하면 상태와 관련된 처리를 보다 편리하게 할 수 있습니다.

이번 포스트에서는 관련 값을 사용하는 Enum case를 비교하는 방법을 알아 보겠습니다.

비교를 위해 우선 Enum case에서 관련 값을 사용하지 않는 경우부터 살펴보겠습니다.

1. case에 관련 값을 사용하지 않는경우

enum State {
    case ready
    case notReady
}

let stateA = State.ready

if stateA == .ready {
    print("Ready")         // ✅ Ready가 결과로 출력 
} else {
    print("Not Ready")
}

관련 값을 사용하지 않는 경우에는 if stateA == .ready 와 같이 case와 case를을 직접 비교할 수 있습니다. 너무나도 직관적인 문법이죠.

2. case에 관련 값을 사용하는경우

관련 값을 사용하는 경우에는 비교 방법이 조금 달라집니다.

enum State {
    case ready
    case loading(String)
    case error(String)
}

let stateA = State.ready

case에 관련 값을 추가했습니다. 이제 앞서 했던 문법으로 case로 비교를 해보죠.

if stateA == .ready {	 //❌ 컴파일 에러 발생! 
    print("Loading")        
} else {
    print("Not Loading")
}

당연히 될꺼라 기대되지만 Enum case에 관련 값이 있는 타입이기 때문에 컴파일 에러가 발생하며 비교할 수 없습니다.

관련 값이 있는 case가 비교 대상인 경우는 어떨까요?

if stateA == .loading(_) {     // ❌ 컴파일 에러 발생! 
    print("Loading")
} else {
    print("Not Loading")
}

if stateA == .loading("Loading") {     // ❌ 컴파일 에러 발생! 
    print("Loading")
} else {
    print("Not Loading")
}

관련 값이 있는 경우도 마찬가지 입니다.

관련 값을 사용하는 경우에는 다음 문법을 사용해 비교할 수 있습니다.

if case .ready = stateA {
    print("Ready")     // ✅ Ready가 결과로 출력
} else {
    print("Not Ready")
}

if case .loading(_) = stateA {
    print("Loading")     
} else {
    print("Not Loading") // ✅ Not Loading이 결과로 출력
}

if case .loading(_) = stateA 과 같이 문법이 마치 “왼쪽의 case의 틀에 오른쪽 case를 할당이 가능하냐?” 는 의미로 이해가 됩니다.

이상 관련 값을 사용하는 Enum case를 비교하는 법에 대해 알아 보았습니다. (👨🏻‍💻지식이 +1 늘었다.)

다음 포스트에서 또 만나요~ 🚀😄

[참 고]

[Xcode] 시뮬레이터에서 Remote Push 시뮬레이션하기

Tue, 11 Feb 2020 00:00:00 +0900

Xcode 11.4부터 시뮬레이터에서 Remote Push Notification의 시뮬레이션을 지원합니다. 😄

시뮬레이션을 하는 방법은 다음과 같이 두가지가 있습니다.

시뮬레이터에 apns 파일을 직접 드래그 하는 방법
CLI를 이용하는 방법

준비

Remote Push Notification를 시뮬레이션 하기 위해서는 우선 사용자에게 푸시 알림 사용 권한을 요청하고 허가를 받아야 합니다.

권한 요청을 위해 AppDelegate 파일의 didFinishLaunchingWithOptions 델리게이트에 권한 요청 코드를 추가합니다.

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
   requestAuthorizationForRemotePushNotification()
   return true
}

// 사용자에게 푸시 권한을 요청
func requestAuthorizationForRemotePushNotification() {
    let current = UNUserNotificationCenter.current()
    current.requestAuthorization(options: [.alert, .sound, .badge]) { (granted, error) in
    	// granted가 true로 떨어지면 푸시를 받을 수 있습닏.
    }
}

앱을 실행하면 권한 요청 팝업이 노출되는데, 허용(Allow)을 선택해 Remote Push를 사용할 수 있도록 해줍니다.

준비는 끝났습니다. 이제 시뮬레이션을 해보죠.

1. 시뮬레이터에 apns 파일을 직접 드래그 하는 방법

apns 파일은 json 포맷의 확장자가 apns인 파일입니다.

apns의 payload 형식을 따라 샘플 파일을 생성합니다.

{
    "Simulator Target Bundle" : "com.joyfulpace.apnsTest",
    "aps" : {
        "alert" : {
            "title" : "최고의 iOS 개발팀 맴버",
            "body" : "쉘든, 제이든, 플라, 네오, 줄리, 셀리나, 루키, 헤이, 세일러, 바트, 스티브, 가브리엘, 딘, 조나단, 토미",
        },
    },
}

paylaod의 key는 다음과 같이 크게 두 부분으로 구성돼 있습니다.

Simulator Target Bundle : 시뮬레이터에 설치된 테스트 앱의 bundleID

aps : Remote Push Notification 사용을 위해 지정된 payload (더 많은 payload key는 이곳에서 확인할 수 있습니다.)

알맞은 앱 bundleID와 payload를 넣고 파일을 저장합니다. 저는 이 파일을 test.apns 로 저장하겠습니다.

이제 이 파일을 시뮬레이터에 드래그 해보겠습니다.

시뮬레이션이 잘 되는 것을 확인할 수 있습니다.

2. CLI를 사용하는 방법

터미널에서도 푸시 시뮬레이션을 할 수 있습니다.

시뮬레이션에는 xcrun 명령을 사용합니다.

명령어는 다음과 같습니다.

xcrun simctl push EEDF7FDD-6C34-4DB6-8A3B-43B71769E2D8 com.joyfulpace.apnsTest test.apns

[xcrun 명령]

$ xcrun simctl push --help
Send a simulated push notification
Usage: simctl push <device> [<bundle identifier>] (<json file> | -)

	bundle identifier
	     The bundle identifier of the target application
	     If the payload file contains a 'Simulator Target Bundle' top-level key this parameter may be omitted.
	     If both are provided this argument will override the value from the payload.
	json file
	     Path to a JSON payload or '-' to read from stdin. The payload must:
	       - Contain an object at the top level.
	       - Contain an 'aps' key with valid Apple Push Notification values.
	       - Be 4096 bytes or less.

Only application remote push notifications are supported. VoIP, Complication, File Provider, and other types are not supported.

파라미터에서 입력해 줘야하는 내용은 다음과 같습니다.

device : 시뮬레이터의 Identifier

bundle identifier : 자신의 앱의 번들 ID

json file : 확장자가 apns여도 상관 없음

시뮬레이터의 Identifier는 다음과 같이 xcrun simctl list devices 명령으로 찾을 수 있습니다. 리스트 중에서 현재 사용중인 시뮬레이터는 Booted라고 상태가 표시됩니다. 시뮬레이터 기종이 맞고 상태가 Booted인 시뮬레이터 identifier를 복사해 사용하면 됩니다.

다음과 같이 grep Booted로 list의 결과를 필터링해 보면 한번에 찾을 수 있습니다.

$ xcrun simctl list devices | grep Booted
    iPhone 11 Pro Max (EEDF7FDD-6C34-4DB6-8A3B-43B71769E2D8) (Booted) 

CLI를 사용할 경우 다음과 같이 apns 파일에 Simulator Target Bundle 부분을 생략할 수 있습니다. bundleID가 CLI의 파라미터에 들어가기 때문이죠.

{
    "aps" : {
        "alert" : {
            "title" : "최고의 iOS 개발팀 맴버",
            "body" : "쉘든, 제이든, 플라, 네오, 줄리, 셀리나, 루키, 헤이, 세일러, 바트, 스티브, 가브리엘, 딘, 조나단, 토미",
        },
    },
}

실행해 보겠습니다. Yay! 😙 잘 됩니다.

이상 시뮬레이터에서 Remote Push Notification을 시뮬레이션 하는 방법에 대해 알아 보았습니다. 😄

[RxSwift Book] Chapter 12: Beginning RxCocoa

Wed, 29 Jan 2020 00:00:00 +0900

이 포스트는 RxSwift - Reactive Programming with Swift 책의 챕터 12에서 눈에 띄는 내용들만 요약해 둔 것입니다. 참고 바랍니다.

1. RxCocoa

UI Control과 다른 SDK 클래스를 wrapping한 커스텀 extension set
iOS, tvOS, macOS의 모든 플랫폼에서 동작

2. ObserverType과 ObservableType

ObserverType : 값을 주입(Inject)시킬 수 있는 타입
ObservableType : 값을 관찰할 수 있는 타입

ControlProperty

Subject 같이 프로퍼티에 새 값을 주입시킬 수 있고(ObserverType) 값의 변화도 관찰할 수 있는 타입(ObservableType).

예) UITextField+Rx.Swift의 text 프로퍼티는 ControlProperty

extension Reactive where Base: UITextField {
    /// Reactive wrapper for `text` property.
    public var text: ControlProperty<String?> {
        return value
    }
    //  이후 내용 생략
}

ControlProperty는 ControlPropertyType를 따름

public struct ControlProperty<PropertyType> : ControlPropertyType {
// 이후 내용 생략
}

ControlPropertyType은 ObservableType과 ObserverType을 따름을 확인

public protocol ControlPropertyType : ObservableType, ObserverType {
    /// - returns: `ControlProperty` interface
    func asControlProperty() -> ControlProperty<Element>
}

Binder

ObserverType을 따름. 값을 주입시킬 수는 있지만, 값을 관찰할 수는 없음.
- 특징 : error를 값으로 받을 수 없음. error가 주입되면 Binder는 debug모드에서 fatalError() 발생시킴. production 모드에서는 런타임 에러로그를 출력.
예) UILabel+Rx.Swift에서 text 바인더 프로퍼티는 값을 주입만 시킬 수 있음.

extension Reactive where Base: UILabel {
    /// Bindable sink for `text` property.
    public var text: Binder<String?> {
        return Binder(self.base) { label, text in
            label.text = text
        }
    }

Binder는 ObserverType를 따름을 확인

public struct Binder<Value>: ObserverType {
// 이후 내용 생략
}

3. Observable의 Binding

RxCocoa에서 binding은 단방향 binding

Bind(to:)

bind(to:)는 subscribe()의 별칭(alias or syntatic sugar)
bind(to: observer)를 호출하면 실제로는 subscribe(observer)가 실행됨

4. Trait

Trait이란? UI 작업시 코드를 쉽고 직관적으로 작성해 사용할 수 있도록 도와주는 특별한 Observable 클래스의 모음

Trait의 규칙

error를 방출하지 않음
메인스케쥴러에서 observe 됨
메인스케쥴러에서 subscribe됨
Signal을 제외한 나머지 Trait은 자원을 공유함(e.g share(replay:1))

RxCocoa의 Traits

ControlProperty : 컨트롤에 data를 binding 하기 위해 사용 (rx namespace 사용)
ControlEvent : 컨트롤의 event를 수신하기 위해 사용
Driver : error를 방출하지 않고 메인스레드에서 처리됨
Signal : Driver와 거의 동일. 한가지 다른 점은 자원을 공유하지 않음. (share(replay:1) 사용하지 않음). 즉, 새로운 subscriber에게 마지막 엘리먼트를 보내주지 않음
- Signal은 event모델링에 유용하고, Driver는 state모델링에 더 적합

Driver와 ControlProperty의 사용

let search = searchCityName.rx.text.orEmpty
	.filter { !$0.isEmpty }
	.flatMapLatest { text in 
	return ApiController.shared.currentWeather(city: text)
	.catchErrorJustReturn(ApiController.Weather.empty)
	}
	.asDriver(onErrorJustReturn: ApiController.Weather.empty)

.asDriver(onErrorJustReturn:) : Observable에서 error가 방출됐을때 Driver에서 error 대신 지정한 기본 값을 리턴하도록 만들어 Driver에서 error가 방출되는 것을 막음

bind(to:) 코드 대신 drive() 코드 사용하기

변경 전 : bind(to:) 사용

search.map { $0.icon }
   .bind(to: iconLabel.rx.text)
   .disposed(by: bag)

search.map { "\($0.humidity)%"}
   .bind(to: humidityLabel.rx.text)
   .disposed(by: bag)

search.map { $0.cityName }
   .bind(to: cityNameLabel.rx.text)
   .disposed(by: bag)

변경 후 : drive사용

search.map { $0.icon }
   .drive(iconLabel.rx.text)
   .disposed(by: bag)

search.map { "\($0.humidity)%"}
   .drive(humidityLabel.rx.text)
   .disposed(by: bag)

search.map { $0.cityName }
   .drive(cityNameLabel.rx.text)
   .disposed(by: bag)

5. RxSwift와 RxCocoa에서의 Traits

[RxSwift] Zip

Tue, 14 Jan 2020 00:00:00 +0900

역할

두 개 이상의 Observable에서 방출된 순서가 같은 아이템을 묶어서 하나의 아이템으로 방출합니다.

예제

[코드]

let disposeBag = DisposeBag()
    
let numSubject = PublishSubject<Int>()
let charSubject = PublishSubject<String>()
    
let zippedObservable = Observable.zip(numSubject, charSubject)
    
zippedObservable
    .subscribe(onNext: { print($0) })
    .disposed(by: disposeBag)
    
numSubject.onNext(1)
charSubject.onNext("A")
numSubject.onNext(2)
charSubject.onNext("B")
charSubject.onNext("C")
charSubject.onNext("D")
numSubject.onNext(3)
numSubject.onNext(4)
numSubject.onNext(5)

[실행 결과]

(1, "A")
(2, "B")
(3, "C")
(4, "D")

numSubject의 아이템 5에 대해서는 charSubject에서 같은 순서에 방출된 아이템이 없으므로 zip 결과로 아무런 아이템도 방출되지 않습니다.

활용

같은 순서쌍으로 처리해야하는 작업에 사용하면 편리 합니다.

예를들면, UITableView에서 선택한 Cell의 indexPath와 그 indexPath에 해당하는 model을 보장하는 처리를 하고 싶을때 zip을 사용할 수 있습니다.

첫번째 Observable: UITableView에서 선택된 아이템의 indexPath

두번째 Observable: UITableView에서 선택된 아이템의 model

[코드]

Observable.zip(tableView.rx.itemSelected, tableView.rx.modelSelected(ServiceType.self))
.subscribe(onNext: { [weak self] (indexPath, serviceType) in
    self?.tableView.deselectRow(at: indexPath, animated: false)
    self?.selectedServiceType.accept(serviceType)
})
.disposed(by: disposeBag)

indexPath을 이용해 선택된 Cell을 deselect하고, model은 선택된 Cell의 모델을 관리하기 위해 사용합니다.

[참 고]

ReactiveX - zip

[Swift] 커링(Currying)이란?

Tue, 07 Jan 2020 00:00:00 +0900

함수형 프로그래밍을 하다보면 커링(Currying)이라는 말을 종종 들어보셨을 겁니다. 이번 포스트에서는 이 커링에 대해 알아 보겠습니다. 포스트가 제법 깁니다. 😅

간단히 알고 넘어가실 분은 TL;DR만 읽으셔도 됩니다.

TL;DR

커링: 여러 인자를 사용하는 함수를 인자 하나만 사용하는 함수로 변환하는 것
커링의 장점
1. 함수의 재사용성 향상
2. 코드의 가독성 향상

이름의 유래

커링이라는 이름은 수학자이자 논리학자인 하스켈 커리(Haskell Brooks Curry)로 부터 유래 됐습니다.

네 맞습니다. 하스켈 언어도 이 사람의 이름에서 가져온 것입니다.

커링이란?

함수형 프로그래밍에서 커링이란

여러 인자를 입력받는 함수를 인자 하나만 입력받는 함수들의 시퀀스로 변환하는 것입니다.

변환된 함수는 인자 하나를 입력받고 값 대신 함수를 반환하는데, 이 반환되는 함수는 다음 인자를 입력으로 받습니다. 이 과정을 입력 값을 모두 처리하고 반환하는 값이 하나만 남을 때까지 반복합니다.

조금 복잡해 보이는데 다음 그림을 보시면 무슨 뜻인지 조금 감이 잡히실 것입니다.

일반 함수를 커링을 이용한 함수로 변환

위 그림이 어떤 의미인지 예제를 통해 살펴보겠습니다.

다음은 입력 받은 두 값을 더해 반환하는 함수 입니다.

func add2(_ x: Int, _ y: Int) -> Int {
    return x + y
}
add2(1, 2) // 결과: 3

위 함수를 커링하면 다음과 같이 변환할 수 있습니다.

func add2Currying(_ x: Int) -> ((Int) -> Int) {
    return { y in
        return x + y
    }
}
add2Currying(1)(2) // 결과: 3

두 함수 모두 같은 입력에 대해 같은 결과를 반환하는 것을 확인할 수 있습니다.

이제 커링을 사용한 함수와 사용하지 않은 함수를 비교해 세부적으로 살펴보겠습니다.

반환값

커링 미사용

func add2(_ x: Int, _ y: Int) -> Int

x, y를 입력 받아 Int 값을 반환합니다.

커링 사용

func add2Currying(_ x: Int) -> ((Int) -> Int)

x를 입력 받고 ((Int) -> Int) 과 같이 Int를 입력받아 Int를 반환하는 함수를 반환합니다.

구현

커링 미사용

return x + y

입력받은 값을 바로 더해 반환 합니다.

커링 사용

return { y in return x + y }

return x + y를 클로저로 감싸서 y가 입력되면 이미 입력받은 값 x에 y를 더한 값을 반환합니다. y가 입력되기 전에는 x값만 들고 있다가 y가 입력되는 순간 값을 계산해 반환합니다.

사용

커링 미사용

add2(1, 2)

인자를 콤마로 구분해 함수를 실행합니다. 함수를 한개 실행하기 때문에 여닫는 괄호가 한번 뿐입니다.

커링 사용

add2Currying(1)(2)

괄호를 분리해 두번 나눠서 실행합니다. 괄호가 두개인 이유는 함수를 두번 호출하기 때문입니다.

그럼이제 앞서 설명드린 세가지를 종합해서 커링함수가 동작하는 방식을 설명드리겠습니다.

func add2Currying(_ x: Int) -> ((Int) -> Int) {
    return { y in return x + y } 
}

위 함수는 앞에서 add2Currying(1)(2)의 형태로 호출했는데 이 함수를 다음과 같이 사용할 수 있습니다.

let threePlus = add2Currying(3)
threePlus(5) // 결과 8

여기서 threePlus는 값이 아니라 함수 입니다. 어떤 함수냐구요? Int값 하나를 입력 받아서, 3에다가 입력받은 Int값을 더해서 반환하는 함수입니다.

바로 이런 함수입니다.

{ y in return 3 + y }

이해가 되시나요? 그렇다면 조금 더 복잡한 케이스를 다뤄보면서 제대로 이해했는지 한번 더 확인해 보도록 하겠습니다.

이번에는 인자 3개를 입력받고 이 값을 모두 더해 반환하는 함수를 만들어 보겠습니다. 우선, 커링을 사용하지 않은 일반적인 함수입니다.

func add3(_ x: Int, _ y: Int, _ z: Int) -> Int {
    return x + y + z
}
add3(1, 2, 3) // 결과 : 6

위 함수를 커링을 사용해 구현하면 다음과 같습니다.

func add3Currying(_ x: Int) -> (Int) -> ((Int) -> Int) {
    return { z in
        return { y in
            return x + y + z
        }
    }
}
add3Currying(1)(2)(3) // 결과 : 6

add3Currying(_ x: Int) -> (Int) -> ((Int) -> Int)에서

첫번째 함수는

(_ x: Int) 이 입력값이고 반환값은 Int -> ((Int) -> Int) 입니다.

두번째 함수는

(Int)이 입력값이고 반환값은 (Int) -> Int 입니다.

세번째 함수는

Int가 입력값이고 Int가 반환값 입니다.

각 함수를 함수별로 쪼개 보겠습니다.

func add3Currying(_ x: Int) -> (Int) -> ((Int) -> Int) {
    return { z in
        return { y in
            return x + y + z
        }
    }
}

let onePlus = add3Currying(1)
let threePlus = onePlus(2)
let result = threePlus(3)

onePlus는 다음과 같은 함수입니다.

    return { z in
        return { y in
            return 1 + y + z
        }
    }

threePlus는 다음과 같은 함수입니다.

    return { z in
        return 1 + 2 + z
    }

result는 다음의 결과 값을 반환합니다.

return 1 + 2 + 3

이제 좀 감이 오시나요?

그럼 이제 이 커링을 Generic을 사용해 일반화 된 함수로 정의해 보겠습니다.

func curry<A, B, C>(_ fn: @escaping (A, B) -> C) -> (A) -> (B) -> C {
        return { (a: A) in
            return { (b: B) in
                return fn(a, b)
            }
        }
    }

커링 함수는 함수(fn)를 인자로 받는데 이 함수는

(a: A) -> (B) -> C와 같이

(a: A)를 인자로 입력받고 (B)를 입력으로 받고 C를 반환하는 함수를 반환합니다.

그리고 그 반환된 함수는

(b: B) -> C와 같이

(b: B)를 인자로 입력받고 C를 반환하는 함수를 반환합니다.

그리고 그 반환된 함수는

입력받은 a와 b로 fn(a, b)를 수행한 값을 반환하게 됩니다.

활 용

커링을 사용하면 함수를 재사용하는데 유용합니다.

함수가 여러 단계를 거쳐 실행되고 재사용될때 마지막 단계에서 변화가 있는 경우, 커링을 사용하면 앞의 단계는 고정시켜 놓고 가장 마지막 단계만 변경할 수 있어 효과적입니다.

예제를 보며 좀 더 자세히 알아보겠습니다.

enum LogLevel: String {
   case debug
   case error
}
func logMessage(level: LogLevel, message: String) {
   print("[\(level)] \(message)")
}

위 코드는 로그를 출력하는 함수 입니다. logMessage 함수에 로그 level과 로그message를 넣으면 로그가 출력됩니다.

커링을 사용하지 않은 일반적인 방법은 다음과 같이 사용하는 것입니다.

logMessage(level: .debug, message: "Log debug - Normal")

로그를 출력하는데 로그레벨은 변함이 없고 메시지만 변하게 되는 경우 어떻게 처리할 수 있을까요?

함수에 Default 파라미터를 지정할 수도 있지만, 그 경우는 Default 파라미터로 지정된 값만 생략 가능하기 때문에 적절한 해법이 될 수 없습니다.

이럴때 커링을 활용할 수 있습니다.

logMessage(level: .debug, message: "Log debug 1st")
logMessage(level: .debug, message: "Log debug 2nd")
logMessage(level: .debug, message: "Log debug 3rd")

위 코드대신 커링을 사용해

let logCurried = curry(logMessage)
let debug = logCurried(.debug)

debug("Log debug 1st")
debug("Log debug 2nd")
debug("Log debug 3rd")

debug("Message") 처럼 변하는 값만 인자로 넣어 사용할 수 있습니다.

또 다른 예를 살펴보겠습니다.

// Without Currying
let fruits: [String] = ["Apple", "Banana", "Peach", "Grape"]
        
fruits.forEach { fruit in
   logMessage(level: .debug, message: fruit)
}
        
fruits.forEach { fruit in
   logMessage(level: .error, message: fruit)
}

위 코드를 커링을 사용하면 다음과 같이 작성할 수 있습니다.

// with Currying
let debug = curry(logMessage)(.debug)
let error = curry(logMessage)(.error)        
fruits.forEach(debug1)
fruits.forEach(error1)

커링의 장점

지금까지 살펴본 예제 코드를 통해 커링 사용의 장점 두 가지를 알 수있습니다.

함수의 재사용을 쉽게 만들어 줌 (인자 중 변하지 않는 값은 고정시키고 변하는 값만 지정해서 함수를 실행할 수 있게 해줌)
가독성을 높여줌

RxSwift에서 응용

Observable에 다음과 같은 extension코드를 작성 후, completion 블럭을 사용하는 비동기 코드를 Observable 시퀀스에 마이그레이션을 커링을 사용해 쉽게 할 수 있습니다.

extension Observable {
    public static func fromAsync(_ asyncRequest: @escaping (@escaping (Element?, Error?) -> Void) -> Void) -> Observable<Element> {
        return Observable.create { (o) -> Disposable in
            asyncRequest { res, error in
                if let err = error {
                    o.onError(err)
                    return
                }
                guard let element = res else {
                    o.onCompleted()
                    return
                }
                o.onNext(element)
                o.onCompleted()
            }
            return Disposables.create {}
        }
    }
    
    public static func fromAsync<T>(_ asyncRequest: @escaping (T, @escaping (Element?, Error?) -> Void) -> Void) -> (T) -> Observable<Element> {
        return { param1 in Observable.fromAsync(curry(asyncRequest)(param1)) }
    }
}

let fetchPostObservable = Observable.fromAsync(PostService.fetchPosts(by:completion:))
        fetchPostObservable(10)
            .subscribe(onNext: { post in
                print("Fetching post with id:\(post.id) succeeded")
            }, onError: { error in
                print("Fetching post failed: \(error)")
            })
            .disposed(by: disposeBag)

struct Post {
    let id: Int
}

class PostService {
    static func fetchPosts(by postId: Int, completion: @escaping (Post?, Error?) -> Void ) {
        print("fetchPosts Closure")
        // post는 API를 통해 수신한 객체
        let post = Post(id: postId)
        completion(post, nil)
    }
}

let fetchPostObservable = Observable.fromAsync(PostService.fetchPosts(by:completion:))

이와 같이 기존에 completion block을 사용하던 코드를 Observable 시퀀스에 간단하게 마이그레이션 시킨 것을 확인할 수 있습니다.

이상으로 커링에 대해 알아봤습니다. 😄

[참 고]

[Swift] 클래스만 사용 가능한 프로토콜의 선언

Tue, 31 Dec 2019 00:00:00 +0900

'weak' must not be applied to non-class-bound 'MyDelegate'; consider adding a protocol conformance that has a class bound

이런 에러가 발생했다구요? 이 에러는 class를 따르지 않는 프로토콜을 weak 변수로 선언해 사용할 때 발생하는 에러입니다.

예를들어 보겠습니다.

프로토콜을 이용해 델리게이트를 선언합니다.

protocol MyDelegate {
    func runDelegateMethod()
}

클래스 안에서 위에서 선언한 델리게이트 프로토콜을 따르는 delegate를 weak로 선언 합니다. weak로 선언한 이유는 Retain Cycle을 피하기 위해서 입니다.

class ClassProtocolTest: MyDelegate {
    weak var delegate: MyDelegate?
    func runDelegateMethod() {}
}

이 코드를 빌드하면 앞서 언급한 에러가 발생합니다. 왜일까요?

프로토콜은 클래스와 구조체, 열거형에 사용 가능합니다. 앞에서 선언한 프로토콜은 클래스에서 사용되는지 아니면 구조체나 열거형에서 사용되는지 알 수 없기 때문에 reference count관리를 위해 사용되는 unowned이나 weak 키워드를 사용할 수 없는 것입니다.

이 에러를 해결하기 위해서는 프로토콜을 class를 따르도록 선언해서 클래스에서만 사용 가능하도록 명시합니다.

protocol MyDelegate: class {
    func runDelegateMethod()
}

이렇게 선언하면 에러 없이 빌드가 가능합니다.

만약 이 클래스에서만 사용가능한 프로토콜을 아래와 같이 구조체에서 사용하려고 하면

struct ClassProtocolTest: MyDelegate {
    weak var delegate: MyDelegate?
    func runDelegateMethod() {}
}

다음과 같이 클래스 타입이 아닌 곳에서 클래스 타입 프로토콜을 따를 수 없다는 에러가 발생합니다.

Non-class type 'ClassProtocolTest' cannot conform to class protocol 'MyDelegate'

[RxSwift] withLatestFrom

Tue, 24 Dec 2019 00:00:00 +0900

역할

두 Observable중 첫번째 Observable에서 아이템이 방출될 때마다 그 아이템을 두번째 Observable의 가장 최근 아이템과 결합해 방출합니다.

예제

[코드]

let disposeBag = DisposeBag()
    
let numSubject  = PublishSubject<Int>()
let charSubject = PublishSubject<String>()
    
numSubject
    .withLatestFrom(charSubject) { "\($0)\($1)"}
    .subscribe(onNext: { print($0) })
    .disposed(by:disposeBag)
    
numSubject.onNext(1)     // 아이템 방출되지 않음 : charSubject에서 방출된 아이템이 아직 1개도 없으므로
    
charSubject.onNext("A")
    
numSubject.onNext(2)     // 2A
    
charSubject.onNext("B")
    
charSubject.onNext("C")
charSubject.onNext("D")
    
numSubject.onNext(3)     // 3D
numSubject.onNext(4)     // 4D
numSubject.onNext(5)     // 5D

[실행 결과]

2A
3D
4D
5D

numSubject에서 아이템이 방출될때만 withLatestFrom 연산이 수행됩니다. 첫번째 Observable에서 첫 아이템(A)이 방출된 시점에 두번째 Observable에서 방출된 아이템이 없으므로, 아무런 아이템이 방출되지 않고 그 이후 부터 아이템이 방출되는 것을 확인할 수 있습니다.

활용

첫번째 Observable: tap 이벤트

두번째 Observable: 이벤트에 대한 처리

두 Observable을 이렇게 구성 한 후 withLatestFrom 연산자를 이용해 결합하면, tap 이벤트가 발생 했을 때 필요한 데이터를 발생시키거나 관련된 처리를 하도록 사용할 수 있습니다.

[코드]

let disposeBag = DisposeBag()
    
let loginButton  = PublishSubject<Void>()
let usernameTextField = PublishSubject<String>()
    
loginButton
    .withLatestFrom(usernameTextField)
    .subscribe(onNext: { print($0) })
    .disposed(by:disposeBag)
    
usernameTextField.onNext("tome.kye")
    
loginButton.onNext(())      // "tome.kye" 아이템 방출
    
usernameTextField.onNext("tommy.kye")
    
loginButton.onNext(())      // "tomme.kye" 아이템 방출

[실행 결과]

tome.kye
tommy.kye

이 예제는 로그인 버튼 선택시 데이터를 전달합니다. .withLatestFrom(usernameTextField) 는 첫번째 Observable의 아이템과 합성하지 않고, 두번째 Observable 아이템만 그대로 전달합니다.

아래 이 코드는

loginButton
    .withLatestFrom(usernameTextField)
    .subscribe(onNext: { print($0) })
    .disposed(by:disposeBag)

다음과 같이 API를 찌르는데 필요한 인자를 전달하는 용도로도 사용 가능합니다.

loginButton
    .withLatestFrom(usernameTextField)
    .flatMap { username -> Observable<UserDataModel> in
    		return API.Request(username: username)
    }

[참 고]

ReactiveX - withLatestFrom

[RxSwift] Subscribe의 동작 파헤치기

Mon, 16 Dec 2019 00:00:00 +0900

Subscribe의 일반적인 사용

RxSwift를 사용한다면 예외 없이 Subscribe를 사용하고 계실 것입니다.

보통 다음같이 사용하죠.

[Subscribe의 사용]

let numbersObservable = Observable.of(1, 2, 3, 4).debug()

numbersObservable
.subscribe()
.disposed(by: disposeBag)

[코드 실행결과]

-> subscribed**
-> Event next(1)**
-> Event next(2)**
-> Event next(3)**
-> Event next(4)**
-> Event completed**
-> isDisposed**

익숙하다구요? 당연하다구요?

그렇다면 한가지 질문을 드리겠습니다.

Observable은 보이는데 Observer는 어딨을까요?

보통 Subject를 Observable이면서 Observer라고 얘기하는데, 여기서 말하는 Observer를 한번이라도 본적 있으신가요? 전 없는데…

Observer 는 어딨는 걸까요? 🤔

Subscribe의 정의

공식 문서를 한번 살펴보겠습니다¹. 설명의 처음 한 문단만 보겠습니다.

Subscribe
operate upon the emissions and notifications from an Observable
The Subscribe operator is the glue that connects an observer to an Observable. In order for an observer to see the items being emitted by an Observable, or to receive error or completed notifications from the Observable, it must first subscribe to that Observable with this operator.

Subscribe는 Observable의 알림과 방출에 따라 동작한다.
Subscribe 연산자는 Observable에 Observer를 연결하는 접착제다. Observable에서 아이템이 방출되거나 에러 혹은 완료 알림을 받기 위해서는 반드시 처음에 이 연산자를 Observable에 사용해 구독해야만 가능하다.

Wha~~t???

역시 공식문서느님은 말해주고 계셨네요. 문서를 읽으며 알 수 있는 사실은 두가지 입니다.

하나는 Subscribe가 Observable에 Observer를 연결해준다는 것! Subscribe가 Observer같이 느껴졌는데 Subscribe가 Observer는 아니였습니다.

다른 하나는 Subscribe가 Operator였다는 사실입니다. 😮 헐…

Observable을 합치거나 발행된 아이템을 변형시키거나 걸러내는 행위를 하는 것만 Operator인줄 알았는데 Subscribe도 연산자였던 것입니다. 하는 일은 정의와 같이 Observable에 Observer를 붙여주는 일이죠.

오호! 지식이 늘었네요! 😙 (지식이 +1 늘었다.)

Subscribe가 Observable에 Observer를 붙여준다는 사실은 확인했는데, 아직까지 Observer가 어디있는지는 발견하지 못했습니다.

이제 뭘해야할까요? Subscribe 안의 코드를 한번 살펴보죠.

Subscribe의 내부

[ObservableType+Extensions.swift]

public func subscribe(onNext: ((Element) -> Void)? = nil, onError: ((Swift.Error) -> Void)? = nil, onCompleted: (() -> Void)? = nil, onDisposed: (() -> Void)? = nil)
        -> Disposable {
            let disposable: Disposable
            
            if let disposed = onDisposed {
                disposable = Disposables.create(with: disposed)
            }
            else {
                disposable = Disposables.create()
            }
            
            #if DEBUG
                let synchronizationTracker = SynchronizationTracker()
            #endif
            
            let callStack = Hooks.recordCallStackOnError ? Hooks.customCaptureSubscriptionCallstack() : []
            
            let observer = AnonymousObserver<Element> { event in
                
                #if DEBUG
                    synchronizationTracker.register(synchronizationErrorMessage: .default)
                    defer { synchronizationTracker.unregister() }
                #endif
                
                switch event {
                case .next(let value):
                    onNext?(value)
                case .error(let error):
                    if let onError = onError {
                        onError(error)
                    }
                    else {
                        Hooks.defaultErrorHandler(callStack, error)
                    }
                    disposable.dispose()
                case .completed:
                    onCompleted?()
                    disposable.dispose()
                }
            }
            return Disposables.create(
                self.asObservable().subscribe(observer),
                disposable
            )
    }

저희가 위 코드에서 살펴볼 부분은 두 부분입니다. 하나는 여기

let observer = AnonymousObserver<Element> { event in
                
                #if DEBUG
                    synchronizationTracker.register(synchronizationErrorMessage: .default)
                    defer { synchronizationTracker.unregister() }
                #endif
                
                switch event {
                case .next(let value):
                    onNext?(value)
                case .error(let error):
                    if let onError = onError {
                        onError(error)
                    }
                    else {
                        Hooks.defaultErrorHandler(callStack, error)
                    }
                    disposable.dispose()
                case .completed:
                    onCompleted?()
                    disposable.dispose()
                }
            }

보시다시피 Subscribe안에서 Observer를 생성하고 있네요! Observer는 event를 종류별로 방출하는 역할을 하고 있네요. 말그대로 이벤트를 관찰하고 거기에 맞는 행위를 하는 Observer역할을 하는 진짜 Observer입니다.

그다음에 살펴볼 코드는 다음 코드입니다.

return Disposables.create(
                self.asObservable().subscribe(observer),
                disposable
            )

Subscribe를 하면 반환되는 것이 Disposable인데 Subscribe안에서 self.asObservable().subscribe(observer) 요런 인자를 만들어서 Disposable을 생성하고 있네요.

self.asObservable()을 좀 더 뜯어보면

extension ObservableType {
    
    /// Default implementation of converting `ObservableType` to `Observable`.
    public func asObservable() -> Observable<Element> {
        // temporary workaround
        //return Observable.create(subscribe: self.subscribe)
        return Observable.create { o in
            return self.subscribe(o)
        }
    }
}

Observable을 생성하고 subscribe를 한 구독체를 반환하고 그 Observable에 .subscribe(observer) 로 Observer를 붙인 구독체를 최종적으로 반환하는 것을 확인할 수 있습니다.

내부에서 subscribe를 두번하는 것에 대한 얘기는 여기서는 생략하고(확실히 잘 몰라서 😓) Subscribe를 했을때 발생하는 일을 정리해 보겠습니다.

Subscribe가 하는 일

Observable을 Subscribe하면 Subscribe내부에서

Observer를 생성하고 생성한 그 Observer를

내부에서 생성한 Observable에 붙이고

붙인 그 구독체를 반환한다.

이렇게 정리할 수 있습니다.

Subscribe가 하는 일을 기억해두세요.

사실 이번 포스트는 다음 포스트인 Observable의 Share와 Share(replay)를 설명하기 위한 사전 포스트거든요. 😊

다음 포스트에서 또 만나요~

ReactiveX - Subscribe operator ↩

[RxSwift] Take

Tue, 10 Dec 2019 00:00:00 +0900

역할

Observable에서 내보낸 아이템 중, 처음 n개의 아이템만 내보냅니다.

예제

[코드]

Observable.of(1,2,3,4)
	.take(2)
	.debug()
	.subscribe()

[실행 결과]

-> subscribed
-> Event next(1)
-> Event next(2)
-> Event completed
-> isDisposed

구독 후 Observable의 아이템 1, 2, 3, 4 를 모두 내보내는 것이 아니라 그중 처음 2개 아이템인 1과 2만 내보낸 후 종료되는 것을 확인할 수 있습니다.

활용

주로 단 1개의 아이템만 내보내는 것을 보장하기 위해 take(1) 형태로 사용됩니다.

아이템이 여러번 방출될 수 있는 Observable에서 한번만 방출 되도록 제한하거나, 다음과 같이 flatMap에서 새로운 Observable이 생성될 때 한번만 생성되도록 조합해 사용합니다.

Observable
.flatMap { anotherObservable.take(1) }

[참 고]

ReactiveX - Take

[Swift] 순수함수(Pure Function)란?

Tue, 03 Dec 2019 00:00:00 +0900

[참고] 이 포스트는 외부 포스트를 요약한 것입니다. 더 자세한 내용을 확인하고 싶으신 분은 원문을 참조하세요.

원문 : Pure functions in Swift - by John Sundell

순수함수

순수함수란 외부 상태에 의존적이지 않고, 어떠한 사이드이펙트도 발생시키지 않는 함수입니다..

순수함수는 언제 얼마나 많이 호출해도 항상 같은 input에 대해 같은 output을 반환합니다. 순수함수라는 말이 이론적인 컨셉으로 보이지만 실제 다음과 같은 실용적인 이점이 있습니다.

이점

- 테스트가 용의하고, 재사용성이 올라감
- 예측가능성이 높아짐

예제를 통해 더 자세히 알아보죠.

예제 1 : 함수 내부에서 값을 변경하는 함수

아래 함수는 String에 확장자가 없으면 추가하는 함수로 아직 완전히 순수하지 않은 함수입니다.

extension String {
    mutating func addSuffixIfNeeded(_ suffix: String) {
        guard !hasSuffix(suffix) else {
            return
        }
        append(suffix)
    }
}

이 함수는 함수 안에서 값을 변경하고 있는데, 이게 큰 문제가 아닌 것 같지만 String이 Value Type이라 나중에 문제가 될 수 있습니다.

이 함수는 다음과 같이 사용할 수 있습니다.

var fileName = contentName
fileName.addSuffixIfNeeded(".md")
try save(content, inFileNamed: fileName)

앞의 함수를 순수함수로 만들기 위해 함수 안에서 값을 변경시키는 대신 값을 반환하도록 다음과 같이 변경 가능합니다.

extension String {
    func addingSuffixIfNeeded(_ suffix: String) -> String {
        guard !hasSuffix(suffix) else {
            return self
        }
        
        return appending(suffix)
    }
}

코드를 조금만 변경했는데, 이 변경을 통해 함수 내에서 상태를 변경 하던 부분을 제거했습니다. 변경한 함수는 아래와 같이 사용가능합니다.

let fileName = contentName.addingSuffixIfNeeded(".md")
try save(content, inFileName: fileName)

또 다른 예제를 살펴보죠.

예제 2 : 외부 상태에 의존적인 함수

로그인 실패시 보여줄 메시지를 만드는 함수를 예를 들어보죠. 이 함수는 로그인 실패 횟수에 따라 보여주는 메시지가 다릅니다.

extension LoginController {
    func makeFailureHelpText() -> String {
        guard numberofAttempts < 3 else {
            return "Still can't log you in. Forgot your password?"
        }
        
        return "Invalid username/password. Please try again."
    }
}

코드에서 보다시피 외부 프로퍼티인 numberofAttempts 값에 따라 반환하는 메시지가 다릅니다.

이 함수를 순수함수로 만들기 위해 다음과 같이 상태 파라미터에 의존적인 함수로 변경할 수 있습니다.

extension LoginController {
    func makeFailureHelpText(numberofAttempts: Int) -> String {
        guard numberofAttempts < 3 else {
            return "Still can't log you in. Forgot your password?"
        }
        
        return "Invalid username/password. Please try again."
    }
}

앞에서 언급했던 것 처럼 순수함수의 가장 큰 이점은 테스트 하기가 쉽다는 것입니다. Input 값을 넣으면 Output 값이 나옵니다.

방금 만들었던 함수는 다음과 같이 테스트가 가능합니다.

class LoginControllerTests: XCTestCase {
    func testHelpTextForFailedLogin() {
        let controller = LoginController()
        
        XCTAssertEqual {
            controller.makeFailureHelpText(numberOfAttemps: 0), 
            "Invalid username/password. Please try again."
        }
        
        XCTAssertEqual {
            controller.makeFailureHelpText(numberOfAttemps: 3), 
            "Still can't log you in. Forgot your password?"
        }
    }
}

인자 값 numberOfAttemps를 달리 넣는 것으로 쉽게 테스트 가능합니다. 이 밖에 순수함수는 다른 것에 의존적이지 않고 영향을 끼치지 않기 때문에 구조화 하기가 더 쉽습니다.

결론

코딩을 할때 앱 전체를 순수함수로만 구성하는 것은 매우 어렵습니다. 하지만 그렇게 하기만 하면 핵심 로직을 더 단단하게 만들고 테스트하기 쉽게 만들 수 있습니다.

Swift 5.1의 유용한 변화 2가지

Wed, 23 Oct 2019 00:00:00 +0900

이번 포스트에서는 Swift 5.1의 유용한 변화 2가지에 대해 살펴보겠습니다.

1. return 생략 (Implicit returns)

Swift 5.1부터 함수나 클로저 안에 return 키워드를 생략 가능합니다.¹ 단, 코드블럭 안에 return이 오직 한번만 사용될 때 생략 가능합니다. 자세한 내용은 이 후 내용에서 확인하실 수 있습니다.

struct Student {
    func whatToDo() -> String {
        "Just Play!"	// 매소드에서 return 키워드가 없이 값 반환 가능
    }
}

computed-property에서 다른 클래스의 매소드나 프로퍼티를 사용하는 곳에도 적용될 수 있습니다.

struct Student {
    var wannaGoCompany: String {
        Apple.name()	// 다른 클래스의 매소드도 return 키워드 없이 반환 가능
    }
}

struct Apple {
    static func name() -> String {
        "Apple Inc."
    }
}

삼항연산자에서도 return을 한번 사용하기 때문에 return 을 생략 가능합니다.

struct Student {
    var isSenior = true

    func whatShouldIDo() -> String {
        isSenior ? "Study Hard!" : "Just Play"
    }
}

if-else 구문 등 return을 두번이상 사용하는 곳에서는 return을 생략할 수 없습니다.

struct Student {
    var isSenior = true
    
    func whatToDo() -> String {
        if isSenior {
            return "Study Hard!"
        }
        else {
            return "Just Play"
        }
    }
}

2. 맴버 초기자에 디폴트값 지원

Swift 5.0까지 클래스나 구조체에 프로퍼티를 선언하고 초기자를 따로 지정하지 않으면, 아래 코드와 같이 자동으로 모든 프로퍼티를 포함하는 초기자를 사용할 수 있었습니다.

struct Company {
    var name: String
    var employees: Int
    var isFAANG: Bool
}

let company = Company(name: "Apple", employees: 345000, isFAANG: true)

하지만 다음과 같이 프로퍼티에 초기값이 있는 경우도 자동으로 생성된 초기자 사용시에는 모든 프로퍼티 값을 할당해야 했습니다.

struct Company {
    var name: String
    var employees: Int = 345000
    var isFAANG: Bool = true
}

let company = Company(name: "Apple", employees: 345000, isFAANG: true)
// Swift 5.1 미만에서 자동 초기자의 사용

Swift 5.1에서는 자동 초기자에 디폴트 값을 지원해서 다음과 같이 사용할 수 있습니다.²

let company = Company(name: "Apple") // 디폴트 값이 있는 프로퍼티는 초기화시 값할당이 생략 가능합니다.

이상 Swift 5.1에서 변경된 유용한 점 2가지를 살펴보았습니다. 😎

[더 자세히 알아보기]

관련내용을 더 자세히 보고 싶으신 분은 다음 Swift Evolution 제안 링크를 참조하세요.

[Swift] Result 타입

Mon, 11 Mar 2019 00:00:00 +0900

개 요

작업(Task) 중에는 실패할 수 있는 작업이 있습니다. 디스크에 파일을 쓰거나, API를 호출해 네트워크를 통해 데이터를 가져온다거나, 특정 URL에 있는 데이터를 불러오는 작업이 이 경우에 해당합니다. 이런 실패 가능한 작업을 처리하기 위해 Swift에서는(4.2 이하 버전) do,try, catch,throws 문법을 제공했습니다.

이 방법은 에러를 런타임에 동기로 자동으로 처리할 수 있게 해주었습니다. 하지만 이 방법으로는 발생 가능한 여러가지 예외 상황에 대해 대처하기 어려운 단점이 있었습니다. Swift5에서는(SE-0235) 이런 점을 보완해 에러를 보다 유연하게 처리할 수 있는 Result<Value, Error>문법을 지원합니다.

문제점

앞서 언급했던 기존의 Swift가 처리하기 어려웠던 상황 중 하나인 에러의 비동기 처리에 대해 한번 살펴보겠습니다. 기존의 Swift 문법에서는 에러를 비동기로 처리하기 위해 다음과 같은 형태의 문법을 사용했습니다.

func load(then handler: @escaping (Data?, Error?) -> Void) {
    //...
}

load { (data, error) in
    guard error == nil else { handleError(error!) }
    
    guard let data = data else { return } // 이런 경우도 발생할까? 🤔
    
    handleData(data)
}

이런 방법으로 에러를 처리하는 것은 몇 가지 문제점이 있습니다.

하나는 런타임에 error가 nil이라고 할지라도 data가 반드시 존재한다는 보장이 없습니다. 즉, error, data 모두가 nil일 수 있습니다.

다른 하나는 우리가 실제로 에러를 처리하기 위해 필요한 상태(state)보다 더 많은 상태가 생겨 불필요한 상태를 추가로 처리해야 한다는 것입니다. 저희가 처리하고자 하는 실행 결과의 상태는 성공(Success)과 실패(Failure) 딱 두가지 입니다.

하지만 위 경우는 다음과 같이 총 네 가지 발생할 수 있습니다.

Data, Error : True, False
Data, Error : True, True
Data, Error : False, True
Data, Error : False, False

저희가 처리하고 싶은 경우는 1번과 3번 두 가지이지만 실제로는 2, 4와 같은 모호한 상태가 추가되는 것이죠. Result타입을 사용하면 이런 에러 처리를 명확하게 할 수 있습니다.

상태의 분리 (Separate states)

다음은 Swift5에서 Result 타입의 정의입니다.

enum Result<Success, Failure: Error> {
    case success(Success)
    case failure(Failure)
}

앞의 예제를 Result를 이용해 바꿔보겠습니다.

func load(then handler: @escaping (Result<Data>) -> Void) {
    //...
}

load { result in
    switch result {
    case .success(let data):
        // load된 data 처리
    case .failure(let error):
        // error 처리
    }
}

Result를 사용하면 모호한 상태의 처리가 필요 없고 꼭 필요한 상태만 처리하면 되니 보다 명시적이고 간결하게 에러처리를 할 수 있음을 확인할 수 있습니다. Result는 기본적인 사용법 외에 다음과 같이 다양하게 사용할 수 있습니다.

Result의 다양한 사용법

1. 타입 에러 (Typed errors)

앞의 예제 코드에서 error는 Swift의 Error프로토콜을 따르는 모든 형태의 에러가 될 수 있는데, 이 경우 발생한 에러가 어떤 에러인지 정확하기 파악하기 어려운 점이 있습니다. 이 에러를 더 안전하고 정확하게 처리하기 위해 연관된 에러(associated error)를 정의해 사용할 수 있습니다.

앞의 예제 코드에서 error를 정의해 사용해 보겠습니다. Swift의 Error를 따르는(Conform) 열거형 LoadingError 를 선언합니다.

enum LoadingError: Error {
    case networkUnavailable
    case timedOut
    case invalidStatusCode(Int)
}

에러 발생시 LoadingError를 발생시키도록 Result의 Error에 LoadingError 타입을 선언합니다.

typealias Handler = (Result<Data, LoadingError>) -> Void

생성한 Handler를 이용해 load 함수를 선언합니다.

func load(then handler: @escaping Handler) {
        //...
}

load 함수의 성공, 실패 처리는 다음과 같이 할 수 있습니다. 에러 발생시 저희가 정의한 에러의 종류에 따라 처리할 수 있습니다.

load { [weak self] result in
    switch result {
    case .success(let data):
        self?.handle(data)
    case .failure(let error):
        switch error {
        case .networkUnavailable:
            self?.showErrorView(withMessage: .unavailable)
        case .timedOut:
            self?.showErrorView(withMessage: .timedOut)
        case .invalidStatusCode(let code):
            self?.showErrorView(withMessage: .statusCode(code))
        }
    }
}

2. Throw 처리

때에 따라서는 작업 결과의 처리를 Switch에서 하지 않고 try, do, catch 에서 직접 결과값을 받아서 처리하고 싶을 때가 있습니다. 이런 경우 성공시 결과값을 반환하고 실패시 throw를 뱉도록 처리도 가능합니다.

extension Result {
    func process() throws -> Success {
        switch self {
        case .success(let value)
            return value
        case .failure(let error)
            throw error
        }
    }
}

do {
    let result = try value?.process()
    handleValue(result)
}
catch {
    handleError(error)
}

3. 지연 처리 (Delayed Handling)

어떤 경우에는 에러처리를 바로 하지 않고 나중에 하고 싶을 때가 있습니다. 다음은 이런 경우에 대해 Result를 사용하지 않고 기존의 방식으로 코딩한 (예) 입니다.

var configString: String?
var configError: Error?

do {
    configString = try String(contentsOfFile: "myfile.data")
} catch {
    configError = error
}

func doSomethingWithConfig() {
    guard let configString = self.configString else {
        handle(configError)
    }
}

이 코드를 Result를 이용하면 클로저를 초기화 파라미터로 사용해 코드를 더 간결히 작성할 수 있습니다.

let configuration = Result { try String(contentsOfFile: "myfile.data") }

func doSomethingWithCongifg() {
    switch configuration {
    case .success(let success)
        handleSuccess(success)
    case .failure(let error)
        handlError(error)
    }
}

4. Result 변형 (Transforming Result)

Result는 map(), flatMap(), mapError(), flatMapError() 함수를 지원합니다. 다음은 Result에서 map()을 사용한 (예) 입니다.

func generateRandomNumber(maximum: Int) -> Result<Int, Error> {
    //...
}

let result = generateRandomNumber(maximum: 7)
let number = result.map { "Generated Random number is : \($0)" }

정의는 다음과 같습니다.

public func map<NewSuccess>(_ transform: (Success) -> NewSuccess) -> Result<NewSuccess, Failure> { }

public func mapError<NewFailure>(_ transform: (Failure) -> NewFailure) -> Result<Success, NewFailure> { }

public func flatMap<NewSuccess>(_ transform: (Success) -> Result<NewSuccess, Failure>) -> Result<NewSuccess, Failure> { }

public func flatMapError<NewFailure>(_ transform: (Failure) -> Result<Success, NewFailure>
) -> Result<Success, NewFailure> { }

이상으로 Swift5에서 추가된 Result타입에 대해 알아봤습니다. Result를 이용해서 에러를 더 쉽고 편하게 처리해 보세요. 😆👍

참고

[Swift] String 관련 용어 정리

Mon, 04 Mar 2019 00:00:00 +0900

용어의 정의를 제대로 알아야 관련 글이나 문서를 읽을 때 정확한 이해가 가능합니다. 이번 포스트에서는 Swift에서 사용되는 String관련 용어에 대해 알아보겠습니다.

String literals(문자 리터럴) : 소스에 있는 문자열을 나타냅니다.

let stringLiteral = "Hello, World!"	

String delimiters(문자 경계) : 문자열에서 시작과 끝의 경계를 구분짓는 문자. Swift에서는 큰따옴표(")를 문자열의 경계로 사용합니다.

let myWord = "Hello, World!" // Hello, World!를 감싸고 있는 큰따옴표(")가 String delimiter 입니다.

Escape characters(이스케이프 문자) : String literal 안에서 특별하게 해석되는 단일문자 혹은 문자열로 Swift에서는 백슬래시(\)(U+005C)를 사용합니다.

let income: Int = 500
let incomeInWon = "\(income)원" // \(income)

Escape character sequences(이스케이프 문자 시퀀스) : 줄여서 Escape sequence라 부릅니다. Escape character가 앞에 붙은 문자열로 이 문자는 문자 그대로 표현되지 않고 컴파일러에 의해 다른 문자로 변환됩니다. 문자를 직접 표현하는게 불가능하거나 어려울 때 사용됩니다. Swift는 다음과 같은 Escape sequence를 지원합니다.

* \0 : null 문자
* \\ : 백슬래시(\)
* \n : 라인피드
* \r : 케리지 리턴 (carriage return)
* \” : 큰따옴표
* \’ : 작은따옴표
* \u{*n*} : 임의의 유니코드 스칼라 값. (n은 1~8자리의 16진수)

Swift에서는 위의 Escaping Sequence를 사용한 [예]

* let wiseWords = "\"Imagination is more important than knowledge\" - Einstein"
* let dollarSign = "\u{24}"        // $,  Unicode scalar U+0024
* let blackHeart = "\u{2665}"      // ♥,  Unicode scalar U+2665
* let sparklingHeart = "\u{1F496}" // 💖, Unicode scalar U+1F496

이상으로 Swift의 String 관련 용어에 대해 알아보았습니다.

[참고]

[Swift] Raw String

Mon, 04 Mar 2019 00:00:00 +0900

Swift에서 String을 사용할 때 누구나 겪었을 만한 불편함이 하나 있습니다. 그건 바로 문자열에서 "나 \를 표현하기 위해 \를 추가로 사용해야 하는 것이죠.

간단한 (예)를 살펴 보겠습니다.

표현하고 싶은 문자는 I love "You" 입니다. You를 "로 감싸기 위해 " 다음과 같이 앞에 \를 추가해야 합니다.

let love = "I love \"You\""

정규식을 사용하는 경우는 더 복잡해 집니다. 정규식 자체도 약간의 복잡함을 갖고 있는데, 여기에 \가 추가되면 보기에 복잡해 보입니다. 아래 정규식은 \Location.latitude 같은 키패스 찾는 정규식입니다.

정규식 자체는 \\[A-Z]+[A-Za-z]+\.[a-z]+ 이렇게 표현되지만, 실제 코드에서 사용하려면 다음과 같이 표현 해야합니다.

let regex1 = "\\\\[A-Z]+[A-Za-z]+\\.[a-z]+"

보시다시피 \가 여러개 추가돼서 복잡해 보입니다. 이렇게 사용된 정규식은 정규식 검증이나, 다른 언어에 복사해서 사용하기 위해 바로 복사해 사용할 수 없고 \를 직접 발라서 사용해야합니다.

그렇다면 "나 \를 사용하기 위해 \를 추가하는 이런 추가적인 작업은 왜 필요한것 일까요?
그 이유는 "와 \가 각각 문자열의 시작과 끝을 나타내는 경계 문자(String delimiters)와 이스케이프 문자(Escape characters)로 사용되기 때문입니다.

다시 말해 "는 문자열의 범위의 경계를 파악하기 위한 기호로 사용하고, \는 이스케이프 문자로 문자열(string literals) 안에서 특별한 일을 처리하기 위해 사용하기 때문입니다.

이런 불편함을 해결하고자 Swift 5.0(SE-0200) 에서는 문자열의 경계를 나타내는 새로운 경계 문자 #"..."# 를 추가한 Raw String 을 지원합니다. 무슨 말인지 잘 모르시겠다구요? 예제를 보겠습니다.

위에 들었던 예제를 한번 살펴보죠.

let love1 = "I love \"You\""
let love2 = #"I love "You""#

비교가 되시나요? 문자열을 큰따옴표 대신 #"문자내용"# 로 감싸고 이 문자내용에 "나 \를 추가적인 \ 없이 사용할 수 있습니다.

앞에서 살펴봤던 정규식을 보죠.

let regex1 = "\\\\[A-Z]+[A-Za-z]+\\.[a-z]+"
let regex2 = #"\\[A-Z]+[A-Za-z]+\.[a-z]+"#

Raw String 문법을 이용해 regex2 같이 추가적인 \없이 정규식을 표현할 수 있습니다.

그렇다면 기존의 문자열 안에 상수나 변수의 내용을 넣고 싶을때 사용했던 \(property)는 어떨까요? 다음과 같이 \#(property)로 표현할 수 있습니다.

let price = 1000
let guide = #"The price of the shoes is \#(price)."#

앞에서 나왔던 것들을 종합해서 사용한 예제는 다음과 같습니다.

let url = "https://apple.com"

let html1 = "<a href=\"\(url)\" title=\"Apple Developer\">"
var html2 = #"<a href="\#(url)" title="Apple Developer">"#

어떤신가요? Raw String을 사용하면 좀더 보기 편하지 않나요? Raw String을 사용하면 이제 더 이상 추가적인 "나, \를 사용할 필요가 없습니다. Yay! 😆

잠깐! 그럼 만약 Raw String 안에 "#(문자열 끝 경계문자)을 써야하는 경우는 어떨까요? 그런 경우에는 문자열 경계 문자를 #"..."# 가 아닌 ##"..."##를 사용하면 됩니다. 그렇게 해서 다음과 같이 표현할 수 있습니다.

let str = ##"My cat is "Good"#GoodDog"##

결과 : My cat is Good#GoodDog

[Swift String에서 경계 문자(Delimiter)의 사용]

String Start Delimiter	Escape Delimiter	String End Delimiter
`"`	`\`	`"`
`#"`	`\#`	`"#`
`##"`	`\##`	`"##`
`######"`	`\######`	`"######`

이상으로 Swift 5.0에서 추가된 Raw String에 대해 알아보았습니다. Raw String을 사용해 사전 정의된 경계문자 ", \ 등이 포함된 문자를 이제 보다 쉽고 편하게 사용할 수 있습니다. Raw String 덕분에 고통을 덜 수 있겠네요.
다음 포스트에서 또 만나요~ 😊

남은 이야기 (Raw String 문법 디자인 뒷 이야기)

Swift의 Raw String 문법을 디자인할때 Rust에서 영감을 받았는데, Rust에서 사용하는 r"..." 나 이것을 변형한 raw"..." #raw"..." #raw("...") 등을 고려해봤는데 안예쁘고 텍스트 콘텐츠 집중을 방해해서 결국 #"..."# 스타일로 결정했다고 하네요. String을 사용할때 #raw"..." 이런식으로 사용해야 한다고 생각하면 끔찍하네요. 좋은 의미로 역시 🍎스럽네요. 애플 굳! 👍

참고

[Swift] ABI stability란?

Mon, 25 Feb 2019 00:00:00 +0900

Swift 5.0에서 가장 중요한 피처는 ABI stability의 지원이라고 할 수 있습니다.
이번 포스트에서는 이 ABI stability 대해 알아보도록 하겠습니다.

ABI란?

ABI라고 하면 뭔가 떠오르는게 있지 않으시나요? 그건 바로 모두가 잘 아는 API!
네~ ABI는 API와 비슷합니다.

API는 Application Programming Interface의 약자로 프로그래밍시 코드에서 사용하는 인터페이스입니다. ABI는 Application Binary Interface의 약자로 바이너리 간 인터페이스입니다. 런타임에 Swift 프로그램 바이너리는 다른 라이브러리와 ABI를 통해 상호작용합니다. 운영체제와 앱, 앱과 라이브러리간 상호작용을 위해 ABI를 사용하게 됩니다.

OS-App-Library간 상호작용

API에는 보통 함수의 이름, 타입, 인자, 리턴 타입 등을 정의 하는데, ABI에는 함수를 어떻게 호출할지, 메모리에 데이터를 어떻게 표현할지, 메타데이터를 어디에 놓고 어떻게 접근할지 등을 정의합니다.

ABI Stability란?

ABI가 안정화 됐다는 말은 앞으로 ABI가 변하지 않을 것이라는 보장입니다. 즉, 바이너리의 내부 처리 방식은 바뀔 수 있지만 인터페이스는 유지된다는 것입니다. 그래서 ABI stability가 지원되면 ABI가 지원된 버전의 Swift 컴파일러로 컴파일한 앱과 이후 업데이트 된 Swift 컴파일러로 컴파일된 라이브러리의 바이너리간 호환이 가능합니다.

Swift 5.0 미만의 Swift는 ABI stable 하지 않습니다. 그래서 각 바이너리 번들에는 고유의 Swift 동적 라이브러리(.dylib 파일)를 갖고 있고 이 라이브러리는 바이너리간 상호 작용을 위해 사용합니다.

ipa파일 내부의 동적 라이브러리 파일

Swift 5.0부터 ABI가 안정화 됐고 이후 Swift 표준라이브러리를 iOS, 즉 운영체제단에 심으면 ABI는 Swift 5.0 이후 모든 버전에서 호환돼 돌아갈 것 입니다.

ABI 안정로 인한 호환성 보장

이 점

ABI가 안정화 되면서 얻게 되는 이점은 무엇일까요?

앱 번들 크기 축소 : 이제 Swift 표준 라이브러리를 앱마다 포함시킬 필요가 없기 때문에 이 라이브러리 크기 만큼 앱 용량을 줄일 수 있습니다.
소스 호환성 : Swift가 새로 나올때마다 마이그레이션 하느라 고생 하셨죠? 이제 구버전으로 작성된 Swift 코드를 새 컴파일러에서 컴파일할 수 있습니다. 즉, 새버전으로의 마이그레이션 고통을 줄여줍니다. 😆
Swift 언어의 변경 축소 : ABI를 유지하기 위해서는 Swift 언어에서 함수의 인터페이스를 바꾸면 안됩니다. 리턴 타입, 매개변수, 숫자, 타입 등 자료형 정의나 구조체 정의, 상수 정의 등도 바뀌면 안됩니다. 그렇기 때문에 앞으로 Swift 언어가 보다 적게 변경될 것을 기대할 수 있습니다.
바이너리 프레임워크 & 런타임 호환성 : 바이너리로 된 프레임워크를 다양한 Swift 버전으로 배포하는 것이 가능해 집니다.

제 한

앞으로 Swift는 ABI stability를 보장하기 위해 Swift 런타임이나 표준 라이브러리에 추가가 필요한 피처는 제안이 제한됩니다. 이 조건에 해당하는 것은 다음과 같습니다.

표준 라이브러리에 새로운 타입, 프로토콜, 프로토콜 순응(Conformance), 함수, 매소드, 프로퍼티 등을 추가하는 것
Swift 타입시스템을 변경하는 것. 예를 들면, 새로운 타입을 추가하거나 기존 타입에 함수 에트리뷰트 같은 새로운 변경자를 추가하는 것 그리고 새로운 브릿징, 서브 타이핑, 동적 케스팅 관계를 추가하는 것

Swift 5.0은 ABI Stability 지원으로 이제 언어의 완숙기에 접어들었다고 보이네요.
이상으로 ABI Stabilibty에 대해 알아보았습니다. 😉

참 조

[Swift] allSatisfy() 매소드

Fri, 09 Nov 2018 00:00:00 +0900

코딩을 하다보면 콜렉션의 모든 원소가 특정 조건을 만족시키는지 확인하고 싶을 때가 있습니다. Swift 4.2에서는 이런 경우 사용할 수 있는 allSatisfy() 매소드를 지원합니다.¹

만약 문자로 구성된 콜렉션에서 모든 원소가 특정 문자를 포함하는지 확인하기 위해 allSatisfy() 매소드를 다음과 같이 사용할 수 있습니다.

let aWords = ["Apple", "Approve", "Analytics"]
let allMatch = aWords.allSatisfy { $0.hasPrefix("A") }

숫자 콜렉션에서도 다음과 같이 사용할 수 있습니다.

let numbers = [28, 32, 64, 90]
let passed = numbers.allSatisfy { $0 >= 28 }

이상으로 Swift 4.2에서 추가된 allSatisfy() 매소드에 대해 알아 보았습니다. 😎

SE-0207 Add an allSatisfy algorithm to Sequence ↩

[Swift] Bool 값을 반전시키는 toggle()

Fri, 12 Oct 2018 00:00:00 +0900

개요

Swift 4.2에서 Bool값을 반전시키는 toggle()이라는 함수가 Bool에 추가 되었습니다.¹ 이 포스트에서는 새로 추가된 toggle()함수에 대해 알아 보겠습니다.

toggle()

코딩을 하다보면 Bool값을 반전시켜야 하는 경우가 있습니다. 보통은 다음과 같이 구현합니다.

myVar.property1.property2.enabled = !myVar.property1.property2.enabled

특히, Bool까지의 경로가 긴 경우 위와 같이 같은 경로를 반복해서 적어줘야 하는 불편함이 있었습니다. 이런 상황에서 편리하게 사용할 수 있도록 toggle()이라는 함수가 Bool에 추가 됐습니다. 그래서 이제 같은 기능을 아래 코드로 구현할 수 있습니다.

myVar.property1.property2.enabled.toggle()

실제 코드를 작성해 실행해 보겠습니다.

[소스코드]

var usePushNotification = false
print("Noti State Before Toggle : \(usePushNotification)")
    
usePushNotification.toggle()
print("Noti State After Toggle : \(usePushNotification)")

[실행결과]

Noti State Before Toggle : false
Noti State After Toggle : true

toggle()의 구현

Swift 표준 라이브러이에 추가된 toggle()함수는 다음과 같이 구현돼 있습니다.

extension Bool {
  mutating func toggle() {
    self = !self
  }
}

이상으로 Swift 4.2에서 추가된 toggle()함수에 대해 알아 보았습니다.

SE-0199 Adding toggle to Bool ↩

앱 개발시 유닛테스트에 대한 생각과 경험

결 론

SwiftData에서 모델링 시 왜 struct가 아닌 class를 사용할까?

SwiftData에서 모델링에 struct가 아닌 class를 사용하는 이유

참고

[책 소개] 토미의 Git with 소스트리

목 차

1. 페이지 소개

2. 이 책의 대상 독자

3. 목차

Part I. Git 개념 이해하기 (Understanding Git Concepts)

Part II. Git 사용 하기 (Using Git)

4. 샘플 챕터(리베이스)

10.1 개요

10.2 리베이스란?

10.3 리베이스의 동작

10.4 리베이스시 주의사항

10.5 머지와 리베이스의 차이점

10.6 리베이스의 활용 (Interactive Rebase)

5. 책 구매 링크

[Swift] @autoclosure란?

정의

예제 코드

@autoclosure를 사용하지 않은 경우

@autoclosure를 사용한 경우

@autoclosure의 사용 예

@autoclosure의 다양한 활용

1. UIView.animate

2. Dictionary

정리

[Swift] Escaping 클로저 (@escaping)

정의

Non-Escaping Closure

Escaping Closure

Non-Escaping Closure 와 Escaping Closure

정리

팀에서 사용 중인 Swift Style Guide (코드 컨벤션)

Swift Style Guide

목차

[1. 코드 포매팅]

1.1 임포트

1.2 빈줄

1.3 들여쓰기

1.4 띄어쓰기

1.5 기타

2. 네이밍

2.1 일반

2.2 클래스

2.3 함수

2.4 약어

3. 기타

3.1 클로저

3.2 클래스와 구조체

3.3 타입

3.4 타입추론 사용

3.5 self

3.6 튜플

3.7 패턴

3.8 제네릭

3.9 static

3.10 final

3.11 프로토콜 extension

3.12 switch-case

3.13 return

3.14 사용하지 않는 코드

[Basic] 정적타입 언어와 동적타입 언어

정의

각 타입의 장단점

정적타입 언어의 장점

동적타입 언어의 장점

정리

[Swift] Codable을 사용해 json 데이터를 디코딩하는 3가지 방법

1. 기본적인 방법

2. 수동으로 key를 지정하는 방법

3. Decoder에 Stratege를 사용하는 방법 (snake-case를 camel-case로 자동으로 변환하는 방법)

정리

RxSwift 6의 변경사항 (What’s new in RxSwift 6)

목차

1. 새 로고

2. Binder가 RxCocoa에서 RxSwift로 이동

SwiftData에서 모델링에 `struct`가 아닌 `class`를 사용하는 이유

`@autoclosure`를 사용하지 않은 경우

`@autoclosure`를 사용한 경우

`@autoclosure`의 사용 예

`@autoclosure`의 다양한 활용

1. `UIView.animate`

2. `Dictionary`

2. `Binder`가 RxCocoa에서 RxSwift로 이동

3. `withUnretained` 추가 (⭐️)

4. `@dynamicMemberLookup`을 사용한 `Binder`의 자동 합성 (⭐️)

5. `Infallible`

6. `Observable<Data>`를 위한 `decode(type:decoder:)`연산자 제공

7. `driver()`, `emit()`에 다중 바인딩 제공

8. `Single`의 구현을 `Swift`의 `Result`를 사용하도록 변경

9. `distinctUntilChange(at:)`연산자에서 Key Path 지원

10. `ReplayRelay` 연산자 추가

11. `DisposeBag` 함수 빌더 추가