프로젝트에서 보기 →

[앱개발] [Flutter] Flutter 개발자는 무조건 알아야 하는 GetX [#1-Navigation]

태그
기술 프로그래밍 코딩 무료 교육
시작일
종료일
수정일

https://www.youtube.com/watch?v=wgJItCEL7hk

1. 이건 꼭 알아야 한다[^1]

[? 질문] Flutter에서 페이지 이동(라우팅) 코드를 왜 더 간단하게 만들 필요가 있는가[^6]
[= 답] 기본 Navigator 방식은 context, MaterialPageRoute, builder 등 반복적 보일러플레이트가 많아 코드가 길어지고 번거롭기 때문에, GetX는 이를 Get.to() 같은 형태로 짧고 직관적으로 대체한다.[^6][^10]

[? 질문] GetX의 Navigation은 어떤 “이동 패턴”들을 어떤 API로 제공하는가[^8]
[= 답] 단순 push(Get.to), 이전 페이지 제거(pushReplacement 성격, Get.off), 전체 스택 제거 후 새 페이지(pushAndRemoveUntil 성격, Get.offAll), 안전한 뒤로가기(Get.back)까지를 간결한 호출로 제공한다.[^8][^12][^18]

[? 질문] 라우팅 시 “값 전달/리턴”, “전환 애니메이션”, “네임드 라우트 + 파라미터/쿼리”는 어떻게 처리되는가[^19]
[= 답] arguments 전달은 Get.arguments로 바로 받으며, 페이지에서 Get.back(result: ...)로 리턴값을 돌려줄 수 있고, transition으로 애니메이션을 쉽게 지정하며, GetPage 기반 네임드 라우팅에서 :param 및 쿼리(?id=...)를 Get.parameters로 간단히 받는다.[^19][^26][^31][^40]

2. 큰 그림[^2]

이 콘텐츠는 Flutter 개발자가 GetX를 사용할 때 가장 체감이 큰 영역 중 하나인 **Navigation(라우팅/화면 전환)**을 중심으로, 기존 Navigator 대비 코드량을 줄이고 기능(스택 제어, 값 전달, 트랜지션, 네임드 라우트 파라미터)을 단순화하는 방법을 예제 버튼들로 단계적으로 시연한다.[^2][^7] 또한 Navigation과 함께 GetX가 제공하는 SnackBar / Dialog / BottomSheet 유틸리티 호출 방식도 “번거로운 기본 구현을 얼마나 줄이는지” 관점에서 빠르게 덧붙인다.[^41][^51]

  • GetX는 Flutter 앱에서 MaterialApp을 GetMaterialApp으로 바꾸는 최소 세팅만으로 내비게이션 기능을 확장한다.[^4][^5]
  • 화면 이동은 Navigator.push(...) 같은 긴 코드를 Get.to(...) 등으로 바꿔 보일러플레이트를 제거하는 방향으로 설계되어 있다.[^6][^10]
  • 네임드 라우트에서 파라미터/쿼리 처리(웹 라우팅처럼)와 각종 UI 유틸(SnackBar/Dialog/BottomSheet) 호출을 간단한 API로 제공해 개발 흐름을 빠르게 한다.[^31][^40][^51]

3. 하나씩 살펴보기[^3]

3.1 GetX는 3개 축(내비게이션/상태관리/DI)으로 나뉜다[^3]

📸 0:06

영상 도입부에서 발표자는 GetX를 크게 3가지 토픽으로 나눈다.[^3]

  1. 내비게이션(Navigation)[^3]
  2. 상태 관리(State Management)[^3]
  3. 디펜던시 인젝션(Dependency Injection)[^3]

발표자 개인 의견으로는 상태 관리는 본인이 주로 써온 Provider가 더 직관적이고 유용하게 느껴졌다고 말한다.[^3] 다만 GetX 전체를 부정하는 게 아니라, “내가 봤을 때 가장 유용했던 것”으로 Navigation을 먼저 설명하겠다고 방향을 잡는다.[^3]

[!NOTE] 발표자의 관점(맥락) GetX를 “전부 도입해야만 하는 프레임워크”라기보다, 영역별로 강점이 다를 수 있고 그중에서도 본인은 내비게이션 체감이 가장 컸다는 전제를 깔고 설명을 진행한다.[^3]

3.2 내비게이션을 쓰기 위한 최소 세팅: GetMaterialApp으로 교체[^4]

📸 0:43

발표자는 GetX 내비게이션을 쓰기 위해 “세팅을 딱 한 가지만 하면 된다”고 말한다.[^4]

  • (전제) 패키지는 설치해야 한다. 영상에서는 “GetX dependency를 받는다”는 식으로 언급한다.[^4]
  • main.dart에서 기존에 보통 쓰는 MaterialApp을 GetMaterialApp으로 교체한다.[^5]

핵심 논리는 다음과 같다.[^5]

  • GetMaterialApp은 MaterialApp을 확장(extend)한 형태라서,
    • GetX 기능도 사용 가능하고
    • 일반적인 MaterialApp 기능도 그대로 동작한다.[^5]

즉, 앱의 최상단을 감싸는 App 위젯을 교체함으로써 GetX 라우팅/유틸 API들을 사용할 준비가 끝난다는 설명이다.[^4][^5]

3.3 (버튼 1) 기본 라우트 이동: Navigator.push의 장황함 vs Get.to 한 줄[^6]

📸 1:31

발표자는 첫 번째 데모로 “스크린 투(Screen2)로 이동” 버튼을 보여준다.[^6]

기존 방식: Navigator.push + MaterialPageRoute + builder

일반적으로 Flutter에서 라우트를 이동할 때 다음 형태를 많이 쓴다고 한다.[^6]

  • Navigator.push(context, MaterialPageRoute(builder: (_) => Screen2())) 같은 패턴[^6]

발표자는 이 방식에 대해:

  • “굉장히 (코드가) 길다”[^6]
  • “쓸데없이 코드를 많이 써야 되는 경향이 있다”[^6]
  • 본인도 늘 그렇게 생각했지만, 이를 일반화해서 줄이는 방식을 직접 만들 생각은 안 했다고 말한다.[^6]

GetX 방식: Get.to(Screen2())

GetX에서는 같은 동작을 다음처럼 줄인다고 시연한다.[^10]

  • Get.to(Screen2()) 처럼 “Get.to라고 한 다음에 스크린만 넣으면 바로 이동”[^10]

버튼을 눌렀을 때 실제로 화면이 이동하며, 네비게이션 스택에 새 페이지가 하나 올라가는 것도 확인한다고 설명한다.[^10][^11]

[!TIP] 가장 먼저 체감되는 GetX 내비게이션 이점 “push 하려면 context 필요하고 라우트 객체 만들고 builder 넣고…” 같은 반복을 Get.to()로 줄여 화면 이동 코드가 한 줄이 된다.[^6][^10]

3.4 (버튼 2) 이전 페이지로 돌아오지 못하게: pushReplacement 성격(페이지 1개 제거)[^12]

📸 2:12

두 번째 데모는 “전 페이지로 돌아가지 못하게 하는 것”을 보여준다.[^12]

발표자의 설명은 “페이지 스택에서 딱 하나의 페이지만 지우는 것”이라는 표현으로 정리된다.[^12] 예시는 다음 흐름이다.[^12]

  • 현재 GetX navigation 데모 페이지에서 다음 스크린으로 넘어간다.[^12]
  • 일반적인 push라면 뒤로 가기 시 다시 이전 페이지(이 데모 페이지)로 돌아온다.[^12]
  • 하지만 여기서는 이 페이지 자체를 스택에서 제거하고 넘어가므로, 뒤로 가기를 누르면 그 전 단계(예: 홈)로 가 버린다.[^12][^13]

발표자는 이를 기존 Flutter에서 보통:

  • pushReplacement 류로 썼다고 언급하면서 “아예 그냥 대체(replacement)해버리는 방식”이라고 설명한다.[^13]

GetX에서는 이를 Get.off(...) 형태로 간단히 만든다고 시연한다.[^14]

3.5 (버튼 3) 모든 페이지 스택 삭제: 스플래시/로그인 이후에 자주 쓰는 패턴[^15]

📸 3:06

세 번째 데모는 “모든 페이지 스택 삭제하기” 버튼이다.[^15] 발표자는 이 패턴이 실제 앱에서 자주 등장한다고 맥락을 준다.[^15]

  • 스플래시 스크린, 로그인 스크린 같은 흐름에서
    “어떤 한 페이지를 띄운 뒤, 지금까지 봐왔던 모든 페이지들을 네비게이션 스택에서 다 삭제”하는 방식을 많이 쓴다.[^15]

기존 Flutter에서는 pushAndRemoveUntil을 떠올리게 하는, 조건을 걸어 스택을 정리하는 코드를 작성해야 한다는 뉘앙스로 말한다.[^15] GetX에서는 이를 한 줄로 가능하게 한다며:

  • Get.offAll(Screen...) 계열 호출로
    “모든 페이지를 삭제하고 새로운 페이지 push”를 한다고 시연한다.[^16][^17]

버튼을 눌러 다음 페이지로 간 뒤, 뒤로가기를 눌러도 더 이상 돌아갈 페이지가 없음을 확인시킨다.[^17]

3.6 안전한 뒤로가기: pop할 곳이 없을 때 검은 화면 문제와 Get.back의 처리[^18]

📸 3:47

발표자는 “조금 특이한데”라며 뒤로가기(팝) 관련 안전성 이야기를 한다.[^18]

문제 상황: pop할 스택이 없는데 pop을 호출하면?

일반적으로 Navigator.pop(context)를 호출했는데 실제로 돌아갈 페이지가 없으면 앱이 “검정색 스크린”처럼 이상 상태가 되거나, 결과적으로 앱을 나가버리는 동작이 생길 수 있음을 언급한다.[^18][^20]

그래서 보통은:

  • “뒤로 갈 페이지가 있는지 없는지 확인한 다음에 pop 시키지 않는다”[^20]
  • 즉, 조건문으로 방어 로직을 넣는 경우가 많다.[^20]

GetX 해결: 조건문 없이 “안전하게 back”

GetX에서는 이 과정을:

  • “if문 사용할 필요 없이 Get.back()을 하면, 라우팅이 안전하게… 기록(뒤로가기)이 불가능할 때는 뒤로 안 가게 된다”라고 설명한다.[^21]

발표자는 이를 “굉장히 유용”하다고 평가한다.[^21]

[!IMPORTANT] 뒤로가기 안정성의 요지 [h pop 가능한지 매번 확인하는 보일러플레이트를 줄이고, 불가능하면 동작하지 않도록 안전장치를 제공한다]는 관점에서 Get.back()을 장점으로 제시한다.[^20][^21]

3.7 GetX 내비게이션의 총평: “많이 써야 되는 코드를 짧게”[^22]

📸 4:37

앞의 데모들을 묶어 발표자는 GetX 내비게이션이:

  • “굉장히 많이 써야 되는 코드를 짧게 쓸 수 있게 하도록 노력을 많이 한 것 같다”[^22]
  • 그래서 그런 점에서 유용하다고 생각한다고 정리한다.[^22]

이후 “내비게이션은 아규먼트(값)도 보내야 하고, 다른 페이지에서 받아오기도 해야 한다”는 요구사항을 제기하며 다음 주제로 넘어간다.[^23]

3.8 페이지에서 값 받아오기(리턴값): await Get.to + Get.back(result: ...)[^24]

📸 4:46

발표자는 “다음 페이지에서 값을 받아올 수도 있어야 된다”고 말하며, GetX에서는 이것도 간단하다고 소개한다.[^23][^24]

흐름 1) A 페이지에서 B로 이동하며 “결과를 기다림”

  • A(예: Screen1)에서 Get.to(Screen...)를 호출할 때 await로 결과를 받을 수 있다고 한다.[^24]

흐름 2) B 페이지에서 값을 선택하고 뒤로가며 result로 반환

예제로 발표자는 라디오 버튼 3개(0~2)를 만들어 선택하게 했다고 설명한다.[^25]

  • 사용자가 2를 누른 뒤 뒤로 가면, B에서 Get.back(result: 2) 같은 방식으로 “원하는 값을 집어넣으면, await 하고 있던 전 route에서 값을 받을 수 있다”고 설명한다.[^26]

시연으로:

  • 2를 선택하고 뒤로 가면 전 페이지에서 2를 받는 장면을 보여주고[^27]
  • 1을 선택해도 1을 받으며[^27]
  • 0을 선택하면 0도 받는다는 식으로 “유연하게… 짧은 코드만 가지고도 라우팅하면서 값을 받아올 수 있다”는 결론으로 정리한다.[^27][^28]

3.9 다음 페이지로 값 보내기(arguments): Get.arguments로 바로 받기[^29]

📸 6:08

이제 “값을 보내는 건 어떻게 하냐, 아규먼트를 보내는 건 어떻게 하냐”로 넘어간다.[^29]

발표자는 여기서도 GetX가 간결하다고 말한다.[^29]

보내기

  • Get.to(다음페이지, arguments: ...) 같은 방식으로 보낸다는 취지로 설명한다.[^29]

받기

받는 방법은 “훨씬 더 간편”하다고 강조하며, 본인이 작성한 코드는 사실상:

  • 화면에서 Get.arguments를 텍스트로 표시하는 정도로 끝이라고 말한다.[^30]

즉, 별도의 복잡한 추출 과정 없이:

  • “그냥 Get.arguments라고만 작성하면 통째로 가져올 수 있다”[^33]

라고 주장한다.

시연에서는 전달 텍스트를 바꿔가며(예: “약은 해요” → “코드팩토리” → 다른 문자열) 저장 후 다시 보내면 수신 화면에 그대로 바뀐 값이 나타나는 것으로 “내가 보낸 게 맞다”를 보여준다.[^32][^33]

발표자는 예전 방식은 받을 때 “귀찮은 작업들이 굉장히 많았다”고 대비시키며, 이제는 훨씬 편해졌다고 말한다.[^33][^34]

3.10 트랜지션(전환 애니메이션): 기본 제공 옵션을 transition 파라미터로[^35]

📸 7:26

다음 주제는 Transition이다.[^35] 발표자는 GetX가 기본으로 제공하는 트랜지션이 “굉장히 많이 있다”고 말한다.[^35]

예를 들어:

  • transition에 특정 옵션(영상에서는 “왼쪽에서 오른쪽” 이동 같은 동작을 언급) 값을 넣으면[^36]
  • 버튼을 눌렀을 때 해당 방식으로 화면이 전환되는 것을 보여준다.[^36]

또 다른 예로 fade in도 언급하며 점점 페이드인 되는 장면을 보여준다.[^37]

정리 메시지는:

  • 트랜지션 옵션이 많고
  • 이를 사용하면 “되게 다이나믹한 앱을 만들 수 있다”
  • 그리고 트랜지션도 “굉장히 간단하게 쓸 수 있다”는 것이다.[^38]

3.11 (발표자가 “진짜 유용”하다고 꼽은 것) 네임드 라우트 + 파라미터/쿼리 처리[^39]

📸 8:17

발표자는 GetX에서 “너무 유용하다고 생각했던 것 중 하나”로 네임드 라우트를 든다.[^39]

기존 경험: MaterialApp의 onGenerateRoute로 네임드 라우트 사용

Flutter에서 onGenerateRoute를 써서:

  • /2면 Screen2, /3면 Screen3 같은 매핑을 하는 것은 원래도 가능하다고 전제한다.[^39][^40]

문제: 파라미터까지 하려면 생각보다 “엄청 귀찮다”

발표자는 “onGenerateRoute에서도 파라미터 넣는 걸 할 수는 있는데, 방법이 생각보다 엄청 귀찮다”고 말한다.[^40]

특히 웹 라우팅처럼:

  • path parameter와 query 개념을 써야
    “되게 다이나믹한 UI”를 만들 수 있는데, 이를 Flutter 기본 라우팅에서 직접 처리하려면 번거롭다는 문제의식을 말한다.[^40][^41]

GetX의 해결: 이미 다 핸들링되어 있다

발표자는 “그거를 이미 다 핸들링해준다”고 말한다.[^41]

구성은 대략:

  • GetPage로 라우트들을 선언하고[^39]
  • 예: /2, /3, /5 등에 스크린을 연결한다.[^39]

여기에 더해 파라미터/쿼리까지 쉽게 다룬다는 게 핵심이다.[^41]

3.12 path parameter(:param) 받기: 콜론의 의미와 Screen5 예제[^42]

📸 9:19

발표자는 콜론(:) 문법을 설명한다.[^42]

  • URL에서 /something/:variable처럼 콜론 뒤에 오는 것은 변수로 작용한다.[^42]
  • 즉, 그 구간은 “다이나믹하게 값이 바뀔 수 있다”는 뜻이다.[^42]

예제:

  • Screen5가 있고, 여기서 :param(영상에서는 :something 또는 :param과 유사한 이름) 값을 받을 거라고 한다.[^43]
  • 홈에서 .../5/1234처럼 입력하고 네임드 라우트를 누르면 Screen5에서 1234가 표시되는 것을 보여준다.[^43][^44]

그리고 값을 test로 바꿔 보내도 Screen5에 test로 바뀌어 표시됨을 시연한다.[^45]

3.13 query parameter(?id=...&name=...) 받기: Get.parameters로 확장[^46]

📸 10:15

발표자는 “추가적으로 쿼리를 보내고 싶다”는 상황을 든다.[^46]

예:

  • URL 뒤에 ?id=4 같은 형태로 붙여 보낼 수 있다고 말한다.[^46]

시연은 대략:

  • .../5/test?id=4처럼 만들어 보내면 이동 후 해당 쿼리 값이 함께 전달되는 것을 확인한다.[^47]

또한:

  • name=cf 같은 추가 쿼리를 붙여도 되며[^48]
  • 수신 페이지에서 Get.parameters를 사용해 name까지 받아오는 모습을 보여준다.[^49]

발표자는 이를 통해:

  • path parameter와 query를 마음대로 조합해
  • “실제 웹에서 URL 네비게이션 하는 것처럼, 굉장히 복잡하게 네비게이션을 빌드할 수 있다”고 결론낸다.[^50]

그리고 개인적으로 “이런 점이 가장 유용하더라”라고 다시 평가한다.[^50]

3.14 네임드 라우트의 부가 이점: Google Analytics 라우트 자동 처리[^51]

📸 11:14

발표자는 네임드 라우트를 쓰면:

  • Google Analytics에서 라우트를 자동으로 가져가 처리해 주기 때문에 “굉장히 편하다”고 말한다.[^51]

그래서 “네임드 라우트를 굉장히 잘 활용했으면 좋겠다”고 권한다.[^52]

3.15 라우팅 외 보너스: GetX SnackBar는 한 줄, 옵션도 많고 ‘위에서 나오게’도 가능[^53]

📸 11:32

발표자는 “라우팅에 대한 건 아닌데”라며 몇 가지를 짧게 보여주겠다고 한다.[^53] 첫 번째가 SnackBar다.[^53]

기본 ScaffoldMessenger 방식의 번거로움 대비

원래 스낵바는 코드가 길다고 언급한다(“굉장히 코드 많이 써야 되잖아요”).[^53]

GetX에서는:

  • 제목(title)과 내용(message)만 넣으면 되는 식으로 간단히 띄울 수 있다고 말한다.[^54]

시연으로 스낵바가 뜨는 것을 보여주고[^55], position 옵션을 바꾸면:

  • 기본(위에서 나오는 형태를 언급)과 다르게
  • 아래에서 올라오게 할 수도 있음을 보여준다.[^56]

또한 스낵바 옵션이 “굉장히 많다”고 하며, 원하는 스낵바를 만들 수 있다고 말한다.[^57]

특히 본인 기억으로는 기본 스낵바는 “위에서 나오게 못하는”데 GetX에서는 가능하다는 점을 “큰 장점”으로 언급한다.[^58]

3.16 Dialog: defaultDialog로 즉시 띄우고, Get.dialog로 위젯 직접 넣어 커스터마이즈[^59]

📸 12:41

다음은 Dialog다.[^59]

  • Get.defaultDialog에 “미드 텍스트” 같은 최소 값만 넣어도 다이얼로그가 바로 나온다고 설명하며 시연한다.[^59][^60]

발표자는 기존 방식에서는:

  • showDialog 호출, builder, context 전달 등 거쳐야 해서 번거롭다고 대비한다.[^61]

그리고 GetX의 커스터마이즈 방향을 2가지로 설명한다.[^62]

  1. defaultDialog 안에서도 설정 가능한 값들이 많아서 어느 정도 커스터마이즈 가능[^62]
  2. 더 나아가 Get.dialog(...)로 실제 Dialog 위젯을 직접 넣어 원하는 다이얼로그를 구현할 수도 있다[^62][^63]

결국 “겉으로는 간단하게 많은 걸 처리해주지만, 원하면 커스터마이즈도 가능”하다는 메시지다.[^63]

3.17 BottomSheet: Get.bottomSheet에 렌더링할 위젯을 넣기만 하면 됨[^64]

📸 13:29

마지막 보너스는 BottomSheet다.[^64]

발표자는 바텀시트도 원래는 “귀찮은 점이 많았다”고 말한 뒤[^64], GetX에서는:

  • Get.bottomSheet(...) 하고
  • 그 안에 렌더링하고 싶은 것을 “그대로 집어넣으면 된다”고 말한다.[^65]

결과적으로 바텀시트가 뜨는 것을 보여주며 마무리한다.[^65]

3.18 결론/권장: 상태관리는 당장 못 바꿔도 Navigation/SnackBar/Dialog/BottomSheet만 바꿔도 코드가 줄어든다[^66]

📸 13:50

발표자는 전체 결론으로:

  • GetX가 내비게이션과 스낵바 같은 것들을 “생각하는 대로 쓰면 되게” 잘 구현해 둔 것이 큰 장점이라고 말한다.[^66]

또한 현실적인 도입 전략을 제시한다.[^67]

  • 상태 관리는 기존 프로젝트에서 쉽게 바꾸기 어렵다.[^67]
  • 하지만 GetX로 내비게이션, 스낵바, 다이얼로그, 바텀시트 사용만 바꿔도
    • 코드 양이 크게 줄고
    • 훨씬 더 직관적이 될 것이라고 주장한다.[^67]

발표자는 “분명히 도움이 많이 될 것”이라고 말하며, 이후 강의에서는 상태관리/DI도 계획 중이라고 예고한다.[^68]

마지막으로 코드는 GitHub에 호스팅되어 있으니 궁금하면 클론해서 보라고 안내하며 종료한다.[^69]

[!TIP] 점진적 도입 제안(발표자 제안) [h GetX를 ‘상태관리까지 전면 도입’하지 않더라도, Navigation/UI 유틸부터 바꾸면 즉시 효용(코드 감소/직관성)을 얻을 수 있다]는 전략을 제시한다.[^67]

4. 핵심 통찰[^70]

  1. [h GetX Navigation의 핵심 가치는 “context 기반 보일러플레이트 제거”다.] 화면 전환에서 반복되는 context + Route + builder 구성을 Get.to() 등으로 치환해 코드 길이/복잡도를 줄이는 데 초점이 맞춰져 있다.[^6][^10]

    • 실행: 기존 Navigator.push가 많은 프로젝트라면, 우선 이동 로직을 Get.to / Get.off / Get.offAll로 치환해 코드량 변화를 체감해본다.[^10][^14][^16]

  2. [h 스택 제어(교체/전체삭제)가 API 레벨로 정리돼 있어 앱 플로우(로그인/스플래시)에 특히 유리하다.] “이전 화면으로 돌아오면 안 되는” 구간에서 Get.off, “과거 스택을 모두 지우고 새 시작점으로”는 Get.offAll로 간단히 표현할 수 있다고 제시한다.[^12][^15][^17]

    • 실행: 로그인 성공 후 홈 진입 시 offAll을 적용해 뒤로가기로 로그인 화면이 뜨지 않게 설계한다.[^15][^17]

  3. [m 뒤로가기 안정성은 실무에서 자주 나오는 예외처리 포인트다.] pop 가능한지 검사하는 방어 로직을 줄이고, 불가능하면 동작하지 않게 하는 Get.back의 “안전한 back”을 장점으로 든다.[^20][^21]

    • 실행: 커스텀 back 버튼/제스처 처리에서 Navigator.pop 직접 호출 대신 안전 동작을 검토한다.[^21]

  4. [h “값 전달/결과 반환”이 단순화되면 화면 간 상호작용 UI를 빨리 만들 수 있다.] Get.arguments로 수신을 단순화하고, Get.back(result: ...)로 결과를 반환하는 패턴을 시연하며, 라디오 선택값(0~2) 반환 같은 상호작용을 쉽게 구성할 수 있음을 보여준다.[^25][^26][^33]

    • 실행: 선택 화면(필터/정렬/옵션 선택)을 별도 페이지로 분리한 뒤 result 반환 구조로 재사용한다.[^26][^28]

  5. [c 네임드 라우트에서 path/query 파라미터를 “웹처럼” 쓰는 기능이 발표자가 꼽는 최강점이다.] :param과 ?id=...&name=... 같은 조합을 Get.parameters로 받는 흐름을 통해, 동적 라우팅을 쉽게 구성할 수 있다고 강조한다.[^40][^42][^49]

    • 실행: 상세 페이지를 /product/:id 같은 형태로 구성하고, 필터/탭 상태는 쿼리로 분리하는 URL 설계를 검토한다.[^42][^46]

  6. [m UI 유틸(SnackBar/Dialog/BottomSheet)은 “기본 구현의 귀찮음을 줄이는” 생산성 도구로 소개된다.] Get.snackbar, Get.defaultDialog, Get.bottomSheet처럼 간단 호출로 띄우고 옵션도 풍부하다는 점을 장점으로 든다.[^54][^59][^65]

    • 실행: 공통 알림/확인 다이얼로그를 GetX 유틸로 표준화해 호출 코드를 단순화한다.[^59][^63]

5. 헷갈리는 용어 정리[^71]

GetMaterialApp: MaterialApp을 확장한 GetX 버전의 앱 루트 위젯으로, GetX 내비게이션/유틸 기능을 사용하기 위한 핵심 세팅 요소라고 설명된다.[^5]
Navigation Stack(네비게이션 스택): 화면 전환 시 페이지가 쌓이는 구조로, 새 페이지 push 시 스택에 올라가고, pop/back 시 내려간다(발표자는 “스택에 하나가 올라간다”는 식으로 설명).[^11]
Named Route(네임드 라우트): /2, /3처럼 문자열 경로로 화면을 이동시키는 방식이며, GetX에서는 GetPage로 등록해 사용한다고 소개된다.[^39]
Path Parameter: URL 경로에서 :id처럼 콜론으로 표시되는 동적 변수 구간을 말하며, GetX에서 이를 쉽게 받을 수 있다고 설명한다.[^42]
Query Parameter(쿼리): ?id=4&name=cf처럼 URL 뒤에 붙는 추가 파라미터이며, GetX에서 Get.parameters로 수신 가능하다고 시연한다.[^46][^49]
Transition(트랜지션): 페이지 전환 애니메이션으로, GetX가 기본 제공 옵션이 많고 간단히 지정 가능하다고 한다.[^35][^38]
Arguments(아규먼트): 페이지 이동 시 다음 페이지로 전달하는 값이며, Get.arguments로 받을 수 있다고 설명된다.[^30][^33]

참고(콘텐츠 정보)[^72]

  • 제목: [앱개발] [Flutter] Flutter 개발자는 무조건 알아야 하는 GetX [#1-Navigation][^72]
  • 채널: 코드팩토리[^72]
  • 길이: 14분 57초[^72]
  • 링크: https://www.youtube.com/watch?v=wgJItCEL7hk[^72]

[^1]: @[00:00]~ 발표 시작 및 오늘 주제(겟X) 예고 전반. [^2]: @[00:02] “이번 시간에는 겟 x …” + @[00:06] 토픽 구분 + @[14:11] 내비게이션/스낵바/다이얼로그/바텀시트 권장 취지. [^3]: @[00:06] GetX 토픽 3가지(내비게이션/상태관리/DI) + @[00:10] 발표자 Provider 선호 및 내비게이션부터 진행. [^4]: @[00:43] “세팅을 딱 한 가지만 하면” + 패키지 다운로드 언급. [^5]: @[00:59] “MaterialApp 앞에 Get만 붙이면… GetMaterialApp” + @[01:10] MaterialApp extend 설명. [^6]: @[01:31]~@[01:41] Navigator.push + MaterialPageRoute + builder가 길고 코드가 많다는 설명. [^7]: @[00:38] 내비게이션 예제 준비 언급. [^8]: @[02:08] 스택에 페이지 올라감 언급 + @[02:12]~ pushReplacement 성격 + @[03:06] all 제거 + @[03:47] back 관련. [^9]: @[01:26] 버튼/스크린2 이동 예제 소개. [^10]: @[01:48]~@[01:54] “Get.to … 스크린 넣으면 바로 이동” + 시연. [^11]: @[02:04]~@[02:12] “네비게이션 스택에 … 하나가 올라가게”. [^12]: @[02:12]~@[02:34] “전 페이지로 돌아가지 못하게… 페이지만 지우고… 홈으로”. [^13]: @[02:38]~@[02:47] pushReplacement 설명. [^14]: @[02:47]~@[02:56] Get.off 류로 간단히 가능하다는 시연 흐름. [^15]: @[03:06]~@[03:20] “모든 페이지 스택 삭제… 스플래시/로그인에서 많이”. [^16]: @[03:25]~@[03:31] “한 줄로 작성” 취지. [^17]: @[03:31]~@[03:41] offAll 후 뒤로가기 불가 시연. [^18]: @[03:47]~@[04:06] pop 관련 코드와 검은 화면 언급. [^19]: @[04:46]~@[05:01] 아규먼트 보내고/받기 필요 제기. [^20]: @[04:16]~@[04:23] “뒤로 갈 페이지 있는지 확인… pop 안 시킴” 설명. [^21]: @[04:23]~@[04:33] “if문 없이 Get.back… 불가능할 때는 뒤로 안감”. [^22]: @[04:37]~@[04:46] “코드를 짧게… 노력” 총평. [^23]: @[04:46]~@[04:59] 값 전달/수신 필요성 언급. [^24]: @[05:08]~@[05:21] Get.to로 이동하며 값 받을 수 있다는 흐름. [^25]: @[05:21]~@[05:27] 라디오 버튼 0~2 구성 설명. [^26]: @[05:33]~@[05:43] Get.back(result: …)로 전 페이지에서 받는다는 설명. [^27]: @[05:43]~@[05:56] 2/1/0 반환 시연 언급. [^28]: @[06:00] “유연하게… 짧은 코드… 값을 받아올 수”. [^29]: @[06:08]~@[06:16] “값 보내는건 어떻게… 이것도 간결”. [^30]: @[06:24]~@[06:29] “그냥 Get.arguments … 텍스트 … 끝”. [^31]: @[07:26]~@[07:56] 트랜지션 소개 및 시연. [^32]: @[06:42]~@[06:50] “코드팩토리로 바꿔볼게요” 수신값 변경 시연. [^33]: @[07:03]~@[07:15] “Get.arguments라고만… 통째로 가져와”. [^34]: @[07:15]~@[07:19] “너무 편한 거야” 평가. [^35]: @[07:26]~@[07:39] 트랜지션 기본 제공 많음 언급. [^36]: @[07:39]~@[07:56] 특정 트랜지션(좌→우) 시연. [^37]: @[07:56]~@[08:02] fade in 시연. [^38]: @[08:02]~@[08:11] 옵션 많아 다이나믹 앱 가능 + “간단하게”. [^39]: @[08:17]~@[08:24] “진짜… 유용… 네임드 라우트” + onGenerateRoute 언급. [^40]: @[08:46]~@[08:56] 파라미터 처리 귀찮음 언급. [^41]: @[08:56]~@[09:14] “이미 다 핸들링” + 웹 라우팅의 파라미터/쿼리 필요성. [^42]: @[09:19]~@[09:36] 콜론 : 설명(변수로 작용). [^43]: @[09:36]~@[09:52] Screen5에서 파라미터 받기 + 1234 시연. [^44]: @[09:55]~@[10:00] 파라미터 이름(예: param)과 매칭 설명. [^45]: @[10:03]~@[10:11] test로 바뀌는 시연. [^46]: @[10:15]~@[10:31] 쿼리 ?id=... 보내기 설명. [^47]: @[10:35]~@[10:40] test + id=4 포함 이동 시연. [^48]: @[10:42]~@[10:51] name=cf 등 추가 쿼리 예시. [^49]: @[10:51]~@[11:03] Get.parameters로 name 등 받기 시연. [^50]: @[11:03]~@[11:14] 웹처럼 복잡한 네비게이션 빌드 가능 + 가장 유용 평가. [^51]: @[11:14]~@[11:28] 네임드 라우트 사용 시 Google Analytics가 자동으로 라우트 처리. [^52]: @[11:28] “네임드 라우트 잘 활용”. [^53]: @[11:32]~@[11:47] 라우팅 외로 스낵바 소개 + 기본 방식은 코드 많음. [^54]: @[11:47]~@[11:58] title/message만으로도 한 줄에 가능 취지. [^55]: @[11:58]~@[12:02] 스낵바 표시 시연. [^56]: @[12:02]~@[12:08] position 변경 시 아래에서 표시 시연. [^57]: @[12:16]~@[12:25] 스낵바 옵션 많고 원하는 형태 가능. [^58]: @[12:25]~@[12:41] 기본은 위에서 나오게 못한다는 기억 vs GetX는 가능, 장점 언급. [^59]: @[12:41]~@[12:52] defaultDialog 최소값으로 바로 표시. [^60]: @[12:52]~@[12:57] 다이얼로그 시연. [^61]: @[12:57]~@[13:02] showDialog/builder/context 등 기존 번거로움 언급. [^62]: @[13:07]~@[13:22] defaultDialog 내 옵션 많음 + Get.dialog로 위젯 직접 넣기. [^63]: @[13:22]~@[13:29] 간단 처리 + 원하면 커스터마이즈 가능 정리. [^64]: @[13:29]~@[13:36] 바텀시트 소개 및 기존 번거로움. [^65]: @[13:36]~@[13:50] Get.bottomSheet에 위젯 넣으면 됨 + 시연. [^66]: @[13:50]~@[14:04] “생각하는 대로 쓰면 돼… 큰 장점”. [^67]: @[14:04]~@[14:18] 상태관리는 당장 어렵더라도 내비게이션/스낵바/다이얼로그/바텀시트만 바꿔도 코드 줄고 직관적. [^68]: @[14:27]~@[14:34] 앞으로 상태관리/DI도 진행 계획 + 구독/좋아요. [^69]: @[14:42]~@[14:54] 코드 GitHub 호스팅, 클론해서 확인 안내 + 종료. [^70]: 영상 전반 결론 및 강조점 종합: @[01:31]~@[04:46], @[08:17]~@[11:14], @[14:04]~@[14:18]. [^71]: 용어들은 영상에서 직접 언급/사용된 개념 기반: @[00:59] GetMaterialApp, @[02:08] 스택, @[08:24] 네임드 라우트, @[09:19] 콜론 파라미터, @[10:15] 쿼리, @[07:26] 트랜지션, @[06:24] arguments. [^72]: 사용자가 제공한 메타데이터(제목/채널/길이/링크).

← 프로젝트에서 보기