이번 프로젝트는 선택지가 다양했다.
1. 우선 대량의 API 사용과 부분적으로 CoreData를 사용하는 난이도 상의 날씨 앱
2. 정말 많은 UI컴포넌트를 가지고 있고 많은 View와 CoreData를 써야하는 난이도 중의 단어장 앱
3. 지금까지 배웠던 기본기들을 다시 한 번 곱씹으며 기초를 탄탄하게 다지는 난이도 하의 알람 앱
이 세가지 중 우리팀은 날씨 앱을 선정을 했다. 팀원들의 공통된 생각으로는 우선 단어장 앱이 날씨 앱보다 UI적으로 생각할 것이 너무 많았다. 기본적으로 그려야하는 View의 개수만 거의 3배 이상 차이날 거라는 예상을 팀원들과 공유했고, API나 CoreData에 미숙하거나 익숙하지 않은 사람들이 많다보니 자연스레 날씨 앱을 선정하게 되었다.
내 역할 - CoreData 구성
최근에 오랫동안 건드리고 딮하게 파보고 있는 기술은 CRUD이다. 이전 과제에서는 Userdefaults를 이용해 CRUD를 구성했다면, 이번 과제에서는 CoreData를 이용해 CRUD를 구성하기로 했다. 아직 사용법이 익숙하지 않았지만, 운이 좋게 CoreData를 구현하는 부분을 내가 담당하기로 했다. 그리고 구성된 CoreData를 UI에 어떻게 녹일지 까지 고민하는 게 내 역할이다.
와이어 프레임 & API 선정
와이어 프레임을 살펴보면 날씨 앱에서 CoreData를 사용해야할 부분은 사용자가 설정해놓은 지역들을 저장해놔야한다는 것이다. 그렇기 위해서 우선 어떤 API를 선정해야할 지가 중요하다. API에서 받아온 정보 중의 일부를 CoreData에 저장해놓고 그 데이터를 앱을 킬때마다 저장소에서 꺼내어 API로 다시 통신을 시켜줘야하기 때문이다. 우선, API로는 OneWeatherMap 이나 우리나라 기상청 API허브 둘 중 하나를 사용하기로 했다. 처음에는 날씨앱을 사용하는 사용자의 타깃을 우리나라 한정으로 잡고자 했을 때, 기상청이 훨씬 디테일한 정보들을 많이 제공한다. 그러나, 기상청 API는 사용하기 위해 JSON파일에서 디코딩하는 게 너무 복잡하고 문서를 하나씩 뒤집어봐야 했다. 그런데 OneWeatherMap에서 제공되는 API는 간단하고 명확하게 데이터들을 보내주고 받을 수 있게 짜여있었다. 또한 사용자들의 범위를 국내에서 국제로 확장할 수 있다는 장점이 있다.
내일 할 일
가장 먼저 해결해야할 문제는 API에서 어떤 데이터를 가져와서 저장소에 저장해야지만 앱을 켰을 때 위치 기반 날씨 정보를 불러올 수 있을까? 이다. 전체적인 틀과 역할 분담은 다 잡혔으니, 본격적인 개발은 내일 시작이다!
