(1) build 함수에 위젯 주렁주렁 달기
build 함수에 return 문에 위젯을 배치해서 처리하는 것이 플러터의 특징이다. UI 구성을 하다보면 위젯 개수가 많아지고 속성도 많아져서 매우 길게 늘어진다. 이렇게 되면 코드가 가독성도 없고, 무거운 앱인 경우 오버헤드가 있다고 한다. 그래서 고안된 추천 사항은 children: [] 속성 설정이 가능한 위젯을 두고 달아둘 위젯을 클래스나 함수로 분리해서 배치하라는 기법이다. 함수보다는 클래스가 더 오버헤드가 적댄다. 빌드할때 반복빌드하는지의 여부 같다. 난 내 코드가 이렇게 반드시 해야 할줄 알았는데 깃헙을 둘러보다보니 유려한 앱을 만든 타개발자들도 나처럼 return 문에 위젯을 주렁주렁 달아서 쓰더라. 우선 이래도 되는 이유도 만만찮다. 나열해보면
(i) 코드가 분산되면 스크롤을 여러번 해야 해서 불편하다
(ii) PC 하드웨어 발달로 인해 램 크기가 커져서 빌드시 지장이 없는 한도가 있다
(iii) 안드로이드 스튜디오에서 heap에 2GB, VM에 1GB 정도 할당되어 있는데 이 설정이 빌드와 실행에 관여한다면 왠만하면 스택오버플로우 안난다
(iv) 태블릿과 모바일도 사양이 좋아져서 지장없는 한도가 있다
(v) 지금 만드는 앱의 처리가 매우 가볍다. 글은 텍스트로 된 커봤자 10KB도 안되는 길이의 글을 처리하는 앱이고 게임도 3D 리소스가 없다
일단 지금 지식 범위 내에서 테스트안해보고 게워낸 체험담인데 UI 배치 구문은 주렁주렁 달아도 괜찮은 것 같다. 다만, UI 외적인 처리가 보일러 플레이트처럼 안되려면 간결한 코드로 해결하는 프로젝트를 구해서 잘 살펴보는 것은 여전히 필요하다. 오늘 만든 게임 처리 코드도 작동은 하되, 구문이 지저분해보이기도 하는데 이것도 기우인가? 일단 쉬운 리팩토링으로 해야 할게 if 문을 switch 문으로 바꾸는 코드 정도. 나머지는 타개발자들도 그냥 나처럼 하는 게 확인이 되었다.
(2) 어떤 문제인지는 미확인인데 오래된 소스코드를 받아와서 컴파일하다보면 다트와 코틀린, JDK, 의존성 라이브러리들의 버전이 문제가 되는 경우가 많다. IDE가 정확하게 짚어주는 편이라, 링크된 문서를 보면서 하다보면 컴파일이 되는데, 때로는 플러터 코드뿐아닌 안드로이드나 iOS 코드도 직접 수정해야 할때가 있다. 일단 IDE가 짚어준대로 할 수 있는 논리적 범위내에서 잘 작동하는 프로젝트와 흡사한 설정인 경우, 문제가 된 버전을 잘 작동하는 프로젝트의 것을 빌려와서 컴파일하면 잘 되기도 하는데 이게 안되기도 한다. 이런 경우, lib, assets, pubspec.yaml 정도만 복사해두고 프로젝트를 다 밀어버린 후, 플러터 프로젝트를 새로 만들어서 거기에 복사해둔 파일을 덮어씌우고 하면 잘 될때가 많다.
플러터 프로젝트 생성시 안드로이드나 iOS 소스 베이스도 함께 생성하던데, 위에 언급한 다트, 코틀린, JDK, 의존성 라이브러리들의 버전 문제도 있을수 있고, 그레이들 캐시 문제거나 그레이들 설정, 저장소 문제 등등이 겹쳐서 문제가 있을 때 위 방법대로 하면 해결이 되는 경우가 많다. 일단 이 방법 쓰기전에 IDE가 짚어준 문서는 읽어보고 적용해보는게 좋을 수는 있다.
(3) 대충 의식 흐름대로 쓴 글이라 표현이 독자들의 판단 의지보다 내 생각을 표시하는데 주력한 글이 되는데, 여튼 이런 저런 상념을 하고 있다. 플러터는 배운지 두달 정도라 더 다루어보고, 더 다루다가 의자가 발동되면 플러터 API 소스코드도 들여다봐야겠다. GlobalKey 관련해서 조금 해봤는데 늘 하는게 옳다. 특히 컴파일 오류 나면 예외 발생인 경우 실행 순서대로 오류 과정 추적하게 IDE가 배려를 해주는데 다 읽어봐야겠다. 지금까지는 코드 구문 바꿔가면서 했고 그래도 버그는 잡히는데 코드 구문 바꾸기전에 API 소스코드도 좀 봐야하겠다.
(4) 안드로이드 스튜디오에 플러터 플러그인을 설치해서 운용하면 안드로이드 API로 개발할때와 같은 사용성으로 플러터도 개발이 가능해진다. 플러터 프로젝트를 생성할때 멀티플랫폼으로 안드로이드, iOS, 리눅스, 웹, 윈도우 소스코드 베이스도 같이 생성한다. 안드로이드의 경우 그레이들을 빌드용으로 쓰는데 정확한 확인은 안했으나 실행 순서를 생각해보면, 그레이들 설정을 기본값으로 되돌릴때 세심한 주의가 필요한 것 같기도 하다.
안드로이드 스튜디오를 설치할때 그레이들도 설치한다. 그레이들이 설치되고 써봤다든지 하면, 프로젝트 루트에 생성된 android 디렉토리 아래 .gradle 디렉토리가 생성되어 필요한 파일을 캐시해두기도 하고 빌드할때 필요한 설정들이 일반적인 방법으로는 고치기가 어려운 파일들이 생성된다. 그런데 빌드 문제가 겹쳐서 그레이들 설정이 의심되는 경우, 이 디렉토리와, 운영체제 사용자 홈디렉토리 아래에도 생성되는 .gradle 디렉토리를 아예 그냥 확 밀어버리면 문제가 있게 되는 것 같기도 하다.
저 두 히든 디렉토리를 지워버리면 그레이들 재설치시, 의존성 라이브러리가 사용자가 지정도 안한 종류가 추가되는 것 같기도 하고, 내가 추가한 패키지가 참조해서 그런지는 미확인인데, 저 두 디렉토리 지우고 그레이들을 다시 설치한 이후부터 앱 컴파일된 apk 파일 크기가 5배가 늘었다.
그냥 강제로 지웠다면 안드로이드 스튜디오를 언인스톨하고 관련 디렉토리를 전부다 지우고 다시 설치하지 않으면 그레이들 설정을 복구하는게 어렵지 않나 싶다.
일단 그레이들은 gradlew.bat 파일에 옵션줘서 조치를 하는 방법이 있을 것 같은데, 디렉토리를 함부로 지우지 말고 저 명령어로 처리하는게 좋을 것 같다. 물론 옵션이 필요한게 제공되면.
이런 저런 상념인데 일단 말은 맞는 것 같다.
