귀하는 로그인되어 있지 않습니다. 이대로 편집하면 귀하의 IP 주소가 편집 기록에 남게 됩니다.스팸 방지 검사입니다. 이것을 입력하지 마세요!===위젯=== Flutter에서는 모든 요소가 위젯(Widget)이다. 페이지조차도 위젯이다. 심지어는 아예 가장 기본이 되는 App 클래스<ref>App 클래스 객체를 main() 함수에서 runApp() 함수 매개변수로 전달하는 것이 모든 Flutter 앱의 시작 지점이다.</ref> 조차도 StatelessWidget 클래스에서 상속 받는다! 대부분의 위젯은 child, 또는 children 속성으로 자식 위젯을 품을 수 있다. 따라서 Flutter의 UI는 위젯의 트리 구조다. 위젯은 상태 변화가 없는 Stateless Widget과 상태 변화를 감지하는 Stateful Widget 두 가지로 나뉜다. 중요한 것은 위젯 자체는 stateless든 stateful이든 불변(immutable)이다. 따라서 위젯 안의 모든 속성은 final이어야 하며<ref>그런데 final이 아닌 필드가 있어도 컴파일을 하면 경고 메시지는 뿜어내지만 빌드가 되긴 된다. 다만 제대로 동작할지는 보장할 수 없다.</ref>, 위젯을 업데이트할 수 있는 메서드 같은 것은 제공하지 않는다. 만약 위젯이 어떤 텍스트를 출력하고 있고, 그 텍스트가 바뀌어야 한다면 안드로이드나 iOS 네이티브로 계산할 때에는 그 위젯<ref>아마 안드로이드나 iOS는 각자 그에 해당하는 다른 이름을 쓸 것이다.</ref>의 setText() 메서드를 호출한다든가 해서 매개변수로 새 텍스트를 넘겨주는 식으로 텍스트를 바꿀 것이다. 즉 명령을 통해 인터페이스를 업데이트 한다. Flutter는 이렇게 하지 않는다. 위젯이 표시할 텍스트는 stateless든 stateful이든 위젯이 만들어질 때 생성자의 매개변수로 넘겨야 하고, 이 값을 바꿀 수 있는 메서드는 없다. 위젯의 색깔을 바꾼다든지, 위치를 바꾼다든지 하는 것도 명령으로 업데이트할 수 없다. 위젯은 build() 메서드를 제공하는데, 이 메서드는 위젯이 만들어졌을 때 한 번만 호출된다. 그렇다면 상태의 변화를 감지하는 Stateful Widget은 상태 변화에 어떻게 대응하나? Flutter가 채용하는 방식은 위젯과 상태를 다른 클래스로 분리한다. 즉 위젯을 그리는 build() 메소드를 위젯이 아닌 상태 (state) 클래스가 가지고 있고, 이 상태 클래스를 immutable인 위젯에서 createState() 메소드에서 만들어 가지고 있는 방식으로 문제를 해결한다. State 클래스는 final이 아닌 속성을 둘 수 있다. 위젯의 상태가 변하면, 즉 위젯의 모양에 영향을 미치는 데이터에 변화가 생기면 상태 클래스에 있는 build()가 위젯을 처음부터 다시 그리며 자신이 품고 있는 위젯 트리도 여기서 다시 그린다. 어떤 상태 변화가 있을 때마다 build()를 불러서 전체 위젯을 다시 그린다면 굉장히 효율이 떨어질 것처럼 보이지만 의외로 좋은데, 실제로는 Flutter 엔진이 어떤 부분이 변했는가를 검사한 다음, 영향을 받는 위젯을 'dirty' 상태로 표시하고, 이 위젯들만 다시 그리는 방식으로 효율을 낸다. 만약 stateful한 위젯에서 상태에 변화를 일으키는, 즉. 위젯을 다시 그려야 하는 dirty한 데이터 변경이 있다면 setState() 메서드를 호출해서 그 안에서 데이터를 변경해야 한다.<ref>[[리액트]]를 써본 사람들이라면 친숙한 방식일 것이다.</ref> UI에 영향을 미치는 데이터가 비동기적으로 변한다면<ref>즉 위젯의 업데이트를 위해 build() 메서드가 호출되었을 때 필요한 상태 데이터가 업데이트 되어 있다는 보장이 없는 경우를 뜻한다.</ref> 이는 [[Dart]]의 Future 또는 Stream 클래스를 이용해서 반영할 수 있다. 이 때에는 위젯의 build() 메서드 안에서 각각 FutureBuilder 또는 StreamBuilder 클래스를 사용해서 처리한다. 특히 구글의 제품인만큼 구글의 [[NoSQL]] 동기화 [[데이터베이스]]인 [[Firestore]]와 궁합이 기가 막히게 좋다. StreamBuilder를 사용하면 [[데이터베이스]]가 업데이트 되었을 때 자동으로 동기화가 되고 UI에 반영된다. 쉽게 말해서 UI 단에서는 업데이트에 대비해서 따로 뭘 할 게 없다는 뜻이다. 다만 단점도 있는데, 이들 위젯이 속해 있는 부모 위젯이 다시 그려질 때, 즉 build()가 호출될 때, 이것들도 다시 build()가 호출되므로 Future 혹은 Stream 객체를 다시 만들어서 그리며, 그때문에 데이터가 불필요하게 다시 로딩되거나 깜빡이는 현상이 나타난다. 또한 UI를 구성하는 방식이 [[XML]]과 같은 외부 파일이 아니라 코드 자체 안에서 구현하는 방식이다. 페이지 자체도 위젯이기 때문에 위젯을 구성하는 build() 메소드 안에서 자식 위젯을 정의하고, 자식 위젯 안에서 자식 위젯을 정의하고... 이런 방식이다. 배치 방법, 마진이나 패딩 같은 것들도 모두 코드로 구현한다. 따라서 위젯의 구성이나 모양을 바꿀 때마다 코드를 다시 컴파일해야 하지만<ref>UI 레이아웃을 [[XML]]로 분리했다고 해도 어차피 빌드를 다시 하긴 해야 하며, 이 과정에서 [[XML]]을 코드로 컴파일하는 과정이 있는 방식이 대다수라 컴파일 효율이 낫다고 보기도 어렵다.</ref> 위에서 이야기한 핫 리로드 때문에 별 불편하지는 않긴 하다. 가독성 측면에서도 XML이 딱히 낫다고 보기 어렵고 효율성 측면에서도 좋은 소리는 못 듣기 때문에<ref>[[리누스 토르발스]]도 [[XML]]이 가장 나쁜 데이터 저장 방식이라고 엄청 깠다.</ref> UI 레이아웃을 코드로 구현하는 부분은 좋은 평가를 받는다. 참고로 설정 파일은 [[YAML]](확장자 .yml) 형식을 사용한다. 프로젝트에 포함시킬 외부 패키지, 글꼴, 그리고 이미지를 비롯한 자산(asset) 파일은 이 안에 포함시켜야 한다. 기존 위젯을 가지고 새로운 위젯을 만들려면 기존 위젯은 상속하지 않는 것이 좋다. 일단 실제로 해 보면 구현이 잘 안 되는 걸 알 수 있다. 대신 StatelessWidget 또는 StatefulWidget 클래스를 상속해서 새 위젯 클래스를 만든 다음 build() 메서드에서 확장하고자 하는 위젯에 내가 구현한 기능을 붙인 위젯 객체를 돌려주는 방식으로 구현해야 한다. 편집 요약 가온 위키에서의 모든 기여는 크리에이티브 커먼즈 저작자표시-동일조건변경허락 라이선스로 배포된다는 점을 유의해 주세요(자세한 내용에 대해서는 가온 위키:저작권 문서를 읽어주세요). 만약 여기에 동의하지 않는다면 문서를 저장하지 말아 주세요. 또한, 직접 작성했거나 퍼블릭 도메인과 같은 자유 문서에서 가져왔다는 것을 보증해야 합니다. 저작권이 있는 내용을 허가 없이 저장하지 마세요! 취소 편집 도움말 (새 창에서 열림)