view model 은 팩토리로 생성하는 이유

ViewModel 은 화면에 표시할 데이터를 제공하는 데이터 Holder 역할을 하게 됩니다.화면을 위한 것이므로 화면과 같은 생명주기를 가져야만 버그 발생 가능성을 줄일수가 있습니다. 만약 List, Detail 두 개 화면이 있을 때 DetailViewModel 이 싱글턴으로 유지되면 새로운 항목 클릭해서 Detail 화면으로 왔을 때 기존 화면의 내용이 잠깐 남아 있다가 교체가 될 수도 있고기존 화면의 내용 일부가 남아 있을 수도 있는 등의 버그 발생 가능성이 있고, 굉장히 귀찮아 집니다. 그래서 화면과 ViewModel 의 생명주기를 같게 하는 것이 중요합니다.

domain 에 data_source 를 만드는 이유.

구현체는 data 레이어, 추상화된 인터페이스는 domain 레이어에 두고 있습니다.domain 레이어가 앱의 핵심 비즈니스 로직을 담당하고 있는데요. domain 레이어에 data_source 의 인터페이스를 두게되면 각 레이어간의 의존관계가 다음과 같아집니다.presentation --> domain 의존성의 방향이 외부에서 내부로 향하게 되는 의존성 역전 원칙(DIP)가 적용되고, 핵심은 domain 이게 됩니다. 이 상태에서는 presentation 의 테스트에 domain 레이어만 필요하게 되고data 레이어의 테스트에도 domain 만 필요하게 됩니다. 만약 data_source 인터페이스가 data 레이어에 있다면 의존 관계는 다음과 같아집니다.presentation --> domain data domain 레이어에 있는 Repository 인터페이스가 data 레이어에 있는 data_source 인터페이스를 참조해야 하기 때문입니다. 이 경우에는 추후에 멀티 모듈 방식으로 프로젝트가 확장되게 될 때 각 레이어를 나누기 어려워 지기 때문에 확장성에 제한이 생길 수 있습니다.

기존 코드 mvvm으로 역할 분리하는 기준이 궁금합니다

인공지능 답변에 이어 제가 답변 드리겠습니다.이 부분이 쉽지 않은 영역인데요.파일 디코딩 -> JSON 변환은 순수하게 데이터를 처리하는 부분이고 Service 또는 DataSource 로 부를 수 있겠습니다.비즈니스 로직은 여기에 앱에 필요한 로직이 가미되면 그것이 비즈니스 로직입니다.비즈니스 로직은 두 군에서 작성할 수 있겠습니다.View에 대한 비즈니스 로직은 ViewModel 에 함수에서 작성합니다.그 외에 데이터의 복잡한 처리가 비즈니스 로직이라고 보면 될 것 같습니다.결론적으로 "앱에 필요한 로직이 가미되면 그것이 비즈니스 로직"이다. 라고 보시면 어떨까요?

ListenableBuilder가 안되요..material import 했는데도 자동완성이 안뜨고 빨간줄이 뜨네요 ..

답변이 늦었습니다.AI 인턴의 말은 무시하시고요. 아직도 안 되실까요?아마도 근처에 const 들이 영향을 줄지도 모르겠습니다. const 들을 하나씩 제거해 보면서 시도해 보세요.

Flutter에서 추천하는 Navigator, Router

go_router 사용에 대해 말씀드리면:1. Hot Reload 시 파라미터 초기화 문제- 개발 중에만 발생하는 이슈로, 실제 프로덕션 환경에서는 문제되지 않습니다- 이는 hot reload의 특성상 상태가 초기화되는 것이 정상적인 동작입니다2. 데이터 전달 방식 선택- extra: 임시적인 데이터나 복잡한 객체 전달에 적합- path/query 파라미터: * 페이지 새로고침 후에도 데이터 유지 필요시 * 딥링킹 지원 필요시 * URL에서 상태 확인이 필요한 경우3. go_router 사용 권장 케이스- 웹 지원이 필요한 프로젝트- URL 기반 라우팅이 필요한 경우- 중첩 라우팅이 필요한 경우- 딥링킹 지원이 필요한 경우4. 일반 Navigator 사용 케이스- 단순한 네비게이션만 필요한 경우- 웹 지원이 불필요한 경우- URL 기반 라우팅이 불필요한 경우결론적으로, go_router는 특히 웹 지원이나 딥링킹이 필요한 프로젝트에서 매우 유용하며, 파라미터 전달 방식은 사용 케이스에 따라 적절히 선택하시면 됩니다.

The following ProgressEvent object was thrown resolving an image codec: [object ProgressEvent]

아니. AI 인턴이 2분만에 답을 해 버리네. 로컬에서는 되고 배포하면 안 되는 경우 대부분 CORS 설정 때문입니다.인턴 말대로 해 보시기 바랍니다.

dispose 오버라이드 메소드 자동완성이 안 됩니다.

툴이 버그가 많아서 안 될 때도 있는데, 일단 AndroidStudio 최신 버전 확인.StatefulWidget 인지 확인해 보시고요.인프런 AI 가 얘기한거 확인 해 보시고, 정 안되면 일단 수동으로 작성하시죠.

provider를 사용하시는 이유가 있을까요?

Provider를 사용하는 이유는 가장 근본에 가깝기 때문입니다.라이브러리 없이 Dart의 ChangeNotifier 와 Flutter의 InheritedWidget 조합으로 상태관리를 할 수 있습니다. 하지만 보일러플레이트 코드가 너무나도 많고 InheritedWidget 부분을 미리 만들어 주는 라이브러리가 Provider 입니다.근본을 알고 있다면 다른 라이브러리를 사용하는데에 문제가 없지만, Riverpod 으로 입문을 했다면 Riverpod 특유의 매직(?) 스러움이 있어서 오히려 근본을 이해하기 어려울 수 있다고 생각합니다.더구나 code generation 을 사용한다면 더욱더 매직 코드가 많아지는데, 매직이라고 표현한 부분은 Riverpod 에서의 provider 는 top-level 에 작성함에도 실제로는 클래스로 생성된다는 점, BuildContext가 아닌 WidgetRef를 왜 사용하는지 등입니다. 이는 사용하는데에는 문제 없을지 몰라도, 동작 원리를 이해하는데에는 방해가 될 수 있고, 근본적인 상태관리를 이해하는데 장해물이 된다고 생각했습니다. 그래서 제 오프라인 강의에서는 상태관리 라이브러리를 도입하지 않고 상태관리를 충분히 기본 API만으로 사용해 본 후에 최대한 나중에 라이브러리를 도입합니다. 그와중에 그나마 Provider 가 근본에 가까워서 먼저 합니다. 결국 모든 라이브러리의 목적이 동일하며 근본을 알면 어떤 라이브러리를 사용해도 상관이 없습니다. 궁극적으로 나중에 다른 라이브러리로 교체하는 것에 문제가 없어야 한다고 봅니다. 그렇지 않다면 내가 특정 라이브러리에 매몰되어 있는 것은 아닌가 생각해 볼 필요가 있습니다. 혹시 Riverpod 이 Provider 의 어떤 점을 개선하려고 만든 것인지 정확하게 말할 수 있는지 생각해 보시고, 정확히 말할 수 없다면최근 리뉴얼한 제 강의 중 'Flutter 초급 - http 통신, 상태관리' 에서 상태관리를 근본부터 하나씩 빌드업하여 4대 라이브러리 (Provider, Bloc, GetX, Riverpod)를 살펴보고 왜 학습에 Provider를 선택했는지를 설명하고 있으니 참고하시기 바랍니다.

클린아키텍처 의존관계 관련

인프런 AI 가 원래 하루 지나서 답을 하는데 이번에는 5분만에 달아버렸네요..ㄷㄷUseCase가 인터페이스를 참조하기 때문에 Repository 구현체가 로컬 DB이거나, 로컬 File 이거나, 리모트에 저장되거나 상관없이 UseCase 의 로직은 영향을 받지 않는 것이 맞습니다.공유해 주신 영상 잘 보았습니다.영상에서 이야기하는 부분과 제가 강의하는 부분이 추구하는 바는 일맥상통합니다.객체가 다른 객체를 참조할 때는 인터페이스를 참조하는 것이 핵심인데요. 혹시 어느 부분에서 개념이 충돌하신다고 느끼셨을지 다시 알려주실 수 있으실까요.이번 강의의 경우 클린 아키텍처 구조를 가져가지만 UseCase 없이 Repository 만 활용하고 있어서 그렇게 느끼셨을까요.아키텍처에 대한 저의 생각을 말씀드리면백엔드의 경우 많은 기능이 있고 이를 추상화하기 위해 헥사고날 같은 아키텍처를 고민하고 있고요.모바일에서도 규모가 큰 앱의 경우 feature 별로 여러개로 나뉘어진 클린 아키텍처를 채용하기도 하기도 하고, MVI 기반의 클린 아키텍처를 채용하기도 하는 등. 다양한 변형이 가능합니다.프로젝트의 규모에 따라 아키텍처는 정답이 없는 부분이기 때문이지요. 다음 강의는 고급편으로 열심히 만들고 있습니다. 이 강의에서도 앱 수준에 맞게 변형된 클린아키텍처를 사용하고 있습니다.가제목은 "현업 수준의 Flutter 앱 작성" 이고요.앱 사이즈가 커서 좀 오래 걸리고 있는데 10월 말까지를 목표로 하고 있습니다.컨셉은 현업 스타일로 Figma 디자인이 주어지면 Mock 데이터를 토대로 앱을 작성하며, Unit Test, UI Test 가 가능한 형태로 코드를 작성하고 최종적으로 Integration Test 로 시나리오를 테스트할 수 있고, 코드 커버지리 목표를 설정하고 달성합니다.개발 환경 설정을 통해 Mock 데이터와 실제 데이터를 쉽게 교체하고, 실제 데이터 구현체를 바꿔도 비즈니스 로직에 영향이 없는 코드를 작성합니다.상태관리 코드의 의존성을 제거하여 쉽게 상태관리 라이브러리를 교체할 수 있고, UI 테스트가 가능하도록 코드를 작성합니다.

이제 버전 3.4인데 쭉 들어도되겠죠?...

챕터 2를 재촬영하여 업데이트하였습니다. 챕터 1을 눈으로만 보셔도 되고, 안 보셔도 됩니다. 예전 챕터 2는 보지 마시고 새로 작성된 것을 보시기 바랍니다.