[🥒Team-6 / iOS / 쏭 & 잭슨] 상세 페이지 및 Persistence 구현

[1song2]

상쾌한 월요일입니다 제이슨☀️
지난 PR 피드백 및 새로운 기능 구현을 코드에 반영해 2차 PR을 드립니다.
프로젝트 기간이 종료되고 PR 드리는만큼 제이슨 시간되실 때 가능하신만큼만 여유롭게 피드백 해주시면 좋을 것 같아요🙏
​

작업 목록

지난 PR 피드백 반영

• FetchDishesUseCase의 RequestValue에서 불필요한 값을 제거 (Category 전체 대신 Category의 name 속성만 요청)
• DishCell에서 네트워크 관련 logic 제거
• DishesListItemViewModel 내부 속성을 Dish entity로 대체
• reloadData 대신 reloadSections로 특정 섹션의 데이터만 업데이트
• Test 코드 작성

기능 구현

• 네트워크 요청으로 받아온 반찬 목록을 Persistence로 저장 (Realm 이용)
• 반찬 배송 정보, 수량 선택, 상세 이미지 등을 대응할 수 있는 상세 페이지 구현
• 메인 페이지에서 특정 셀을 탭하면 해당 상세 페이지로 이동

구조 설계 흐름도

• 각 클래스를 Diagram화 & MVVM 계층에 맞게 분류 링크
  ​

학습 키워드

Realm, UIScrollView (Paging), reloadSections
​

고민과 해결

Realm 데이터 저장

from @JacksonPk
이번 프로젝트에서 Persistence를 이용하는 방법을 고안했고 DB를 사용하기위해 Realm을 써 보았습니다.
Alamofire의 Result값에 따라 items를 가져올 시 Realm에 dish값을 저장했고, 네트워크 연결이 안될 시(WIFI/LTE OFF) Realm에 있는 DB를 불러와 메인 페이지에 보여주는 방식으로 고안했습니다.
궁금했던 점은 Persistence에 있는 이 데이터들을 고안한 방식처럼 관리해도 괜찮은 것인지, 혹은 더 나은방법이나 다른 접근으로 사용할 수 있는지 궁금합니다.
​

reloadSections

from @1song2
이번 프로젝트의 메인디쉬라고 말씀해주신 reloadSections 부분을 꼭 구현해보고 싶어서 지난 주말동안 시도해보았습니다.
결과적으로 성공하진 못했는데요😭 시도해보는 과정 중에서 느낀 점이 몇가지 있어 아래 공유드립니다.

문제 상황 및 시도 방안

1. [문제] items는 section에 대한 정보를 가지고 있지 않기 때문에 reloadSections(_:)에 매개변수로 담을 section index를 알 수 없음

• [시도] category에 sectionIndex와 items를 속성값으로 추가
• category를 observe해 items에 변동 사항이 있을 시 해당 sectionIndex로 reloadSections 시도

2. [문제] 1번과 같이 수정 후 콘솔에 아래와 같은 에러 메시지 발생 (프로그램이 동작은 됨)

[UICollectionView] Invalid update: invalid number of items in section 0. 
The number of items contained in an existing section after the update (11)
must be equal to the number of items contained in that section before the update (0),
plus or minus the number of items inserted or deleted from that section (0 inserted, 0 deleted)
and plus or minus the number of items moved into or out of that section (0 moved in, 0 moved out). - will perform reloadData.
UICollectionView instance: <UICollectionView: 0x7fe58382de00; frame = (0 47; 390 763); clipsToBounds = YES;
autoresize = RM+BM; gestureRecognizers = <NSArray: 0x600003cf34e0>; layer = <CALayer: 0x6000032d77e0>; 
contentOffset: {0, 0}; contentSize: {390, 294}; adjustedContentInset: {0, 0, 0, 0}; layout: <UICollectionViewFlowLayout: 0x7fe582f10c00>;
dataSource: <BanchanCode.MainPageCollectionViewDataSource: 0x6000032898e0>>;
currentUpdate: [UICollectionViewUpdate - 0x7fe581c124d0: old:<UICollectionViewData: 0x600000d884b0> new<UICollectionViewData: 0x600000d8c000>
items:<(
    "DS(1)",
    "IS(1)"
)>]

• [시도] 브레이크 포인트 등을 통해 파악한 결과, 두 section이 동시에 업데이트 되는 시점에 해당 에러가 발생함을 파악 (동시성 이슈?)
• reloadSections 사용시, 현재 reloadSections를 시도하는 section 외에는 변동사항이 발생해서는 안됨을 이해
• 해당 에러가 발생하면 Xcode 자체에서 reloadSections 대신 reloadData를 대신 호출
  ​
  해당 문제를 해결한 다른팀 동료분들 코드를 참고해 수정하고자 시도는 해보았지만, 아무래도 어느 정도 개발이 진행된 코드의 전체 구조를 뜯어고쳐야 하는 부분이기에 쉽지가 않았습니다😢
• 수정을 시도했다 포기한 부분
  • main, soup, side를 각각의 view model로 두는 대신 하나의 view model로 묶고 내부에 배열 혹은 딕셔너리로 main, soup, side를 가지고 있도록 함
  • Observable 대신 closure를 사용해 items 값에 변화가 생기는 시점에 해당 카테고리 값을 view controller로 전달할 수 있도록 함

꼭 해보면 좋겠다고 팁을 주신 부분인데 완전히 구현하지 못하고 넘어가 너무 아쉽지만,
그래도 해결을 위해 여러가지로 시도해보면서 느끼고 배우는 게 참 많았습니다. 제이슨 감사드려요.
(말씀주시기 전까진 reloadSections라는 메소드가 존재하는지도 몰랐었습니다😭)
추후 기회가 된다면 반찬 프로젝트를 아예 처음부터 구현하면서 해당 기능을 다시 시도해보고 싶네요!
​
2주동안 정말 고생 많으셨고 감사했습니다. 새로운 한주, 한달 힘내서 시작하시길 바랄게요!

[ehgud0670]

넵 ㅎㅎ 고생하셨습니다. 천천히 살펴보고 코멘트 드릴게요!

[ehgud0670]

궁금했던 점은 Persistence에 있는 이 데이터들을 고안한 방식처럼 관리해도 괜찮은 것인지, 혹은 더 나은방법이나 다른 접근으로 사용할 수 있는지 궁금합니다.

​=>넵, 지금과 같이 작성해도 괜찮을 것 같네요! primaryKey도 잘쓰고 계시고요. 이 프로젝트 말고 더 복잡한 상황이 있어야 더 나은 방법이 뭐가 있을지 고민할 수 있을 것 같습니다. 다른 백엔드분들에게 DB 작성하기 까다로운 상황으로 어떤게 있는지 질문해보세요 ㅎㅎ
=> 다만 사용하는 전체적인 로직이 효율적이지 못한 것 같습니다. 모바일에서 DB는 네트워크 사용량을 줄이기 위해서도 사용합니다. 맨 처음에는 데이터를 서버로부터 받아 DB에 저장하고, 그 이후에는 DB에 데이터가 있다면 데이터를 서버로 요청하지 않고 DB의 데이터를 사용하는 방법은 어떨까요? 그리고 업데이트 Interval를 둬서 시간이 지나 데이터를 업데이트 해야 하면 다시 서버로부터 데이터를 요청하는거죠.

이번 프로젝트의 메인디쉬라고 말씀해주신 reloadSections 부분을 꼭 구현해보고 싶어서 지난 주말동안 시도해보았습니다.

=> 이 부분 구현해 보시려고 고생 많으셨습니다. 구현하려고 주말에도 코딩하시고 정말 대단하시네요 💯 저도 이 부분 구현 못해서 옆에 친구한테도 물어보고 그랬어요 ㅠㅠ ㅋㅋ. 그리고 이전 기수들 중에서도 이거 다시 구현해보라고 하면 못할 사람들도 꽤 있을거에요. 어려운 부분이니 너무 상심하지 않으셨으면 좋겠습니다. 그리고 reloadSections는 이전에 안썼으면 당연히 모르는 거니깐 신경쓰지마세요 ㅎㅎ
=> reloadSections 이 부분 그래서 지금 코드로 제가 구현해보았습니다. 이 부분 따로 오프라인으로 제가 학원에 가서 설명 해드릴수 있을 것 같은데 설명해드릴까요? 글로만 설명해드리려고 하니 복잡하네요 ㅋ.ㅋ 뵐 수 있으면 다른 부분들도 추가로 더 설명드리겠습니다!

• 추가로 짧은 시간안에 DetailPageVC까지 구현하시고 대단하시네요! 고생많으셨습니다. 👏

p.s 너무 늦게 피드백을 드려 죄송하네요... ㅜ.ㅜ 반영은 안하셔도 되니 피드백만 봐주시고 코멘트 달아주세요 ㅎㅎ. 두 분도 피드백 확인하셨으면 머지 하셔도 됩니다.

[ehgud0670]

covenience init을 쓰신 이유가 따로 있을까요? 특별한 이유가 없으시다면 그냥 init을 써도 될 것 같습니다.

[ehgud0670]

이 부분에서 prices 와 badges를 추가하는게 깔끔하겠네요. 그리고 찾아보니 append(objectsIn:) 라는 것도 있는데 써보시는 게 어떨까요?

[ehgud0670]

mainVC에도 viewModels를 가지고 있고 datasource와 delegate에도 viewModels를 가지고 있네요.
이렇게 여러 객체가 공통된 viewModels를 가지고 있는 것보단 하나의 객체만 프로퍼티로 가지고 있는 것이 더 깔끔하고 로직이 단순하여 코드를 파악하기 좋습니다.
최소한 이 프로젝트에서는 단 하나의 객체만이 가지게 할 수 있으니 여유 있으실때 시도해보세요.

[1song2]

지금 간단히 생각해보기로는 delegate나 dataSource를 별도의 객체로 분리하지 않고, MainPageViewController를 extend해 사용한다면 viewModels를 하나로 사용할 수 있지 않을까 싶은 생각이 드네요!

viewController를 가볍게 사용하고자 파일을 분리해 작성한 것이었는데, 말씀하신대로 여러 객체가 viewModels를 가지고 있는 것은 확실히 헷갈리고 깔끔하지 않은 것 같습니다🤔

또 다른 개선 방법이 있을지도 좀 더 고민해보겠습니다!

[ehgud0670]

viewModels 배열(자료구조)를 가지고 있는 CategoryViewModel 객체를 만드는 건 어떨까요?
이러한 객체가 있으면 메소드로 더 추상화 가능할것 같아요.

팁

• 하나의 총체적인 뷰모델을 먼저 생각하고 안에 세부적인 뷰모델을 작성한다고 생각하시면 쉽게 쉽게 객체를 만드실 수 있을 것 같아요.
• 맨 처음에 뷰모델을 구현하실때 하나의 VC에서 제일 큰 뷰모델 하나를 만들고 프로퍼티로 모델 값만 두고 메소드만 추가하시는 걸 추천드립니다. 그 다음에 세부적인 뷰모델을 차근차근 구현하는거죠.

[1song2]

네 제이슨 주신 의견에 공감합니다!
자료를 많이 찾아본 것은 아니지만 이렇게 viewModel을 여러개 가지고 있기 보다는 크게 아우르는 하나의 viewModel을 사용하는 것이 일반적인 것 같다는 느낌을 받았어요.
다만 개선이 생각처럼 되지 않아 그냥 현재의 구조로 두고 아쉬움만 느끼고 있었는데,
팁 주신 내용을 참고해 한번 수정해보도록 하겠습니다!

[ehgud0670]

observe 메소드가 category에서만 쓰이는 군요!
items의 observe 메소드가 쓰이지 않는다면 items는 Observable<[DishesItemViewModel]> 타입이 아닌 [DishesItemViewModel] 이 타입이어도 될 것 같네용

[1song2]

reloadSections를 시도해보는 과정에서 category를 급하게 추가하다 보니 필요 없는 부분에서 Observable이 사용되고 있는 걸 놓쳤네요. PR 전에 작성했던 코드를 좀더 꼼꼼히 살피는 습관을 들이도록 하겠습니다!

[ehgud0670]

DispatchQueue.main.async 이 부분 주석처리해도 UI를 메인스레드에서 처리하고 있지 않다는 경고가 안뜰껍니다. 왜 그런지 고민해보세요 ㅎㅎ

[1song2]

위에 피드백 주셨던 responseDecodable부터 계속 메인에서 처리를 하고 있기 때문일까요?👀

[ehgud0670]

DispatchQueue.main.async를 여기에 옮겨도 되지 않을까요?

[1song2]

아래 DispatchQueue 관련 주셨던 다른 피드백과 종합해서 생각해보면,
좀더 직접적으로 UI를 처리해주는 부분에서 DispatchQueue를 사용하는 것이 낫다는 말씀이실까요?
아직 완벽히 감이 오진 않아서 아래 말씀해주신 것처럼 스레드간 역할을 좀더 학습해보고 그부분 고민해 코드 작성해보겠습니다!

[ehgud0670]

forcedunwrapping 은 좋지 않아요. 아예 사용 안하시는 걸 권장합니다.
try? 을 사용하거나 do-try-catch 구문으로 에러를 잡는 것이 좋습니다

[JacksonPk]

감사합니다. 튜토리얼대로 따라만 하다보니 force를 이용했습니다. 앞으로는 try catch로 구현해보는 습관을 키우도록 하겠습니다!

[ehgud0670]

• 마찬가지로 try? 을 사용하거나 do-try-catch 구문으로 에러를 잡는 것이 좋습니다.
• 또 스위프트에서 Error란 처리가능한 에러를 말합니다. 스위프트의 Error는 자바, 오브젝티브씨의 Error 및 Exception와는 또 어떻게 다른지 공부하시면 Swift를 보다 깊게 이해하실 수 있을 것 같아요.
  • 이 부분에 대해서는 제가 스터디하면서 작성한 글이 있는데 한번 보시는 것도 좋을것 같아요 ㅋㅋㅋ ㅎㅎ. 비판은 환영입니다!!

[JacksonPk]

감사합니다. 이번 기회에 저도 Result<T,Error> 에 대한 개념을 살짝 맛보았는데( 네트워크 연결이 안됐을 때 에러 처리를 이용해서 DB의 아이템을 불러오는 방식으로 구현하기 위해서) 제이슨이 써주신 글을 한번 읽어보고 이해해보겠습니다!

[ehgud0670]

아 넵, 글이 좀 정제되어 있진 않아요 ㅋㅋㅋ

[ehgud0670]

DispatchQueue.main.async가 observe에 있는것보다 refreshView처럼 UI처리하는 메소드에 위치하는게 자리잡는 게 더 낫지 않을까요? 메인 스레드가 다른 스레드와 다르게 어떤 역할을 할 수 있는지 고민하시고 코드 작성하시면 좋을 것 같습니당

[JacksonPk]

궁금했던 점은 Persistence에 있는 이 데이터들을 고안한 방식처럼 관리해도 괜찮은 것인지, 혹은 더 나은방법이나 다른 접근으로 사용할 수 있는지 궁금합니다.

​=>넵, 지금과 같이 작성해도 괜찮을 것 같네요! primaryKey도 잘쓰고 계시고요. 이 프로젝트 말고 더 복잡한 상황이 있어야 더 나은 방법이 뭐가 있을지 고민할 수 있을 것 같습니다. 다른 백엔드분들에게 DB 작성하기 까다로운 상황으로 어떤게 있는지 질문해보세요 ㅎㅎ
=> 다만 사용하는 전체적인 로직이 효율적이지 못한 것 같습니다. 모바일에서 DB는 네트워크 사용량을 줄이기 위해서도 사용합니다. 맨 처음에는 데이터를 서버로부터 받아 DB에 저장하고, 그 이후에는 DB에 데이터가 있다면 데이터를 서버로 요청하지 않고 DB의 데이터를 사용하는 방법은 어떨까요? 그리고 업데이트 Interval를 둬서 시간이 지나 데이터를 업데이트 해야 하면 다시 서버로부터 데이터를 요청하는거죠.

네, 그 로직이 좋은 방식이라고 생각합니다. 제가 계속 생각해봤던 것이 실제 앱이라고 생각해봤을 때, 서버에서 업데이트 되지 않았을까(예를들어, 특정 가게에서 메뉴의 가격을 바꾼다던지.) DB에 있는 데이터를 보여주면 사용자측면에서 혼돈이 올까 싶어서 네트워크가 연결이 되지 않을 경우에만 일시적으로 DB에 있는 데이터를 보여주도록 로직을 짜 보았습니다. 업데이트 Interval에 대한 개념을 이해하지못해서 이렇게 로직을 구현했네요. 감사합니다.

[ehgud0670]

넵, 추가로 time interval에 대해서도 말씀드리고자 코멘트 드렸어요, 수고하셨습니다! 👏