파파비의 블로그

우리가 위젯을 만들 때, listview나 gridview 같은 것 안에 들어가는 위젯의 경우, Data Model을 만들어놓고, 그 Model의 값에 따라 위젯이 만들어지도록 하는 경우가 많다. 이런식으로 말이다. Product라는 class 형태로 이루어진 data set이 있어서, 이 data set을 for문을 돌리든 해서, 바로 위젯으로 만들어버린다. 위젯을 만들 때, 위 사진처럼, 인수를 직접 넣어서, 진행했다. 하지만 이것이 불편한 점이 있는데, 상태 변화에 따라 Rebuild를 하기 위해선 Statful 위젯을 사용해야 한다는 점이다. 그리고 저렇게 넣는것도 불편하고 말이다. (만약 딱 저 위젯한테만 영향을 미치고, 인수를 넣을 필요도 없고 하면 굳이 provider를 만들 필요없고 Sta..

Provider는 사실 Data Provider를 말한다. 따라서 Data를 관리할 새로운 Class가 필요하다. (보통 model 폴더를 만들거나 provider 폴더를 만들어서 거기에 dart 파일을 만들고 data provider class를 만든다.) 1) ChangeNotifier를 상속(?) 하는 Mixin으로 Class를 만든다. (Mixin을 만들 때는 with를 사용한다) 이렇게 되면 of(context)를 이용하여 다른 위젯들과 직접 연결되는 통로를 만들 수 있게 된다. 2) Data는 전부 Data Provider Class 내에서 제공/수정이 이루어져야 한다. 우리는 Data Provider Class의 객체를 통해 data를..

...으로 흩어지게 한 뒤에 다시 list로 감싸서 새로운 리스트 만들어서 전달해보리기. 참고로 이것은 provider에서 쓴 것인데, 이렇게 한 이유는 내부적으로 수정사항이 일어나면 notifiyListeners() 를 실행시켜야 하는데, 외부에서 레퍼런스를 받게되면 직접 수정할 수 있게되고, 그런데 notifiyListeners() 는 실행되지 않아서 꼬일 수 있게 되기 때문이다.

set state을 활용하여 state management를 하게 되면 불편한 점이 많다. 위젯들 간에 data는 constructor를 통해 이동시켜야 되는데, 퍼포먼스 측면이나 코드의 지저분함이나 모두 악영향을 미치기 때문이다. 보통은 가장 상위에 data를 두어야하고, 그렇게 되면 data가 바뀔 때마다 상위 위젯이 build를 실행하면 불필요하게 대부분의 위젯들이 rebuild 된다. 따라서 퍼포먼스 측면에서 안 좋다. >> 우린 필요한 위젯들만 다시 build하고 싶다 또한 코드가 매우지저분한게 되는데 불필요하게 constructor를 통해 쓰지도 않는 data를 받거나 할 수도 있다. >> 우린 불필요한 코딩은 하고 싶지 않다 이 두가지 불편을 해소해주는 것이 Provider이다. 1) Pro..

1) GridView - ListView와 사용법이 거의 똑같다. - ListView처럼, GridView와 GridView.Builder가있다. - 기본적으로 필요한 속성은 3가지이다. itemcount, itembuilder, gridDelegate - itemcount, itembuilder는 ListView와 같은 개념이다. - gridDelegate이 특이한 놈이다. gridView가 어떻게 생길지 결정해주는 놈이다. - 속성으로 2가지 위젯중 하나를 고르면 된다. 1) SliverGridDelegateWithFixedCrossAxisCount > grid 기둥 개수를 미리 선정해서, 사이즈가 어떻든 그에 맞추는 방식 > (컨텐츠들의 사이즈가 바뀜) 2) SliverGridDelegateWith..

1) Expanded 안에는 ListView가 들어갈 수 있다. (왜 여태 안된다고 생각했을까, Expanded의 높이 or 넓이는 무한정인줄 알았다.) 2) SwitchlistTile > 텍스트가 있고, 옆에 스위치까지 함께 존재하는 형태의 위젯이다. 편리하게 사용가능하다. 근데 플러터는 특이한게, switch의 값이나 상태가 변할 때, setstate을 직접해주어야 한다는 것이다.

Navigator를 통해 PushNamed를 하면서 data를 보내게 되면, ModalRoute.of(context)~ 를 사용하여 data를 받게 되는데, 만약 그 data를 우리는 위젯 수명주기 함수인 init을 통해 초기화를 하고 싶다고 하더라고 할 수 없다. 이유는 init은 context가 형성되기 전에 미리 빌드 되기 때문이다. 그래서 그 init 직후에 build가 실행되기전, context는 완성됐을 때, 실행되는 함수인 didChangeDependencies에 context 관련 메소드들을 넣으면 된다. 아무튼 이 함수는 근데, setstate이 실행되거나 하면 자동으로 실행기도 하는데, 그래서 우리는 한번만 실행할 수 있도록 isInit Flag를 해두었다.

화면을 네비게이터로 띄운 뒤, 그 화면에서 본래 화면으로 data를 전송하고 싶을 수가 있다. 그럴땐, navigator pop에 data를 넣어서 보내면 된다. 이렇게 말이다. 여기를 보면 . 버튼 콜백으로 pop을 하는 것이 보이고, 안에 mealID라는 data를 보냈다. 그냥 data 아무거나 넣어버리면 된다. 그럼 data는 어디서 어떻게 받을까? 저 화면을 push한 그 곳에서 받는다. 이 코드가 위의 화면을 push한 곳이다. push 메소드는 사실 future함수이다. 따라서 then을 통해, 저 메소드만 따로 메모리에 올려서 완료된 뒤에 then 부분이 실행되게 할 수 있다. then안에 있는 value는 pop이 보낸 것이다. 우린 저 값을 사용하면 된다. print('!!')은 언제 ..