RxMVVM-DataCenter is iOS app architecture to remove dependencies among ViewControllers. If you see the result which is made by using RxMVVM-DataCenter at https://github.com/skyfe79/RxGitSearch. You can know there is no dependencies among ViewControllers and how to use Rx techniques. RxMVVM-DataCenter 은 어떻게 하면 의존성을 제거할 수 있을까에 대한 고민에서 시작된 프로젝트입니다. RxGitSearch라는 작은 예제를 만들어서 ViewController간에 의존성을 제거하였고 Rx를 사용하여 앱을 유연하게 변화에 빠르게 대응할 수 있도록 구현하였습니다.

1. ARCHITECTURE
FOR
iOS APPs
SUNGCHEOL KIM
Burt.K
skyfe79@gmail.com
http://github.com/skyfe79
http://blog.burt.pe.kr

3. 설계도 유출
문제가 되는 쪽은?
하드웨어 소프트웨어
? ?

4. 하드웨어 설계도
• 유출되면 큰일이다.
• 왜?

5. 소프트웨어 설계도
• 유출되면 큰일이다.
• 글쎄?
• 설계도가 있어도 설계도를 구성하는 각 컴포넌트들을 다
시 작성해야 하기 때문에 시간이 걸리거나 컴포넌트 재작
에 필요한 도메인 지식이 없을 경우 불가능할 수도 있다

6. 소프트웨어 소스코드
• 유출되면 큰일이다?
• 만약 모듈간에 Dependency가 아주 강한 소스코드라면?
• 글쎄?
• 소스코드 전체를 그대로 빌드해서 복사하는 수준이 아니
라면 소스코드를 변경하거나 일부 모듈을 재사용하는 것
이 어려워 시간 비용이 커진다.

7. Dependency
문제는!

8. A B
A가 B에 의존할 때, A는 무엇을 하기 위해서 반드시 B가 필요한 것
Dependency

9. 지금까지의 얘기의 결론은?

10. 하드웨어는
인수인계가 쉽다.

11. 소프트웨어는
인수인계가 어렵다.

12. 소프트웨어 설계 철학 중
한 축은?

13. 디펜던시를 줄이자!
(가능하면 제거하자)

14. 왜?

15. 사람이 코드를 작성하니깐

16. 사람은 영원하지 않다.

17. 언젠가는 떠나고

18. 언젠가는 죽는다.

19. 즉, 언젠가는
누군가가 대신해서 코드를
관리해야 한다.

20. Dependency가 강한 코드
를 교체하려 한다면?

21. 교체 하기가 힘들다.
부수효과로 인해
불가능할 수도 있다.

22. 이런 경우
책A
(김성철)
책B
(김성철)
책B
(김성철)
책B
(김성철)
책B
(김성철)
김성철
김성철을 홍길동으로
변경해야 하는경우
A,B,C,D,E 모두 수정해야 한다
홍길동

23. 이렇게 하면?
책A
(사원A)
책B
(사원A)
책B
(사원A)
책B
(사원A)
책B
(사원A)
사원A
김성철을 홍길동으로
변경해야 하는경우
말그대로 김성철을 홍길동으로
변경하면 된다.
홍길동김성철

24. 강력한 Dependency 사이에
레이어를 두면 dependency
가 약해진다!

25. MVC

26. Model - View - Controller

27. Massive View Controller

28. Massive View Controller
• Delegate
• Callback
• View Decoration
• Firing Request REST API
• DB CRUD
• …

29. 왜?
• Model-View-Controller간에 dependency가 너무 강하
기 때문이다.
• Model은 변경이 자주 일어 나지 않는다. -> 재사용가능
• View도 변경이 자주 일어 나지 않는다. -> 재사용가능
• Controller는 변경이 자주 일어 난다 -> 그러나 Massive
View Controller로 재사용 불가능

30. 기획서, 디자인, 추가기능
등등의 변경사항

31. 컨트롤러의 변경이 가장
많다.

32. 레이어를 만들자!

33. MVVM

34. MVVM
View
(ViewController,
View)
ViewModel Model

35. 뷰(VC,V)와 모델간에 레이어
(VM)를 두어 Massive View
Controller 가 되는 것을 막자

36. 좋은점
V VM M
1. 테스트 코드를 작성하기 편하다.
2. VM과 M은 변경이 자주 일어 나지 않아 재사용성이 높다
3. V는 변경이 자주 일어나지만 Dependency와 책임이 약해
쉽게 변경 가능하다.
4. Rx와 찰떡궁합니다.

37. V
1. 뷰를 꾸미고 레이아웃 하는 것만 책임지면 된다.
2. 모델이 등장하지 않는다.
1. 단, iOS의 TableView나 CollectionView에서는
모델이 등장할 수 있다.
왜? DataSource가 model을 cell-view로 전환해주는
Adapter이기 때문이다.

38. M
1. 말 그대로 모델, 데이터 필드의 모임

39. VM
1. Firing API Request
2. Callback
3. Firing DB CRUD

40. Rx

41. 1.Control Flow -> Data Flow
2.Asynchronous operations and
event/data streams

43. Rx-MVVM
V VM M
Binding Observable
VM은 비동기 데이터 스트림으로 M을 다룬다.
바인딩을 통해 M이 변경되거나 VM의 액션이 일어나면
V가 자동으로 변경되도록 한다.
즉, 프로그래머는 V에서 데이터, 이벤트 흐름에 대해 플로우를
설계하면 그만이다!

44. 실제 적용 사례
http://github.com/skyfe79/
RxGitSearch

45. iOS App에 등장하는
또 하나의 강력한
Dependency!

46. Navigation

47. Android VS iOS
Activity
process
Activity
process
Activity
process
TASK
VC VC VC
PROCESS

48. Android
• 화면 네비게이션이 기본으로 IPC에 기반을 두고 있음
• 다른 액티비티의 인스턴스를 현재 액티비티에서 생성할
수 없음
• Intent를 통해서 입력 데이터를 전달함
• 결과를 onActivityResult로 받음
• 액티비티간에 dependency가 아주 약함

49. iOS
• iOS는 한 프로세스 안에 여러 VC를 가지고 있음
• 같은 메모리를 공유하기 때문에 현재 VC에서 다른 VC의
인스턴스를 생성할 있고 멤버 함수도 호출할 수 있음
• 화면 네비게이션을 위해 VC간에 알아야 하는게 필수임
• 결과는 Delegate로 받아서 델리게이트의 존재도 알아야
함
• 아주 강력한 Dependency가 생김!

50. Apple의 해법

51. 화면 네비게이션을 위한
Mediator를 두자.

52. Segue

53. Segue
• VC간의 네비게이션을 Segue를 통해 VC가 서로 몰라도 네비게이션
이 되게 하자.
• performSegue(“push-segue”)
• 그러나 데이터 주입(Injection)을 해야 할 때 강력한 디펜던시가 생김
• prepareSegue()
• destinationViewController가 무엇인지 알아야 함
• destinationViewController의 인스턴스를 사용해야 함

54. iOS App에 등장하는
또 하나의 강력한
Dependency!

55. Delegate

56. Apple의 해법

57. Block

58. Block
• 델리게이트를 통해 역할을 대신 수행하지 말고 Block을
통해서 역할을 주입하라.
• 델리게이트를 사용하지 말고 Block을 사용하여
Dependency를 제거한다.
• Retain Cycle 등에 민감함

59. 우리의 해법

60. Apple의 전략과 동일하게
Mediator를 두자.

61. Router

62. http://user/detail/:userid
->
UserDetailViewController

63. route(“http://user/detail/1”)
func onButtonClicked() {
}

64. • Route를 사용하는 VC에서 UserDetailViewController를
모름
• 필요한 데이터는 URL 형식으로 전달함
• 결과를 받을 경우에는? 콜백블럭을 사용

65. route(“http://user/detail/1”) { result in
// do something with result
// backing route
}
func onButtonClicked() {
}

66. 만약 전달하는 데이터가
Heavy 하면?

67. Rx + MVVM을 수정하자

68. https://medium.com/ribot-labs/android-application-
architecture-8b6e34acda65#.gbqrq9oib

69. Ribot의 경험을 바탕으로

70. Rx + MVVM을 수정하자

71. Postoffice or DataCenter

72. D
A
T
A
C
E
N
T
E
R
GPS
DB
REST
FILE
Observable
Observable
Observable
Observable
D3W
Delegate
Observable
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
URL Route

73. D
A
T
A
C
E
N
T
E
R
GPS
DB
REST
FILE
Observable
Observable
Observable
Observable
D3W
Delegate
Observable
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
V VM
Binding Ob/Process/Post
URL Route
이것만 재사용 가능!
때에 따라서는 이것도 재사용 가능!
교체가
쉽다!
아
무
런
의
존
성
이
없
다
!

74. http://github.com/
skyfe79/RxGitSearch
완벽한 실제 적용 사례

75. VM
func postResultData() {
dataCenter.post(“searchResult”, resultCollection)
}
VC
func viewDidLoad() {
dataCenter.receive(“searchResult”)
.asObservable
.subscribeOnNext { result in
…
}
}

76. • 델리게이터가 필요없다
• 콜백체인으로 인한 콜백헬에 빠질 일이 없다.
• Dependency가 V-VM, VM-M 에만 존재한다.
• V-VM은 아주 약한 Dependency다
• VC와 VC간에 Dependency가 없다.

77. 요즘 iOS 서비스앱은?

78. 데이터 Flow가 아주 많다.

79. 이벤트 Flow가 아주 많다

80. 때로는 사람의 생명과도
직결되는 앱이다.

81. 앱이 안정적 이어야한다

82. 앱이 변화에 빠르게 대응
해야 한다.

83. RxMVVM+DataCenter

84. http://github.com/
skyfe79/RxGitSearch

85. 감사합니다