(1.0.1 ver.) Out Now!
👇🏻👇🏻👇🏻👇🏻👇🏻
https://apps.apple.com/kr/app/lottodiary/id6479727804

프로젝트 소개

앱 소개 & 기획

행운을 기록해요, 로또 일기

당신은 오늘 로또를 사면서 무엇을 꿈꾸셨나요?
우리의 삶에서 희망을 품고 로또를 구매하는 순간이 주는 작은 설렘이 있습니다.
'로또 일기' 앱은 그 설렘과 희망을 담아, 당첨되면 실현하고 싶은 꿈들을 기록하고, 나만의 행운을 찾아가는 여정을 돕는 친구가 되어 드립니다.

기획 계기

짧은 기획 기간과 짧은 기획 계기는 아래 사진 하나로 설명할 수 있겠다.

개발 기간 & Configuration & v1.0 기능

개발 기간

• 3/8 ~ 3/24 (2주)

Configuration

• 최소버전 15.0 / 세로 모드 / 라이트모드 / iOS

v1.0 기능

1️⃣. 로또 관련 / 2️⃣. 일기 관련으로 분리해서 정리

• 1️⃣. 로또 관련:
• 로또 결과 조회(QR코드 인식 -> Web으로 연결),
• 로또 번호 생성(랜덤 번호, 로또번호 생성),
• 나의 번호 저장(CRUD),
• 로또 판매점 정보 지도에 표시 & 현위치 인식,
• 로또 구매 WebView,
• 로또 결과 발표 시간에 Local Notification

• 2️⃣. 일기 관련:
  하고 싶은 일/일상 기록, 이미지, 소원태그 저장(CRUD)

• #️⃣. 기타:
  문의하기(이메일), 알림 설정, 개인정보 처리방침

기술 스택

(v1.0) 기준

• UIKit / AVFoundation / Vision / CoreLocation / WebKit, SafariServices
• CodeBasedUI / SnapKit / CompositionalLayout / CollectionViewPagingLayout
• MCV / MVVM / Realm / Alamofire / Codable
• 로또 동행복권 API, KakaoMapSDKv2 맵, 키워드 검색 API, Local Notification

(v1.1) 업데이트 예정 기능

v1.1 업데이트 기능

(구현에 급급해 포기한 것들..)

• 나의 번호 기반 당첨 내역 조회 및 저장

• 소원 태그 기반 차트 UI(탭바에 추가 예정)(DGChart)

• 일기 수정 기능 버그 픽스

• 메인뷰UI 개선

• Firebase Google Analytics & Crashlytics

• 네트워크 통신 상태코드 대응

• 일기 정렬(FSCalendar)

👩🏻‍🚒 트러블 슈팅

1. Diffable + Realm의 콜라보

매번 CollectionViewDelegate, FlowLayout을 활용한 UI만 연습하다가,
iOS14버전부터 사용할 수 있는 Diffable + CompositionalLayout을 활용해보기로 했다.

결과는..
🤦🏻‍♀️

1. Realm Delete시 타입이 다를 때 나타나는 에러
   https://velog.io/@maddie/iOS-Diffable-Realm-Delete-Error

2. Diffable과 Realm을 함께 사용할 때 종종 등장하는 에러
   https://velog.io/@maddie/iOS-Realm-Delete-%EC%97%90%EB%9F%AC

이제 생각해보니, 내가 처음에 한 방법은(블로그 내용) 임시방편밖에 되지 않았다. 궁극적으로 해결한 방법은 해당 Realm Repository를 fetch해오는 코드를 프로젝트 전체에서 다시 검색해보고, 실질적으로 사용되지 않는 코드를 삭제함으로써 에러를 해결할 수 있었다. 그리고 snapshot이 아닌, dataSource.applySnapshotUsingReloadData()를 사용했다. 대신 applySnapshotUsingReloadData는 diffable을 쓰지 않고 reloaddata로 동작시키기 때문에, 처리되는 로직이 달라지기에 해결이 되었다.

2. KakaoMapsSDK v.2 사용기

요구사항: iOS13 이상
카카오맵 SDK ver2는 가이드와 샘플코드(CocoaPod 설치필요)가 잘 되어있음에도 가져다 쓰는데에 어려움이 많았다. 엔진, ViewContainer 이런 키워드가 어색했을 뿐만 아니라, 뷰도 코드베이스가 아닌 스토리보드 베이스였다.
그래서 단계별 학습 및 구현을 해보았는데,
1) 처음에는 카카오맵을 띄우고,
2) 그 다음에는 현위치에 지도 카메라를 옮기고, (이 과정에서 현위치 버튼을 먼저 만들었다.)
3) 그리고 키워드 검색 API를 호출해서 특정 지역과 그 바운더리 내에서 "복권"이라는 키워드로 검색해서 데이터를 받아오고,
4) 이 데이터를 테이블뷰에 띄우고, didselectrowat시점에 해당 위도경도를 지도로 띄웠다.

사실은 하나의 데이터를 지도에 마커로 띄우는 것고, 여러 데이터를 마커로 우선 띄우고 싶었는데,
(카카오맵의 Poi, LodPoi에 해당)
이는 구현에 실패했고, 4)번 내용처럼 우선 구현해두었다.

1. https://velog.io/@maddie/iOS-KakaoMapsSDK-v.2-%EC%B9%B4%EC%B9%B4%EC%98%A4%EB%A7%B5API
2. https://velog.io/@maddie/iOS-KakaoMapsSDK-v.2-%EC%B9%B4%EC%B9%B4%EC%98%A4%EB%A7%B5API-2-%ED%86%BA%EC%95%84%EB%B3%B4%EA%B8%B0

✍🏻 회고

스스로 잘한 점

1. 새로운 기술을 의미있게 충분히 활용했나?

• Alamofire 사용: 이 프로젝트에서 Alamofire는 로또 API와 카카오맵 키워드 검색 API를 연동하는 데에 사용했는데, Alamofire의 효율성과 신속함 때문이었다.
  또 상태 코드에 따른 네트워크 상황 대처를 Alamofire의 응답 처리 기능을 통해 세밀하게 구현할 수 있었다. 이로 인해 앱의 네트워크 통신 부분에서 발생할 수 있는 다양한 예외 상황들을 효과적으로 관리할 수 있었으며, 사용자 경험을 크게 개선했다고 생각한다.

• Realm 사용: 로컬 데이터베이스를 적극적으로 활용하기 위해서 Realm을 사용해서 CRUD 작업을 수행했다. 앱의 전반적인 데이터 관리가 용이해졌다.

2. 같은 API여도 차별화를 주었나?

1) 개인 능력: 이 프로젝트에서 사용한 로또 API는 단순히 회차로 요청하면 해당 회차의 로또 당첨 번호를 받아오는 게 전부였다. 따라서 로또 번호가 발표되는 날짜와 시간 이후에 앱에 접속하면 그 다음 회차를 호출해야 한다. 그런데, 이렇게 날짜에 따른 회차를 계산하는 알고리즘 이외에는 API 활용 연습을 더 해보고 싶은 욕심이 생겼었다.

2) 앱의 차별화: 단순히 데이터를 조회하는 것을 넘어서, 단순 위치 검색이 아닌, 사용자의 현재 위치를 기반으로 주변의 로또 판매점을 찾아주는 기능을 추가함으로써, 사용자에게 더 큰 편의성을 제공했다고 생각한다. 또 업데이트되지 얼마 되지 않아, 레퍼런스 하나 없던 카카오맵"v2"를 활용하여 Poi(마커)를 띄웠다는 데에 의미있다.

스스로 반성할 점

1. 비즈니스로직을 고려하며 구현했나?

프로젝트를 진행하면서, 가장 중점을 둔 부분은 사용자 경험이었다. 하지만 비즈니스 로직의 구현에 있어서는 더 많은 고민이 필요했던 것 같다.
예를 들어, 로또 번호를 저장하고 관리하는 기능을 구현할 때, 편하게 번호를 입력할 수 있는 (예쁜) UI에 집중하느라, 어떻게 하면 데이터를 더 효율적으로 관리할 수 있을지에 대한 깊이 있는 분석이 부족했다.

2. MVVM이 의미있게 동작하나?

사실 뷰와 뷰 컨트롤러를 분리해본 건 MainView밖에 없다. 그 대신 이외의 나머지 뷰들에는 모두 ViewModel과 Observable을 통해 데이터의 상태를 관찰하고 UI를 업데이트하려 노력했다. 또 강한 참조로 인한 앱 크래시를 줄이기 위해 weak self를 적극적으로 사용해보았다. 그래도 모든 부분에서 MVVM이 의미있게 동작하고 있는지에 대해 반성할 여지가 있다. 일부 뷰모델에서는 너무 많은 비즈니스 로직을 포함시키는 등, MVVM의 기본 원칙에서 벗어난 구현이 있었다. 추후에 리팩토링을 통해 개선해봐야겠다.

3. 데이터 설계를 체계적으로 계획했나?

데이터 설계에 있어서 개발 초반에 체계적인 계획의 부족함을 느꼈다.
사실 개발 도중 Realm 테이블 수정을 크게 두 번 진행해야 했고, 이는 앱을 사용하는 동안 사용자와 개발 팀 모두에게 추가적인 작업을 요구하는 결과를 초래했다. (TestFlight로 테스트를 진행해주던 팀원분들이 앱을 다시 깔아야 했다)
특히, 로또 번호를 저장하는 테이블에 필요한 속성을 누락시키거나, 일기 데이터를 관리하는 테이블 설계 시 이미지 처리 로직에 문제가 있었던 점은 더욱 세심한 사전 계획과 검토가 필요했던 부분인 것 같다. 이 경험을 통해 앞으로는 데이터 모델 설계 초기 단계에서부터 비즈니스 요구사항을 면밀히 분석하고, 유연성 있는 설계를 고려하는 중요성을 깨달았다. 또한, 변경 가능성이 있는 부분을 사전에 예측하고, 확장성을 고려한 설계가 필요함을 배웠다.