Recommandé
Contenu connexe
Tendances
Tendances (18)
Similaire à Create App Easier With SVC Pattern - DroidKnights 2019 @Seoul
Similaire à Create App Easier With SVC Pattern - DroidKnights 2019 @Seoul (20)
Create App Easier With SVC Pattern - DroidKnights 2019 @Seoul
- 1. SVC 패턴으로 앱 쉽게 만들기 Speaker.남반석
- 2. 오늘 여러분과 만들어볼 앱 - https://github.com/BansookNam/svc-lotto SVC LOTTO Features: 1. 셔플 2. 한번에 뽑기 3. 연속 자동 뽑기 4. 직접 뽑기
- 3. MVP? MVVM? SVC? 오늘 여러분과 만들어볼 앱
- 4. SVC 패턴이 생긴 이유
- 5. SVC 패턴이 생긴 이유 회사에서 실무로 5개의 프로젝트를 경험: => 패턴 구조 제각각. • 패턴 없이 상속만 쓰는 곳 • MVP • MVP with Interactor • MVVM => 유지보수 할수록 코드 복잡 & 이해가 잘 되지 않음.
- 6. SVC 패턴이 생긴 이유 “더 쉬운 방법은 없을까?”
- 7. SVC 패턴이 생긴 이유 패턴 없이 그냥 개발하면 안되요?
- 8. 패턴 없이 그냥 개발하면 안되요? 태초에는 행복하다
- 9. 태초에는 행복하다 좋아요 효과 넣어주세요 게시판을 등급제로 바꾸려고요 로그인 안한 사람도 쓸 수 있게 안될까요? 푸시 왔을때 화면에도 보여주세요 패턴 없이 그냥 개발하면 안되요?
- 10. 점점 늘어나는 스펙과 코드 하나의 Class File에 1000줄이 넘어가면 패턴 없이 그냥 개발하면 안되요?
- 11. CODE HELL
- 12. 1000줄이 넘는 클래스를 막기 위해서는 해야한다.중복 제거 패턴 없이 그냥 개발하면 안되요?
- 13. 1000줄이 넘는 클래스를 막기 위해서는 해야한다.예방미리 패턴 없이 그냥 개발하면 안되요?
- 14. 1000줄이 넘는 클래스를 막기 위해서는 해야한다.분리미리 패턴 없이 그냥 개발하면 안되요?
- 15. 그래서 어떻게 분리하는게 좋죠? 패턴 없이 그냥 개발하면 안되요?
- 16. 패턴 없이 그냥 개발하면 안되요? https://github.com/googlesamples/android-architecture/ MVP와 MVVM
- 17. MVP와 MVVM
- 18. MVP 1. View를 배치 2. View에서 사용자 Action 감지 처리 3. Action에 따라서 알맞은 동작 수행하기 4. 동작의 결과를 다시 View에 Rendering 앱을 만드는 순서 MVP와 MVVM
- 20. - View를 배치 - View에서 사용자 Action 감지 처리 - Action에 따라서 알맞은 동작 수행하기 - View <-> ViewModel과 Binding MVVM앱을 만드는 순서 MVP와 MVVM
- 21. MVP나 MVVM으로 개발하면 되는데 를 왜 만들었어요?SVC 패턴 없이 그냥 개발하면 안되요?
- 22. SVC 패턴이 생긴 이유 패턴 없이 그냥 개발하면 안되요?
- 23. MVP SVC 패턴이 생긴 이유 MVVM 불편을 느낌 패턴에 대한 원론적인 오류나 비판이 아니라 실무적인 사용성 및 구조에 대한 불편 오해하지 말아주세요
- 24. MVP의 불편 SVC 패턴이 생긴 이유
- 25. (https://github.com/googlesamples/android-architecture/tree/todo-mvp-kotlin) 반복적인 interface 파일 생성/관리 •하나의 클래스를 위한 인터페이스 •메서드 추가, 제거를 위해 2번씩 수정하는 번거로움 •View <-> Presenter 강한 1:1 결합 MVP의 불편
- 26. 비지니스 로직 View 로직 분리 우리의 목표 (https://github.com/googlesamples/android-architecture/tree/todo-mvp-kotlin)MVP의 불편
- 28. Presenter View Activity, Fragment 우리의 현실 •View 관련작업을 할때 presenter가 노출되어 있어 쉽게 비지니스 로직에 관여할 수 있음 •startActivityForResult, onActivityResult 등 화면 전환과 관련된 로직이 View에 들어감. -> View와 관련 없는 코드와 섞이기 시작. -> Activity, Fragment의 코드 읽기가 어려워짐 (https://github.com/googlesamples/android-architecture/tree/todo-mvp-kotlin)MVP의 불편
- 30. MVVM의 불편 유저 인터랙션의 (클릭, 스크롤, 스와이프) 처리 방식이 다양하다. (https://github.com/googlesamples/android-architecture/tree/todo-mvvm-live-kotlin) 2. Command Observer 필드 관찰 3. 별도의 리스너 1. ViewModel 직접 호출
- 31. MVVM의 불편 1. ViewModel 객체의 함수를 직접 호출 하는 방법 => ViewModel의 역할은 Data 보관. 함수가 생기면 ViewModel이 무거워 질 수 있다 => 해당 ViewModel Data 변화를 주는 메서드 외에는 직접 호출은 지양. (https://github.com/googlesamples/android-architecture/tree/todo-mvvm-live-kotlin)
- 32. MVVM의 불편 2. Command Observer 필드 관찰 (https://github.com/googlesamples/android-architecture/tree/todo-mvvm-live-kotlin) 1) 필드 선언 2) 필드 관찰 3) 필드 invoke => 함수 구현은 ViewModel 밖으로 추출 가능. => MVP보다 번거롭다. (3가지 코딩을 해야함) (명령이 많아질 수록 필드 증가)
- 33. MVVM의 불편 3. 별도의 리스너 구현 => ViewModel이 아닌 객체로 액션을 전달 가능 => 바인딩이 일어나는 Activity, Fragment에서 리스너 구현 (https://github.com/googlesamples/android-architecture/tree/todo-mvvm-live-kotlin) 예제에서는 Listener를 통해 ViewModel 함수 호출. => 이럴꺼면 차라리 xml에서 viewModel을 직접 호출하는게 call 뎁스를 줄일 수 있다.
- 34. MVVM의 불편 인터랙션 처리의 방식이 다양하고, 한가지로 정하기가 애매하여 화면 스펙마다 사용 방식이 다름 (https://github.com/googlesamples/android-architecture/tree/todo-mvvm-live-kotlin) => 코드 복잡을 유발 => 팀에서 규칙을 정해야 좋음
- 35. MVVM의 불편(https://github.com/googlesamples/android-architecture/tree/todo-mvvm-live-kotlin) Databinding 사용시 View에서 문제가 생겼을때 Xml 파일에 debuging이 불가능. (break point) 자동 생성된 {layout_name}BindingImpl 클래스를 열어 위치를 추적 해야함
- 36. MVVM의 불편(https://github.com/googlesamples/android-architecture/tree/todo-mvvm-live-kotlin) 해당 Xml에 크래시가 아닌 UI오류가 발생했는데 문제가 BindingAdapter, InverseBindingAdapter 내부 로직 오류라면 발견하기가 쉽지 않음. => Static 함수로 이뤄지기 때문에 연결고리 찾기 어려움) => 프로젝트 구조를 잘 파악해야함 => BindingAdapter가 많아질 수록 관리 어려움 (팀의 Management 필수)
- 37. SVC 패턴이 생긴 이유 - 껍데기 역할의 interface 파일 관리 - 비지니스 로직과 View 로직의 분리 안됨 - 사용자 인터랙션 처리의 애매함 - View 로직의 Debugging이 힘듦 - 제거 - 분리 - 단일 방법 제시 - Debugging 가능 어려움 해결 +α - Activity, Fragment 중복 로직 제거 - 나눠진 컴포넌트 재사용 - View의 추상화 가능
- 38. SVC 패턴이 생긴 이유 SVC 설명
- 40. S V C SVC 설명
- 41. SVC 설명 S Screen Activity, Fragment - 화면의 특정 영역을 담당 - 이전 화면에서 넘어온 정보 세팅 (Intent, Bundle) - 다음 화면 이동을 수행함. (startActivity, fragment 이동) - 다음 화면의 결과를 받아옴 (onActivityResult)
- 42. SVC 설명 Views inflate된 xml 관리 - Screen이 보여주는 xml 관리 - 정보를 받아 화면에 Render - 유저의 인터렉션을 ControlTower에 전달 (feat. ViewsAction) - View들이 모여있는 큰 커스텀뷰 V
- 43. C SVC 설명 ControlTower 로직을 담당하는 관제탑 - Screen의 LifeCycle 이벤트 처리 - Views에서 발생한 viewsAction 처리 - 그 외에 등록한 각종 센서의 이벤트 처리 - 네트워크 상태 변화 처리
- 44. SVC 설명 SVC - 입문
- 45. SVC - 입문 app/build.gradle build.gradle 둘 중에 하나 https://github.com/naver/svc
- 46. SVC - 입문 •@SvcActivity => Activity로 만들어주고 •@SvcFragment로 바꾸면 => Fragment가됨 •@SvcDialogFragment로 바꾸면 => Dialog가됨 •@RequireViews, @RequireControlTower 추가 S 상속 클래스명 규칙 : SVC_{클래스명}
- 47. SVC - 입문 1. 액션이 존재하는 화면이라면 ActionViews를 상속, GenericType에는 ViewsAction을 명시 2. layoutRedId에는 inflate될 xml id를 전달 V
- 48. SVC - 입문 1. ViewsAction을 implements 2. 해당 Views에서 ControlTower에게 전달 함수 추가 V
- 49. SVC - 입문 V 디자인 전담 개발자와 분리해서 작업 가능 중요 포인트 ★★★★★
- 50. SVC - 입문 V 1. Xml 2. Views 3. ViewsAction 디자인 전담 개발자와 분리해서 작업 가능 중요 포인트 - ★★★★★ 3가지 파일로 뷰 작업 완전 분리
- 51. SVC - 입문 1. @ControlTower 추가 2. @RequireScreen 소속 Screen 명시 (추상 Screen도 가능) 3. @RequireViews 명령할 views 타입 명시 (추상 Views 가능) C 상속 클래스명 규칙 : SVC_{클래스명}
- 52. SVC - 입문
- 53. SVC - 입문 SVC는 쉽다면서요..!?
- 55. SVC-Template 설치 : https://github.com/naver/svc-template Mac or Linux Window copy $ANDROID_STUDIO_FOLDER$plugins androidlibtemplatesother $ git clone https://github.com/naver/svc-template.git $ cd svc-template $ ./install.sh
- 56. SVC - 입문 File - New 옵션 안에 (or 우클릭) “SVC” 새로운 메뉴를 찾을 수 있음. 원하는 Activity나 Fragment, Dialog를 선택합니다.
- 57. SVC - 입문 1. Name 2. Author name
- 58. SVC - 입문 파일 생성 완료. => Rebuild Project 수행
- 59. SVC - 입문 입문을 축하합니다.
- 60. SVC - 입문 SVC - 설계
- 61. SVC - 설계 SVC - 설계 Types
- 62. SVC - 설계 Types MVP와 가장 다른점 - Activity, Fragment에서 View가 빠져나옴 - Views에서 viewsAction을 통해서 ControlTower에 직접 전달 (Views는 비지니스 로직을 알지 못함)
- 63. SVC - 설계 Types
- 64. SVC - 설계 Types
- 65. SVC - 설계 Types
- 66. SVC - 설계 Types
- 67. SVC - 설계 Types ViewModel 내부 필드가 여러 종류의 속성들을 들고 있다면, ControlTower가 여러 Model들을 통해서 중간 관리를 해주는 것이 복잡도를 낮출 수 있다.
- 68. SVC - 설계 Types ViewModel 내부 필드가 한 종류의 데이터 집합을 관리한다면, ViewModel이 직접 Model을 통해 데이터를 관리하는게 관계적 측면과, 유지 보수측면에서 낫다. (ControlTower의 불필요한 중간 연계를 끊을 수 있다.)
- 69. SVC - 설계 Types Screen들은 서로 정보를 주고 받으며 사용자에게 필요한 것을 제공한다.
- 70. SVC - 설계 Types SVC - Lotto - 설계
- 71. SVC - Lotto - 설계
- 72. SVC - 설계 Types SVC - Lotto - Commits
- 73. SVC - Lotto - Commits https://github.com/BansookNam/svc-lotto https://github.com/naver/svc 설명
- 74. SVC - Lotto - Commits 프로젝트 생성
- 75. SVC - Lotto - Commits MainApplication 추가
- 76. SVC - Lotto - Commits Ball 객체 추가
- 77. SVC - Lotto - Commits SVC 와 필요한 library 추가
- 78. SVC - Lotto - Commits MainViews layout 구성
- 79. SVC - Lotto - Commits MainViews layout 구성 BottomNavigationView ViewPager ActionBar
- 81. PagerAdapter Model data를 세팅해주지 않는다? ViewPager안의 Fragment
- 84. ViewPager안의 Fragment 코드가 비어있다는건 => 화면 전환, 이동 없다는 의미
- 85. Fragment안의 Views
- 86. Fragment안의 Views
- 88. 아주 잘 따라오고 계십니다 ^^ Fragment안의 Views
- 89. Fragment안의 Views SVC 한걸음 더
- 90. SVC 한걸음 더 SVC - Advanced
- 91. SVC - Advanced - ControlTower 스펙이 많아 코드가 500줄을 넘어갈때 1. ControlTower 쪼개기 2. RecyclerView에서 ViewModel 활용하기 - RecyclerView에 list 데이터 대신 ViewModel 넣기
- 92. 1. ControlTower 쪼개기 MainControlTower - 255 Lines MainControlTower - 83 Lines 70% 코드 감량
- 94. 1. ControlTower 쪼개기 Interface로 분리 Default Method 이용
- 95. 1) ControlTower안에 비슷한 일을 하는 메서드 통으로 잘라내기 Interface로 분리
- 96. 2) 메서드를 묶을 Interface 생성후 메서드 붙여넣기 ex) {***}Controller, {***}Plugin 등의 네이밍 추천 Interface로 분리
- 97. 3) 필드가 존재하지 않기 때문에 에러가 발생 Interface로 분리
- 98. 4) 필요한 필드를 상단에 정의 Interface로 분리
- 99. 5) 원래 구현체에 implement후, 필드에 override 명시 Interface로 분리
- 100. Interface로 분리 메소드 성격에 따라 로직이 분리됨, 추후에 메서드 재사용 가능
- 101. Interface로 분리 장점: - ControlTower의 가독성 향상 - 실제 구현부는 interface 안에 있기 때문에
- 102. Interface로 분리 2. RecyclerView에서 ViewModel 활용하기
- 103. 2. RecyclerView에서 ViewModel 활용하기 언제 필요하나? •리스트인데, 정보가 계속 바뀌어야되는 경우. 출처: Toss 왜 필요하나? •adapter.notify**를 하지 않아도 됨 •ViewModel 값만 바꿔주면 갱신
- 104. 2. RecyclerView에서 ViewModel 활용하기 1) ScreenActionAdapter를 상속한 Adapter 생성
- 105. 2. RecyclerView에서 ViewModel 활용하기 Adapter에 Screen? 1) ScreenActionAdapter를 상속한 Adapter 생성
- 106. 2. RecyclerView에서 ViewModel 활용하기 1) ScreenActionAdapter를 상속한 Adapter 생성
- 107. 2. RecyclerView에서 ViewModel 활용하기 2) ScreenActionHolder를 상속한 ViewHolder 생성
- 108. 2. RecyclerView에서 ViewModel 활용하기 3) 만든 Adapter를 Views에서 세팅
- 109. 2. RecyclerView에서 ViewModel 활용하기 SVC - Advanced 끝
- 110. SVC - Advanced 끝
- 111. SVC - Advanced 끝 SVC 한번 써보시겠어요?
- 112. SVC - Advanced 끝
- 113. SVC - Advanced 끝 다른 패턴들과의 비교 항목
- 114. 다른 패턴들과의 비교 항목 •Code 라인 수 •화면 전환 로직의 배치 •스펙 변경 대응 능력 •디버깅 •유닛 테스트
- 115. 다른 패턴들과의 비교 항목 •Code 라인 수 생산성을 정성적인 수치로 가장 간단하게 확인할 수 있는 방법. 같은 스펙을 놓고 코드 라인 숫자를 비교해보면. 실제로 프로그래머가 코드를 작성하는 양을 알 수 있고, 코드가 적을 수록 문제가 생긴 위치를 찾는 데 더 유리하다.
- 117. 다른 패턴들과의 비교 항목 •Code 라인 수 •화면 전환 로직의 배치 •스펙 변경 대응 능력 •디버깅 •유닛 테스트 https://medium.com/@bansooknam/ 1주일 뒤 기고 예정 나머지는
- 118. 다른 패턴들과의 비교 항목 테스트도 가능한가요?
- 119. 테스트도 가능한가요? https://github.com/BansookNam/android-architecture.git 네 테스트도 가능합니다. UnitTest 안에서 Screen의 LifeCycle을 변경하면서 테스트 가능 TaskDetailFragmentTest, TasksFragmentTest 참고
- 120. 가장 좋은 패턴은? 테스트도 가능한가요?
- 121. 가장 좋은 패턴은? 1. 프로젝트에 참여하는 모든 팀원들이 함께 선택하고 2. 팀원들의 개발 시간을 줄여주고 3. 팀원들끼리 커뮤니케이션하기 쉽고 4. 서로 담당 영역이 바뀌어도 쉽게 적응할 수 있을만큼 구조화를 잘해놓은 아키텍처
- 122. 가장 좋은 패턴은 ‘켄트백의 구현 패턴’ (에이콘출판, 2008) “패턴은 절대적인 진리가 아니다 의사 결정을 돕는 도구다” “반복적인 문제의 해결책을 제공해서 프로그래머가 남는 시간과 에너지, 창의력을 진정 독창적인 문제 해결에 사용할 수 있게 해준다”
- 123. Thank You 😊 Special Thanks To Naver Team & skydoves
- 124. Q&A