ios 52일차

과제에 관한 기록

1. DiffableDataSource

• 기존 Protocol 방식의 문제점
  • CollectionView가 DataSource에게 데이터를 물어보는 pull 방식.

2. Diffable 방식

• DataSource가 CollectionView에게 현재 상태를 선언하는 push 방식.
  • 기존 방식: CollectionView → DataSource (물어봄)
  • Diffable: DataSource → CollectionView (선언함)

3. Snapshot이란

• 특정 순간의 UI 상태를 담은 사진 (값 타입, struct).

4. Hashable이란

• 어떤 값을 고유한 숫자(hash)로 변환할 수 있다는 의미.
• Snapshot이 Hashable을 요구하는 이유:

hash값으로 "이 아이템이 이전에도 있었던 애인가?"를 O(1)로 판단.

indexPath를 더 이상 사용하지 않는 이유:

• DataSource가 Snapshot 안에서 hash로 각 아이템을 추적하므로 indexPath 배열 접근 불필요.

5. enum vs struct의 Hashable

• enum이 자동으로 Hashable한 이유:
  각 case 자체가 고유하기 때문. rawValue가 있으면 그것을 hash로 사용.

• struct가 채택 선언이 필요한 이유:
  어떤 프로퍼티를 hash 계산에 포함시킬지 컴파일러가 임의로 결정할 수 없어서 개발자가 명시적으로 선언해야 자동 합성 동작.

// 모든 프로퍼티가 Hashable(String?)이므로 자동 합성됨
struct Music: Codable, Hashable {
    let trackName: String?
    let artistName: String?
    let collectionName: String?
    let artworkUrl60: String?
    let artworkUrl100: String?
}

6. 구현 순서

Step 1. 타입 선언

Step 2. configDataSource

Step 3. Snapshot 생성 및 적용

Step 4. RxSwift bind에서 호출

Decision

API

• 결정:
  • URLSession + Single로 설계한다.
• 이유:
  • 네트워크 요청은 1회 요청하여 성공과 실패로 응답하기 때문에, 제너릭을 적용하여 모든 응답을 하나의 메서드로 처리할 수 있다.
• 발생할 수 있는 문제점:
  • 현재 구현한 코드는 URL만 받는 구조로 HTTP Method와 인증 헤더의 추가를 구현하기 위해서는 로직 자체를 변경해야 한다.

URL? URLRequest?

• 결정:
  • URL 직접 사용
• 이유:
  • 현재 구조는 GET 요청만을 사용하고 헤더인증이 없기 때문에, URLRequest 대신 URL을 사용하여 빠르게 처리한다.
• 발생할 수 있는 문제점:
  • 앞서 말한 내용처럼, 헤더 추가 등에서 다른 문제를 발생시킬 수 있으며 수정을 위해서는 코드의 변경이 불가피하다.

Observable.zip

• 결정:
  • 4개의 API를 Observable.zip으로 병렬 요청한 뒤 결과를 합쳐서 반환한다.
• 이유:
  • zip은 모든 소스가 완료될 때 한번만 방출하기 때문에, API의 도착 순서에 관계없이 한번에 업데이트할 수 있다는 이점이 있다.
• 발생할 수 있는 문제점:
  • 4개 중 하나라도 문제가 발생한다면 zip이 실패하여 Error로 처리된다. 에러가 발생한 API만 재시도하거나 부분 결과를 표시하는 것이 불가능하다.