---
# System prepended metadata

title: '날씨 앱 [STEP 3-1] Blu, Jenna'

---

# 날씨 앱 [STEP 3-1] Blu, Jenna

>안녕하세요! 코리(@corykim0829)🐶!
🌙**TEAM LuNna**🌙 의 Blu, Jenna입니다!
>
>STEP 3도 저번 스텝과 같이 1, 2로 분리해서 진행해 보려고 합니다.
>3-1에서는 Collection View를 활용하여 기초적인 앱의 UI 구성과 API로부터 받아온 데이터를 View에 적용하는 작업을 진행하였고,
>3-2에서는 요구사항 중 하나인 Configuration 부분에 대해 추가적으로 학습 후 활용하여 UI를 구현, 화면을 위에서 아래로 끌어당기는 경우 새로고침하는 기능을 구현할 예정입니다.
>
>아직 정리되지 못한 코드들이 많습니다.
>해당 부분은 코리의 리뷰를 적극 반영하여 STEP 3-2를 진행하면서 최대한 정리해보도록 하겠습니다!!
>
>먼저 연락 주신 덕분에 더 열심히 할 수 있었습니다!👍
>비가 오더니 날씨가 꽤 쌀쌀해진 거 같아요~! 감기 조심하세요 코리! 😷
>이번 리뷰도 잘 부탁드려요! 감사합니다! 🙇🏻🙇🏻


<br>

# 🧑🏼‍💻 작업 목록
## UI 구현(1)
- [x] Collection View를 활용하여 앱의 UI 구현
    - [x] header view에 현재 날씨 적용
    - [x] cell에 5일 예보 적용
- [X] 코드베이스 Auto Layout 구현
- [x] View에 데이터가 보이도록 적용
    - [x] DateFormatter를 활용하여 날짜 포맷 적용
- [x] 아이콘 이미지를 불러오도록 URLService 모델 변경 

<br>

![실행화면](https://user-images.githubusercontent.com/71758542/230283216-a06e55a3-3c93-4548-96fc-fe25efefbd6d.gif)

<br>


# 📚 학습 키워드 및 학습 내용
## 1. CollectionView
> 🖇️　참고한 공식문서: 
> - [Collection Views](https://developer.apple.com/documentation/uikit/views_and_controls/collection_views)
> - [UICollectionView](https://developer.apple.com/documentation/uikit/uicollectionview)
> - [UICollectionViewDataSource](https://developer.apple.com/documentation/uikit/uicollectionviewdatasource)
> - [UICollectionViewFlowLayout](https://developer.apple.com/documentation/uikit/uicollectionviewflowlayout)

- **학습 내용**
    - `UICollectionView는` `UITableView`처럼 'ordered collection of data items'를 레이아웃대로 띄울 수 있는 뷰이되, 'ordered'의 방향이 세로 리스트형태로 국한되지 않아 grid처럼도 구현이 가능한 타입
    - `UITableViewCellStyle`과 같은 건 없지만, 최근 list cell 및 layout이 추가되는 등 구현의 편의성과 유연함이 더해지고 있음
- **적용 과정**
    - `UICollectionViewListcell`, `UICollectionViewListlayout`을 쓰고자 했으나, 기본 콜렉션뷰를 구현해본 적이 없으므로 기초부터 학습하기로 합의, 커스텀 셀과 `UICollectionViewFlowLayout`을 이용해 구현
    - `defaultCellConfiguration()`을 쓰기에 앞서 콜렉션뷰 자체의 구현에 집중하고자 헤더뷰용, 셀용 커스텀셀을 정의하여 사용
- **문제와 해결**
    |문제와 해결|내용|
    |:---:|:---|
    |**문제**|- 비동기 데이터를 셀 서브뷰에 할당하는 작업이 어려웠음 |
    |**해결**|- Task 블록을 통해 필요한 async-await, completion handler의 작업이 모두 끝난 후에 콜렉션뷰의 reloadData()작업이 이루어지도록 통제 |
    
- **아쉬운 점**
    - 요구사항인 configuration을 이용하지 않음 -> ⭐️Step 3-2에서 리펙토링 예정

## 2. DateFormatter
> 🖇️　참고한 공식문서: 
> - [Date](https://developer.apple.com/documentation/foundation/date)
> - [DateFormatter](https://developer.apple.com/documentation/foundation/dateformatter)
> - [Data Formatting Guide](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/DataFormatting/Articles/dfDateFormatting10_4.html#//apple_ref/doc/uid/TP40002369-SW1)


- **학습 내용**
    - `DateFormatter`는 날짜와 텍스트 표현 사이의 변환기 역할을 함
    - 다양한 지역화된 사전 설명 및 구성 옵션을 제공
    - 날짜 및 시간을 고정 형식으로 표현하고 싶을 때 사용자 지정 형식 문자열을 지정할 수 있음
- **적용 과정**
    - String extension에 이니셜라이저로 구현
- **문제와 해결**
    |문제와 해결|내용|
    |:---:|:---|
    |**문제**|- `Date(timeIntervalSinceReferenceDate:)` 사용 시 월/일은 일치하지만 요일이 다르게 나타나는 문제 발생<br> - 한글로 된 요일을 얻기 위해 DateFormatter `setLocalizedDateFormatFromTemplate(_:)` 메서드를 활용하여 지정된 locale을 사용하여 날짜 형식을 설정하려고 하였지만 슬래시`/`가 제대로 표시되지 않는 문제 발생|
    |**해결**|- API의 dt에 해당하는 데이터가 unix, UTC로 unix UTC는 1970년 1월 1일 00:00:00 UTC 이후의 초 수로 시간을 표시하여 타임스탬프를 나타내는 방법이기 때문에 이에 해당하는 `Date(timeIntervalSince1970:)` 생성자를 사용하는 것으로 문제 해결 <br> - 공식문서상 `setLocalizedDateFormatFromTemplate(_:)` 메서드는 말 그대로 날짜 형식 패턴을 포함하는 문자열인 템플릿을 기반으로 데이터를 설정하는 것이기 때문에 "MM"이나 "h"으로 구성된 날짜 형식 패턴 템플릿을 넣어주면 자동으로 지정된 locale에 맞추어 localized해 주지만 이로 반환된 데이터는 프로젝트에서 요구하는 형태가 아님, 형태를 맞추기 위해 custom format을 지정해줄 수 있는 dateFormat 프로퍼티를 사용하여 "MM/dd(EE) HH시"로 지정해 줌

    
<br>

# 🙋🏻 질문 거리
## 1. 기본 타입(String, Double)의 Extension 관련
String extension(/Model/Extension/String+.swift)에 CoreLocation을 import, DateFormatter를 활용하여 아래 세가지 초기화자를 구현하였습니다.
1. Int 타입의 데이터를 String 타입으로 변환하는 초기화자
2. 위경도를 기반으로 변환된 주소 형태인 `CLPlacemark`를 인간 친화적인 주소로 변환하는 초기화자
3. Double 타입의 기온을 소수점 아래 한 자리만 남기고 도에 해당하는 기호(°)룰 붙여서 String 타입의 데이터로 변환하는 초기화자
구현하다보니 String의 extension 내부에 너무 많은 기능을 구현한 것이 아닌지 고민되었습니다.
지금처럼 진행해도 괜찮은지, 해당 역할을 하는 타입을 별도로 구현하는 것이 더 좋은지 질문드립니다!

## 2. URLService 네이밍 관련
`Weather`, `URL`, `Service`, `Request`, `Parse`, `Endpoint` 등의 키워드를 중복 없이 네이밍 가이드에 맞도록 적절히 배치하기 어려웠습니다. Service가 포괄적인 의미의 단어라고 들어 그리 적절치는 않은 이름이라고 생각했지만,
이미지 관련된 로직을 묶어 분리하기, 혹은 쌍으로 존재하는 parse·make·request류 네이밍의 메서드들을 통합하는 등의 리펙토링을 고려하고 있기에 && 따라서 앞으로 네이밍 근거가 변경될 여지가 있다고 판단하였기에 우선 현재 기능들을 고려하여 URL'Service'라고 네이밍 하였습니다.
혹시 추천하실 만한 네이밍 키워드가 있다면 조언 부탁드립니다...!