개발자놀이

화면의 설정 정보를 담는 Route는 여러 Callback methods를 가지고 있다. 이 메서드들은 자신이 Navigator에 push/pop 될 때 호출되고, nextRoute가 push/pop될때도 호출된다. 앱을 개발할 때 현재 화면이 Natigator에서 가장 위에 표시되는 화면인지 알고 싶을 때가 있다. 특히 다음 화면으로 넘어갔다가 다시 이전화면으로 돌아올 때 화면의 데이터를 갱신하거나 기타 필요한 동작을 해야 할 때가 있기 때문이다. 물론 await Nativiator.push()를 처럼 await구분을 이용해서 다음 화면이 pop될때 까지 기다리는 방법도 있지만 화면이 복잡해지고 연결된 다음화면이 여러 개 있을 경우 일괄적인 처리가 필요할 때도 있다. Android에서는 Activity..

Flutter에서 화면의 이동을 관리하는 위젯으로 Navigator가 있다. Flutter는 모든 것이 위젯이라는 말처럼 화면 전환을 관리하는 것 역시 위젯으로 만들어져 있다. 이 말은 Navigator를 앱 전체 화면의 전환으로 사용할 수도 있고 화면의 일부 영역에 배치해서 그 부분에 대한 전환만 담당하게 할 수도 있다는 뜻이다. 앱 내에서 영역별 화면의 전환을 위해 다양하게 사용할 수 있다. 보통 MaterialApp을 가장 최상위 위젯으로 구성하게 되는데, 이때 MaterialApp은 내부적으로 하나의 전체 화면을 사용하는 Navigator를 하나 가지고 있다. 이를 통해 앱의 전체 화면의 전환을 관리할 수 있다. 보통 Navigator를 가져올 때 Navigator.of(context)로 가져와 ..

TDD을 적용하기 위해서 가장 필수적인 부분은 테스트가 용이한 구조로 설계되어야 한다는 것이다. 앱을 구조적으로 만들려면 아키텍처의 각 구성요소들의 역할이 정확하게 정의되야 하고, 그들간의 의존관계가 명확해야 한다. 지금 부터 어떻게 하면 앱을 테스트하기 좋은 구조 만들 수 있는지 StatefulWidget으로 만들어진 간단한 화면을 예로 설명해보도록 하겠다. 로그인 화면 하나를 만들어 보자 . 로그인 화면이 있고 이 화면에서는 유저로 부터 Id와 password를 입력받아 서버로 인증요청을 보내고 그 결과를 화면에 표시 한다. - ID는 이메일 형식만 허용한다 - PW는 최소 5자 이상이다. - 모든 입력이 정상적으로 완료되면 로그인 버튼이 활성화 된다 아직 까지 우리는 구조적으로 분리하지 않았기 때문..

내가 작성한 소스코드를 신뢰할 수 있을까? 내 동료가 작성한 소스코드를 신뢰할 수 있을까? 사람이 직접 작성한 모든 소스코드는 결함을 가질 수 밖에 없다. 그래서 우리가 작성한 코드가 올바르게 동작함을 증명할 필요가 있다. 사실 개발 일정에 쫓기다보면 테스트 코드를 작성하지 않고 기능을 만들기에 급급할 수도 있다. 하지만 그렇게 급하게 만든면 완성도가 떨어지고 결함을 가진 프로그램이 만들어진다. 나중에 오류를 찾느라 더 오랜 시간을 허비하기도 한다. 테스트 코드를 작성하는 것은 다음과 같은 이유로 여러움을 겪는다. 1. 개발 시간의 증가 처음 테스트코드를 작성해 보면 시간이 더 많이 필요한 것이 사실이다. 실제로도 개발 로직에 작성된 코드 수보다 테스트코드를 더 많이 작성해야 하는 경우가 많이 발생한다...

지금까지 Widget과 Element 관계에 대해서 알아보았다. 이런 관계가 만들어지는 근본적인 이유는 Flutter의 속도를 높이고 Rendering에 필요한 연산을 최소화 하기 위해서 이다. 그래서 Element는 결국 최종적으로 화면에 정보를 표시하기 위한 정보를 담는 RenderObject들과 연결되고 이 정보들을 재활용 함으로써 Widget들의 잦은 빌드 이벤트를 처리한다. Widget Tree 개발자가 build함수에서 Widget들을 구성해서 반환하면 이것들이 모여 하나의 큰 Widget tree를 만든다. Widget tree는 실제로 존재한다기 보다는 개발자가 인지할 수 있도록 편의상 만든 개념에 가깝다 (dart devtool의 widget inspector에서 볼 수 있는 widget..

Widget에게 Key란? Widget.key property에 부여되는 값으로 Element의 재사용을 판단하기 위해 사용된다. 빌드 과정 중 생성된 newWidget이 oldWidget의 Element를 재사용할 수 있는지를 판단할 때 사용된다. Flutter는 기본적으로 Element를 재사용하는 것을 전제로 만들어져 있다. 우리가 Widget를 생성할때 별도의 key값을 주지 않아도 Element가 재사용되는데 oldWidget의 Key와 newWidget의 key가 모두 nul l일 때도 같은 Key라고 판단하기 때문이다. 아래 코드는 Element가 재사용 가능한지 확인하는 코드인데 위에서 설명한 내용을 간략하게 잘 보여준다. static bool canUpdate(Widget oldWidge..

보통 안드로이드 개발을 하다 플러터를 접하게 되면 가장 먼저 찾아보는 개념이 LifeCycle이다. 안드로이드에서는 Activity나 Fragement의 LifeCycle과 상태 변화에 따라 적절한 함수들이 호출된다. 이 함수들을 잘 이용해서 상황에 맞는 프로그램을 기능들을 추가하게 되는데 플러터에서도 이와 유사한 개념이 없을까 하고 찾아보게 된다. 이때 가장 먼저 접하게 되는 정보들이 StatefulWidget의 Lifecycle일것이다. 위 다이어그램만 보면 StatefulWidget에 그럴듯한 LifeCycle이 있는것 처럼 보인다. 하지만 정확히 이야기 하자면 StatefulWidget은 LifeCycle을 가질 수 없다. 왜냐 하면 모든 Widget은 Immutable 하며 build과정에 항상..

"Flutter는 모든 것이 Widget으로 이루어져 있다"라는 말을 들어 보았을 것이다. 우리 개발자들은 Widget만 있으면 앱의 화면을 만들고 기능을 구현할 수 있다. 특히 StatelessWidget과 StatefulWidget을 만들 수 있고, 기본으로 제공되는 Widget의 사용법만 숙지한다면 간단한 화면 정도는 쉽게 만들어 낼 수 있다. 하지만 Flutter는 정말 Widget만으로 이루어진 것일까? Widget의 반복적인 생성 개인적으로 처음 Flutter을 접했을 때 가장 궁금했던 것 중 한 가지가 build함수가 재호출 되어 함수 내부에서 Widget들을 다시 생성하는데 어떻게 60 프레임을 보장할 정도로 빠른 화면 구성이 가능할까였다. 코드로만 보면 build함수 내부에서는 항상 새로..