goRouter

인프런 AI가 잘 정리를 해줬네요 🙂 여기서 제 의견을 드리자면 이미 잘 사용중이고 문제 없이 Get의 toNamed 방식을 사용하고 있다면 GoRouter로 리펙토링을 할 필요 없다고 생각합니다. 저도 여러 프로젝트에서 Getx의 Route인 toNamed 방식으로 사용하고 있는데 어느정도 규모가 있더라도 큰 문제 되지 않습니다.

appBar 텍스트 컬러 적용이 안돼요!

안녕하세요 캡쳐하신 이미지대로 작성하셨는데도 글색상이 흰색으로 보이지 않는다는 말씀이실까요? app.dart 파일과 detail.dart 파일을 보내주시면 검토해보겠습니다. 감사합니다.

모델 객체에 대해

모델설계를할때 유연하게 설계를할필요가 있습니다 질문주신것처럼 원래 데이터에 null이 있으면안되지 안나라고 하셨는데 맞습니다 api로 전달받은 데이터는 null이 오면 안되겠죠 하지만 네트워트 통신이고 서버 상태에 따라 어떻게 데이터가 들어오게 될지 보장하기 어렵습니다. 또한 시간에 지남에 따라 api 스펙이달라짐으로인해 특정 field가 더이상 보내주지 않는다라고 한다면 이런 경우를 대비해 필드를 null 가능하게 설계하면 예상치 못한 오류를 방지할 수 있습니다

네이버api프로젝트세팅부분에서

StatefulWidget의 경우 부모로부터 전달받는 값이 아닌 이상 보통 State 상속받은 클레스 내에 변수를 선언합니다. 부모로부터의 데이터를 사용하여 상태관리를 할 경우 StatefulWidget 클래스에서 받아주고(생성자)부모와의 데이터 관계가 없을때는 State 클래스에서 생성한다고 보시면 되겠습니다. 한가지 예를 들어 설명드리자면 submit 버튼이 있다고 가정하겠습니다. submit 버튼이 동작하려면 부모 위젯의 입력 필드(id/password)들이 채워져야 버튼이 활성화가 될 것입니다. 이때 Submit 버튼에 disabled라는 값이 있어야하고 그 값은 부모위젯에의해 결정됩니다(id/pssword 입력여부) 이때 disabled는 StatefulWidget에 존재하게됩니다 그리고 버튼이 눌릴때 특정 애니메이션 효과를 넣는다고 가정하면 애니메이션은 부모위젯과 관계가 없죠 그렇기때문에 애니메이션 컨트롤러는 State쪽에 선언하고 관리 합니다

네이버api프로젝트세팅부분에서

안녕하세요 좋은 질문을 주셔서 저 역시 한번 더 생각할 수 있었습니다. 우선 dio 주입을 MyApp에서 만들어서 하지 않고 main 함수에서 해주는 이유에 대해서 설명을 드리겠습니다. 사실 MyApp에서 만들어서 사용해도 문제 되지 않습니다. 단지 main 함수에서 만들어준 이유는 배포 환경을 고려해서 설계하기 위함입니다. 물론 지금 강의에서 만든 앱의 경우 Flavor 설정(배포별 환경이 다르게 설정)을 하지 않아서 MyApp에 생성해도 상관이 없겠지만 만일 Flavor를 설정한다고 한다면 main 함수를 local, dev, staging, prod 별로 나눠서 설정하게 될 것이고 각 함수에 각각의 endpoint가 설정되어야 하기 때문입니다. 두번째 질문에 답을 드리자면 Stateful 위젯과 Stateless 위젯을 사용하는 이유에 대한 질문인것 같은데 맞는지 모르겠네요 어떨때 Stateful을 사용하고 어떨때 Stateless를 사용하는지는 왠만하면 Stateless위젯을 사용합니다. 이유는 상태관리를 bloc을 사용해서 관리 하고 있기 때문에 페이지나 컨포넌트에 상태를 갖을 필요가 없기 때문입니다. 그럼에도 Stateful를 사용해야 할때가 있는데 그럴때는 위젯의 라이프사이클을 사용하기 위함입니다. Stateful 위젯은 다양한 경우 발생되는 이벤트들지 존재합니다. (Initstate, dispose, didChangeDependencies. 등등 ) 각각을 왜 사용하는지에 대해서는 위젯 라이프사이클에 대한 영상을 찾아보심을 추천드립니다. 그리고 Stateful를 사용할때는 간단한 컨포넌트를 만들때 사용합니다. bloc이나 cubit을 사용하기에는 heavy 하기 때문에 간단하게 위젯의 상태를 통해 만들어줄때 사용하게 됩니다. 질문에 답이 되었을지 모르겠네요.

잘 모르겠어요

앱개발에 있어서 setState로 개발하기엔 한계가 있습니다. 그렇기에 별도의 상태관리 라이브러리를 사용하곤 하는데 상태관리 라이브러리에는 다양하게 존재합니다. bloc은 구조가 잘 잡혀있기 때문에 여러 개발자가 작업하기에 용의하여 대규모 프로젝트에서 사용되는 편입니다. 반면 getx의 경우 사용이 편리하고 bloc에 비해 쉽게 이해되는 부분이 있어서 getx를 가장 많이 사용되고 있는 편입니다. setState를 이해를 하셨다고 한다면 bloc은 다소 어려울 수 있습니다. 우선 getx를 먼저 보시면서 상태관리의 역할과 직접 앱을 상태관리를 통해 구현을 해보시다 보면 상태관리에 대한 어느정도 개념이 잡히실것입니다. 그 이후에 bloc을 다시 보시면 이해가 될 것이라 생각됩니다. 책 리뷰앱은 구매하셨다니 감사합니다. 한번 구매해 놓으시면 평생 수강이 가능하시니 우선 getx를 통한 상태관리 이해를 먼저 해보시는 것을 추천 드립니다. 감사합니다 ~!

doc id와 uid

파이어 베이스 데이터베이스 사용방식으로 docId 값을 내부 field의 값으로 사용하지 말라는 말이나 사용해도 된다는 내용은 없습니다. 그리고 docId와 uid 값을 같게 하면 몇가지 유용한 점이 있습니다. 우선 docId를 uid와 같게 해도 문제 되지 않는 이유는 DocId는 방대한 문서들의 유일한 key입니다. 즉, collection내에 하나만 존재하는 조건만 갖춘다면 어떤 데이터라도 상관이 없습니다. 실제로 firebase console로 접속해서 데이터를 넣으려고 할때 docId를 직접 입력할 수도 있습니다. 그렇다면 고객의 uid는 유일한 키 입니다. 나의 서비스의 고객들중에 고객의 uid가 중복될 가능성은 없습니다. 그렇기 대문에 docId를 uid로 사용해도 무방한 조건이 됩니다. 또한 docId를 uid로 사용해서 한다면 장점이 있습니다. 조회 속도가 훨씬 빠릅니다. 왜냐면, 많은 document들이 있는데 document를 찾는데 docId를 가지고 조회를 한다면 direct로 조회를 할 수 있지만 특정 필드의 값으로 조회하는 where를 사용하게 되면 문서들을 하나하나 확인하면서 찾기 때문에 속도 차이가 분명하게 나뉘게 됩니다.물론 field들을 색인이라고 해서 docId처럼 빠르게 찾을 수 있는 설정을 할 수 있지만 이부분을 추가 비용이 발생될 수 있는 부분입니다. (색인 할 수 있는 field개수 있음 -무료에서) 물론 보안상 중요한 문서를 DocId를 uid를 같게 사용하면 보안상 문제의 요소가 있을 수 있습니다. 그래서 이를 막기 위해 데이터베이스 접근 권한을 자신의 데이터에만 접근 할 수 있도록 설정하는 등의 방법을 사용 할 수 있습니다.

실제 폰에서 테스트 시 리뷰 작성 버튼 위치

확인해보니 그렇군요 시뮬레이터로 하다보니 가상 키보드가 올라오지 않아서 확인이 안됐었군요.알려주셔서 감사합니다. 해당 문제는 여러가지 방법으로 문제를 해결 할 수 있겠지만 그 중 가장 간단한 방법은 하단 리뷰 TextField가 아닌 다른 영역을 더치시 키보드가 닫히도록 처리 하는 방법이 있습니다. 그것을 위해서는 body 영역의 Column 위젯을 GestureDetector로 감싸주고 onTap시 FocusScope를 onfocus 시켜주는 것입니다. 소스코드는 다음과 같습니다. GestureDetector( onTap: () => FocusScope.of(context).unfocus(), behavior: HitTestBehavior.translucent, child: Column( children: [ BookReviewHeaderWidget( naverBookInfo: naverBookInfo, reviewCountDisplayWidget: // 이하 소스 동일 이렇게 작성을 하게 되면 다른 영역 터치시 키보드가 다시 내려가는 것을 확인 할 수 있습니다. 그렇게 하면 발생되는 문제는 이상하게 수정한 내용이 다시 초기화 되는 문제가 발생되는 것을 알 수 있습니다. 그것은 _ReviewBox 위젯에 didUpdateWidget을 initReview 값으로 초기화 해주고 있기 때문입니다. 이 부분은 최초 위젯이 랜더링 될때만 initreview를 받고 그 이후에는 업데이트 해줄 필요가 없는 부분입니다. 그래서 최초 위젯 랜더링 시에는 editingController.text 값이 빈 상태이기 때문에 다음과 같은 조건을 추가해줘야 합니다. @override void didUpdateWidget(covariant _ReviewBox oldWidget) { super.didUpdateWidget(oldWidget); if (editingController.text.isEmpty) { editingController.text = widget.initReview ?? ''; } }이렇게 수정해주면 문제를 해결 할 수 있습니다. 또 다른 방법은 외부 라이브러리를 이용한 방법입니다. keyboard_attachable이 라이브러리를 사용하면 키보드 상단에 고정을 시키는 방식으로 채팅 화면을 생각하시면 쉬울 것입니다. 단 이렇게 하면 화면 디자인을 수정해 줘야 하는 부분도 있고 소스코드를 많이 수정해야 하는 부분이라 현 강의에서는 위 첫번째 방식으로 문제를 해결하는 것을 추천드리겠습니다.

후속 강의 질문

후속 강의에 관심 가져주셔서 감사합니다.[Bloc 응용] 실전 앱 만들기 (책 리뷰 앱) : SNS 로그인, Firebase 적용, Bloc 상태 관리, GoRouter대시보드 강의는 Cubit으로 강의를 진행하고 있습니다. 감사합니다.

애플 로그인 위해 애플 개발자 인증센터는 Developer 프로그램 가입해야 하나요?

안녕하세요 애플로그인 관련해서 질문을 주셨는데;;아쉽지만... 개발자 가입이 되어야 테스트가 가능합니다... 제가 알고있는것과 관련해서 저도 예전에 찾아보았는데 그런 방법은 없다고 하더군요 지금 시점에서는 그런방안을 제공하고 있을지는 찾아보진 못했지만. 아마도 개발자 가입이 되어야 할 것입니다.