플러터로 가위바위보 게임을 만들고 있습니다. 우선 가위, 바위, 보 중에서 하나를 누르면 선택지가 입력되어 게임이 진행되는 구조인데요. 채점하는 동안 선택지를 더 못고르게 DateTime() 함수로 2초 동안 못고르게 만들었습니다. 그런데 구조적인 문제로 인해 화면이 로딩되고나서 무심코 유저들이 가위, 바위, 보를 탭하다보면 2초간 못고르게 된게 화면 로드할때부터 효력이 있어서 이것저것 누르다보면 UI에 대한 신뢰감이 저하됩니다.

그래서 화면 로드 후 첫로드일때만 3초간 딜레이를 주고 있습니다. 3초부터 0초까지 카운트 다운 합니다.

우선 아래와 같은 코드면 됩니다.

코드에서 중요한 것은 _timer 변수를 Timer? 타입으로 지정하고 Timer.periodic(duration) 객체를 담아 1초 간격으로 tick해서 적절한 처리를 하는 원리입니다. _timer 변수는 Timer 객체를 담고, 인자로 주어지는 timer로 tick을 조사합니다. tick은 0부터 시작해서 이 함수에서는 1초 간격으로 늘어나는데, 이를 조건문으로 검사해서 setState() 로 갱신해줍니다.

이렇게 실행하면 UI에서

처럼 해둔 위젯에 표시가 갱신됩니다.

이렇게 만든 initCountDown()을 initState() 함수에 기재합니다.

이 위치 이외에 build() 함수 등에 두면 갱신시마다 initCountDown() 이 실행되어 $counter 부분이 점멸하니 반드시 initState()에서 실행하여 화면 갱신되어도 두번 다시 실행되지 않게 합니다.

플러터로 텍스트를 목록으로 표시하고 탭하면 지정한 작동을 하도록 하는 위젯이 꽤 됩니다. 그중에서 간편하게 쓸 수 있는 것이 ListTile 입니다. ListTile은 해시맵과 같은 유형으로 읽어들인 구조적인 데이터의 구조를 입력받아 각 타일을 채워넣는 것이 자동화됩니다. 아래처럼 할 수 있습니다.

이렇게 저장된 데이터를 리스트로 만들어 저장하고 이 값을 map() 으로 받아와서 처리할 수 있습니다. 이 경우 Row()나 Column()의 children: [ ] 속성에 기재하면 여러개의 ListTile이 자동으로 만들어집니다.

위와 같이 하면 map((e) => ListTile() 이 가능해집니다. 여기에 주어진 e 변수는 연관 배열처럼 쓸 수 있습니다. 목록이 자동으로 완성됩니다.

그런데 가끔 목록에 이미지를 추가하고 싶어질 때가 있습니다. 이미지를 추가하려고 하면 ListTile의 경우 leading: 이나 trailing: 속성에 둡니다. 그런데 이 속성에 이미지를 배치하면 좌측이나 우측에 배치되고 위로는 안되서 방법을 찾는데 잘 안찾아지네요. 스택오버플로우처럼 경험 많고 상세하게 답변이 오가는 사이트에서도 뾰족한 답변을 안해줍니다.

구글 공식 API 문서를 살펴보니, ListTile의 title: 속성과 subtitle: 속성은 Widget을 넘겨받는 속성이라, Text외에도 Image.asset()을 넘겨도 되겠다는 생각이 들었습니다. 아니나 다를까, 해보니 됩니다. 위 예제 구조를 그대로 받는다면, title: 에 이미지를 배치하고 subtitle: 에 글의 메타데이터를 배치하는 방법이 가능해집니다.

구체적으로 아래처럼 하면 됩니다.

웹검색만으로는 방법이 잘 안찾아지는데 실력이 늘으니 구글 공식 API 문서 읽다가 힌트를 얻네요.

참고로 thumbnail() 함수는 Image.asset을 포함하는 위젯 모음을 리턴하구요. metainfo() 함수는 제목과 카테고리를 처리하는 Column() 위젯에 Text() 위젯을 집어넣어 리턴합니다. 한마디로 말해 title: 속성에 Image.asset()을 포함하는 처리를 할 수 있다는 것입니다.

위의 코드는 dataList1에 map() => ListTile을 달아 쓰기에 ListTile 안에서만 작동하게 해야 e 변수를 쓸 수 있습니다. 그래서 뭔가 신박한 코드구조를 개발할 수 있을지 모르지만, ListTile이 제공하는 속성을 최대한 이용해야 합니다. 달리 말해 특정 위젯 구조를 무조건 써야할때, 어느 속성에 어느 위젯을 배치할지, 살펴보려면 구글 공식 API 문서를 잘 보면 힌트가 얻어집니다. 위의 예에서는 Text 대신에 Image.asset을 배치하는 힌트를 얻으려고 찾아보았구요. 타위젯도 흡사한게 가능한지는 구글 공식 API 문서에서 찾아보면 됩니다. 각 API 클래스 해설 페이지에서 Properties를 잘 보면 됩니다. Properties를 잘 보면 가능한 속성과 어떤 타입인지 잘 나옵니다.

(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 파일에 옵션줘서 조치를 하는 방법이 있을 것 같은데, 디렉토리를 함부로 지우지 말고 저 명령어로 처리하는게 좋을 것 같다. 물론 옵션이 필요한게 제공되면.

이런 저런 상념인데 일단 말은 맞는 것 같다.

플러터의 장점은 UI 배치가 매우 쉬운 배려가 되어 있는 언어라는 점입니다. 위젯 형태로 제공되는 기본 UI 구성 요소가 많이 제공되고, 각각의 위젯 내부에 배치할 수 있는 속성에 위젯 클래스를 배치하기만 하면 UI 구성이 잘 됩니다. 이 장점으로 인해 저도 아주 훌륭한 혜택을 받고 있습니다. 다트와 플러터에서 제공되는 제작사가 만든 UI 위젯뿐아니라, 사용자 생태계에서 제공되는 패키지도 쓰면 아주 쉽게 UI 배치가 되서 좋습니다.

플러터는 화면을 채우는 위젯에 하위 위젯을 배치하면서 UI 구성을 설계해갑니다. main() 함수에서 runApp()으로 호출되는 최상위 위젯 아래에 return 문을 확장해가면서 코딩을 할 수 있습니다.

이 파일을 실행하면 화면에 Hello, world!가 뜰 것입니다. 다른 언어처럼 실행 첫진입 지점을 포함한 파일이 읽히게 되고, 이 파일에 정의된 main() 함수에서 runApp() 함수가 실행됩니다. 위 예제에서는 다른 클래스를 return하지 않고 즉시 Center() 위젯을 불러와서 그 안에 텍스트를 표시하는 Text() 위젯을 배치해서 코딩이 되었습니다.

주목할 것은 Center() 함수 안에 child: 라고 표시된 부분입니다. 플러터에서 제공하는 위젯들은 계층구조를 가지고 배치가 되는데, 배치하는 위치에는 십중팔구 타위젯을 배치할 수 있게 설계된 속성이 옵니다. 위의 경우 child: 라고 표시된 부분이 그러한데요. Center() 위젯이 설계될 당시에 child: 속성을 써서 타위젯을 배치하게 되게 해둔 것입니다. 여기에 올 수 있는 위젯이라면 다 올 수 있습니다. (플러터 API doc에 나옴) 예제에서는 화면 중앙에 배치하기 위해 Center() 위젯을 최상위 위젯으로 두었고 그 안에 Text() 위젯을 써서 문자열을 표시하게 해두었습니다.

때로는 MaterialApp()과 Scaffold() 같은 위젯을 return 해서 보다 더 규모있는 앱을 만들기도 하죠.

이 경우 유의할 것은 child: 와 흡사하면서 여러개의 위젯을 병렬해서 배치가 가능한 위젯들이 있다는 것입니다. Column() 이나 Row()가 그 예로, child: 대신 children: [ ] 과 같은 속성이 제공되면, [ ] 안에 여러 위젯을 쉼표로 구분하면서 배치할 수 있게 해서 레이아웃 구성에 효율이 있게 될때가 많습니다.

이 경우 특히 좋은 것은 전역변수로 지정한 변수에 상태값을 대응시켜서 같은 자리에 내용만 바꿔 위젯 표시를 하고 싶을때 가능해게 해준다는 것입니다.

위에 예에서처럼 children: [ ] 내부에 특별한 방법으로 채워주면 실행이 가능한 기능이 있습니다. setState() 함수로 _conditional 값을 조정하면 _conditional 값에 따라 같은 위치에 Text() 값만 바뀌어 표시할 수 있습니다. 조정된 _conditional 이 충족되는 값일때 : 로 구분한 영역의 코드만 재실행되는 것입니다. 이렇게 하면 안내 메시지 표시할때 route 기능 없이도 같은 위치에 다른 표시를 할 수 있게 됩니다.

예를 들면 GestureDectector() 와 같이 onTap: 속성이 제공되는 위젯에서 사용자가 탭한 것을 받아서 setState() 함수로 _conditional 값을 바꿔주면 실행이 됩니다.

이 경우 _conditional 변수가 전역변수여야 하고, setState() 함수가 실행가능해야 합니다. (setState() 실행 가능한 한 조건은 createState() 함수로 State 클래스가 작성되어 있어야 합니다)

설명을 잘한지 모르는데, 일단 흐름은 이해가 될 것입니다. setState() 함수를 실행하는 코드 예시는 아래 링크에서 힌트를 얻어보세요.

https://docs.flutter.dev/development/ui/interactive

참고가 되셨을 것 입니다.

본래 28MB 정도 크기로 설치되던 앱이 모종의 이유로 159MB까지 늘어났습니다. 그 이유는 의존성 라이브러리의 비대화, 리소스 파일이 너무 큰 경우 등등의 원인이 있습니다. 이를 해결할때 참조할만한 방법을 소개합니다.

우선 플러터로 안드로이드 스튜디오에서 작업할때를 기준으로 소개합니다.

Project 패널에서 아래 파일을 엽니다.

Project→android→app→build.gradle

그리고 아래 라인을 입력합니다. 우선 defaultConfig 블락 안에

이 라인을 추가하면 현재 시장에서 널리 쓰이는 CPU로 된 장비에 특화되게 빌드를 해서 앱 용량이 작아지는 효과가 있습니다. 더 정확하게 말하자면 시장에서 널리 안쓰이게 된 아키텍처를 빌드에서 제외하는 것입니다.

이 방법과 유사한 방법으로 apk파일을 위 아키텍처에 따라 각각 생성하고 업로드하게 하는 방법이 있는데 개별 apk 파일 크기는 더 줄어들어도 개발자에 의하면 크래시가 잘 되어 위 방법을 추천한댑니다.

그리고 같은 파일에 아래 라인을 입력합니다. buildTypes 안의 release 블락에

를 추가합니다. 이렇게 하면 불필요한 코드를 정리해줍니다. 대략 이런 모양새입니다.

그리고 안드로이드 스튜디오 상단 메뉴에서 Refactor→Remove unused resources 를 선택하여 리팩토링하면 안쓰는 리소스를 정리해줍니다.

그리고 앱 빌드시 상단 메뉴에서 Run→Flutter Run ‘main.dart’ in Release Mode 로 빌드해서 기기에 심어도 디버깅 모드로 할때보다 앱이 2분의 1 더 줄어듭니다.

때로는 플러터 프로젝트 디렉토리에서 android 디렉토리에 들어가서 .\gradlew app:dependencies 명령어로 의존성 라이브러리 검사를 해서 IDE 메뉴에서 삭제하기도 하면 좋다지만 이 단계는 생략하고 위에 방법들만 써도 앱 크기가 3분의 1에서 5분의 1까지 줄어들었습니다.

그래도 변화가 없으면 기기에서 앱을 수동으로 지우고 위에 방법을 모두 실행해보세요. 변화가 있습니다.

플러터로 안드로이드 앱을 만들때 런처 아이콘이 화면에 표시되고 그 다음 메인 화면으로 넘어갑니다. 이 경우 스플래시 화면을 XML 독립적으로 만들었다면 시각적으로 방해가 됩니다. 예를 들면 main.dart에서 splash_screen.dart의 SplashScreen 클래스를 호출해서 스플래시를 표시하는 체제일때, 안드로이드에서 실행시 런처 아이콘이 SplashScreen 클래스보다 우선 표시되어 시각적인 방해가 되죠.

이 경우 안드로이드에서 실행한다면 해당 플러터 프로젝트에서 생성된 android 디렉토리로 가서 리소스 파일로 생성된 style.xml 파일 두개를 수정해야 합니다.

경로는 Project 패널에서 android→app→src→main→res→values→style.xml
경로는 Project 패널에서 android→app→src→main→res→values-night→style.xml

두 파일이고 대충 아래와 같아야 합니다.

res/values/style.xml

res/values-night/style.xml

여기서 중요한 대목은 첫번째 style 지정인 LaunchTheme 엘리먼트 하위 엘리먼트로

를 추가하는 것입니다.

이렇게 해두고 플러터 프로젝트를 빌드하고 실행하면 런처 아이콘이 안뜨고 앱이 실행이 됩니다.