GDG Korea Android AAC-ViewModel 토론 저장용

• 아무래도 최근 viewmodel 관련해서 공부를 했어서 관심이 많이가는 토론을 지켜봤습니다. 실력은 부족하지만 비교적 최근에 공부한 덕분에 조금이라도 이해가 더 잘 되는 느낌이었습니다. 해당 토론을 통해 최근 트렌드를 알 수 있음과 동시에 많은 지식들을 알 수 있게 되었습니다.
• 정리를 최대한 다 하고 싶었지만, 편의점 알바를 하며 토론을 들어 제대로 듣지 못했기 때문에 정리가 뭔가 맞지 않을 것입니다... 혹시 이 글을 보시는 분이 있다면, 잘못된 내용들 지적 부탁드립니다. 그리고 Q&A 질문들 답변 가능하신 분들도 답변 부탁드립니다!

토론 참가자들

왜 aac-viewmodel을 뷰모델이라고 정했을까?

💡 AAC-ViewModel의 비하인드 스토리: 만든 구글러들과 이야기를 해봤는데, 뷰모델이라는건 문자 그대로 뷰를 표현해야하는 데이터를 담는 컨테이너 목적으로만 의도했었다고 한다.

 

AAC-VIewModel을 쓰면 전통적인 ViewModel이라고 할 수 있을까?

• 사실 MVVM에서 VM은 개념에 조금 더 가깝고, AAC은 구현에 가깝다고 느꼈다. AAC VM으로는 MVVM VM이라곤 할 수 없다. 이것 때문에 창의성에서 앗아간다고 생각한다.
• 다른분들꺼 정리못함.. 근데 AAC로 잘만 만들면 된다 마인드인 사람들도 몇분 계셨었음

**어떤 데이터로 통신하면 될까?(**flow, livedata)

• livedata는 프레젠테이션 레이어에서 쓰기좋다 비동기 처리가 많이 일어나는 도메인보단
• stateflow, sharedflow를 코루틴에서 많이씀

room에서 라이브데이터쓸 때 도메인으로 구분하는데 라이브데이터를 도메인에서 쓰는게 맞을지?

• 쓰지말라고 강력하게 이야기할것같다. 선택은 자유 flow를 쓰는게 좋다. 종속성을 갖는데 unit test를 돌릴 때 발목을 잡게된다.
• 플루님: 권장하지않음, 라이프사이클오너를 연결해줘야하는데 room쪽에 영향을 주면 애매하다.

flow을 쓰면 코루틴이 필수적일텐데 코루틴을 못쓰면 대안은 무엇일지?

• rxjava를 써라
• mvvm은 1:N 관계로 보통 쓰게된다(근거를 제대로 못 들음)
• 데이터 처리는 어떻게할지? 뷰모델간에는 데이터통신이 없다고 생각한다.

어디까지가 뷰인가?

• 텍스트뷰같은것도 다 뷰다
• 액티비티나 프래그먼트는 뷰가 아니고 xml을 뷰라고 생각한다고 한다. 트레이드오프마다, 개발자 팀마다 다를수도잇다고 생각한다.
• 인플레이드된 뷰 컴포넌트가 뷰이다
• 사실 이것보다 로직을 잘 나눠야한다고 생각한다. 그래야 뭐든 분리가 쉽다.

뷰모델이 context를 가지면 안되는지? applicationContext를 가져야하는지

• 앱컨텍스트도 적합하지 않은 경우가 있다고 한다.
• 메모리릭이 아니더라도 안 넘기는게 좋다. 뷰모델은 안드로이드와 종속성을 최대한 분리해야한다. 그래서 래핑을 해서 인터페이스만 넘겨서 특정 액션이 가능하게 해준다.

aac 없이 config 어떻게 해결하는지?

• 그냥 세이브엔스턴스 쓴다고 한다.
• 사실 aac도 큰 데이터는 넣으면 안된다.
• 해시 테이블에 저장하는 구조라서 좋진않다.
• 차라리 데이터를 어떻게 관리할것인지를 더 고민해봐야한다.
• 세이브인스턴스는 번들 크기를 넘진 못한다. 다른 방법을 고안해야한다.

two way는 어떻게 사용할지,

• two way binding 거의 안쓴다고 함
• 컴포즈 할 때 걸리적 거릴까봐 제거하는 추세이다

라이브데이터랑 뮤터블라이브데이터는 왜 나눴는지?

• 프로퍼티를 노출할지 함수를 노출할지 고민해봐야할 것이다. 보통 함수를 노출할텐데 그거랑 같다고한다.

google sunflower가 MVVM을 공부하기 좋았는가?

• 코드적으로 이해하기 도움이 됐다. 근데 이론적으로는 궁금증이 많이 들었다고 한다. 실무에서도 이렇게 쓰이는가? 싶엇다규 한다 그래서 다 흡수하려곤 안하고 가볍게 봤다고 한다.
• 기초가 되는것 같다. 맹신하진 않는다.
• sunflower로 교육자료를 만들어봣었는데, 생각보다 지양하는바가 복잡하다. 뷰모델은 비즈니스 로직의 집합인데 함수가 검증이 되어야하는데 조금 애매했다. 실무에서는 더 나은 코드패턴도 있었다.
• 누구한테 제공하기 위한 프로젝트인지, 전문가가 대상이 아니다, 진입점이라고 생각한다.

바로 위 사진 1번째 질문

• 가급적이면 어댑터에 안 던지는게 좋다. 클릭이벤트 쓸 때 어쩔수없이 뷰모델 던지는경우가 잇는데, 액티비티 전체에서 사용하는 뷰모델로 안하고 작은 뷰모델로만(로직수행용으로 만들어서) 사용한다
• 사실 컴포즈가 나오면서 이슈가 깔끔하게 해결됐다. 최대한 빨리 컴포즈로 넘어가라....
• aac를 리싸이클러뷰에 넣는건 기능 분류가 이상해질것이다.
• 뷰모델은 비즈니스 로직의 집합체라고 한다.

Q&A에 달린 질문들

• (1) 드로이드 카이지처럼, MVVM 중 VM 은 Interface 로 두어 Pure 하게 만들고, Android, IOS 에서 각각 AndroidVM : PureVM, AACVM() / IOSVM : PureVM() 하는 경우도 있는데 해당 방식에 대한 스피커 분들의 생각이 궁금합니다  (edited) (2) 해당 방식으로 구현했을 때는 MVVM 의 VM (추상화된 View)을 만족하고 이를 구현하는 곳에서는 Platform 에 의존적인 AACVM 을 상속받아 사용하면 MVVM 의 VM 과 AACVM 이 분리 되어 있으면서도 둘의 장점을 모두 취할 수 있을 것 같다고 생각이 들어서요  (edited)
• aac-viewmodel에서 flow collect를 해도 될까요? 화면이 보이지 않을때는 collect하면 안된다고 생각하는데, 가끔 필요한 경우가 있어서요. 최대한 안하는게 맞을까요?  (edited)
• 약간 동떨어진 질문일수도 있는데, 내부적으로 compose로 넘어가야 하는지, 어떻게 적용할지에 대한 논의는 어떻게 진행하고 계신가요? 팀별 얼라인이 어려울때가 있어서 문의드립니다
• 뷰의 데이터를 관리할 때 뷰에서 필요한 모든 데이터를 호이스팅으로 최상단까지 끌어온 후 하나의 데이터 클래스(스테이트)로 모아서 하나의 옵저버블로 관리를 해야할지, 데이터 클래스를 낱낱이 해체 후 각각을 옵저버블로 만든 후 하위 뷰에서 데이터 바인딩을 해야할지 궁금합니다
• AAC-ViewModel 에서 lifecycleObserver 를 사용하여 View의 lifecycle 을 제어한다면 1:1 로 강결합되기 때문에 지양해야된다고 생각이 되는데 어떻게 생각하시는지 궁금합니다.
• A B C 뷰모델 클래스가 있고, A 뷰모델 클래스의 변수와 함수를 B C 뷰모델 클래스에서 동일하게 사용한다면, A 뷰모델 클래스를 open 클래스로 만들고 B C 뷰모델에서 상속받는 형식으로 사용해도 될까요? (A뷰모델에는 mutableLivedata, Livedata가 들어있습니다
• 뷰모델, 뷰의 상태 바인딩은 어떠한 형태로 진행하시나요? 뷰 컴포넌트와 라이브데이터 1:1 대응도 가능할거고, 혹은 리덕스와 비슷하게 보이는 화면이나 스코프를 그룹하여 하나의 데이터 클래스로 UI를 대변해서 표현해서 보여주는 형태도 가능할 것 같은데 어떻게들 관리하시는지 궁금합니다.

공유해주신 링크들

2020년 글이지만 SavedStateHandle을 살펴본 내용 글입니다. http://pluu.github.io/blog/android/2020/02/20/savedstatehandle/

ui state : https://developer.android.com/jetpack/guide/ui-layer/events#recyclerview-events

two-way 바인딩시에 언급한 메소드 내용은 이걸 언급했습니다. https://developer.android.com/topic/libraries/data-binding/expressions#event_handling