## 시작 전 주의사항

<notice>
 이 포스트에선 플러터 프로젝트를 생성하는 방법을 다뤄봅니다.
 따라서 플러터 SDK 설치나, 관련 환경설정이 안되신 분은 [**`플러터 시작하기`**](https://wjlee611.github.io/blog/flutter/001_installation)를 꼭 읽어보시고 다시 와주시기 바랍니다.
</notice>

<notice>
 본 블로그의 플러터 개발환경은 `VSCode`와 `터미널`로 고정됩니다.
 따라서 다른 개발환경에 대한 정보는 없으므로 이 점 참고 부탁드립니다.
</notice>

## 프로젝트 생성

프로젝트 생성을 위해 우선 본인이 프로젝트를 관리할 폴더로 이동해주세요.
제 경우에는 깃허브로 버전관리를 하는 프로젝트의 경우 `~/Documents/GitHub` 폴더에서 일괄적으로 관리하는 편입니다.

```bash:Terminal
cd ~/Documents/GitHub
```

이후에는 아래의 명령어로 플러터 프로젝트를 생성합니다.

```bash:Terminal
flutter create <proj_name>
```

이 때, 프로젝트를 생성할 때 알아두면 유용한 (거의 필수) 몇 가지 옵션을 소개드립니다.

### --org

이 옵션을 지정하면 프로젝트를 생성할 때 패키지명을 지정할 수 있습니다.

```bash:Terminal
flutter create <proj_name> --org <package_name>
```

<notice>
 \<package_name\>이 100% 동일하게 패키지 이름이 되는 것은 아닙니다.
 옵션명에서 유추할 수 있듯 기관의 이름을 적는 것입니다.

 따라서 진짜 패키지 이름은 `<package_name>.<proj_name>` 형식이 됩니다.
</notice>

예로들어 아래와 같이 프로젝트를 생성했다고 가정해봅시다.

![230914-164837](/posts/002_project_initalize/230914-164837.png)

이 경우에는 프로젝트명 - `gdsc_study` / 패키지명 - `com.gmail.wjlee611` 입니다.
따라서 프로젝트에서 실제로 적용되는 패키지명은 아래와 같아집니다.

![230914-165226](/posts/002_project_initalize/230914-165226.png)

> Android - `com.gmail.wjlee611.gdsc_study`
> iOS - `com.gmail.wjlee611.gdscStudy`

같은 명령어라도 다른 패키지명이 생성되니 나중에 앱을 배포할 때 반드시 패키지명을 확인하도록 합시다.

### -i swift

기본적으로 생성되는 iOS 코드는 `Objective-C` 입니다.
하지만 이 옵션을 추가하면 `Swift`로 생성되게 됩니다.

### -a kotlin

기본적으로 생성되는 Android 코드는 `Java` 입니다.
하지만 이 옵션을 추가하면 `Kotlin`으로 생성되게 됩니다.

플러터 프로젝트 생성 가이드 입니다.

플러터 프로젝트 만들기

<tip>
 이 포스트는 계속해서 업데이트 됩니다.
 유용한 댓글이나 경험을 남겨주시면 해당 내용도 추가하겠습니다!
</tip>

## Getting Started

[flutter_flavorizr](https://pub.dev/packages/flutter_flavorizr)의 사용방법에 대해 설명합니다.

### pubspec.yaml

해당 파일에서 하단에 `flavorizr` 필드를 작성합니다.

```yaml:pubspec.yaml {4, 18}
 # Flavor settings
 flavorizr:
 flavors:
 dev:
 app:
 name: "DEV APP_NAME"
 android:
 applicationId: "dev.package.name.app_name"
 # icon: "assets/app_icon.png"
 firebase:
 config: "android/firebase/dev/google-services.json"
 ios:
 bundleId: "dev.bundle.id.appName"
 # icon: "assets/app_icon.png"
 firebase:
 config: "ios/firebase/dev/GoogleService-Info.plist"

 prod:
 app:
 name: "APP_NAME"
 android:
 applicationId: "package.name.app_name"
 # icon: "assets/app_icon.png"
 firebase:
 config: "android/firebase/prod/google-services.json"
 ios:
 bundleId: "dev.bundle.id.appName"
 # icon: "assets/app_icon.png"
 firebase:
 config: "ios/firebase/prod/GoogleService-Info.plist"
```

위와 같은 경우에는 `dev`, `prod` 두 개의 flavor 환경을 구축하는 경우입니다.

다음은 아래에 추가로 필드를 기입하면 됩니다.
공통사항은 app, AOS 전용사항은 android, iOS 전용사항은 ios 아래에 기입하면 됩니다.

자세한 내용은 flavorizr의 공식 문서를 참고하시면 좋습니다.

### CLI

pubspec.yaml 작성을 완료했다면, 아래의 명령어를 사용하면 자동 빌드됩니다.

```bash:bash
 dart run flutter_flavorizr
```

빌드가 완료되면 아래의 파일들이 자동 생성 및 자동 수정될 것 입니다.

- main.dart
- **main_prod.dart**
 prod 빌드 환경에 맞는 초기 세팅을 진행하는 파일입니다.

 ```dart:main_prod.dart {1, 9}
 // Import from prod dependency
 import 'package:flutter/material.dart';

 import 'flavors.dart';

 import 'main.dart' as runner;

 Future<void> main() async {
 F.appFlavor = Flavor.prod;

 await runner.main();
 }
 ```

- **main_dev.dart**
 dev 빌드 환경에 맞는 초기 세팅을 진행하는 파일입니다.

 ```dart:main_dev.dart {1, 9}
 // Import from dev dependency
 import 'package:flutter/material.dart';

 import 'flavors.dart';

 import 'main.dart' as runner;

 Future<void> main() async {
 F.appFlavor = Flavor.dev;

 await runner.main();
 }
 ```

- **flavors.dart**
 flavor 관련 static field를 관리하는 클래스 파일입니다.

 ```dart:flavors.dart
 enum Flavor {
 dev,
 prod,
 }

 class F {
 static Flavor? appFlavor;

 static String get name => appFlavor?.name ?? '';

 static String get title {
 switch (appFlavor) {
 case Flavor.dev:
 return 'DEV APP_NAME';
 case Flavor.prod:
 return 'APP_NAME';
 default:
 return 'title';
 }
 }
 }
 ```

- pages/my_home_page.dart


### VSCode debug setting

디버깅 시 아래의 명령어를 사용해서 실행할 수 있습니다.

```bash:bash
 flutter run --flavor prod -t lib/main_prod.dart
 flutter run --flavor dev -t lib/main_dev.dart
```

하지만, VSCode의 디버깅 탭을 100% 활용하기 위해 추가 설정을 진행하면 좋습니다.

우선, 프로젝트 폴더에서 `.vscode` 폴더를 생성, 내부에 아래의 파일을 추가합니다.

```json:launch.json
 {
 "configurations": [
 {
 "name": "dev",
 "request": "launch",
 "type": "dart",
 "args": ["--flavor", "dev"],
 "program": "lib/main_dev.dart"
 },
 {
 "name": "prod",
 "request": "launch",
 "type": "dart",
 "args": ["--flavor", "prod"],
 "program": "lib/main_prod.dart"
 }
 ]
 }
```

이렇게 설정하면 명령어 없이 디버깅 탭에서 버튼을 통해 실행할 수 있습니다.

## Tips & Addon(?)

flavor를 사용할 때 추가로 구현하면 좋은 것들, 혹은 firebase와 같은 추가 설정이 필요한 부분에 대해 설명합니다.

### Config

flavor의 주된 사용 목적에는 prod, dev 에서의 API endpoint를 다르게 설정하는 등, 앱 내부에서 상수들을 별도로 관리하는데에 있을 것 입니다.
따라서 이러한 처리를 자동으로 하도록 Config 객체를 만들어 관리하는 방법에 대해 소개하겠습니다.

우선 코드 전문부터 보겠습니다.

```dart:config.dart {5, 8, 29}
 import 'package:child_goods_store_flutter/constants/networks.dart';
 import 'package:child_goods_store_flutter/flavors.dart';

 class Configs {
 // Add configs here
 final String baseUrl;

 // Initialize configs here
 Config._dev() : baseUrl = Networks.devBaseUrl;

 Config._prod() : baseUrl = Networks.baseUrl;

 factory Config(Flavor? flavor) {
 switch (flavor) {
 case Flavor.dev:
 _instance = Config._dev();
 break;
 case Flavor.prod:
 _instance = Config._prod();
 break;
 default:
 _instance = Config._dev();
 break;
 }
 return instance;
 }

 static Config? _instance;
 static Config get instance => _instance ?? Config(F.appFlavor ?? Flavor.dev);
 }
```

위 코드는 일단 Configs 싱글톤 객체를 생성하는 파일입니다.
그 과정에서 기본적으로 F(lavor) 클래스의 appFlavor static 필드를 생성자에 주입 받습니다.

즉, `Configs.instance` 를 호출하는 것 만으로토 현재 실행 환경의 flavor가 적용된 Configs 싱글톤 객체를 반환받을 수 있습니다.

여기에 추가로 본인이 원하는 필드(e.g. baseUrl)를 추가하고, 각 생성자에서 각 환경에 맞게 초기화 해주시면 됩니다.

그럼 앞으로 `Configs.instance.baseUrl`를 사용하는 것 만으로도 빌드 환경에 따라 다른 값이 알아서 적용되게 됩니다.

### Firebase

firebase의 `google-services.json`이나, `GoogleService-Info.plist`를 빌드 환경에 맞게 알아서 처리하는 방법도 알아봅시다.

<tip>
 firebase 프로젝트 및 service 파일을 빌드 환경에 맞게 분리하면 좋은게,
 가끔 Test 라며 푸쉬 알림이 실 사용자에게 전송되는 일을 예방할 수 있기 때문입니다.
</tip>

우선 firebase 프로젝트를 생성합니다.
자세한 생성 방법 및 flutterfire CLI 설치 방법은 생략합니다.

다음은 프로젝트 폴더에서 아래의 CLI 명령어를 실행하여 firebase 프로젝트에 flutter 앱을 추가해줍니다.

```bash:bash
 flutterfire config \ 
 --project=firebase_project_name \
 --ios-bundle-id=bundle.id.appName \
 --android-package-name=package.name.app_name
```

위 명령어는 firebase_project_name firebase 프로젝트에 prod 빌드 환경의 앱을 추가하는 명령어 입니다.

1. 만약 **같은** firebase 프로젝트에 dev 빌드 환경의 앱을 추가하려면 아래의 명령어를 입력하면 됩니다.

 ```bash:bash {3-4}
 flutterfire config \ 
 --project=firebase_project_name \
 --ios-bundle-id=dev.bundle.id.appName \
 --android-package-name=dev.package.name.app_name
 ```

 <notice>
 2번째 부터 `ios/firebase_app_id_file.json` 파일이 중복된다는 경고가 나오는데,
 이는 개발환경에 무관하게 동일한 파일이기 때문에 override 해도 상관 없습니다.
 </notice>

2. 만약 **다른** firebase 프로젝트에 dev 빌드 환경의 앱을 추가하려면 아래의 명령어를 입력하면 됩니다.

 ```bash:bash {2}
 flutterfire config \ 
 --project=dev_firebase_project_name \
 --ios-bundle-id=dev.bundle.id.appName \
 --android-package-name=dev.package.name.app_name
 ```

성공적으로 추가 되었다면, 자동으로 생성되는 `google-services.json`이나, `GoogleService-Info.plist`는 일단 제거해줍니다.

여기까지 성공했다면 firebase 프로젝트에 4개의 앱이 추가되었을 것입니다.
(AOS prod, dev / iOS prod, dev)

![240302-233903](/posts/flavorizr/240302-233903.png)

이제 `google-services.json`, `GoogleService-Info.plist` 파일을 다운로드 받아 `pubspec.yaml` 파일에 적힌 경로에 각각 다운로드 합니다.

```yaml:pubspec.yaml {11, 16, 25, 30}
 # Flavor settings
 flavorizr:
 flavors:
 dev:
 app:
 name: "DEV APP_NAME"
 android:
 applicationId: "dev.package.name.app_name"
 # icon: "assets/app_icon.png"
 firebase:
 config: "android/firebase/dev/google-services.json"
 ios:
 bundleId: "dev.bundle.id.appName"
 # icon: "assets/app_icon.png"
 firebase:
 config: "ios/firebase/dev/GoogleService-Info.plist"

 prod:
 app:
 name: "APP_NAME"
 android:
 applicationId: "package.name.app_name"
 # icon: "assets/app_icon.png"
 firebase:
 config: "android/firebase/prod/google-services.json"
 ios:
 bundleId: "dev.bundle.id.appName"
 # icon: "assets/app_icon.png"
 firebase:
 config: "ios/firebase/prod/GoogleService-Info.plist"
```

해당 경로는 본인 프로젝트의 파일 관리 정책에 맞게 알아서 설정해주시면 됩니다.

그리고 다시 아래의 명령어를 실행하면 알아서 firebase 환경 설정이 완료됩니다.

```bash:bash
 dart run flutter_flavorizr
```

<notice>
 반드시 관련 파일은 .gitignore에 추가하여 보안에 유의합시다.

 ```md:.gitignore
 # Secret - Common
 lib/configs/firebase_options.dart
 lib/configs/firebase_options_dev.dart
 # Secret - Android
 android/firebase
 android/app/src/prod/google-services.json
 android/app/src/dev/google-services.json
 # Secret - iOS
 ios/firebase
 ios/firebase_app_id_file.json
 ios/Runner/prod/GoogleService-Info.plist
 ios/Runner/dev/GoogleService-Info.plist
 # Secret - iOS auto generated
 ios/Runner/GoogleService-Info.plist
 ```
</notice>

마지막으로 `main_prod.dart`, `main_dev.dart`에 초기화 설정을 해주면 끝입니다.

```dart:main_prod.dart {1, 2}
 // Import from prod dependency
 import 'package:child_goods_store_flutter/configs/firebase_options.dart';
 import 'package:firebase_core/firebase_core.dart';
 import 'package:flutter/material.dart';

 import 'flavors.dart';

 import 'main.dart' as runner;

 Future<void> main() async {
 F.appFlavor = Flavor.prod;

 WidgetsFlutterBinding.ensureInitialized();

 await Firebase.initializeApp(
 options: DefaultFirebaseOptions.currentPlatform,
 );

 await runner.main();
 }
```

```dart:main_dev.dart {1, 2}
 // Import from dev dependency
 import 'package:child_goods_store_flutter/configs/firebase_options_dev.dart';
 import 'package:firebase_core/firebase_core.dart';
 import 'package:flutter/material.dart';

 import 'flavors.dart';

 import 'main.dart' as runner;

 Future<void> main() async {
 F.appFlavor = Flavor.dev;

 WidgetsFlutterBinding.ensureInitialized();

 await Firebase.initializeApp(
 options: DefaultFirebaseOptions.currentPlatform,
 );

 await runner.main();
 }
```

(자세히 보면 firebase_options.dart 파일의 import 경로가 다릅니다)

## TroubleShoots

글쓴이가 실제로 해보며 겪은 문제와 그에 대한 해결법에 대해 정리해봤습니다.

### Unable to load contents of file list

글쓴이는 아래와 같은 에러를 본 적이 있습니다.

> Error (Xcode): Unable to load contents of file list: '/Target Support Files/Pods-Runner/Pods-Runner-frameworks-Debug-dev-input-files.xcfilelist'
>
> Error (Xcode): Unable to load contents of file list: '/Target Support Files/Pods-Runner/Pods-Runner-frameworks-Debug-dev-output-files.xcfilelist'

해당 에러는 특정 파일이 존재하지 않을 때 발생하는 에러로, flavorizr 생성 CLI 명렁어를 실행했음에도 생성되지 않는 경우가 종종 있었습니다.
그럴 경우에는 아래의 스탭을 천천히 밟아가면 대부분 해결될 것입니다.

1. ios &rarr; Xcode로 열기 &rarr; 상단 상태바에서 Product &rarr; Clean Build Folder

 ![240302-235526](/posts/flavorizr/240302-235526.png)

2. 아래 명령어로 pod 업데이트, depencency 초기화 및 재설치

 ```bash:bash
 cd ios/
 sudo gem update cocoapods --pre
 pod update
 pod repo update
 pod deintegrate
 pod install
 ```

3. flavorizr 명령어 재실행

 ```bash:bash
 dart run flutter_flavorizr
 ```

4. ios &rarr; Xcode로 열기 &rarr; Runner(PROJECT) &rarr; Info &rarr; Configurations 의 파일이 잘 설정되어있는지 확인

 ![240303-000448](/posts/flavorizr/240303-000448.png)

5. 아래의 파일의 include가 아래와 같이 작성되어있는지 확인

 ```c:ios/Flutter/Debug.xcconfig
 #include? "Pods/Target Support Files/Pods-Runner/Pods-Runner.debug.xcconfig"
 #include "Generated.xcconfig"
 ```

 ```c:ios/Flutter/Release.xcconfig
 #include? "Pods/Target Support Files/Pods-Runner/Pods-Runner.release.xcconfig"
 #include "Generated.xcconfig"
 ```

### FirebaseCommandException

글쓴이는 아래와 같은 에러를 본 적이 있습니다.

> FirebaseCommandException: An error occured on the Firebase CLI when attempting to run a command.
> COMMAND: firebase apps:create ios child_goods_store_flutter (ios) --bundle-id=dev.io.github.u3C1S.child_goods_store_flutter --json --project=child-goods-store 
> ERROR: Failed to create iOS app for project child-goods-store. See firebase-debug.log for more info.

이 경우에는 iOS bundleId가 snake_case로 작성되어서 발생한 문제였습니다.

**반드시, iOS bundleId는 camelCase로 작성**하도록 합시다.

빌드 환경을 분리를 위한 flutter_flavorizr의 거의 모든 것

flavorizr

<notice>
 Flutter Color의 `lerp()` 와 연결되는 내용은 **아닙니다**.
 (이론적인 부분은 일맥상통 하지만, 정확히는 애니메이션에 대한 포스트 입니다)
</notice>

우선 시작하기에 앞서 [**`gyro_provider`**](https://pub.dev/packages/gyro_provider) 플러그인을 소개합니다~
저의 첫 라이브러리이자, pub.dev 데뷔 작품(?)입니다 ㅎㅎ

![gyro_provider_demo](/posts/lerp/gyro_provider_demo.gif)

모바일 기기의 자이로스코프 센서를 이용해서 위젯을 변형시키거나, 센서 값을 제공하는 라이브러리 입니다.
이번 포스트는 이 플러그인을 개발하며 배웠던 내용을 소개 하겠습니다.

## 문제 인지

Flutter Animation은 AnimationController가 지정한 시간(Duration)동안 동작합니다.

```dart:.dart
_animationController = AnimationController(
 vsync: this,
 duration: Duration(seconds: 1),
)
```

그리고 Animation은 AnimationController에 의해 변화되는 값을 보관하고 있죠.

```dart:.dart
_xAnimation = Tween<double>(
 begin: 0,
 end: _xTarget,
).animate(_animationController);
```

예로 들어 AnimationController의 값이 **0**에서 **1**로 _1초 동안_ 변할 동안 _xAnimation의 값은 **0**에서 **_xTarget**까지 _1초 동안_ 변화하는 것이죠.
즉, AnimationController에 의해 Animation의 값이 **선형 보간**되는 것입니다.

만약 _xTarget의 값이 도중에 변한다면 어떻게 될까요?

### 문제 발생

여기서 문제가 발생합니다.

애니메이션은 새로운 _xTarget 값을 향해 바뀌는 것이 아닌, 바뀌기 전의 _xTarget값을 향해 선형 보간될 것입니다.

---

## Lerp

바뀐 후의 _xTarget값을 향하여 선형 보간을 하기 위해서는 AnimatedContainer를 리셋시키고 Animation을 재정의 해야 합니다.

```dart:.dart
_animationController.reset();

_xAnimation = Tween<double>(
 begin: 0,
 end: _xTarget, // new value
).animate(_animationController);

_animationController.forward();
```

하지만 이런식으로 코드를 짠다면 문제가 발생하겠죠.
시작점(begin)이 0으로 초기화 되기 때문입니다.

따라서 begin의 값은 AnimationController를 초기화 하기 직전의 Animation의 값을 가지고 있어야 할 것 입니다.

```dart:.dart
var currX = _animation.value;

_animationController.reset();

_xAnimation = Tween<double>(
 begin: currX,
 end: _xTarget, // new value
).animate(_animationController);

_animationController.forward();
```

위와 같이 코드를 수정한다면, _xTarget가 변경되었을 때, 위 코드를 실행하면 
진행되던 애니메이션이 이어서 부드럽게 새로운 애니메이션이 되어 새로운 _xTarget를 향하여 진행할 것입니다.

### 장점

AnimatedContainer의 Duration보다 짧은 시간안에 _xTarget 값이 변하더라도 애니메이션을 부드럽게 진행시킬 수 있습니다.

즉, _xTarget이 변할 때마다 새로운 선형 보간을 적용할 수 있게 되는 것입니다.

### 단점

AnimatedContainer의 Duration이 길수록 _'뭔가 늦게 반응한다'_ 라는 느낌을 받으실 수 있습니다.

그렇다고 Duration을 _xTarget이 변화하는 주기보다 짧게 설정할 경우에는 애니메이션 중간마다 끊기는 느낌을 받을 수 있습니다.

---

## 코드 리뷰

그럼 선형 보간과 관련한 [**`gyro_provider`**](https://pub.dev/packages/gyro_provider)의 코드를 리뷰해보며 이해를 굳혀봅시다.

### forward

우선 애니메이션이 진행 중입니다.

```dart:gyro_provider.dart {30}
 @override
 void initState() {
 super.initState();
 ...
 // Initialize animation
 _animationController = AnimationController(
 vsync: this,
 duration: widget.animationDuration,
 )
 ..addListener(_animationListener)
 ..addStatusListener(_animationStatusListener);

 _linearCurve = CurvedAnimation(
 parent: _animationController,
 curve: Curves.linear,
 );
 _easeCurve = CurvedAnimation(
 parent: _animationController,
 curve: Curves.easeOut,
 );

 _xAnimation = Tween<double>(
 begin: 0,
 end: _xTarget,
 ).animate(_linearCurve);
 _yAnimation = Tween<double>(
 begin: 0,
 end: _yTarget,
 ).animate(_linearCurve);
 _animationController.forward();
 }
```

0에서 _xTarget 으로 이동 중이겠죠.

### change target

그러다 _xTarget의 값이 변화합니다.

```dart:gyro_provider.dart {12}
 void _gyroListener() {
 var value = _gyroscopeController.value;
 _gyroData.value = value;
 widget.gyroscope?.call(value);

 if (value.x.abs() < 0.1 && value.y.abs() < 0.1 && !widget.centerLock) {
 ...
 }
 // Change the target rotation angle by the amount the sensor value changes
 // and animate toward that value.
 else {
 _xTarget += value.x;
 _yTarget += value.y;
 }
 // The animation only changes when the widget is not being moved to the center.
 if (!_onCenter) {
 _animation(curve: _linearCurve);
 }
 }
```

하지만, 현재 AnimatedContainer가 변형시키는 Animation의 _xTarget 값은 변화하지 않았습니다.

### reset

따라서 애니메이션을 중지시키고 재설정을 합니다.
하지만, 중지 시키기 전에 현재까지 변화한 Animation의 값을 보관합니다.

```dart:gyro_provider.dart {4, 6}
 void _animation({required CurvedAnimation curve}) {
 if (!mounted) return;

 var xCurr = _xAnimation.value;
 var yCurr = _yAnimation.value;
 _animationController.reset();
 _xAnimation = Tween<double>(
 begin: xCurr,
 end: _xTarget,
 ).animate(curve);
 _yAnimation = Tween<double>(
 begin: yCurr,
 end: _yTarget,
 ).animate(curve);
 _animationController.forward();
 }
```

### (re)forward

그리고 다시 애니메이션을 동작 시킵니다.

```dart:gyro_provider.dart {8, 15}
 void _animation({required CurvedAnimation curve}) {
 if (!mounted) return;

 var xCurr = _xAnimation.value;
 var yCurr = _yAnimation.value;
 _animationController.reset();
 _xAnimation = Tween<double>(
 begin: xCurr,
 end: _xTarget,
 ).animate(curve);
 _yAnimation = Tween<double>(
 begin: yCurr,
 end: _yTarget,
 ).animate(curve);
 _animationController.forward();
 }
```

---

## 마무리

코드 전문은 오픈소스로 공개된 [**`gyro_provider`**](https://pub.dev/packages/gyro_provider) 레포에서 확인하실 수 있습니다.

Flutter Animation에 대해 잘 모르는 상태로 플러그인 개발 프로젝트를 시작했는데,
무작정 시도하긴 했지만, 배워가는 점도 많았던거 같습니다. 
(적어도 AnimationController, Animation은 나름 자유자재로 사용할 수 있게 되었다는 거?)

사실 네이티브 코드에서 센서의 인터벌(interval)을 매우 빠르게 설정하면(초당 60 이상) 애니메이션을 구현할 필요도 없을 것입니다.

하지만, 초당 60번의 통신은 성능 저하의 원인이 될 수 있다는 생각이 들었고,
기기 사양이 안좋은 경우에는 초당 60회의 통신이 불가능할 수도 있을지도 몰랐기에 이런 방식으로 구현했습니다.
(초당 10~15회 통신, 기기 주사율에 맞도록 사이의 값은 애니메이션을 이용해 lerp(선형 보간))
~_이 부분을 문제 인지에 적는게 나았을지도.._~

사실 신경 쓸 필요도 없을지도 모르지만, 이런 고민 덕분에 새로운 시도를 할 수 있게 되어 오히려 좋았던 거 같습니다.

애니메이션을 이용해서 선형 보간(Linear Interpolation)를 쉽게 구현해봅시다.

Lerp (애니메이션 선형 보간)

Flutter로 개발하다보면 TabController, AnimationController와 같은 Controller에 `vsync: this` 를 반드시 종속성 주입해야 하는 경우가 있습니다.
이럴 때 마다 TickerProviderStateMixin 을 상속받아 사용해서 this를 사용할 수 있게 되는데, 이게 항상 궁금했었죠...

그러다, Flutter 애니메이션을 공부하다 그 이유를 알게되었고, 그 내용을 정리해보고자 합니다.

## Ticker

우선 Ticker에 대해 알아야 합니다.

Ticker는 매 프레임마다 함수를 호출하는 역할을 수행하는데, 아래의 코드를 살펴봅시다.

```dart:stateful_widget.dart {7}
late final Ticker _ticker;

@override
void initState() {
 super.initState();
 _ticker = Ticker(
 (elapsed) => print(elapsed);
 );
 _ticker.start();
}

@override
void dispose() {
 _ticker.dispose();
 super.dispose();
}
```

이렇게 하면, 이 위젯이 위젯트리에 올라가서 상태가 컨텍스트에 등록되는 순간부터 매 프레임마다 elapsed가 찍히게 됩니다. (대략 60fps)
만약, `_ticker.dispose()` 를 호출하지 않는다면, 위젯트리에서 내려가도 Ticker가 계속 함수를 매 프레임마다 호출하게 될 겁니다.

정리하자면, 매 프레임마다 함수를 호출하게 해주는 클래스가 Ticker 입니다.
하지만, 왜 Ticker를 사용하는 걸까요?

바로 **부드러운 화면 모션** 때문입니다.
매 프레임마다 함수를 실행한다는 것은, 매 프레임마다 화면을 업데이트 시킬 수도 있다는 뜻입니다.
자원을 많이 잡아먹긴 하겠지만, 최적화만 잘 한다면, 부드러운 애니메이션을 보여줄 수 있겠죠!

### TickerProvider

이제, Ticker가 뭔지, 왜 사용하는지를 알았습니다.
하지만, 강력한 기능을 가진 만큼, 취급에 주의해야 하겠죠...
생성하고, 함수를 등록하고, 반드시 dispose 해야하는...

이런 과정을 개발자에게 맡겼다간 반드시 실수가 발생할 것입니다.
따라서 Ticker의 사용을 은닉화 하기위해 우선 Ticker을 생성하는 인터페이스(정확히는 abstract class)가 제공되는데, 이게 바로 TickerProvider 입니다.

```dart:ticker.dart
abstract class TickerProvider {
 /// Abstract const constructor. This constructor enables subclasses to provide
 /// const constructors so that they can be used in const expressions.
 const TickerProvider();

 /// Creates a ticker with the given callback.
 ///
 /// The kind of ticker provided depends on the kind of ticker provider.
 @factory
 Ticker createTicker(TickerCallback onTick);
}

```

이 클래스를 상속받은 클래스는 반드시 createTicker 구현해서 사용해야 하며, 이름에서 알 수 있듯 이 함수는 Ticker를 반환하게 됩니다.

예로 들어, TickerProvider의 구현체 중 하나인 SingleTickerProviderStateMixin의 내부를 살펴보겠습니다.

```dart:ticker_provider.dart {5}
mixin SingleTickerProviderStateMixin<T extends StatefulWidget> on State<T> implements TickerProvider {
 Ticker? _ticker;

 @override
 Ticker createTicker(TickerCallback onTick) {
 _ticker = Ticker(onTick, debugLabel: kDebugMode ? 'created by ${describeIdentity(this)}' : null);
 _updateTickerModeNotifier();
 _updateTicker(); // Sets _ticker.mute correctly.
 return _ticker!;
 }

 @override
 void dispose() {
 _tickerModeNotifier?.removeListener(_updateTicker);
 _tickerModeNotifier = null;
 super.dispose();
 }
}
```

간단하게만 보면 해당 mixin에서 Ticker 생성과 삭제에 필요한 모든 기능을 수행한다고 볼 수 있습니다.

<tip>
 필요한 모든 기능 중, 가장 중요한 기능은 `자원 관리` 라고 생각됩니다.
 실제로 설명의 최상단에도 언급되어 있습니다.
 > Provides a single [Ticker] that is configured to only tick while the current tree is enabled, as defined by [TickerMode].

 즉, 사용을 강제하는 주된 이유는 위젯이 위젯 트리에 등록된 상태에서만 Ticker를 제공함으로서 자원을 효율적으로 실수 없이 관리하기 위함이라고 생각됩니다.
</tip>

### Controller

생성했으면 이를 사용해야겠죠?
이 때, vsync 가 사용됩니다.

```dart:animation_controller.dart {12, 15}
class AnimationController extends Animation<double>
 with AnimationEagerListenerMixin, AnimationLocalListenersMixin, AnimationLocalStatusListenersMixin {

 AnimationController({
 double? value,
 this.duration,
 this.reverseDuration,
 this.debugLabel,
 this.lowerBound = 0.0,
 this.upperBound = 1.0,
 this.animationBehavior = AnimationBehavior.normal,
 required TickerProvider vsync,
 }) : assert(upperBound >= lowerBound),
 _direction = _AnimationDirection.forward {
 _ticker = vsync.createTicker(_tick);
 _internalSetValue(value ?? lowerBound);
 }
}
```

vsync는 TickerProvider를 인자로 받게 되는데, TickerProviderStateMixin을 상속받은 클래스(위젯)에서 `vsync: this` 를 다형성의 원리에 의해 종속성 주입하면 해당 클래스(위젯)의 createTicker 함수를 호출할 수 있게 되는 것입니다.

즉, Controller는 부드러운 애니메이션을 위해 Ticker를 사용해야 하는데, 개발자에게 이를 맡겼다간 실수가 발생할 수도 있고, 기타 여러 이유 때문에 TickerProvider 로부터 ticker를 받도록 구현되었고, 그 과정에서 vsync로 종속성을 주입받게 되었다고 정리해볼 수 있겠습니다.

---

## Animation 엿보기

정리하는 차원에서 `_animationController.forward()` 의 과정을 추적해봅시다.

```dart:animation_controller.dart
TickerFuture forward({ double? from }) {
 _direction = _AnimationDirection.forward;
 if (from != null) {
 value = from;
 }
 return _animateToInternal(upperBound);
}
```

애니메이션의 방향(_direction)을 설정하고 `_animateToInternal` 함수를 실행합니다.

```dart:animation_controller.dart
TickerFuture _animateToInternal(double target, { Duration? duration, Curve curve = Curves.linear }) {
 double scale = 1.0;
 if (SemanticsBinding.instance.disableAnimations) {
 switch (animationBehavior) {
 case AnimationBehavior.normal:
 scale = 0.05;
 case AnimationBehavior.preserve:
 break;
 }
 }
 Duration? simulationDuration = duration;
 if (simulationDuration == null) {
 final double range = upperBound - lowerBound;
 final double remainingFraction = range.isFinite ? (target - _value).abs() / range : 1.0;
 final Duration directionDuration =
 (_direction == _AnimationDirection.reverse && reverseDuration != null)
 ? reverseDuration!
 : this.duration!;
 simulationDuration = directionDuration * remainingFraction;
 } else if (target == value) {
 simulationDuration = Duration.zero;
 }
 stop();
 if (simulationDuration == Duration.zero) {
 if (value != target) {
 _value = clampDouble(target, lowerBound, upperBound);
 notifyListeners();
 }
 _status = (_direction == _AnimationDirection.forward) ?
 AnimationStatus.completed :
 AnimationStatus.dismissed;
 _checkStatusChanged();
 return TickerFuture.complete();
 }
 return _startSimulation(_InterpolationSimulation(_value, target, simulationDuration, curve, scale));
}
```

`_startSimulation` 실행에 필요한 값들을 연산하고, 기존에 실행 중이던 애니메이션을 stop 하는 것으로 보입니다.
이 후, `_startSimulation` 함수를 실행합니다.

```dart:animation_controller.dart {5}
TickerFuture _startSimulation(Simulation simulation) {
 _simulation = simulation;
 _lastElapsedDuration = Duration.zero;
 _value = clampDouble(simulation.x(0.0), lowerBound, upperBound);
 final TickerFuture result = _ticker!.start();
 _status = (_direction == _AnimationDirection.forward) ?
 AnimationStatus.forward :
 AnimationStatus.reverse;
 _checkStatusChanged();
 return result;
}
```

초기 값을 설정하고 _ticker를 시작하는 모습입니다.
참고로 위 코드를 보면 아시겠지만, _ticker는 `_tick` 함수를 매 프레임마다 호출하게 됩니다.
따라서 `_tick` 함수도 살펴봅시다.

```dart:animation_controller.dart
void _tick(Duration elapsed) {
 _lastElapsedDuration = elapsed;
 final double elapsedInSeconds = elapsed.inMicroseconds.toDouble() / Duration.microsecondsPerSecond;
 _value = clampDouble(_simulation!.x(elapsedInSeconds), lowerBound, upperBound);
 if (_simulation!.isDone(elapsedInSeconds)) {
 _status = (_direction == _AnimationDirection.forward) ?
 AnimationStatus.completed :
 AnimationStatus.dismissed;
 stop(canceled: false);
 }
 notifyListeners();
 _checkStatusChanged();
}
```

매 프레임마다 _value값이 업데이트 되고, notifyListeners를 통해 화면을 업데이트 하는 모양새입니다.

Ticker와 TickerProvider mixin에 대해 알아봅니다.

Ticker

기존 JsonSerializable로 아래와 같은 응답을 모델링 하였습니다.

```json:json
{
 'code': 1000,
 'message': '성공',
 'data': { ... }
}
```

이런 식으로, code, message(선택) 가 반드시 포함된 응답이 오는 상황이어서
code, message를 갖고있는 ResModel,
그리고 ResModel을 상속받아 만든 DataModel 이런식으로 구현하였습니다.

하지만, JsonSerializable로 구현했던 모델들을 Freezed로 마이그레이션 하는 과정에서 문제가 발생했습니다.
바로, Freezed는 상속이 불가능하다는 점..!

그래서 해결책을 몰색하던 중 ResModel에 제네릭 타입의 data 멤버를 추가하면 어떤가 하는 조언을 받았습니다.

좋은 해결책인거 같기도 하고, 마침 Freezed에 대해 딥하게 알아보고 공부할 겸 이 해결책을 적용해보기로 하였습니다.

## 구현

### DataModel

우선 Data에 해당하는 객체를 모델링 하였습니다.

```dart:diary_model.dart
part 'diary_model.freezed.dart';
part 'diary_model.g.dart';

@freezed
class DiaryModel with _$DiaryModel {
 factory DiaryModel({
 @JsonKey(name: 'diaryid') int? id,
 @JsonKey(name: 'dcontent') String? content,
 @JsonKey(name: 'dtime') DateTime? time,
 @JsonKey(name: 'dtag') EEmotion? emotion,
 @JsonKey(name: 'userid') int? userId,
 @JsonKey(
 name: 'openable',
 fromJson: openableFromJson,
 toJson: openableToJson,
 )
 bool? isOpen,
 }) = _DiaryModel;

 factory DiaryModel.fromJson(Map<String, dynamic> json) =>
 _$DiaryModelFromJson(json);
}
```

`@JsonKey` 어노테이션을 통해 API에서 전달하는 key와 모델링의 변수명을 변환했습니다.
또한, openable key의 value가 0 or 1 로 표현하는 bool 형식이라
0 &rarr; false, 1 &rarr; true 로 변환하는 함수(openableFromJson/ToJson)를 적용하였습니다.

### ResModel

그 다음 공통 응답 모델을 맡을 ResModel을 제네릭으로 모델링합니다.

```dart:res_model.dart
part 'res_model.freezed.dart';
part 'res_model.g.dart';

@Freezed(genericArgumentFactories: true)
class ResModel<T> with _$ResModel<T> {
 factory ResModel({
 required int code,
 String? message,
 T? data,
 }) = _ResModel;

 factory ResModel.fromJson(
 Map<String, dynamic> json,
 T Function(dynamic json) fromJsonT,
 ) =>
 _$ResModelFromJson<T>(json, fromJsonT);
}
```

여기서 눈여겨 봐야 할 점은 fromJson의 인자로 fromJsonT 함수를 전달한다는 것입니다.

보통은 fromJson에 json 만 인자로 넘기는데, 제네릭을 포함하는 경우 문제가 발생합니다.
바로 제네릭에 해당하는 객체의 직렬화, 역직렬화 로직을 프로그램은 모른다는 것이죠.

따라서 해당 로직을 대신 수행할 fromJsonT 함수를 인자로 추가로 받는 것입니다.
(toJsonT는 freezed에 의해 자동 생성되며, 마찬가지로 toJsonT를 인자로 받습니다.)

이를 build_runner가 알도록 하기 위해 **@freezed** 어노테이션 대신 **@Freezed** 를 사용하며,
`genericArgumentFactories`을 true로 설정합니다.

### fromJson / toJson

이제 실제로 사용도 해봐야겠죠?

```dart:diray_repository.dart
var resModel = ResModel<DiaryModel>.fromJson(
 res.data,
 (json) => DiaryModel.fromJson(json),
);
```

첫 번째 인자로 API의 응답으로 온 json 이 들어갑니다.
두 번째 인자로는 제네릭 타입의 역직렬화를 수행하는 함수가 들어가는데, 제네릭이 DiaryModel 이므로, DiaryModel.fromJson를 넣어주면 됩니다.
(참고로 파라미터로 전달되는 json 인자에는 data의 value가 전달됩니다.)

toJson도 살펴봅시다.

```dart:diray_repository.dart
var reqJson = resModel.toJson(
 (model) => DiaryModel.fromJson(model),
);
```

인자로는 제네릭 타입의 직렬화를 수행하는 함수가 들어가는데, 제네릭이 DiaryModel 이므로, DiaryModel.toJson를 넣어주면 됩니다.
(참고로 파라미터로 전달되는 model 인자에는 diaryModel의 인스턴스가 전달됩니다.)

### 결과물

data가 없는 경우, 또는 필요 없는 경우에는 아래와 같이 fromJson을 사용할 수 있습니다.

```dart:auth_interceptor.dart
var res = ResModel.fromJson(response.data, (json) => null);
if (res.code == 2000) {
 AuthBlocSingleton.bloc.add(AuthSignoutEvent());
}
...
```

또한, data가 있는 경우, 또는 필요한 경우에는 아래와 같이 fromJson을 사용할 수 있습니다.

```dart:diray_repository.dart
Dio dio = Dio();
dio.interceptors.add(AuthInterceptor());
var res = await dio.get(
 '/diary',
 queryParameters: {
 'emotion': emotion.key,
 },
 data: {
 'page': page,
 },
);

var resModel = ResModel<DiaryModel>.fromJson(
 res.data,
 (json) => DiaryModel.fromJson(json),
);
```

코드의 재사용성을 최대로 하고, 로직간의 의존성을 최소화 하도록 구현해본 유익한 시간이었습니다 ㅎㅎ.

API 응답 모델링에서 사용하면 좋은 Freezed 제네릭 테크닉에 대해 소개합니다.

Freezed에서 제네릭 사용하기

보통 Bloc은 BlocProvider로 context(위젯트리)에서 관리하고, `context.read<Bloc>()` 형태로 읽어오죠?
하지만, 이 경우 문제가, context 밖에서는 Bloc에 접근할 방법이 없다는 것입니다.

제 경우에는, dio interceptor에서 Bloc에 접근하고 싶은 상황이었죠..

이런 상황, 혹은 앱 실행시간동안 계속 필요한 Bloc의 경우 Singleton Pattern을 이용하여 관리하는 유용한 방법에 대해 설명하려 합니다.

## BlocBuilder

우선 BlocBuilder, Listern의 bloc 파라미터를 먼저 살펴봅시다.
보통은 bloc 파라미터를 null값으로 놔두고 사용합니다.

하지만, 아래의 bloc 소스 코드를 살펴보겠습니다.

```dart:bloc_builder.dart {9}
class _BlocBuilderBaseState, S>
 extends State<BlocBuilderBase<B, S>> {
 late B _bloc;
 late S _state;

 @override
 void initState() {
 super.initState();
 _bloc = widget.bloc ?? context.read();
 _state = _bloc.state;
 }
 ...
}
```

보이는 바와 같이, bloc이 null값이면 context에서, notnull이면 bloc 에서 bloc을 가져오는 방식으로 작동합니다.

즉, context에서 bloc에 접근할 수 없는 경우에는 bloc 파라미터에 bloc을 직접 주입시키면 되는 것입니다.
이를 응용해서 코드 어디에서나 Singleton Pattern을 통해서 bloc에 접근하는 방법을 사용해 볼 수 있겠습니다.

## 구현

### Singleton

우선, context 외부에서 관리할 Bloc의 인스턴스를 보관할 Singleton 객체를 하나 만들어줍니다.

```dart
class AuthBlocSingleton {
 AuthBlocSingleton._constructor();
 static final AuthBlocSingleton _signleton = AuthBlocSingleton._constructor();
 static AuthBlocSingleton get instance => _signleton;

 static late final AuthBloc _bloc;
 static AuthBloc get bloc => _bloc;

 static initializer({required AuthenticationRepository repository}) {
 _bloc = AuthBloc(authenticationRepository: repository);
 }
}
```

이렇게하면, AuthBlocSingleton.bloc 으로 코드 전역에서 접근할 수 있습니다.
(물론 사용하기 전에 initializer 메서드를 호출해야만 합니다)

### Initialized

그리고, bloc에 종속성을 주입해야 하는 경우, 사용하기 전에 주입하도록 합시다.

```dart:app_routes.dart

class _AppRoutesState extends State<AppRoutes> {
 late GoRouter _routerConfig;

 @override
 void initState() {
 super.initState();

 // Initialize AuthBloc
 AuthBlocSingleton.initializer(
 repository: context.read<AuthenticationRepository>(),
 );
 ...
 }
 ...
}
```

제 경우에는 repository를 context에 주입하여 사용하고 있기 때문에, context에 접근 가능한 최상위 위젯에서 bloc에 주입시켜 초기화를 진행하였습니다.

### 결과물

이제 BlocBuilder, Listener는 아래와 같이 코드 한 줄만 추가하면 됩니다.

```dart {2}
BlocBuilder<AuthBloc, AuthState>(
 bloc: AuthBlocSingleton.bloc,
 builder: (context, state) {
 ...
```

이렇게 하면, BlocProvider로 Bloc을 생성하지 않고도 Bloc을 사용할 수 있습니다.
아래와 같은 장점도 챙길 수 있죠!
1. 위젯트리가 가벼워진다.
2. 싱글톤으로 코드 어디서나 Bloc에 접근할 수 있다. (state, add() 모두 가능)

따라서 dio의 interceptor 클래스에서 아래와 같은 코드로 가능해집니다.

```dart:auth_interceptor.dart {17}
class AuthInterceptor extends Interceptor {
 ...
 @override
 void onResponse(
 Response response,
 ResponseInterceptorHandler handler,
 ) async {
 // Logging
 debugPrint(
 '[RES] [${response.requestOptions.method}] ${response.requestOptions.uri}',
 );

 // Error handling
 var res = ResModel.fromJson(response.data, (json) => null);
 if (res.code != 1000) {
 if (res.code == 2000) {
 AuthBlocSingleton.bloc.add(AuthSignoutEvent());
 }
 handler.reject(
 DioException.connectionError(
 requestOptions: response.requestOptions,
 reason: res.message ?? Strings.unknownFail,
 error: res,
 ),
 );
 return;
 }

 handler.next(response);
 }
 ...
}
```

api 응답 중 jwt관련 인증 문제가 발생하는 경우, 자동으로 로그아웃 하는 로직도 이런식으로 구현할 수 있습니다.

BuildContext 없이 BLoC에 접근하고, listen 하는 방법을 알아봅니다.

BLoC, context 외부에서 관리하기

FCM을 구현하는데 있어, FCM 세팅이나 수신하는 방법에 대한 글은 많이 봤는데,
이를 상태관리와 엮어서 소개하는 글은 못봤던거 같습니다.

제 경우에는 코드 스타일을 통일하는 것을 좋아하기 때문에, FCM 역시 상태관리를 이용해서 관리하고 싶었습니다.

또한, 저는 Bloc을 애용하기 때문에, 이번에는 FCM이 수신되면 Bloc을 통해 해당 상태를 관리하는 방법에 대해 알아보려 합니다.
(정확히는 Cubit을 사용할 예정입니다)

<notice>
 해당 방식은 부족한 제 지식으로 자체 구현한 방법이기 때문에 다소 어설프게 보일 수 있음을 알려 드립니다.
</notice>

## FirebaseMessaging

우선 FCM을 사용하기 앞서, FirebaseMessaging 객체를 조금만 살펴봅시다.

앱의 상태(fore/background, terminate)에 따라 FCM 수신 방법이 달라지는데, 각 상태에 따른 수신 방법은 아래와 같습니다.

- **foreground**

 앱이 화면위에서 실행중인 경우에 해당하며, 수신 방법은 다음과 같습니다.

 ```dart:.dart
 FirebaseMessaging.onMessage.listen(listenFCM);

 void listenFCM(RemoteMessage? message) { ... }
 ```

- **background**

 앱이 죽지는 않았지만 화면위에 없는 경우. 
 즉, 태스크매니져 상에만 존재하는 백그라운드 상태에 해당하며, 수신 방법은 다음과 같습니다.

 ```dart:.dart
 FirebaseMessaging.onMessageOpenedApp.listen(listenFCM);

 void listenFCM(RemoteMessage? message) { ... }
 ```

- **terminate**

 앱이 완전히 종료된 상태에 해당하며, 수신 방법은 다음과 같습니다.

 ```dart:.dart
 FirebaseMessaging.onBackgroundMessage(onBackgroundMessage);
 ...
 Future<void> onBackgroundMessage(RemoteMessage message) async { ... }
 ```

 <notice>
 fore/background 와 다르게, terminate의 이벤트핸들러는 static 형식, 또는 전역으로 관리되는 비동기 함수여야 합니다.
 </notice>

<tip>
 fore/background의 경우에는 onBlah getter를 이용해서 stream을 반환하고, stream의 listen을 이용해서 stream을 구독합니다.
 즉, 인스턴스가 존재하는한, 스트림 형식으로 지속해서 FCM과 같은 이벤트를 수신할 수 있습니다.
 
 반면에 terminate의 경우에는 앱이 죽은 상태에서의 FCM 수신을 담당하기 때문에, stream 형식으로 지속적으로 수신할 필요가 없습니다.
</tip>

---

## 구현

### State

Cubit에서 관리할 상태 클래스를 우선 정의합니다.

```dart:fcm_cubit.dart
class FCMState extends Equatable {
 final FCMEvent state;
 final String? body;
 final FCMDataModel? data;

 const FCMState({
 this.state = FCMEvent.none,
 this.body,
 this.data,
 });

 factory FCMState.fromBgMessage(RemoteMessage? message) {
 if (message != null) {
 if (message.notification != null) {
 return FCMState(
 state: FCMEvent.message,
 body: message.notification!.body,
 data: FCMDataModel.fromJson(message.data),
 );
 }
 }
 return const FCMState();
 }

 @override
 List<Object?> get props => [
 state,
 body,
 data,
 ];
}
```

`FCMEvent`는 자체 정의한 해당 fcm의 타입을 관리하는 enum 타입입니다. (option)

`body`는 앱의 푸쉬 알림에서 보여지는 문자열을 보관하는 멤버 변수입니다.

<tip>
 기본 firebase_messaging 에서 FCM이 수신되었을 때, 푸쉬알림은 background, terminate 상태에서만 표시되고, foreground 상태에서는 푸쉬알림이 발생하지 않습니다 (FCM 자체는 수신됨).
 
 따라서, body에 데이터를 보관하고, 상태가 변화했을 때 Snackbar 와 같은 방식으로 사용자에게 알려줄 수 있습니다.
</tip>

`FCMDataModel`은 FCM의 data 객체의 정보를 저장하는 자체 모델입니다.
이 모델은 int `code`, String `data`을 갖고있습니다.
`code`는 일종의 응답코드로, code에 따라 FCM이 수신되었을 때의 앱의 동작이 달라지게 됩니다.
`data`는 직렬화된 객체의 json 문자열으로, code에 따라 파싱 방법이 달라지며, 필요한 정보를 보관합니다.

모든 FCM 이벤트 핸들러는 `RemoteMessage` 객체를 파라미터로 넘겨받기 때문에, 해당 객체를 이용한 생성자를 구현하여 상태를 업데이트 합니다.

### Cubit

다음으로 위에서 언급했던 fore/background는 Cubit 생성자에서 스트림을 구독받도록 구현합니다.

```dart:fcm_cubit.dart
class FCMCubit extends Cubit<FCMState> {
 final String _fcmToken;

 FCMCubit(
 this._fcmToken,
 RemoteMessage? bgMessage,
 ) : super(FCMState.fromBgMessage(bgMessage)) {
 // fcm listening
 // at foground
 FirebaseMessaging.onMessage.listen(listenFCM);
 // at background
 FirebaseMessaging.onMessageOpenedApp.listen(listenFCM);
 }

 // token getter
 String get token => _fcmToken;
 
 void listenFCM(RemoteMessage? message) {
 if (message != null) {
 emit(FCMState(
 state: FCMEvent.message,
 body: message.notification?.body,
 data: FCMDataModel.fromJson(message.data),
 ));
 }
 emit(const FCMState());
 }
}
```

이렇게 하면 fore/background 에서 FCM이 수신될 때 마다 listenFCM 리스너가 실행이 되고,
해당 리스너 안에서 emit을 2회 호출하게 됩니다.

첫 번째 emit에서는 위에서 정의한, RemoteMessage의 데이터를 활용해 초기화된 FCMState 상태로 업데이트 되고,
두 번째 emit에서는 init 상태의 FCMState 상태로 되돌립니다.

두 번째 emit이 필요한 이유는, 동일한 FCM이 2번 연속 수신되는 일도 존재할 수 있기 때문에 상태를 초기화 시켜 2번 모두 정상적으로 수신시켜 주기 위함입니다.

### main

이제 main에서 FCM Token과 권한 요청, terminate의 동작을 정의하도록 합니다.

```dart:main.dart
RemoteMessage? bgMessage;

void main() async {
 // flutter ensure initialized
 WidgetsFlutterBinding.ensureInitialized();

 // request FCM permission
 FirebaseMessaging.instance.requestPermission(
 badge: true,
 alert: true,
 sound: true,
 );

 // listening fcm from background
 FirebaseMessaging.onBackgroundMessage(_onBackgroundMessage);

 // get fcm token
 String? fcmToken = await FirebaseMessaging.instance.getToken();
 debugPrint('FCM Token: $fcmToken');

 runApp(MyApp(
 fcmToken: fcmToken ?? '',
 bgMessage: bgMessage,
 ));
}

Future<void> _onBackgroundMessage(RemoteMessage message) async {
 bgMessage = message;
}
```

제가 구현했을 때는, terminate 에서의 FCM 수신은 앱의 최초 화면을 제어하는 용도로만 사용했었습니다.

따라서, bgMessage에 임시 보관하여 runApp으로 넘겨주었습니다.
이후에 별도 처리를 통해 go_router의 initialRoute를 설정하였습니다.

### BlocProvider

이제 FCMCubit을 BuildContext에 등록을 시킵시다.

```dart:main.dart
class MyApp extends StatelessWidget {
 final String fcmToken;
 final RemoteMessage? bgMessage;

 const MyApp({
 super.key,
 required this.fcmToken,
 this.bgMessage,
 });

 @override
 Widget build(BuildContext context) {
 return MultiRepositoryProvider(
 providers: [ ... ],
 child: MultiBlocProvider(
 providers: [
 BlocProvider(
 create: (context) => FCMCubit(
 fcmToken,
 bgMessage,
 ),
 lazy: false,
 ),
 ...
 ],
 child: const App(),
 ),
 );
 }
}
```

이렇게 하면 Bloc을 통해 FCM의 상태를 관리할 준비가 모두 끝납니다.

### 결과물

```dart:.dart {1}
BlocListener<FCMCubit, FCMState>(
 listener: (context, state) {
 if (state.data?.code == "10000") {
 // action for res code 10000
 }
 if (state.data?.code == '10001') {
 // action for res code 10001
 }
 if (state.data?.code == '10002') {
 // action for res code 10002
 }
 },
 ...
),
```
FCM이 수신될 경우, `BlocListener<FCMCubit, FCMState>`를 통해 FCM에 의한 state에 접근할 수 있고,

```dart:.dart {6}
BlocProvider(
 create: (context) => SignalStateBloc(
 homeSignalBoxRepository: context.read<HomeSignalBoxRepository>(),
 myIdx: context.read<UserCubit>().state.user!.userIdx!,
 jwt: context.read<UserCubit>().state.user!.jwt!,
 fcmToken: context.read<FCMCubit>().token,
 ),
),
```

서버에서 FCM Token이 필요한 경우 `FCMCubit.token`을 통해 해당 클라이언트의 FCM Token을 조회할 수 있습니다.

Bloc으로 FCM까지 관리 완료!

FCM 응답을 BLoC을 이용해서 상태관리 하는 방법에 대해 알아봅니다.

FCM, BLoC으로 관리하기

저는 게임이나, 깃허브(깃허브 서비스 그 자체)에서 영감을 많이 얻는 편입니다.
그 중에 깃허브 앱에서 꼭 따라해보고 싶은 UI가 있었습니다.

![github_app](/posts/valuenotifier/github_app.gif)

바로 AppBar가 스크롤함에 따라 움직이는 애니메이션이죠!

그래서 구글링 해보니까 ScrollController와 `ValueNotifier` 만 있으면 쉽게 구현이 가능했기에 오늘은 이 방법에 대해 적어보려 합니다.

## ValueNotifier

[공식문서](https://api.flutter.dev/flutter/foundation/ValueNotifier-class.html) 의 내용을 요약하면 다음과 같습니다.

> ChangeNotifier를 상속 받았으며, 단일 value를 갖고 있습니다.
> oldValue와 newValue를 == 연산자를 통해 비교하며,
> 그 값이 다를 경우 listener 에게 notify 하게 됩니다. (notifyListeners를 호출하는 방식)

따라서 ValueNotifier는 일종의 observer pattern으로 구현되어 있기 떄문에 stateful widget의 상태주기에 의해 제어되지 않을 수 있습니다.



### ValueListenableBuilder

이 위젯은 필수로 valueListenable 인자를 받게 되어있습니다.
이 인자로는 반드시 Listenable 을 상속받은 `ValueListenable` 객체를 넘겨주어야 합니다.

이 때, ValueNotifier는 **ValueListenable의 구현체**이기 때문에 ValueNotifier를 인자로 넘겨주면 이 빌더 위젯이 ValueNotifier 상태가 변화하면 알아서 이 부분만 재랜더링 하게 되는 것입니다.

```dart:value_listenable_builder.dart
@override
void didUpdateWidget(ValueListenableBuilder<T> oldWidget) {
 super.didUpdateWidget(oldWidget);
 if (oldWidget.valueListenable != widget.valueListenable) {
 oldWidget.valueListenable.removeListener(_valueChanged);
 value = widget.valueListenable.value;
 widget.valueListenable.addListener(_valueChanged);
 }
}

void _valueChanged() {
 setState(() { value = widget.valueListenable.value; });
}
```

실제로 위젯을 까(?)보면 valueListenable이 변경될 때 마다 stateful 위젯이 재랜더링 됨을 볼 수 있었네요!

---

## 구현

이제 이론적인 내용은 다뤄봤으니 실제로 구현을 해봅시다.

### 컨트롤러

```dart:myinfo_screen.dart {4, 5}
class _MyinfoScreenState extends State<MyinfoScreen> {
 static const double _expandedHeight = 250;
 static const double _appbarHeight = Sizes.size52;
 late ScrollController _scrollController;
 final ValueNotifier<double> _titleBottomPadding = ValueNotifier(0);

 @override
 void initState() {
 super.initState();
 _scrollController = ScrollController();
 _scrollController.addListener(_scrollListener);
 }
```

우선 ScrollController와 ValueNotifier를 생성 및 초기화 해줍니다.
dispose도 잊지 마세요!

### 위젯

```dart:myinfo_screen.dart {6, 19}
override
 Widget build(BuildContext context) {
 return Scaffold(
 appBar: AppBar(
 title: ValueListenableBuilder(
 valueListenable: _titleBottomPadding,
 builder: (context, value, child) => AnimatedContainer(
 duration: const Duration(milliseconds: 1),
 margin: EdgeInsets.only(
 bottom: value * 2,
 top: _appbarHeight,
 ),
 child: child,
 ),
 child: ... 
 ),
 ),
 body: CustomScrollView(
 controller: _scrollController,
 ...
```

그리고, 스크롤이 되는 위젯에는 ScrollController 객체를 넣어주고,
스크롤에 따라 애니메이션 되어야 할 부분은 ValueListenableBuilder 위젯으로 구현합니다.
이 떄, valueListenable의 인자로 ValueNotifier 객체를 넣어줍니다.

<tip>
 여기서 ValueListenableBuilder의 builder 함수의 파라미터로 넘어오는 value로
 ValueNotifier에 보관되어있는 value의 값에 접근할 수 있습니다.
</tip>

### 이벤트 리스너

```dart:myinfo_screen.dart
void _scrollListener() {
 const ratio = 0.3;
 if (_expandedHeight - _appbarHeight * ratio > _scrollController.offset) {
 _titleBottomPadding.value = 0;
 }
 if (_expandedHeight - _appbarHeight * ratio <= _scrollController.offset &&
 _expandedHeight + _appbarHeight * (1 - ratio) >=
 _scrollController.offset) {
 _titleBottomPadding.value =
 _scrollController.offset - _expandedHeight + _appbarHeight * ratio;
 }
 if (_expandedHeight + _appbarHeight * (1 - ratio) <
 _scrollController.offset) {
 _titleBottomPadding.value = _appbarHeight;
 }
}
```

마지막으로 ScrollController의 listener 함수를 구현하면 깃허브 앱 AppBar 구현 완료!

### 결과물

![my_app](/posts/valuenotifier/my_app.gif)

라이브러리 안쓰고 직접 구현하고, 코드 분석해보는...
조금은 성장하는 맛이 있는 시간이었습니다 ㅎㅎ

setState 없이 일부분만 리랜더링 할 수 있도록 해주는 ValueNotifier, ValueListenableBuilder 에 대해 알아봅니다.

ValueNotifier

## factory constructor

`factory` 키워드를 사용하면 아래와 같은 기능을 구현할 수 있다고 공식문서에 나와 있습니다.

1. 인스턴스를 `캐시에서 반환`하여 클래스의 인스턴스를 한 번만 생성할 수 있도록 합니다. (일종의 Singleton 패턴 구현법)
2. 생성자에서 `서브 클래스`(상속 받은 클래스)의 인스턴스를 반환할 수 있습니다.

둘 다 신기한 기능입니다. (다만 언제 사용하는게 적재적소인지는 잘 모르겠네요..)
1번부터 알아봅시다.

### caching

```dart:.dart
class Singleton {
 static final Singleton _instance = Singleton._internal();

 Singleton._internal() {}

 factory Singleton() {
 return _instance;
 }

 void getHash() {
 print(this.hashCode);
 }
}

void main() {
 Singleton s1 = new Singleton();
 Singleton s2 = new Singleton();

 s1.getHash(); // 302000605
 s2.getHash(); // 302000605
}
```

위와 같이 구현한다면, Singleton 클래스의 인스턴스는 `단 한개`만 생성되게 됩니다.
클래스 로드 시점에 static으로 이미 인스턴스가 만들어지기 때문이죠.
하지만 이런 사용용법은 의미가 없어보입니다.
차라리 아래의 예시가 더 의미 있어보입니다.

```dart:.dart
class SingletonLog {
 final String value;

 static final Map<String, SingletonLog> _cache = {};

 SingletonLog._internal(this.value);

 factory SingletonLog(String value) {
 return _cache.putIfAbsent(value, () => SingletonLog._internal(value));
 }

 void getHash() {
 print(this.hashCode);
 }

 String getValue() {
 return value;
 }

 Map<String, String> getLogs() {
 Map<String, String> result = {};
 _cache.forEach((key, value) {
 result[key] = value.value;
 });
 return result;
 }
}

void main() {
 SingletonLog s1 = new SingletonLog('log1');
 SingletonLog s2 = new SingletonLog('log2');

 s1.getHash(); // 888013580
 s2.getHash(); // 870182876

 print(s1.value); // log1
 print(s2.value); // log2

 print(s1.getLogs()); // {log1: log1, log2: log2}
 print(s2.getLogs()); // {log1: log1, log2: log2}
}
```

이렇게 하면 s1, s2가 같은 인스턴스를 반환받기 때문에, 어디에서 로그를 추가해도 모든 객체가 같은 로그기록을 보관할 수 있습니다.

<tip>
 그럼 이런 의문이 듭니다.
 hashCode가 다르게 나오는데, 그럼 다른 객체 아닌가요?
 
 실제로 s1 == s2의 값은 `false`입니다. 따라서 `다른 객체`가 맞습니다.
 하지만 **약간 변형**이 이루어지긴 했으나, `싱글톤 패턴` 역시 맞습니다.
 
 왜냐하면, 인스턴스의 생성을 **클래스 내부**에서 `_internal`로 생성하고, 생성자를 외부에서 호출하지 못합니다.
 또한, static으로 선언된 `_cache` 내부에서 인스턴스를 보관하기 때문에 _cache를 통해서 **전역적으로 인스턴스를 공유**하게 됩니다.
 
 그렇다고 항상 다른 객체를 반환하는 것은 아닙니다.
 실제로, s2를 생성할 때, s1과 동일하게 `'log1'`을 주입시키면 s1, s2 동일한 hashCode를 갖게 됩니다.
 왜냐하면, factory 생성자는 일단 캐시되어있는 인스턴스를 반환하기 때문에,
 _cache 내부에 인스턴스를 저장하고 있고, s1, s2 모두 같은 데이터를 갖고 있기에 메모리주소 역시 같아집니다.
</tip>

### return subclass constructor

그럼 2번도 알아봐야겠죠?

```dart:.dart
class Human {
 final String name;

 Human(this.name);

 factory Human.create(String name, {required bool isMan}) {
 if (isMan) {
 return Male(name);
 }
 return Female(name);
 }
}

class Male extends Human {
 Male(String name) : super(name);
}

class Female extends Human {
 Female(String name) : super(name);
}

void main() {
 Human man = new Human.create('h1', isMan: true);
 Human woman = new Human.create('h2', isMan: false);

 print(man.name); // h1
 print(woman.name); // h2
}
```

이 방식은 객체지향 프로그래밍의 다형성의 원리를 충족시키기에 좋은 문법입니다.

신기한 점은 부모 클래스 생성자에서 자식 클래스의 생성자를 호출해 반환한다는 점입니다.
이렇게하면 인스턴스 생성 시점에 조건을 달아 다른 인스턴스를 반환하는 것이 가능해집니다.
_(상태나 이벤트를 클래스로 관리할 때 유용해 보이네요!)_

### constructor body

사실 공식문서에는 자세히 설명하진 않지만, factory 생성자의 가장 큰 이점은 `final variable`을 생성자에서 `initialize list`로 **초기화하지 않아도 된다는 점** 이라고 생각합니다.
정확히 말하자면, 생성자를 내부에서 호출함으로서 생성자 호출 전, `전처리`를 할 수 있다는 점이 이점이라고 생각합니다.

예시를 봐야겠죠?

```dart:.dart {7-10}
class Human {
 final String name;

 Human(this.name);

 // Human.withSir(String name) : this.name = 'Sir - ' + name;
 factory Human.withSir(String name) {
 String newName = 'Sir - ' + name;
 return Human(newName);
 }
}

void main() {
 Human man = new Human.withSir('h1');

 print(man.name);
}
```

위 코드에서 주석처리 된 부분과 하이라이트 된 부분 모두 동일한 기능을 수행합니다.
지금은 간단하게 문자열 앞에 `Sir - `을 붙이도록 했지만, 만약 배열을 직렬화 해야하는 상황이라면?
한 줄로 처리하기 복잡한 기능은 분명 일반 생성자의 initialize list로 처리하는덴 한계가 있을 것입니다.

<tip>
 한 줄로 처리하기 복잡한 코드는 예로들어 `json serialize` 부분이 있겠죠?
 
 그래서 우리가 무의식적으로 사용하던 factory가 사실은 인스턴스 생성을 편-안하게 생성하기 위해 사용했던 것이었습니다!
</tip>

---

## get, set

getter, setter 메서드를 이용해서 객체의 가상 멤버변수(`property`)를 읽고 쓰는게 가능해진다는 건 다른 객체지향 언어에도 있는 기능입니다.
dart에선 이를 가능케 하는 키워드가 `get`, `set` 입니다.

공식문서에 있는 코드를 분석해봅시다.

```dart:.dart
class Rectangle {
 double left, top, width, height;

 Rectangle(this.left, this.top, this.width, this.height);

 // right, bottom 이라는 두 개의 계산된 프로퍼티 정의.
 double get right => left + width;
 set right(double value) => left = value - width;
 double get bottom => top + height;
 set bottom(double value) => top = value - height;
}

void main() {
 var rect = Rectangle(3, 4, 20, 15);

 print(rect.right); // 23.0
 print(rect.left); // 3.0
 rect.right = 20;
 print(rect.right); // 20.0
 print(rect.left); // 0.0
}
```

제 개인적인 생각에는 get은 가상의 멤버변수를 만들어서 이를 사용하게 해주고,
set은 이 가상의 멤버변수를 위해 처리해야 하는 기능을 함수 내부에서 별도로 처리하게 해준다가 주된 사용법인거 같습니다.

<notice>
 제가 `가상`의 멤버변수라고 표현한 이유는, get으로 정의된 변수는 그 자체가 특정 값을 저장할 수 없고, 별도로 정의된 멤버변수에 의존해야 하기 때문입니다.
</notice>

### interface

그렇다면 get, set을 언제 사용해야 잘 사용한걸까요?
보통은 멤버변수를 `은닉화`하고 이를 `접근제어`를 할 때 사용하는 방식이 대부분일 것입니다.

하지만, 개인적으로 `인터페이스`를 구현할 때 역시 get의 적절한 사용처라고 개인적으로 생각합니다.
예를 들어봅시다.

```dart:.dart {2}
abstract class IColor {
 String get color;
}

class Car implements IColor {
 final String name;
 @override
 final String color;

 Car(this.name, this.color);
}

class Boat implements IColor {
 final String name;
 @override
 final String color;

 Boat(this.name, this.color);
}

void main() {
 Car car = Car('car1', 'red');
 Boat boat = Boat('boat1', 'red');

 print(car.color == boat.color); // true
}
```

<tip>
 dart에선 abstract class로 구현해도 될 정도로 interface의 의미가 약합니다.
 최근에는 interface 키워드가 추가되었으나, implements 하는 것이 아닌 extends 해도 에러가 안 날정도로 중요하진 않은 거 같습니다.
 abstract interface와 같이 키워드를 중복해서 쓰는 경우도 있으므로 자세한 내용은 [**`공식문서`**](https://dart.dev/language/class-modifiers#interface)를 참고해주세요.
</tip>

두 클래스간 `필요에 따라` 공통속성을 갖고싶게 할 때 interface를 사용하곤 하는데요,
dart는 `null-safety` 언어이기 떄문에, get 키워드가 없다면 **abstract class라 하더라도 멤버변수를 초기화** 해줘야만 합니다.
그러면 코드가 아래처럼 복잡해지겠죠.

```diff-dart:.dart {2}
 abstract class IColor {
 String color;

+ IColor(this.color);
 }

 class Car implements IColor {
 final String name;
 @override
 final String color;

 Car(this.name, this.color);

+ @override
+ set color(String _color) {
+ color = _color;
+ }
 }
```

## stream

비동기의 4번타자, `future`는 완료되지 않은 연산을 나타냅니다.
비동기 함수가 return을 해야만 future은 연산이 완료되었다는 것을 알려줍니다.

그에 반면, `stream`은 **일련, iterable**한 비동기 이벤트입니다.
따라서 iterable과 같이 동작하게 됩니다만, 그 과정이 비동기인 것이죠.

즉, future은 요청시 다음에 올 이벤트를 받는 방식이라면,
stream은 준비가 된 후 이벤트가 있음을 알려주는 방식입니다.

### async* / yield

`async*`는 async와 마찬가치로 이 함수가 비동기 함수라는 것임을 선언하는 키워드 입니다.
차이점은 이 함수는 `Stream<T>`을 반환하기 때문에 일련의 비동기로 연산된 결과를 반환하게 됩니다.
즉, **지속적으로 값을 반환**하기 위해 `yield` 키워드가 return을 대신하여 값을 반환합니다.
_(return 키워드는 여기서 사용 불가합니다)_

예시를 살펴봅시다.

```dart:.dart
Future<int> sumStream(Stream<int> stream) async {
 var sum = 0;
 await for (final value in stream) {
 print('get stream value $value');
 sum += value;
 }
 return sum;
}

Stream<int> countStream(int to) async* {
 for (int i = 1; i <= to; i++) {
 await Future.delayed(Duration(milliseconds: 200));
 print('stream $i ready');
 yield i;
 }
}

void main() async {
 var stream = countStream(3);
 var sum = await sumStream(stream);
 print(sum);
}
```

> (0.2초 대기)
> stream 1 ready
> get stream value 1
> (0.2초 대기)
> stream 2 ready
> get stream value 2
> (0.2초 대기)
> stream 3 ready
> get stream value 3
> 6

Stream 역시 비동기로 처리되는 **일련**의 연산이라는 것을 알려주는 객체이기 때문에,
실제 연산 결과를 받으려면 await을 사용해서 값이 전달받을 때 까지 대기해야 합니다.

따라서, dart에서는 `await for` 키워드를 제공하여 iterable한 비동기 이벤트를 처리할 수 있도록 도와줍니다.

<tip>
 동기적은 `Iterable<T>` 객체를 반환하고 싶다면 `sync*` / `yield` 키워드를 사용하면 됩니다.
</tip>

<tip>
 stream은 파일읽기와 같이 한 번의 요청이 있으면 처음부터 끝까지 끊김없이 진행되어야 하는 `Single subscription streams`, 
 브라우저의 마우스 이벤트와 같이 Observer pattern을 사용하기에 언제든지 누구나 stream을 들을 수 있는 `Broadcast streams` 으로 나뉩니다.
 
 뿐만 아니라, stream은 iterable한 성격을 갖는다 했었는데, 이런 stream을 제어할 수 있는 여러 메서드 또한 존재합니다.
 따라서 자세한 내용은 [**`공식문서`**](https://dart-ko.dev/tutorials/language/streams#working-with-streams)를 참고하시는걸 추천 드립니다.
</tip>

## mixin, with

간단하게 말하면 class &rarr; `mixin`, extends &rarr; `with`와 같은 개념입니다.
물론 이해를 돕기위해 위와같이 적었을 뿐, 완전히 다른 키워드이니 혼동하지 마시길 바랍니다.

클래스를 상속할 때는 부모 클래스에서 미리 정의된 변수나 메서드를 자식 클래스에서 구현하지 않아도 바로 사용할 수 있습니다.
하지만, 계층구조를 나타내기 위해 **반드시 한 개의 클래스를 상속**해야 한다는 단점이 있죠.

여러개의 자료 구조를 공유하기 위해서는 인터페이스를 구현 하는 방법으로 사용해야 합니다.
하지만, 인터페이스는 말 그대로 틀만 제공하고 **구현은 별도로 해야한다**는 단점이 있습니다.

이 떄, extends와 implements의 **중간 포지션**에 위치한 키워드가 with이고, with은 mixin을 받을 수 있습니다.

```dart:.dart
mixin SwimBehabior {
 void swim() {
 print('swim');
 }
}

mixin FlyBehiabior {
 void fly() {
 print('fly');
 }
}

class Duck {
 final String name;

 Duck(this.name);
}

class RealDuck extends Duck with SwimBehabior, FlyBehiabior {
 RealDuck(super.name);
}

class RubberDuck extends Duck with SwimBehabior {
 RubberDuck(super.name);
}

void main() {
 RealDuck duck = RealDuck('duck');

 duck.fly();
 duck.swim();
}
```

이런식으로 implements 처럼 여러 인터페이스를 사용할 수 있지만, extends 처럼 재정의할 필요 없이 사용할 수 있습니다.
하지만, mixin을 사용할 때는 클래스 구성요소가 `매우 세분화` 되어있는게 좋습니다.
이런저런 메서드를 잔뜩 만들어놓으면 상속했을 때 **필요없는 기능도 수행**할 수 있는 상황이 발생할 수 있기 때문입니다.

이런 상황이 생길 가능성이 있는 코드는 mixin 보단 `Strategy pattern`으로 구현하는 것이 더 좋습니다.

```dart:.dart {18, 22-24}
abstract class SwimBehavior {
 void swim();
}

abstract class FlyBehavior {
 void fly();
}

class CanSwim implements SwimBehavior {
 @override
 void swim() {
 print('swim');
 }
}

class Duck {
 final String name;
 SwimBehavior swimBehavior;

 Duck(this.name, this.swimBehavior);

 void performSwim() {
 swimBehavior.swim();
 }
}

class RealDuck extends Duck implements FlyBehavior {
 RealDuck(String name) : super(name, CanSwim());

 @override
 void fly() {
 print('fly');
 }
}

class RubberDuck extends Duck {
 RubberDuck(String name) : super(name, CanSwim());
}

void main() {
 RealDuck real = RealDuck('duck');
 RubberDuck rubber = RubberDuck('duck');

 real.performSwim();
 real.fly();
 rubber.performSwim();
}
```

사실 mixin을 사용하지 않더라도 class의 `상속 depth를 깊게` 하는 방법도 있으니, 본인의 상황에 맞게 취사선택을 잘 하는 것이 좋은 개발습관이 될 것입니다.

Dart 언어에 대한 보다 심화된 내용을 정리해봤습니다.

Dart 언어 마스터

<notice>
 기초적인 지식이 필요하신 분들은 [**`Dart 언어 기초`**](https://wjlee611.github.io/blog/flutter/003_dart_basic) 포스트를 읽어보시길 권장드립니다.
</notice>

## async / await

`async`, `await` 키워드는 **비동기 프로그래밍**시 빠지지 않는 키워드입니다.
여기서 `.then()` 메서드나 Dart 에서 `Future<T>` 도 포함해서 원리와 적절한 사용법까지 알아보고자 합니다.

<tip>
 `비동기 프로그래밍`
 특정 코드가 완료되기 전, 다른 코드를 수행함으로서 코드의 실행 순서가 순차적(동기적)으로 실행되지 않는 프로그래밍 방식입니다.
 보통 처리완료까지 시간이 많이 걸리는 네트워크 통신이나 파일 입출력 등에 많이 사용됩니다.
</tip>

<notice>
 비동기 처리는 `단일 스레드(Dart의 경우 단일 Isolate) 환경`에서 이루어집니다.
 따라서 비동기 처리를 한다고 해도, 비동기 함수가 `컴퓨팅 자원 사용량이 많다`면 해당 스레드(Isolate)는 `일시 정지`되는 현상이 발생할 수 있습니다.
 
 이와 관련한 자세한 내용은 아래 [**`Isolate`**](https://wjlee611.github.io/blog/flutter/004_dart_advanced#isolate) 파트에서 다루겠습니다.
</notice>

### Future

`Future` 객체는 지금 당장은 처리되지 않았지만, 미래에 처리가 완료될 데이터를 알려주는 객체입니다.
예를 들어봅시다.

```dart:.dart
Future<String> futureStr() async {
 print('do something');
 return Future.delayed(Duration(seconds: 2), () => 'future string');
}

void main() {
 print('start');
 print(futureStr());
}
```

위의 futureStr() 함수는 호출 후 2초뒤에 'future string'을 반환하는 함수입니다.
실행결과는 어떻게 될까요?

> start
> do something
> Instance of 'Future\<String\>'
> (2초 후 종료)

답은 `future 객체` 입니다.
어찌보면 당연합니다. `main` 함수는 비동기 함수도 아닐 뿐더러 futureStr의 리턴값은 `Future<String>` 이라고 명시해두었으니 말이죠.

![230917-211924](/posts/004_dart_advanced/230917-211924.png)

future는 `Uncompleted`, `Completed` 상태를 갖습니다.
비동기 함수 호출시에 future은 Uncompleted 상태를 갖습니다.
따라서 `Instance of 'Future<String>'`와 같은 결과를 출력한 것이죠.
하지만 함수가 성공적으로 종료되면 future은 비로소 Completed 상태를 갖습니다.
따라서 `future string`과 같은 결과를 출력하게 될 것입니다.

사용자 입장에서는 Future 객체는 중요하지 않습니다. 중요한 것은 Future 객체가 처리되고 나서 반환되는 데이터인거죠.
따라서, Future 객체의 처리(비동기 함수)를 원활히 하기위해 `async`, `await` 키워드를 사용하는 것입니다.

### async

async 키워드는 이 함수가 비동기 처리를 수행하는 함수임을 명시하는 키워드 입니다.
다만 위의 예시에서 보듯, 반드시 `Future<T>` 객체 또는 `void`를 반환해야만 합니다.

그렇다면, main 함수를 async 키워드를 붙여 실행한다면 제대로된 결과가 나올까요?

```dart:.dart
Future<String> futureStr() async {
 print('do something');
 return Future.delayed(Duration(seconds: 2), () => 'future string');
}

void main() async {
 print('start');
 print(futureStr());
}
```

> start
> do something
> Instance of 'Future\<String\>'
> (2초 후 종료)

그렇습니다. 함수를 비동기 처리하는 함수로 선언한다고 해서 해결되지는 않습니다.
함수 내부에서 비동기 처리가 진행될 수 있다는 것을 암시할 뿐, `어디서` 비동기 처리를 해야하는 지는 명시하지 않았기 때문이죠.

### await

await 키워드는 **해당 키워드가 명시된 비동기 처리**(futureStr)가 완료될 때 까지 **비동기 함수**(main)의 처리를 `멈추겠다`는 의미입니다.
그렇기에 await 키워드는 반드시 async 키워드가 명시된 함수 내부에서만 사용할 수 있는 것입니다.

그렇다면 futureStr의 함수 앞에 await를 명시하여 비동기 함수가 끝날 때 까지 대기시킨다면 어떨까요?

```dart:.dart
Future<String> futureStr() async {
 print('do something');
 // return Future.delayed(Duration(seconds: 2), () => 'future string');
 await Future.delayed(Duration(seconds: 2));
 return 'future string';
}


void main() async {
 print('start');
 print(await futureStr());
}
```

> start
> do something
> (2초 대기)
> future string
> (즉시 종료)

비로소 원하던 결과가 나왔습니다.

---

## Isolate

`Isolate`는 Dart에서 스레드를 부르는 용어라고 생각하시면 됩니다.

![230917-221122](/posts/004_dart_advanced/230917-221122.png)

Isolate는 스레드와 마찬가지로 멀티 코어 CPU의 장점을 살리는 프로그래밍 기법으로 `별도의 이벤트 루프`를 갖는 실행 흐름을 만들어 `병렬적인 처리`를 가능케 합니다.
하지만, 스레드와 용어에서의 차이점을 두는 이유가 있습니다.

보통 **스레드**라 하면 `메모리 영역을 공유`한다고 배웠습니다. 하지만 그 때문에 `race-condition`이 발생하는 문제점을 고려하여 프로그래밍을 했어야 합니다.

하지만, **Isolate**는 스레드와 다르게 `메모리 영역 또한 공유하지 않습니다`.(물론 코드 영역은 공유합니다) 
그렇기에 mutex, lock 등을 고려할 필요가 없는 편의성이 있습니다.

하지만 왜 Isolate를 알아야 하고, 사용해야만 할까요?

### Isolate vs Async

아래의 영상을 확인해봅시다.

<YT id='HkBaS098BrE' />

`Main isolate`부분은 json 데이터 파싱과 화면 빌드를 `하나의 isolate`에서 구동한 결과입니다.
영상에서 보시는 바와 같듯 십몇만줄의 json 파싱은 단일 isolate 환경에서 구동하기에는 다소 무리가 있습니다.
아무리 async로 실행 결과를 뒤로 미룬다 할지라도 실제 데이터 파싱하는 동작과 화면을 그리는 동작 모두 `동일한 isolate`에서 처리되기 때문에 `성능상 이슈`가 생길 수 밖에 없습니다.

하지만 `Worker isolate`부분은 json 데이터 파싱을 `별도의 worker isolate`에서 구동한 결과입니다.
차이는 명확합니다. 화면에 그리는 동작과 파싱 동작이 `별도의 isolate`에서 처리되기 때문에 화면을 그리는 부분에서 `랙이 걸리지 않습니다`.

이렇듯 단일 isolate에서 동작이 버벅일 정도로 무거운 기능을 수행해야 한다면, 해당 기능은 별도의 isolate로 빼서 처리하는 것이 사용자에게 더 나은 경험을 제공하게 됩니다.

해당 영상에서 구동하는 코드는 [**`Arkhive repo`**](https://github.com/wjlee611/arkhive/blob/main/lib/bloc/enemy/enemy_data/enemy_data_bloc.dart)에서 확인하실 수 있습니다.

---

## function

### callback function

콜백 함수는 함수의 인자로 넘겨주어 넘겨받은 함수 내부에서 실행 가능한 함수를 의미합니다.
예시를 살펴봅시다.

```dart:.dart
void main() {
 int value = 0;

 print(valueModifire(value: value, modifire: add1)); // 1
 print(valueModifire(value: value, modifire: sub1)); // -1
}

int add1(int value) => value + 1;
int sub1(int value) => value - 1;

int valueModifire({
 required int value,
 required Function(int) modifire,
}) {
 return modifire(value);
}
```

위 코드에서는 `valueModifire`의 인자로서 `add1`, `sub1`을 전달했습니다.
이 때, 이 두 함수를 `callback function`라고 부르고, 이 함수는 valueModifire 내부에서 `modifire`의 형태로 호출됩니다.

보통은 이런식으로 `동일한 함수` 내부에서 `서로 다른 기능`을 수행해야 할 때 콜백 함수로서 전달하는 경우가 많습니다.

```dart:.dart
void main() async {
 int value = 0;

 print(await valueModifire(value: value, modifire: add1)); // await 1 second -> 1
 print(await valueModifire(value: value, modifire: sub1)); // await 1 second -> -1
}

int add1(int value) => value + 1;
int sub1(int value) => value - 1;

Future<int> valueModifire({
 required int value,
 required Function(int) modifire,
}) async {
 await Future.delayed(Duration(seconds: 1)); // something actions
 return modifire(value);
}
```

또는, `특정 함수의 동작이 끝난 후` 수행해야 할 기능이 있을 때 많이 사용되곤 합니다.

Dart 언어에 대한 심화된 내용을 정리해봤습니다.

Dart 언어 심화

<warning>
 제가 생각하기에 **너무 기초지식**이다 하는 부분은 과감하게 **제외**했습니다.
 다만, 기초지식이다 하더라도 `개념적으로 매우 중요`하거나 `많이들 알려주지 않는 내용`은 포함하였습니다.
</warning>

## variables

변수 네이밍 방법은 다음과 같습니다.

```dart:.dart
 <제어자> <타입> <변수이름> = <값>;
```

타입은 int, String 과 같은 타입들이 오거나, `var` 와 같은 타입 추론 키워드도 사용할 수 있습니다.
제어자에는 `final`, `const`, `late`, `static` 와 같은 키워드가 오게 됩니다.

### var

dart에선 var는 타입 추론 키워드로 사용되는 예약어입니다.
따라서 `<값>`에 어떤 데이터가 오는지에 따라 변수의 타입이 결정됩니다.
단, 값을 지정하지 않을 때는 `dynamic` 타입으로 자동 결정됩니다.

<tip>
 `dynamic?`
 타입 안정성이 보장되지 않지만, 모든 타입의 데이터를 할당할 수 있도록 해줍니다.
 보통 json 파일을 파싱할 때 임시로 데이터 형식을 지정할 때 많이 사용합니다.
</tip>

### final vs const

`final`과 `const` 둘 모두 데이터의 불변성을 보장하고 싶을 때 사용하는 키워드 라는 점에서는 공통점을 갖습니다.
또한, 이 키워드를 사용한다면 타입을 굳이 지정하지 않아도 알아서 `var`로 타입을 지정하는 효과가 있습니다.
하지만 둘 사이의 중요한 차이점이 있습니다.

`final`은 런타임에 값이 지정됩니다.
따라서 메모리상의 `heap 영역`에 데이터가 저장됩니다.
그렇기에 생명주기는 스코프 내부로 한정되기 떄문에 flutter 에서 **build 메서드**가 호출될 때 이 부분은 `반복적`으로 메모리에 올라왔다 내려갔다를 반복하게 됩니다.

`const`는 컴파일타임에 값이 지정됩니다.
특이한 점인 const 키워드로 지정된 데이터는 메모리상에 별도로 적재되지 않고, `컴파일된 코드의 상수 풀(constant pool)`상에 저장됩니다.
따라서 별도의 인스턴스가 생성되지 않고, 생명주기도 프로그램 수명과 동잃하기에 flutter 에서 **build 메서드**가 호출될 때 이 부분은 `다시 랜더링되지 않습니다`.

### late

dart는 **null-safety** 언어입니다.
따라서 `<타입>?` 와 같이 `?`로 null값이 가능하다고 지정해 주지 않는한 변수 선언시(혹은 인스턴스 생성시) 반드시 값을 지정해야 합니다.
하지만, `late`의 경우에는 인스턴스 생성 시점에 null값을 허용하지만, 이후에 `단 한번` 값을 할당할 수 있도록 해주는 키워드입니다.

물론, null값이 임시 허용이 되는만큼 사용에 주의가 필요합니다.

### static

`static`은 클래스가 로드될 때 값이 지정됩니다.
따라서 heap영역이 아닌 `클래스 자체 메모리 영역`에 저장됩니다.
그렇기에 일반 메서드에선 static 변수에 접근할 수 있지만, static 메서드에선 일반 변수에 접근할 수 없습니다.
하지만 그렇기에 클래스를 인스턴스화 하지 않아도 바로 접근이 가능합니다.

---

## function

dart는 사실 js를 대체하기 위해 나온 언어라고 합니다.
그래서일까요, dart의 모든 데이터 타입도 사실은 모두 `Object`입니다.

뿐만 아니라, `변수에 함수를 할당`하거나, `익명 함수`, `람다 함수` 모두 사용 가능합니다.

### named parameter

보통 함수의 파라미터는 아래와 같이 작성하곤 합니다.

```dart:.dart
 void myFunction(int num) {
 ...
 }
 ...
 myFunction(1);
```

하지만 입력받고자 하는 파라미터가 많아진다면, 인자를 넘겨줄 때 어느 자리에 어느 데이터를 넘겨야 할지 알기가 어렵습니다.
특히 flutter에서는 위젯을 만들 때 인자를 십수개씩 넘기는 경우가 많죠...

그렇기에 `named parameter` 기능을 제공합니다. (마치 js에서 객체를 인자로 넘기 듯)

```dart:.dart
 void myFunction({required int myNum}) {
 ...
 }
 ...
 myFunction(myNum: 1);
```

이렇게 하면 함수 호출이나, 클래스 생성자 호출시 어느 인자에 어느 데이터를 넘겨야 하는지 명확해집니다.

물론, 위 두 방식을 `혼합`하여 사용할 수도 있습니다.

```dart:.dart
 void myFunction(String str, {required int val}) {
 ...
 }
 ...
 myFunction("string", myNum: 1);
```

---

## class

### constructor

```dart:.dart
class Car {
 final String color;
 int wheels;
 String? name;

 Car({
 required this.color,
 required this.wheels,
 this.name,
 });
}
```

기본적으로 생성자는 위와 같이 정의할 수 있습니다.
`named parameter` 형식으로도 사용이 가능합니다. (대부분의 flutter 위젯은 위와 같이 정의합니다)

### named constructor

```dart:.dart
Car {
 final String color;
 late int wheels;
 String? name;

 Car.fourWheels({required this.color, this.name}) {
 this.wheels = 4;
 }
}
```

클래스를 생성할 때 특별한 기능을 붙인채로 인스턴스화 할 수 있도록 `named constructor`를 지원합니다.
보통 초기상태를 위한 `.init`, 모델링을 위한 `.fromJson`와 같이 쓰이곤 합니다.
(참고로 이 때 factory 키워드를 이용해서 싱글톤 패턴으로 많이 구현하는데 이는 다음에 소개하겠습니다)

### initializer list

위에 `wheels`을 별도로 초기화하기 위해 late 한정자를 사용했는데요, 보기가 안좋습니다.
`final` 멤버변수는 생성자 body에서 값을 지정할 수 없기에 저런식으로 표현했는데요,
`initializer list`를 이용하면 final 멤버변수도 생성자 호출시 별도로 처리할 수 있습니다.

```dart:.dart
class Car {
 final String color;
 final int wheels;
 String? name;

 Car.prototype({required this.color}) : wheels = 4 {
 this.name = 'proto';
 }
}
```

`:`를 붙여 `: wheels = 4`와 같이 사용할 수 있습니다.
또한, 뒤에 body를 붙여 추가작업 또한 할 수 있습니다.

initializer **list**에서 알 수 있듯 `wheels = 4` 와 같은 initializer를 `,`를 이용해서 여려개 연달아 초기화할 수 있습니다.

### redirecting constructor

```dart:.dart
class Car {
 final String color;
 final int wheels;
 String? name;

 Car({
 required this.color,
 required this.wheels,
 this.name,
 });

 Car.fourWheels({required String color, String? name})
 : this(
 color: color,
 wheels: 4,
 name: name,
 );
}
```

기존의 생성자를 `this`로 호출하여 named constructor를 구현한 방식입니다.
다만, 이 경우에는 생성자의 body를 구현할 수 없습니다.

Dart 언어에 대한 기초지식을 정리해봤습니다.

Dart 언어 기초

## 들어가며...

이 포스트에선 플러터(Flutter) 개발을 시작할 때 세팅해야할 전 과정에 대해 설명합니다.
Flutter SDK 설치부터 에뮬레이터 세팅, VSCode 세팅, 추가로 유용한 단축키에 대해서 알아봅니다.
다만, 단축키는 운영체제, 에디터 환경, 설정에 따라 다를 수 있으니 이점 참고 바랍니다.

<notice>
 **이미 설치를 완료하신 분들도 시간 내셔서 [**`VSCode 세팅`**](https://wjlee611.github.io/blog/flutter/001_installation#vscode-%EC%84%B8%ED%8C%85)부터 읽어보시는 것을 강력 추천드립니다.**
</notice>

블로그 주인장은 M1 Mac 환경에서 세팅하였기에 리눅스 계열 세팅방법을 기준으로 다뤄봅니다만,
윈도우 머신에서의 세팅도 다뤄볼 겁니다. (다만, 실제 테스트는 하지 않았기에 오류가 있을지도 모릅니다)

참고로 아래의 모든 설치과정은 [**노마드코더**](https://nomadcoders.co/flutter-for-beginners)의 강좌를 정리한 자료입니다.

- https://nomadcoders.co/flutter-for-beginners/lectures/4133
- https://nomadcoders.co/flutter-for-beginners/lectures/4142

---

## Flutter SDK 설치

Flutter SDK를 설치할 때 방법이 크게 두 가지로 나뉩니다.
첫 번째는 Flutter 공식 사이트에서 제공하는 방식을 따라가는 방법
두 번째는 패키지 매니저를 이용해서 설치하는 방법

제 개인적인 생각에는 패키지 매니저를 이용하는 방법이 더 간단해 보입니다.
첫 번째 방법을 따라하려면 환경 PATH도 설정해야 하기에 좀 무서워 보이기 때문이죠...
~_(그리고 제가 이 방법밖에 안해보기도 했구요...)_~

그래도 일단은 두 방법 모두 소개해 드리겠습니다.

### 공식 사이트

1. [**플러터 공식 페이지**](https://flutter.dev)로 접속합니다.

2. `Get started`로 들어갑니다.
 ![230913-211858](/posts/001_installation/230913-211858.png)

3. 본인 운영체제에 맞는 Flutter SDK를 설치합니다.
 ![230913-212121](/posts/001_installation/230913-212121.png)

 이후에는 공식 사이트에서 제공하는 문서를 천천히 따라하시면 됩니다.

---

### 패키지 매니저 (MacOS)

1. [**Homebrew**](https://brew.sh/)에 들어갑니다.
 ![230913-214251](/posts/001_installation/230913-214251.png)

<notice>
 _참고로 Homebrew는 MacOS에서 사용할 수 있는 **대부분의 개발자도구를 터미널로 설치할 수 있는 강력한 도구**입니다._
 _Flutter가 아니더라도 **반드시** 설치하는게 정신건강에 이롭습니다._
</notice>

2. `터미널`을 열어줍니다.

3. 아래의 명령어를 입력하여 Homebrew를 설치합니다.
 (공식 사이트에서 복사하는 것을 권장합니다)

```bash:Terminal
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

4. 아래의 명령어로 Flutter SDK를 설치합니다.

```bash:Terminal
brew install --cask flutter
```

---

### 패키지 매니저 (Windows)

1. [**Chocolatey - individual**](https://chocolatey.org/install#individual)에 들어갑니다.
 ![230913-213419](/posts/001_installation/230913-213419.png)

2. `PowerShell`을 관리자 권한으로 실행합니다.

3. 아래의 명령어를 입력하여 Chocolatey를 설치합니다.

```shell:PowerShell
Get-ExecutionPolicy
```

만약 `Restricted` 라고 뜬다면 아래의 명령어 중 하나를 입력하면 됩니다.

```shell:PowerShell
Set-ExecutionPolicy AllSigned
또는
Set-ExecutionPolicy Bypass -Scope Process
```

그 이후에 아래의 긴- 명령어를 입력합니다.
(공식 사이트에서 복사하는 것을 권장합니다)

```shell:PowerShell
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
```

`Chocolatey` 설치가 완료되었다면 `choco` 라는 명령어가 실행 가능할 겁니다.

4. 아래의 명령어로 Flutter SDK를 설치합니다.

```shell:PowerShell
choco install flutter
```

### 설치 확인 방법 (1)

터미널 창에 `flutter` 를 입력해봅시다.
`Command not found` 와 같은 에러를 제외하고 뭐라도 뜬다면 설치가 완료된 것입니다.

---

## 애뮬레이터 설치

아래의 공식 문서를 통해 설치하는 것이 가장 바람직합니다.
설명도 친절해서 왠만하면 설치하는데 문제가 없을겁니다. (아예 없진 않음...)
관련 링크를 아래에 정리합니다.

🫧[**MacOS - ios setup**](https://docs.flutter.dev/get-started/install/macos#ios-setup)
🫧[**MacOS - android setup**](https://docs.flutter.dev/get-started/install/macos#android-setup)

🫧[**Windows - android setup**](https://docs.flutter.dev/get-started/install/windows#android-setup)

### 설치 확인 방법 (2)

터미널 창에 `flutter doctor` 를 입력해봅시다.
![230913-220216](/posts/001_installation/230913-220216.png)

SDK, 애뮬레이터, 에디터까지 발생하는 문제사항을 한 눈에 파악할 수 있습니다.

<tip>
 참고로 최초 실행시 안드로이드 라이센스에 동의하라는 에러 혹은 경고가 나타날 수 있습니다. 
 그럴 땐 당황하지 마시고 아래의 명령어를 입력하면 됩니다.
 (_설치할 때 꼼꼼히 읽어보면 이런 내용도 있다는 걸 확인할 수 있죠..._)

 

 ```bash:Terminal
 flutter doctor --android-licenses
 ```
</tip>

### Troubleshooting

간혹가다 Xcode `command line tools`에서 문제가 발생하는 경우가 있습니다.
명령어 라인 도구는 Xcode를 설치할 때 자동적으로 설치됩니다.

하지만 제 경우에는 Xcode를 설치하기 전에 아래의 명령어로 미리 설치한 적이 있었습니다.

```bash:Terminal
xcode-select --install
```

명령어 라인 도구를 먼저 설치하고 Xcode를 설치하면 가끔 정상동작하지 않는 에러가 발생하는 거 같습니다.
이런 경우에는 명령어 라인 도구를 제거하고 다시 설치하면 해결됩니다.

---

## VSCode 세팅

사실 마켓플레이스에서 `Flutter`, `Dart` 확장을 설치하기만 하면 개발할 준비가 끝나긴 합니다.
하지만, 개발 편의성과 코드 통일을 위해서 필요한, 혹은 유용한 `확장`과 `setting.json`을 공유할까 합니다.

### setting.json

아래와 같은 키값을 추가하면 개발에 있어 편의성이 증진됩니다.
하지만, 설정을 건드릴 땐, 본인의 설정과 충돌이 생기는지 반드시 확인한 후에 추가하시는 것을 권장합니다.

참고로, setting.json은 `명령 팔레트`를 열고 `settings.json`을 검색하면 바로 나옵니다.
또 참고로, 명령 팔레트는 `Command(Window) + Shift + P` 명령어 조합으로 열 수 있습니다.

```json:settings.json showLineNumbers
{
 ...
 "editor.codeActionsOnSave": {
 "source.fixAll": true
 },
 "dart.previewFlutterUiGuides": true,
}
```

`Line 3-5`의 설정은 자동으로 필요한 모든 곳에 `const` 키워드를 삽입해주는 설정입니다.
flutter에서 const를 사용하는 것은 매우 중요한데 그 이유에 대해서는 다음에 설명하도록 하겠습니다.
일단은 가능하다면 반드시 const를 붙이는게 좋고, 이를 자동으로 붙여줄 수 있다는 것만 기억합니다.

`Line 6`의 설정은 flutter 위젯을 트리 구조로 선으로 연결해주는 설정입니다.
![230913-222546](/posts/001_installation/230913-222546.png)

flutter은 위젯의 depth가 깊어지는 단점이 있는데 이를 어느정도 극복하게 해주는 유용한 설정입니다.

### Error Lens

![230913-223129](/posts/001_installation/230913-223129.png)

Error Lens는 코드 문제의 원인을 에디터상에 바로 띄워주는 확장입니다.
실시간으로 무슨 에러가 있는지 한 눈에 확인할 수 있는게 개인적으로 매우 만족하면서 사용하고 있습니다.

![230913-223528](/posts/001_installation/230913-223528.png)

개인적으로 눈뽕(?) 방지를 위해 `line` 이 아닌, `message` 로 설정하는 것을 추천드립니다.

![230913-224036](/posts/001_installation/230913-224036.png)

또한, 분석 레벨에서 `info` 는 제거해주시는 것을 추천 드립니다.

flutter의 경우 info가 중첩되서 뜨는 경우가 많기에 위 두 세팅을 바꾸지 않으면 아래와 같은 눈뽕(?)을 자주 겪게 될 지도 모릅니다...
![230913-223954](/posts/001_installation/230913-223954.png)

### Image preview

![230913-224456](/posts/001_installation/230913-224456.png)

Image preview는 로컬, 네트워크 이미지를 미리보기 형식으로 띄워주는 확장입니다.
FE 개발 입장에서 이미지나 svg, icon을 사용할 일이 많은데, 이를 미리볼 수 있다는 것 만으로도 많은 시간을 절약할 수 있습니다.

---

## VSCode 단축키

개발 시간을 줄여주는 유용한 단축키 및 snippets 를 소개합니다.

### Code Action

![230913-224956](/posts/001_installation/230913-224956.png)

flutter 개발을 하다보면 중간에 위젯을 다른 위젯으로 감싸거나, 부모 위젯을 통째로 드러내야 하는 경우가 잦은데,
이를 일일이 코드를 잘라내고 붙여넣기 하는건 매우 귀찮은 작업입니다.

하지만 이 기능을 수행하는데 있어 Code Action은 매우 유용한 도구들을 제공합니다.

기능을 수행하고자 하는 위젯의 좌측에 `💡(전구) 모양 아이콘`을 클릭하면 해당 위젯에서 수행할 수 있는 여러 기능들을 보여줍니다.

또는 `Command(Window) + .` 단축키로 빠르게 Code Action에 접근할 수 있습니다.
매우매우 자주쓰는 기능이니 본인 에디터 환경에 맞는 단축키를 외우도록 합시다.
~_(사실 외울 필요도 없이 쓰다보면 손가락이 알아서 움직이게 된다는...)_~

### Intellisense

쉽게 말하면 `코드 추천 + 자동완성` 기능입니다.

코드를 입력하다 보면 자동으로 코드를 추천해줄텐데, 실수로 이를 꺼버리는 일이 발생합니다.
이 경우 코드를 지웠다가 다시 치는 것 보단, `Option(Alt) + Space`로 다시 활성화 시키는 것이 더 유용합니다.

### st + (intellisense)

![230913-230035](/posts/001_installation/230913-230035.png)

플러터의 위젯의 대부분은 Stateful, Stateless 위젯을 상속 받습니다.
그에 따라 여러 메서드를 override해서 사용해야만 하는데요,
이 모든 코드를 일일이 입력하는 것도, 기억하는 것도 쉽지 않습니다.

이 경우에는 `st`를 입력하고 intellisense 기능을 이용하면 VSCode가 알아서
Stateful, Stateless 위젯의 필수 부분을 알아서 완성해주고,
클래스 이름과 관련한 부분 모두를 선택한 상태로 사용자의 입력을 기다리게 됩니다.

따라서 사용자는 아래의 절차를 밟으면 간단하게 위젯 하나를 생성할 수 있게 됩니다.

1. st + (intellisense)
2. 원하는 부모위젯(Stateful, Stateless) 선택
3. 원하는 클래스 이름 입력

## 마무리

지금까지 Flutter SDK 설치부터 VSCode 단축키까지 개발에 앞서 필요한 모든 준비단계를 알아봤습니다.
추가로 필요한 설정이나 기능은 알아보시고 추가하여 사용하신다면, 개발이 조금이라도 더 즐거워지리라 생각됩니다.

긴 글 읽어주셔서 감사드리고, 모두 알찬 `Flutt-er` 생활 되시길 바랍니다!

플러터 설치 및 VSCode 세팅 가이드입니다.

플러터 시작하기

스스로 배우며 깨달은 플러터 지식의 산실입니다.