[생글] 개발 후기

 

 

 

 

 

 

🗓  개발 기간 : 2020.06 ~ 2021.02 

🔎 서비스 이름 : 생글

📌 서비스 한줄 소개 : 🧠 하루 3번 , 3분 동안 글쓰기 습관 길들이기! 생글로 시작하는 간단하고 솔직한 글짓기 

✏️ 사용한 언어 / 구조 : Swift, MVVM 

📇 사용한 라이브러리나 기술 : RxSwift, RxDataSources, Moya, Firebase, CoreData 등

📍 앱스토어 주소 :  release soon

 

서론 : 

기획단계부터 참여한 제 첫 사이드프로젝트입니다.

작년 4월말, 5월쯤 사당역에 모여서 기획 회의하고, 4시쯤인지 4시 30분쯤인지 사당에서 3400 버스타고 학원 가는길에는 수학문제를 풀었어야 했습니다.

 

사용한 라이브러리 소개:

작년 4월 말, 5월 말쯤만 해도 이 프로젝트에 라이브러리를 하나도 쓰지 않겠다고 했습니다. 서버리스하게 동작할때는 어떻게 저렇게 다 구현해냈으나, RxSwift, Firebase를 쓰게 되는 쯤에는 앱이 커지고, 기능을 붙이면 붙일수록 기초 컨셉을 유지하기가 어려웠고 최소한의 라이브러리를 사용하자! 라고 타협했습니다.

 

(순서무관)

1. Moya / RxMoya

2. RxSwift, RxCocoa, RxDataSources

3. Firebase 

4. XLPagerTabStrip

5. SwiftyGIf

 

실제 사용하는 UI 라이브러리는 볼드체를 칠한 두개입니다. 이번 포스팅은 이 라이브러릴 왜 썼는지에 집중해서 글을 써 보겠습니다.

 

1. Moya 

네트워킹 추상화 라이브러리입니다. 실제로 API를 콜하는 로직은 Alamofire를 사용하고 있습니다. API가 많아지면 많아질수록 API를 라우팅하는 로직을 관리하기가 어려웠는데, 모야가 한방에 해결해 주었습니다.

공부하고 실제로 사용을 해보니 너무 좋다는 생각이 들어서 글을 썼었답니다 

2020/09/08 - [iOS] - [iOS] Moya에 대해서 공부해보아요

 

사실 열거체로 라우팅하는 로직을 관리해서 편하게 서버통신을 할 수 있다는 장점은 URLSession이여도 당연히 되는것입니다.

서버 API들의 타입이 비슷한것들끼리 모아서 열거체로 구성한다, 그리고 API를 직접 콜하는 함수들을 만들어서 사용하면 되는것이 본질인가 해서 한번 만들어 사용해보기도 했습니다.

 

그러나 판매하는 제품이 좀 더 맛있고 기성제품을 사서 쓰는 이유가 있듯 다시 모야로 돌아오게 되었습니다. 그 이유는 일단 손이 잘 안갔고, 무엇보다 협업하는 사람이 있게되는 경우, 이를 사용해야 할 이유를 설명하고 설득하기보다 모야를 쓸 것 같았습니다..

이런 경험이 모여서 언젠가 도움이 되리라 생각합니다.

 

2. RxSwift, RxCocoa, RxDataSources

ReactiveX 라이브러리들을 사용하게된 이유는, ICT 인턴쉽 프로그램으로 들어간 회사 프로젝트에 RxSwift(MVC)가 있었고, 거부감이 거의 없었다는 것, 새로운 기술스펙에 대한 동경이 있었기 때문에 열심히 공부해서 사용했던 것 같습니다.

 

지금은 그렇지 않습니다. 데이터를 처리하고 뷰를 구현하는데 확실히 다른 시선이 생긴 것 같습니다.

해당 뷰에 바인딩된 데이터, 특히 RxDataSources를 사용하고 나서는 뷰를 바라보는 시각이 많이 달라진 것 같습니다.

예를 들어 좋아요 갯수, 글 내용 수정, 삭제, 글 필터(제목 필터, 글 내용 필터 등)들이 테이블뷰나 컬렉션뷰에 바인딩된 데이터를 변화시켜야 할 때 이걸 미리 알고 뷰모델을 설계하는것과 아닌것은 많은 차이가 있다고 생각합니다. (gif 첨부)

 

또, 비지니스로직을 설계할 때 그럼 RxSwift가 필수인 것인가? 라고 생각하면 그렇지는 않은것 같습니다. 비지니스 로직을 담당하는 클래스가 하나 늘어난 것이라고 생각하기 때문입니다. 그렇지만 RxSwift가 있으면 편하고 없으면 당장 어떻게 해야할지는 고민을 해봐야 할 것 같습니다.

 

여튼, 후회는 없고 Combine이 빠르고 훌륭하다고 소문이 들려오지만 Minimum Deployment Target이 13이 되는 그 시점까지는 Combine을 배우지 않을까 싶습니다. 

 

3. Firebase

Crashlytics, FCM을 사용하고 있습니다.

스토리지는 사용했었으나 CoreData로 바꿨습니다. 

 

4.  XLPagerTabStrip: github.com/xmartlabs/XLPagerTabStrip

꽤나 유명한 페이징 라이브러리입니다. 

이것도 정말 안 쓰고 싶었답니다만... 자세한 내용은 밑에 '어려웠던 점' 칸에서 기술할 예정입니다.

 

5. SwiftyGif: github.com/kirualex/SwiftyGif 

저희 앱에는 gif가 있는데, lottie를 사용했었으나 lottie에서 미지원하는 에프터이펙트 익스텐션(?...정확히 잘 모르겠습니다)을 사용해서 앱에 제대로 그려지지 않았습니다. 여러 gif 라이브러리들이 있는데, 가장 가볍고 버그 없어 보이는 친구를 선택했습니다.

 

모바일 개발의 시선에서 램에 민감하고 CPU에는 그래도 덜 민감 (차라리 둔감)한 경향이 있습니다. gif를 개선한 라이브러리들의 설명을 보면, gif의 모든 프레임을 잘라서 램에 올려두는 기본 방식이 아니고, 프레임을 쪼개서 사용하기 근처 몇 프레임만 램에 올려놓는 방식을 사용한다고 합니다. 따라서 CPU 사용량은 올라가고 RAM의 사용량은 줄어든다고 합니다. 

프로젝트 홍수가 지나가면 가장 들여다보고 싶은 구조가 gif 라이브러리들, Kingfisher로 대표되는 이미지 캐싱 라이브러리들입니다.

꼭 열어보고 분석해서 블로그에 글을 올리도록 하겠습니다.

어려웠던 점

가장 어려웠던 부분은 인스타그램 마이페이지 같은 형식의 뷰입니다. 저번에도 있었는데 이렇게 구조를 위배하는 개발이 제일 어려운 것 같습니다. 버티컬 스크롤 안에 버티컬 스크롤이라던지, 서치뷰를 커스텀 한다라던지

 

 

마이서랍 뷰

 

 

gif에서 보는것과 같이 버티컬 스크롤 안에 버티컬 스크롤 구조입니다. 그리고 좌우로 페이징이 되어야 합니다.

저 구조에서 사용한 라이브러리는 XLPagerTabStrip, RxDataSources입니다. 다만 저 페이징 라이브러릴 써도 여전히 많은 작업이 필요했습니다. 이 문제를 해결하기위해 비슷한 라이브러릴 찾아서 뜯어보았습니다.

 

github.com/OfTheWolf/TwitterProfile

OfTheWolf/TwitterProfile

이런 뷰에 대응되는 라이브러리가 두개 있었는데 그 중 하나입니다. 얘가 XLPagerTabStrip을 사용하고 있습니다.

이 라이브러리는 스타가 적은 편이고 업데이트도 안 된 편인데, 그럼에도 불구하고 선택한 이유는 

 

0. 이전 개발한 앱에서 같은 뷰를 같은 라이브러리로 구현

1. 구현체가 swift file 5개

2. 따라서 이해가 비교적 잘 됨

 

조금 신기한 구조를 잠시 설명드리면

저 각각이 전부다 뷰컨트롤러이고 메인 뷰컨트롤러 위에 올려져있는 구조입니다. (HeaderVC / BottomVC1 /  BottomVC2) 

그리고 XLPagerTabStrip은 PageViewController로 구성되어있으니 BottomVC1, BottomVC2를 좌우 스와이프 가능하게 함

 

 

(비지니스 로직 부분)

좋아요를 하고 돌아오면 이전 화면에 좋아요가 반영되어야 하는 부분 등 바인딩된 데이터를 변경해야하는게 많은데,

이전 화면의 데이터를 변경하는 방법이 무려

 

(1) 페이지네이션

(2) 좋아요

(3) 글 수정

(4) 글 삭제

(5) 글 공개, 비공개

(6) 최신순 / 인기순 필터링

 

...! 6개나 됩니다. 이들 모두 바인딩 된 데이터를 변화시킬 수 있어야 합니다.

RxDataSources를 구현하는 시점에서는 조금 다른데,

원래대로라면

(1) 서버데이터 (2) 유저액션 (3) 후처리 가 되어야 하는데

 

Rx를 사용하면

(1) 서버데이터 (2) 유저액션 선처리 후 옵저빙 (3) 유저액션 트리거

이렇게 이루어져야 합니다.

코드를 잘라서 가져왔습니다. 위와 같이 `scan(into: ~)`로 바인딩되어있는 데이터를 변경시킬 수 있습니다.

 

마치며

이제 하나둘 프로젝트를 마감하며 밀린 프로젝트 후기를 작성하고 있습니다. 최근에 작성하는 코드가 지금은 맘에 들지만 나중에는 분명히 맘에 들지 않을게 분명합니다. 이런 이유로 이렇게 작성했구나~! 라는 의도를 남기고 싶어서 후기를 작성하고 있습니다. 

 

디자인이 예쁘고, 개발 기간도 길기도 하고, 등등.. 애정이 많은 프로젝트입니다.

작은 소망으로는 버전 몇개 올릴 수 있을 정도로 유저유입이 있었으면 좋겠습니다... 되게 앱이 예쁘고 인터랙션도 많은데.....

기능도 살펴보면 되게 많답니다...

 

네..죄송합니다. 오늘도 읽어주셔서 감사합니다. 많이 발전해서 좋은 글 쓰겠습니다.

만약 궁금하신 것이 있다면 댓글이나 메일 부탁드립니다!