전체 글

많은 플러터 프로젝트들이 모델 선언을 할 때 Freezed 패키지를 사용한다. 왜 다들 Freezed 를 사용할는 걸까? 꼭 패키지를 써야하는걸까? 등등 몇가지 의문점이 들게되었고 공부한 기록을 블로그 포스트로 남겨보려한다. 먼저 모델 선언에 있어서 전제조건은 모델을 통해 만들어진 인스턴스가 같은 녀석인지 다른 녀석인지 비교할 수 있어야한다. 이를 동등성 비교라고 부르는데 왜 모델 선언에 있어서 동등성 비교가 중요할까? 이유는 3가지로 요약할 수 있다. 1. 데이터 무결성 확인데이터 무결성이란 모든 데이터 값이 정확한 상태(state)임을 보장할 수 있음을 의미한다. 즉 데이터의 중복이 생겨선 안된다는 것이다. 예를 들어 강아지라는 모델을 만들고 두마리 강아지 인스턴스를 만들었다고 하자. 만약 두마리 강..

Don't use 'BuildContext's across async gaps.Try rewriting the code to not use the 'BuildContext', or guard the use with a 'mounted' check.블록으로 로그인 이벤트를 처리하는 함수를 작성하고 있었다.로그인을 성공하면 메인화면으로 이동해야했기 때문에 view에서 context를 받아야만 했다.하지만 로그인 함수(비동기)안에서는 context를 건네주지 말라는 문구가 떴다. 문제 원인 BuildContextBuildContext 는 위젯트리에서 해당 위젯이 트리 어느부분에 위치하고 있는지 알 수 있는 정보이다. 즉 네이밍 그대로 빌드하는데 필요한 정보(문맥)이라고 볼 수 있다.  플러터에서 UI를 그려낼..

Squircle 이란?플러터로 sliver 리스트를 구현하던 중 corner radius 값을 주어 끝을 둥글게 만드는 코드를 작성했다. 하지만 막상 실기기로 돌려보니 끄트머리가 묘하게 각져있는 것을 확인할 수 있었다. 앱 디자인이 전반적으로 "둥글둥글" 느낌이 나야하는데 먼가 SwiftUI에서 구현했을 때랑 느낌이 달랐다.. 분명 SwiftUI는 CornerRadius값만 주어도 둥글둥글한 느낌이 살아있었다. 백문이불여일견, 바로 같은 Corner Radius를 주어 SwiftUI와 Flutter를 비교해보았다. 역시 애플 갓위는 SwiftUI 코드로 작성한 Rounded Container이고 아래는플러터로 작성한 Rounded Container이다. 자세히 들여다보면 플러터 모서리가 묘하게 각져있음을..

소셜로그인을 구현하면서 사용자가 두번째 로그인부터는 생체인증으로 간단하게 메인으로 진입하게 구현하기위해 사용자 로그인 기록을 로컬 DB에 넣어야했다. 보통 이런정보는 보안이 딱히 중요하지 않고 간단한 정보라 생각해서 iOS의 경우 Userdefault에 저장했고 플러터에서는 Userdefault 랩핑하고있는 Shared Preference 패키지를 사용하려고 했다. 하지만 안드로이드 진영 SharedPreference에 이슈가 있다는 것을 알게되어 공식문서를 들여다 보게 되었다.  shared preferences 는 위와 같이 iOS의 userdefaults를, 안드로이드의 SharedPreferences를 랩핑하고 있는 패키지이다. Userdefaults는 iOS에서 단순한 DB저장 도구로 키-밸류형..

플러터에는 사용자 터치이벤트 처리를 위한 위젯으로 Inkwell 위젯과 GestureDetector 위젯이 있다. Inkwell 위젯Inkwell 위젯은 Material 위젯안에서 사용되기 때문에 Material 디자인 시스템이 적용되어 사용자 이벤트를 처리한다.따라서 사용자가 탭할시 Material 디자인 테마 효과인 Ripple Effect가 기본으로 구현된다. GestureDetector 위젯 GestureDetector 위젯도 inkwell 위젯처럼 사용자 터치이벤트를 처리해준다.차이점으로는 GestureDetector는 Matrial 하위위젯이 아니다! 따라서 Material 디자인 시스템이 적용되지 않고 위와같은 리플 이펙트도 적용되지않는다.또한 inkwell보다 좀더 다양한 터치제스쳐 처리가..

진행 중인 사이드프로젝트에 참여하게되어서 클론을 받았으나 위와같은 firebase_option 이 임포트가 안된다는 에러가 발생했다. 이러한 경우 에러발생원인이 크게 두 가지인데 1. 정말로 yaml 파일에서 firebase_core 패키지를 넣어주지 않았거나2. 플러터 프로젝트를 파이어베이스와 연동하지 않았거나. (Flutterfire Configure 작업 필요) 이미 진행되고 있는 프로젝트를 클론받았을 때 위와같은 에러가 뜬다면 후자일 가능성이 높다. 1번의 경우는 그냥 yaml에다 패키지 넣어주면 되고 2번은 후술할 내용에 따라 에러를 해결할 수 있다. 💡 flutterfire configure 작업이란?flutterfire configure 작업은 FlutterFire CLI를 사용하여 Flu..

Error: The plugin "cloud_firestore" requires a higher minimum iOS deployment version than your application is targeting. To build, increase your application's deployment target to at least 13.0 as described at https://docs.flutter.dev/deployment/ios  에러내용은 cloud firestore 패키지는 최소 iOS 13을 지원하는데 지금 너의 프로젝트는 iOS12로 타겟팅되어있어~ 라는 내용이다. VSCode에서 새로운 프로젝트를 만들면 디폴트값으로 iOS12로 타겟팅되기 때문에 13이상으로 올려주어야한다.  먼저..

답변 요약// Key Pathlet person = Person(name: "Alice", age: 25)let nameKeyPath = \Person.name // Person 객체의 `name` 프로퍼티에 대한 Key Pathlet ageKeyPath = \Person.age // Person 객체의 `age` 프로퍼티에 대한 Key Path 상수나 변수에 함수를 참조로 할당할 수 있는 것처럼  프로퍼티의 위치도 참조로 할당할 수 있습니다. 프로퍼티에 직접 접근해서 값을 꺼내오는게 아니라 키패스를 사용하면 간접적으로 접근하여 특정 타입의 어떤 프로퍼티 값을 가리켜야 할지 미리 지정해두고 사용할 수 있습니다.  이를 다르게 말한다면 키패스는 프로퍼티에 대한 접근을 추상화한 타입입니다.부가 설명/..

답변 요약Key-Value Observing 이란 특정 키값의 변화를 감지하는 기능으로 객체 프로퍼티 변경사항을 다른 객체에게 알릴 수 있는 코코아 프레임워크에 내장되어 있는 패턴입니다.부가 설명KVC(Key-Value Coding)는 NSKeyValueCoding 프로토콜에 의해 동작한다. NSKeyValueCoding 의 특징은 컴파일 타임에 접근하는 것이 아닌 문자열을 사용하여 런타임에 객체의 프로퍼티에 접근하거나 값을 설정한다는 것이다. Key-value coding은  KVO(Key Value Observing), 코코아 바인딩, 코어 데이터 등 코코아 프레임워크에 자주 적용되는 원리이다. 또한 NSObject를 채택하고 있는 친구는 모두 NSKeyValueCoding 프로토콜을 채택하고 있다고..

Statless 위젯의 경우Stateless 위젯의 경우 위와 같이 같은 타입이라도 다른 데이터로 인식하지만 이러한 위젯트리를 정말로 그리는 Element Tree 에서는 같은 타입은 모두 똑같이 인식해버린다.  만약 위젯트리에서 Red와 Blue의 context를 바꾸더라도 둘은 같은 타입이기 때문에 Element Tree는 이를 전혀 알 수 없다.Stateful 위젯의 경우Stateful 위젯의 경우 State는 위젯이 가지고 있는 것이 아닌 Element Tree가 소유하고 있다. 만약 위젯트리에서 Red, Blue 가 바뀐다면 Element Tree 에서는 Red WidgetTree에 Blue State를 넣게 된다.  이렇게 같은 타입이여도 Element Tree에서 다른 위젯으로 인식할 수 있..