Notice
Recent Posts
Recent Comments
Link
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Archives
Today
Total
관리 메뉴

Stacking Fire

THERE을 나오면서, Processor에 대하여 본문

개발/iOS

THERE을 나오면서, Processor에 대하여

라우비 2018. 2. 19. 17:49

2017년 8월에 들어간 THERE에서 2018년 2월에 나오게 되었고, 새 버전 네이티브 iOS 코드에서 손을 놓아야만 했다. 회사를 나오게 된 것도 아쉽지만, 작업을 끝맺지 못한 게 더 아쉽다. 특히 THERE이라는 회사에 꼭 필요한 기능이라고 생각해서 만든 'Processor' 클래스를 제대로 써보지 못한 것이 아쉽다. 미래의 나 혹은 미래의 THERE 개발자를 위해, Processor에 대해 간단히 써 두고자 한다.


(아래의 내용은 작성당시 아직 개발중인 THERE iOS 4.0 버전의 내부 커스텀 API에 대한 설명입니다만 순수하게 iOS 프론트엔드 개발에 관한 내용이며, THERE 서비스에 대한 기술적인 내용을 포함하지 않습니다.)


THERE은 서로 다른 시스템을 가진 투어 및 액티비티 제공사들과 협력해야 하는 서비스이다. 그런데 이런 업체들은 예약을 위해 원하는 정보의 종류와 순서가 다양하다. 그러다 보니, 정적인 뷰 구성으로는 여러 가지 배리에이션의 뷰컨트롤러가 생겨날 것이다. 서로 많이 다르지 않은 기능임에도 말이다. 그리고 전체 정책에서 뭔가 하나가 바뀌면 모든 뷰 컨트롤러를 수정해야만 한다. 효율적이지 못하다. 그래서 뷰컨트롤러는 하나로 두되 거기에 예약을 위한 정보 처리를 담당하는 'Processor'가 정보의 질의와 순서, 연관성 컨트롤을 하도록 했다. (VIPER의 프레젠터와 라우터가 하는 일을 유사하게 하고 있다.)

Question

그러려면 우선 질의와 답변이 추상화되어야만 했다. 그래서 맨 처음 만든 것이 질의를 뜻하는 'Question'이다. 이 클래스는 물어보는 데 필요한 정보와, 물어보는 정보가 어떤 특성을 지니는지를 알고 있다.


우선은 어떤 타입의 질문인지를 알아야 했다. 그래서 아래와 같이 데얼에서 만든 시점에 필요하다고 생각되는 질의 타입 5개를 정하고, 그에 맞게 정의했다. 선택지가 있는 'selective'타입에는 그 선택지들을 배열로 타입 이넘 자체에 포함하게 했다. 나중에 'QuestionView'가 이걸 이용해 Picker의 row 정보를 채우게 될 것이다.

enum QuestionType {
  case text
  case selective(choices: [String])
  case multiSelective(componentTitles: [String], choices: [[String]], units: [String])
  case number(unit: String)
  case availableDate(dates: [Date])
}

그리고 이걸 활용해서 질문군으로 묶기 위한 QuestionSet, 질문하는 UIView인 QuestionView, 또 그걸 묶는 QuestionSetView를 만들었다. QuestionSet을 관리하는 일을 Processor에게 맡기고, 뷰컨트롤러에게는 'Askable'이라는 프로토콜을 준수하도록 했다.

Askable

Askable은 QuestionSet을 제공했을 때 그걸 QuestionSetView로 만들어 화면에 표시하는 ask(questionSet:)과 물어봤던 내용을 역으로 지우는 unAsk(questionSet:)을 기본 조건으로 가진다. 이를 통해 이 프로토콜만 준수하면 하나의 뷰 컨트롤러가 서로 다른 종류와 순서와 조건의 질문들을 처리할 수 있게 된다.

구조

그래서 예약 뷰는 아래의 3가지 클래스가 일을 담당한다.

BookingViewModel → BookingProcessor → BookingViewController(Askable)

각기 좌측에 있는 클래스의 인스턴스를 소유하며, 데이터는 좌측에서 우측으로 전달된다.

주요 역할을 정리하면 아래와 같다.


  • 각 ViewModel : 서비스에 리퀘스트 요청 및 정보 저장. (Model 인스턴스 소유)
  • BookingProcessor : 비즈니스 로직, 다음 뷰가 어디인지 정하는 역할. (QuestionSet 인스턴스 소유)
  • BookingViewController : 화면 표시. (QuestionSetView 소유)

더 디테일한 내용들이 있지만, 기본 아이디어는 여기까지다. 작동하는 것까지 확인은 했지만, 좀더 다듬을 것들이 많았는데 나오게 되서 아쉽다. 누군가가 그 소스를 다시 만지게 되더라도 아마 이걸 가지고 계속 쓰기는 좀 혼란스러울 것이다. 그래도 이해를 돕기 위해 남겨둔다.

Comments