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 테스트가 가능하도록 코드를 작성합니다.