[개발하는남자 핸즈온 플러터] 챕터10 첫 페이지 진입 처리 - 최신화

개요

안녕하세요 개발하는남자 개남입니다. 지난 포스트에 이어서 핸즈온 플러터 챕터 10장을 리뷰 하겠습니다. 이번장에서는 크게 리뷰할 부분이 딱히 없습니다. 책에 나와있는 설명을 잘 읽어 보시면 내용 이해가 어렵지 않게 되실 것입니다.
이번 포스팅에서는 최신 라이브러리 최신화 부분과 간단한 코드 리뷰정도 진행하고 다음 장 리뷰로 넘어가겠습니다.

소스코드 : https://github.com/sudar-life/bamtol_market_clone_coding
브런치 정보 : chapter10
플러터 버전 : Flutter 3.32.5
Dart 버전 : Dart 3.8.1

코드리뷰

main 함수

모든 서비스는 보통 main함수로 부터 시작됩니다. 플러터 역시 main 함수로 앱이 실행이 되며 이때 부터 소스코드를 따라 분석하면 전반적인 소스를 확인 할 수 있습니다.

late SharedPreferences prefs;
void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  prefs = await SharedPreferences.getInstance();
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );

  runApp(const MyApp());
}

여기에서 SharedPreferences를 main 함수 밖에 선언했습니다. 이는 전역 변수를 선언한 것으로 소스코드 어디에서든 해당 prefs를 참조해서 접근할 수 있습니다.

전역 변수의 장점

1.접근성

프로그램 어디서든 접근 가능
함수 간 데이터 공유가 쉬움
매개변수로 전달할 필요 없음

2.편의성

코드 작성이 간단함
여러 함수에서 같은 데이터를 사용할 때 편리
설정값이나 상수를 저장하기 좋음

3.메모리 효율성

한 번만 할당되어 메모리 사용량 절약
프로그램 종료 시까지 유지됨

전역 변수의 단점

1.네임스페이스 오염
2.예측 불가능성

어디서든 수정이 가능하기 때문에 예상치 못한 값이 나올 수 있음

3.디버깅 어려움

어디서 수정이 되었는지 추적이 어려움
여러 함수에서 동시에 접근하면 버그 발생 가능성

4.메모리 누수

프로그램 종료까지 메모리에 남아있음
가비지 컬렉션 대상이 되지 않음

책에서는 손쉽게 접근하여 구현이 가능한것을 보여드리기 위함으로 전역변수로 진행하였습니다. 원래 앱을 설계한다고 한다면 영구저장소 관리 컨트롤러를 만들거나 서비스를 만들어서 의존성을 주입하여 개발을 진행하게 될 것입니다.

MyApp클래스

return GetMaterialApp(
    title: '당근마켓 클론코딩',
    initialRoute: '/',
    theme: ThemeData(
    appBarTheme: const AppBarTheme(
        elevation: 0,
        color: Color(0xff212123),
        titleTextStyle: TextStyle(
        color: Colors.white,
        ),
    ),
    scaffoldBackgroundColor: const Color(0xff212123),
    ),
    getPages: [
        GetPage(name: '/', page: () => const App()),
    ],
);

다음 함께 살펴볼 부분은 MyApp클래스의 build 함수 부분입니다. 밤톨마켓클론코딩의 상태관리는 손쉽게 관리하기 위해 Getx를 사용했습니다. Getx의 상태관리 뿐 아니라 route 관리까지 같이 해주기 때문에 이를 사용하기 위해서는 기존 MaterialApp 클래스를 wrapping한 GetMaterialApp으로 변경해주면 기존의 설정인 MaterialApp 클래스의 모든 옵션들을 그대로 사용하면서 추가적으로 route 부분만 Getx를 이용할 수 있게 처리가 됩니다.

initalRoute로 / 경로로 설정했고 getPages옵션에 정의한 배열의 첫번째 요소를 보면 GetPage클래스를 사용해서 / 경로를 정의하고 있습니다. 해당 경로로 route될때는 App 이라는 클래스를 실행되도록 정의했다고 보시면 되겠습니다.

그럼 앱이 실행되면 자동적으로 App 클래스가 실행될 것이라고 예상을 하면 되겠습니다.

App 클래스

1.initState함수

@override
void initState() {
    super.initState();
    isInitStarted = prefs.getBool('isInitStarted') ?? true;
}

이미 책을 통해 Flutter위젯에 대해 공부를 했다면 StatefulWidget의 라이프사이클의 내용을 이해하고 있을 것입니다. 한번 집고 넘어가자면 initState함수는 위젯이 생성될때 한번만 호출이 되고 두번다시 호출되지 않는 함수 입니다.

💡
상위 위젯이 해당 위젯을 다른 위젯으로 변경한뒤 다시 화면에 그려지게 될 경우는 다시 생성되는 것이기 때문에 initState함수는 다시 불리게 됩니다.

위 라이프 사이클을 이해하고 initState를 통해 prefs에서 isInitStarted값을 불러옵니다. 해당 값에 따라 InitStartPage위젯을 그릴지 SplashPage위젯을 그릴지를 결정하게 됩니다.

2.build 함수

return isInitStarted
    ? InitStartPage(
        onStart: () {
            setState(() {
                isInitStarted = false;
            });
            prefs.setBool('isInitStarted', isInitStarted);
        },
        )
    : const SplashPage();

여기서 이야기 하고 넘어갈 부분은 InitStartPage위젯의 onStart라는 옵션입니다. 해당 옵션은 함수를 선언하도록 설계되었습니다. 해당 함수는 사용자가 시작하기 버튼을 클릭하면 호출될 함수입니다. 클릭 이벤트는 InitStartPage위젯에서 발생하는데 왜 그 이벤트를 왜 부모인 App위젯으로 반환해서 처리 하는 걸까요?

사실 InitStatePage에서 이벤트 처리 해도 되고 App으로 넘겨줘서 처리해도 상관은 없습니다. 다만 이렇게 설계한 이유에 대해서 말씀을 드리자면

만일 InitStatePage에서 prefs를 통해 값을 바꾸고 보여지고 있는 페이지를 InitStartPage에서 SplashPage로 전환시키기 위해서는 App위젯으로 상태가 변경되었다는 신호를 전달해주면됩니다. 그렇게 하기 위해서는 상태관리인 Getx를 통해 Controller를 정의하고 App에서 이를 감지하고 있도록 해야 합니다.

복잡성을 줄이고 간단하게 StatefulWidget의 setState의 특성을 활용하기 위하여 시작하기 버튼 이벤트를 App위젯으로 전달해서 화면전환을 가능하도록 만들어 낸것입니다.