RIBs는 Uber의 크로스 플랫폼 아키텍처 프레임워크입니다.
- 대규모 모바일 프로그램을 위해 설계됨
Uber 용도의 프레임워크 설계할 때 아래 원칙을 준수해주세요
- 교차 플랫폼 협업
- iOS와 안드로이드 앱이 비슷해짐
- 전역 상태 및 의사결정 최소화
- RIB는 잘격리된 개발 RIB의 깊은 계층구조 내에서 캡슐화를 권장하고 전역상태 문제를 방지
- 테스트 가능성 및 격리
- 클래스는 격리된 상태에서 단위 테스트 및 추론 이 쉬어야한다.
- RIB 클래스를 쉽게 테스트하고 독립적으로 추론할 수 있습니다.
- 개방 폐쇄 원칙
- 개발자는 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있어야합니다.
- ReactiveX를 사용하여 종속성 순서를 사용하여 조속성 순서를 지정하고 안정한 종속성 주입(DI) 시스템을 사용하여 클래스 종속성을 나타내며 많은 DI 범위를 사용하여 데이터 불변량 생성을 장려
-
이전에 VIPER 아키텍처로 작업한 적이 있다면 RIB의 클래스 분석이 익숙할 것입니다. RIB는 일반적으로 다음 요서로 구성되면 모든 요소로 구성됩니다.
-
Interactor
- 비지니스 로직을 포함한다
- Rx 구독을 수행하고, 상태 변경 결정을 내리고, 어떤 데이터를 저장할 위치(DB), 다른 RIB를 자식으로 연결해야 하는지 결정
- 수명 주기로 제한되어야한다.
- 활성화된 경우에만 비즈니스 로직이 실행되도록하는 도구를 구축해야합니다.
- 비활성화되지만 구독이 계속 실행되어 비즈니스 논리 또는 UI 상태에 대한 원치 않는 업데이트가 발생하는 시나리오를 방지할 수 있습니다.
-
Router
- Interactor를 수신하고 그 출력을 하위 RIB 연결 및 분리로 변환합니다.
- 라우터의 존재 이유는 아래 2개입니다
- 라우터는 하위 Interactor를 모의 처리하거나 그 존재에 신경 쓸 필요 없이 복잡한 Interactor 논리를 쉽게 테스트할 수 있도록 해주는 Humble Object의 역활을 합니다.
- 라우터는 상위 Interactor와 하위 Interactor 사이에 추가 추상화 계층을 생성하고 Interactor간의 동기식 통신이 조금 더 어려워지고 RIB 간의 직접 연결 대신 반응형 통신의 채택이 권장됩니다.
-
Builder
- 빌더의 책임은 모든 RIB의 구성 클래스와 각 RIB의 자식에 대한 빌더를 인스턴스화 하는 것 입니다.
- 빌더에서 클래스 생성 로직을 분리하면 iOS에서 모의 가능성에 대한 지원이 추가되고 나머지 RIB 코드는 DI 구현의 세부 사항과 무관합니다.
- 빌더는 프로젝트에서 사용되는 DI 시스템을 인식해야하는 RIB의 유일한 부분입니다.
- 다른 빌더를 구현하면 다른 DI 메커니즘을 사용하는 프로젝트에서 나머지 RIB 코드를 재사용할 수 있습니다.
-
Presenter
- 프리젠터는 비즈니스 모델을 뷰 모델로 또는 그 반대로 변환하는 상태 비저장 클래스입니다.
- Presenter는 생략될 수 있고 Presenter가 생략된다면 View(Controller) 또는 interactor의 책임이 됩니다.
-
View(Controller)
- UI를 빌드하고 업데이트합니다.
- UI 구성 요서 인스턴스화 및 배치, 사용자 상호 작용 처리, 데이터로 UI 구성 요소 채우기
- 애니메이션을 포함합니다.
- 여기는 단위테스트가 필요한 코드가 포함되어 있지 않습니다.
-
Component
- 구성 요소는 RIB 종속성을 관리하는 데 사용합니다.
- 이들은 RIB를 수성하는 다른 유닛을 인스턴스화하여 빌더를 돕습니다.
- 부모 RIB의 구성 요소는 일반적으로 자식 RIB의 빌더에 주입되어 자식이 부모 RIB의 종속성에 액세스할 수 있도록 합니다.
애플리케이션 상태는 주로 현재 RIB 트리에 연결된 RIB에 의해 관리되고 표시됩니다.
사용자가 단순화된 승차 공유 앱에서 여러 상태를 진행함에 따라 앱은 다음 RIB을 연결 및 분리합니다.
RIB는 해당 범위 내에서만 상태 결정을 내립니다. 예를 들어 Loggedln RIB는 Request 및 OnTrip과 같은 상태 간 전환에 대한 상태 결정만 냅니다. OnTrip 화면에 있으면 어떻게 행동할지 결정하지 않습니다.