![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/ZSGGy/btsHuoq6v7B/hAWrG99DIbDzQ2keymQsm1/img.png)
플러터에서 애니메이션을 구현하는 기반 클래스는 Ticker입니다. Ticker는 프레임이 업데이트될 때마다 등록한 콜백 함수를 호출하고 프레임이 업데이트되기까지 경과한 시간을 정의해주는 역할을 하는 녀석입니다. 하지만 우리는 대부분 티커의 인스턴스를 직접 생성하지는 않습니다.(물론 인스턴스를 생성하여 사용할 수도 있습니다.) TickerProvider라는 공급자 역할을 하는 클래스에 의해 Ticker를 생성합니다. 위젯 상태 내에서 애니메이션을 구현한다면 주로 SingleTickerProviderStateMixin 또는 TickerProviderStateMixin 믹스인을 사용하여 해당 클래스가 TickerProvider으로 동작 될 수 있도록 선언합니다. // 해당 선언부에서 TickerProvider..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/ErwfQ/btsHu5dwXVy/mx6Tdg3aSz7SAnRy7fiv70/img.png)
Stateful 위젯은 화면 상에서 사라지거나 위젯 트리 상에 존재하지 않으면(보통 dirty widget 이라고 부릅니다.) 위젯의 상태가 Dispose(폐기)되어 아무런 조치를 취하지 않는다면 상태를 유지할 수 없습니다. 해당 위젯을 다시 빌드하려고 한다면 기존에 존재하던 상태가 아니라 초기 값을 지닌 상태를 기반한 위젯이 빌드될 것입니다. 이렇게 되는 원인은 "메모리 관리와 효율성을 위해서"입니다. 모든 위젯의 상태들이 위젯 트리에 없더라도 메모리에서 불필요하게 존재한다면 생각만 해도 이는 굉장히 비효율적인 상황인 것이죠. 하지만 예외의 상황은 항상 있는 법, 이를 방지하는 방법은 매우 간단합니다.위젯의 상태 클래스를 AutomaticKeepAliveClientMixin로 확장하여 이를 해결할 수 ..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/w0Vc0/btsHurOSE35/sDKtr2SmIIkgsdMKVEnYRk/img.png)
플러터를 시작하시는 분들은 상태가 변화하였다고 프레임워크에 이를 알리기 위해 setState() 함수를 호출합니다. 모든 위젯의 상위 위젯을 RootPage라고 정의하고 여러 페이지를 이동한 상황에서 사용자가 인위적인 방법으로 테마를 다크로 설정하였다면, 최상위 위젯인 RootPage의 setState() 함수를 호출하면 되지 않나라고 간단하게 생각하는 분이 있을 겁니다. 하지만 이러한 방법은 setState() 함수가 호출된 상태만이 업데이트되었다고 알리는 행위이기 때문에 당연히 실패할겁니다.(그 하위 위젯들 모두 상태가 변화했다고 정의하는 것이 아닙니다.) 이는 당연히 비효율적인 빌드를 방지하는 매우 효율적인 기법입니다. 그렇다고 해서 생명주기 함수인 didUpdateWidget() 함수를 오버라이드..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/cewiym/btrXyqUc0Ds/oqimACKo19HtdbabZJKml0/img.png)
가장 기본적인 State를 참조할 수 있는 방법에 대해 알아보도록 하겠습니다. 먼저 특정 부모 위젯의 State를 참조하는 방법은 간단합니다. class ExampleWidget extends StatefulWidget { const ExampleWidget({super.key}); /// Context 중 제네닉 타입으로 정의된 State의 가장 가까운 부모 위젯을 반환합니다. static State? of(BuildContext context) { return context.findAncestorStateOfType(); } @override State createState() => ExampleWidgetState(); } Current의 State는 ExampleWidgetState 입니다. co..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/bRWNEH/btrXn5Rlvaq/KSZnKpQO1I55HWERnJ1YK0/img.png)
플러터를 개발하는데 있어서 빠질 수 없는게 바로 Listener 위젯입니다. (Gesture Recognizer를 구현하여 제스처를 커스텀해서 사용한다던가 자체 RawGestureDetector를 구현하는 경우가 아니라면 일반적인 상황에서 거의 사용되지 않습니다.) 해당 위젯은 사용자의 포인터를 인식하고 전달하는 역할을 하는 위젯입니다. 그렇다면 GestureDetector와 다른 점이 무엇일까요? GestureDetector는 단순히 Gesture Arena 또는 Gesture Disambiguation(제스쳐 명확화)(Tap인지 DoubleTap인지 LongPress인지를 일관성있게 정의하는 것을 말합니다)에 의해 제스쳐를 정의합니다. 이는 Gesture Recognizer(Tap, Double, L..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/dN2Blj/btsHtsBoVxP/brsnlGofgMlWcc4AWxvSIK/img.png)
Touch Slop은 사용자가 스크롤을 하려는 건지 클릭하려 하는 건지 가로로 스크롤 또는 세로로 스크롤 하려는 것인지 정확하게 판단하기 위해 특정 픽셀을 최소로 이동해야 하는 거리를 뜻합니다. 안드로이드의 Touch Slop은 8입니다.반면 플러터의 경우 18입니다.(해당 이유는 플러터의 경우 안드로이드와 다르게 스크롤 드레그라고 판단되고 그냥 손을 때면 스크롤 활동 (IdleScrollActivity가 아니라 BallisticScrollActivity)이 활성화된 상태에서도 포인터 추적을 그만두어 또 다시 사용자의 제스처를 판단해야되기 때문에 발생하는 현상인 것 같습니다. 단순히 Touch Slop을 높이므로서 사용자의 실수를 줄인 것 같으나 HoldScrollActivity라는 스크롤 활동이 존재하..
- Total
- Today
- Yesterday
- 디자인 패턴
- utility types
- 책임 연쇄
- Structural Pattern
- canvas animation
- 현재 오프셋
- Flutter
- animatable-js
- TypeScript
- 객체 지향
- touch slop
- web
- JavaScript
- 팩토리 메서드
- Factory Method
- 객체지향
- android
- 타입스크립트
- conditional types
- 추상 팩토리
- AutomaticKeepAliveClientMixin
- 안드로이드
- 최대 오프셋
- jetpack compose
- 문자열 템플릿
- npm package
- 안드로이드 개발
- js animation
- nested scrolling
- NestedScrollConnection
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 |