[Flutter] Clean Architecture, Reactive Programming, WebView (git flow, singleton, etc.)

Part 4는 주로 심화된 내용으로 개념적인 것을 위주로 설명. Part 3에서 휙휙 지나갔던 개념을 다시 집어주는 느낌이나, 여전히 어려운 개념들임.

 

4.1.1)

- 위의 그림은 깃플로우 전략인데, feature branch는 기능 개발, develop은 base(개발브랜치)의 역할을 해서 merge 시킴.

- 용어의 정리: 마켓출시는 말그대로 플레이스토어에 출시하는 거고, 배포는 출시 전 내부 테스트 (다운 받아서 실제 디바이스에서도 돌려보고 등등)하는 걸 일컫.

- release branch는 마켓출시의 후보군 정도. 내부 클라이언트에 올라가고 QA들이 테스팅함. 버그가 발생하면 release branch에서 고침. 다 끝나면 그제서야 마스터 브랜치에 머지됨.

- 위의 release 브랜치에서 버그 픽스된 버전은 다시 개발 브랜치로 머지돼서 거기서 시작함.

- hotfix는 출시 후 QA도 잡지 못한 리포트 된 버그를 빠르게 수정하여 마스터 브랜치로 재차 머지시킴. 얘는 바로 다시 출시되어야 해서 변경내역이 최소화 되어야 함.

- 가장 보편적으로 쓰인다 함.

 

4.1.2)

- 위는 git flow고, 아래는 github flow라고, 깃헙에서 사용하기 좀 복잡해서 이걸 추천:

- 브랜치명 같은 깃헙 관련 전략 및 팁 전수해줌.

- PR 이후 브랜치 삭제하셈.

 

4.2.1-2)

- 추상화 클래스를 통해 자식클래스가 implements하여 좀 더 유연하게 구현 가능 (예시는 잘 찾아봐).

- Dependency Injection도 abstract class와 같이 의존성을 낮추기 위해 있는거,, 종류는 constructor/setter/method injection 이렇게 있는데, 보통 constructor injection만 쓴다함.

- 안드로이드에선 dagger와 service locator에 대한 설명. Service locator는 전역 접근해서 별도로 구석에 몰아넣고 구현해야하고, 대거와 달리 런타임에 결정됨. 중간에 교체도 가능함.

- 플러터에선 get_it이란 패키지로 service locator를 표방함. get_it 원리와 주요 기능 설명. --> get x를 위한 빌드업임.

 

4.2.3)

- Singleton은 객체의 인스턴스가 오직 1개만 생성해서 여러 곳에서 사용하는 것.

- 이미 생성되어 있는 인스턴스를 사용해서 속도 측면에서 유리하고, 데이터를 공유하기 편함.

 

4.2.4)

- injectable is a convenient code generator for get_it.

- @annotation을 활용해서 구현함.

 

4.3.1-4)

- 클린아키텍처:

- view: 화면 / view -> presenter한테 명령 / UseCase가 비즈니스 로직 / DataStore가 외부서버 혹은 로컬 / Entity는 DTO임 (서버 맞춤 모델) / domain layer의 모델은 실제로 앱에서 쓰는 모델이고 translator를 통해 해석됨.

- 도메인과 데이터 레이어 간의 통신은 레포지토리를 통해서 함.

- 클린아키텍처는 초보용은 아니래. 한 번에 이해 못함. 나도 그럼.

 

4.4.1-5) 클린아키텍처 실습 --- Part 3 Todo앱에 이미 적용한 거 설명

- common 폴더는 앱 전체가 같이 쓰는 것들을 담아둠. 보통 core라고도 많이 한다는 듯.

- presentation 폴더 바로 밑에는 feature를 두는 게 좋대.

- 서버는 remote, 로컬은 local로 명명함. -> 카톡처럼 두 개 다 쓴다면 상위 파일을 하나 더 만들면 좋겠지.

- entity를 model로, 또 그 반대로 만드는 파일을 mapper라 함.

- 이 Todo앱을 클린아키텍처로 나눈 게 정답은 아니어도 전형적으로 통용되는 형태라 참고하기 좋은 듯.

- 이 강사는 get_it을 선호하는 것 같음.

 

4.5.1)

- 리액티브 프로그래밍(=Rx, Reactive Extension): 비동기적인 데이터 흐름을 다루는 프로그래밍

- 연속적이고 비동기적으로 전달되는 데이터에 즉각 반응하도록 하는 프로그래밍 기법이고, 예시로 유튜브 구독과 알림/검색 자동완성 기능 (debounceTime활용)이 있음.

- 더 자세히 말하자면, 구독한 채널에서 새로운 영상이 올라오면 즉각 알림 받아볼 수 있는 것.

- 어떻게 구현할 것인가? 다트에서 자체적으로 Stream을 제공함.

- Rx는 서드파티프레임워크인데 스트림처럼 단순 데이터 흐름을 처리하는 것 뿐만 아니라, 데이터 흐름을 조작할 수 있게 도움.

 

4.5.2-3)

- Rx에서는 Observable이라는 클래스로 표현함.

- Broadcast Stream (hot observable) vs Single Stream (cold observable)

- cancel 잘 안하면 메모리 누수 이슈 있을 수 있으니 신경쓰셈.

- 각종 기능/함수 설명. RxMarbles 참고.

- EventBus는 앱에서 발생하는 각종 이벤트를 구독할 수 있음. 여러 화면에서 동시에 대응 가능(스크롤, 메뉴 이동, 프로필 정보 수정 등)

 

4.5.4-5)

- 간단 또스에 debounce & throttle 적용. 예전에 이거 관련해서 블로그에 글 적은 적 있음.

- UI를 선반영 시키고자 할 때 쓰로틀 많이 씀.

- 얘넨 대충 최적화 시킬 때 쓰임. 꿀팁도 방출함 (dialog를 쓴다든지...)

- 자동완성 시 잦은 쿼리 요청으로 서버 과부하 이슈가 있어 debounce를 쓰는 거.

 

 

4.6.1-2)

- 플랫폼 채널 이론. 위치 정보, OS버전, 접근 권한 여부, 공유하기, 이미지피커 등 이런건 플러터 자체 기능이 아닌, 플랫폼(OS) 시스템 기능으로, 플랫폼 채널을 통해 접근 가능한 것.

- MethodChannel을 통해 플랫폼(네이티브)와 통신, result(응답값) 처리 필요하고, 이걸 지원하는 데이터 타입도 전달 가능함 (error 포함)

- 메시지와 응답은 비동기 처리되고, 각 네이티브 플랫폼은 메인 스레드에서 호출해야함. 양방향 가능.

 

4.6.3)

- pigeon: 플랫폼채널 구현에 있어 메시지를 주고 받을 때, 동일한 arguments와 datatypes를 보장하기 어려움 (not typesafe).

- 그래서, pigeon 패키지를 활용해서 코드 generate해줌. 아주 대세임.

- .g파일들은 자동생성된 코드라 직접 수정 절대 X

 

4.6.4)

- Federated plugins: plugin전용 아키텍처 느낌인데, 서로 다른 플랫폼에 대한 지원을 별도의 패키지로 분할한 거.

- app-facing package: 플러그인 사용자가 플러터 앱에서 직접 사용하느 ㄴ패키지고,

- platform package: OS별 구현 코드가 포함된 패키지로 app facing package에 의해 호출돼서 사용됨. 근데 특정 플랫폼 기능이 아니라면 사용자가 직접 이 패키지를 접근해서 쓰지 않음.

- platform interface package: 플랫폼 별 통일된 인터페이스 패키지인 것.

 

- 용어 정리: 패키지는 다트로만 구성되어 있는 패키지고, 플러그인은 멀티 플랫폼 지원을 위한 코드가 포함된 패키지임.

 

4.6.5)

- Channels and plaform threading ... 이건 실무에서도 쓰일지 잘 모르겠다 함. 좀 뇌절 느낌이지만 그래도 isolate 개념을 포함하여 알아두면 좋음.

- 다트는 싱글 쓰레드 환경인데, 무거운 작업시 비동기 처리하면 버벅거림.

- isolate은 싱글 스레드로 별도 이벤트 루프가 구축되어 개별 메모리를 사용하게 해줌. 

 

4.6.6)

- Google IO 2023에서 실험하고 있는 내용 소개 : FFI (Foreign Function Interface)

 

4.6.7)

- shared preferences 구조 설명. 대부분 사용하는 패키지로 이때까지 플젝들 실제로 대부분 사용함.

- 서버에 저장하기 애매한 것들,,, eg. 테마 등

- 앱 삭제해도 데이터 살려두려면 key chain 같은 거 쓰면 된대 (지나가듯이 말함) ...찾아서 쓸 거 같진 않음.

- completer 쓰면 좋을 때가 있어서 기억하고 있으라함.

 

4.6.8)

- google_maps_flutter 구조 설명. naver map도 당근 있음.

 

4.7.1-3)

- 웹뷰: 앱 내에서 웹 페이지를 보여주는 view.

- 앱 업데이트 없이 변경이 필요한 화면 중 법, 정책 관련된 것들은 웹뷰 필요 (이용약관).

- 외부 시스템 이용시 (결제 모듈, 인증 모듈).

- 매우 복잡하고 변경 많은 UI,, 커머스 상품 상세페이지 따위.

- 플러터의 강력한 기능 중 하나가 PlatformView 기반에서 오는데, 플러터 화면(위젯)에 부분적으로 네이티브 플랫폼(android, ios 등) UI를 보여줄 수 있음(UI component). 대표적인 예시로 구글 맵이 있음.

- webview flutter package 소개해줌.

- 그래도 platformview 단점은 존재함. 지원 안되는 기능도 몇몇 있다고 함.

- inappwebview라는 플러그인이 단점들에 대한 보완이 될 수 있다함. 근데 써드파티야.

 

4.7.4)

- 인앱브라우저: 웹뷰를 활용하여 커스텀하여 앱 내부에서 브라우저 기능 화면 지원.

- ios를 위해 appbar영역은 웹뷰가 아닌 플러터 위젯으로 작업한다 함.

- 인앱브라우저를 구현하면 사용자의 앱 이탈을 막을 수 있지만 관리 포인트가 늘어남. 반대 개념이 외부브라우저임.

- 시스템브라우저도 활용 가능(deeplink,, 웹페이지에서 앱 열기). 인앱인데 사파리 뷰컨트롤러 사용. 이걸 제일 추천한다하고, 슬랙이랑 디스코드가 이걸 쓴다함.

- 4.7.5) 에서 웹뷰 실습함. 중요한 팁들 포함되어 있어보임 (prevent, mounted, etc.)

- 4.7.6) 인앱브라우저 실습. 국내 기준 인앱브라우저를 많이 쓴다함. 사파리뷰컨 쓰면 커스텀은 많이 됨.

- 4.7.7) inappwebview 플러그인 사용.

- 4.7.8) 연장선...

 

 

 

괜춘한 자료: https://danawalab.github.io/flutter/2022/08/05/Flutter-Getx.html

Flutter - GetX를 이용한 상태관리

 

 

 

 

출처: 패스트캠퍼스