편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.
최신판 | 당신의 편집 | ||
1번째 줄: | 1번째 줄: | ||
[[구글]]에서 개발하는 | [[구글]]에서 개발하는 크로스 플랫폼 프레임워크. 한글로는 '플러터'로 주로 쓴다. 프로그래밍 언어로는 [[구글]]에서 개발한 [[Dart]]를 사용한다. 안드로이드와 iOS를 지원하며, 2019년 구글 I/O에서는 웹 개발까지 할 수 있는 Flutter Web 프레임워크까지 들고 나왔다. 즉 [[안드로이드]], [[iOS]], 웹에서 돌아가는 앱을 하나의 코드로 전부 개발할 수 있다는 이야기다. 2020년 들어서는 [[윈도우]]와 [[맥OS]], [[리눅스]]까지도 지원해서 데스크톱 프로그램까지도 Flutter로 만들 수 있다. | ||
물론 정말 이렇게 할 수 있는 범위는 기기 공통으로 제공하는 기능으로 한정하며 특정 OS에서만 지원되는 기능이나 하드웨어를 컨트롤하려면 그에 맞는 네이티브 코드가 필요하다. 이 부분은 [[안드로이드]]라면 [[코틀린]]<ref>처음에는 [[자바]]였지만 [[구글]]이 [[오라클]]과의 소송전 때문에 [[코틀린]]을 밀어주는 방향으로 가고 있어서 이제는 Flutter도 프로젝트를 만들 때 안드로이드 네이티브 코드로 [[코틀린]]을 사용한다.</ref>, [[iOS]]라면 [[Swift]]를 사용해서<ref>이것도 처음에는 | 물론 정말 이렇게 할 수 있는 범위는 기기 공통으로 제공하는 기능으로 한정하며 특정 OS에서만 지원되는 기능이나 하드웨어를 컨트롤하려면 그에 맞는 네이티브 코드가 필요하다. 이 부분은 [[안드로이드]]라면 [[코틀린]]<ref>처음에는 [[자바]]였지만 [[구글]]이 [[오라클]]과의 소송전 때문에 [[코틀린]]을 밀어주는 방향으로 가고 있어서 이제는 Flutter도 프로젝트를 만들 때 안드로이드 네이티브 코드로 [[코틀린]]을 사용한다.</ref>, [[iOS]]라면 [[Swift]]를 사용해서<ref>이것도 처음에는 오브젝티브 C였다가 애플이 [[Swift]]를 주력으로 바꾼 이후에는 Flutter도 프로젝트를 만들 때 iOS 네이티브 코드로 [[Swift]]를 사용하고 있다.</ref> 붙일 수 있도록 Flutter에서 지원하고 있다. 구글의 차세대 OS로 점쳐지고 있는 Fuchsia도 UI 단에서는 Flutter를 기반으로 할 것으로 보인다. 즉 현재의 행보는 모바일과 데스크톱을 걸친 다양한 환경들을 Fuchsia로 통합하기 위한 포석으로 볼 수 있다. | ||
2021년 | 2021년 3월에 열린 Flutter Engaged 행사에서는 Flutter 2 계획을 발표했다. 베타 상태였던 웹과 데스크톱 환경 개발을 정식으로 지원하는 것이 주요한 변화다. 프론트엔드 앱과 백엔드까지 Flutter 하나로 개발할 수 있으며, 데스크톱과 웹, 모바일을 연계해서 각각의 환경에 최적화된 기능을 제공하는 앱을 만들 수 있을 것으로 기대하고 있다. | ||
==특징== | ==특징== | ||
13번째 줄: | 9번째 줄: | ||
===기기에 독립된 사용자 인터페이스=== | ===기기에 독립된 사용자 인터페이스=== | ||
지금까지 모바일을 겨냥한 | 지금까지 모바일을 겨냥한 크로스 플랫폼 프레임워크는 [[아파치 코르도바]]처럼 웹 뷰를 사용하되 여기에 사용되는 자원을 각 기기에 미리 심는 방식, 즉 앱이 로컬 웹 서버로 돌아가도록 해서 웹 앱보다는 빠르고 OS 관계 없이 똑같은 인터페이스를 제공하거나<ref>하지만 운영체제의 기본 웹브라우저를 사용하므로 웹브라우저에 따라 모양이 좀 다를 수는 있다.</ref>, 리액트 네이티브나 [[자마린]]처럼 각 OS의 네이티브 기능을 최대한 활용해서 인터페이스는 조금 차이가 나지만 빠른 속도를 추구하는 방법이 있는데, Flutter는 이들 둘과는 아예 다르다. 각 OS의 네이티브 그래픽 기능을 최대한 활용하되 각 OS의 유저 인터페이스를 무시하고 몽땅 Flutter가 자체 제공한다. 즉, 각 OS는 그림 그릴 캔버스만 제공하고 그 위에 뭘 표현할지는 Flutter의 렌더링 엔진인 skia가 다 그려버리는 것. 그 때문에 OS에 관계 없이 똑같은 모습의 유저 인터페이스를 제공한다. Flutter는 두 가지 인터페이스 디자인을 기본 제공한다. OS에 따라 디자인을 달리 하는 것도 가능해서 안드로이드에서는 머티리얼, iOS에서는 쿠퍼티노 인터페이스<ref>[[애플]]이 아니라 [[구글]]에서 자사의 머티리얼 디자인과 구별하기 위해 붙인 이름이다. 애플 폰사가 쿠퍼티노에 있기 때문에 이런 이름을 붙였다.</ref> 를 사용하는 식으로 할 수도 있고 그 반대로도 할 수 있다! 같은 앱에서 입맛에 맞게 어떤 부분은 머티리얼, 어떤 부분은 쿠퍼티노 디자인을 적용할 수도 있다. 다만, 똑같은 기능을 하는 인터페이스라고 해도 모양이나 크기가 다를 수 있으므로 이를 감안해야 한다. 네이티브 UI를 활용하는 것에 비해서 속도 면에서 불리하지 않은가 싶을 수 있는데 테스트 결과를 보면 상당히 준수하게 나온다. 렌더링 엔진인 skia는 [[C++]]로 구현했는데 최적화를 무척 잘 했는지 성능이 아주 좋다. 그리고 지금도 계속 최적화를 하고 있어서 업데이트 될 때마다 어느 정도나 성능을 향상시켰는지 공지한다. | ||
다만 Flutter 웹은 [[HTML]]와 | 다만 Flutter 웹은 [[HTML]]와 CSS를 사용한다. 이쪽은 이 두 가지만 가지고도 어지간히 다 할 수 있기도 하고<ref>아파치 코르도바가 내장한 [[HTML]]을 UI에 사용하는 방식으로 크로스 플랫폼 모바일 앱을 구현할만큼 HTML과 CSS만 있으면 웬만한 UI는 다 구현할 수 있다.</ref> 웹 표준을 무시하면 매장당하는 문제도 있다. Flutter를 웹 개발에 쓰면 사실상 [[HTML]]나 CSS 코딩 없이 [[Dart]]만으로 다 만들 수 있다.<ref>애초에 Flutter의 구조가 웹 구조에 힌트를 얻은 것이기도 하다. [[자바]] 기반 아파치 위켓 웹 프레임워크는 모든 것을 위젯으로 보고 모든 구성요소를 위젯 트리 구조로 구성하며, [[XML]] 같은 것을 쓰지 않고 UI도 코드로 몽땅 처리하는 데다가 stateless와 stateful 개념을 가지고 있어서 많은 면에서 Flutter와 닮아 있다.</ref> | ||
===핫 리로드=== | ===핫 리로드=== | ||
24번째 줄: | 20번째 줄: | ||
핫 리로드나 핫 리스타트는 기기의 접속을 끊으면 변경된 내용이 반영되지 않으므로 변경된 내용을 기기에 완전히 심기 위해서는 실행을 중단시킨 다음 다시 컴파일해서 실행시키거나 프로파일 모드 또는 릴리즈 모드로 실행시켜야 한다. 참고로 프로파일 모드는 디버깅 정보가 그대로 다 뜨지는 않지만 앱 성능 측정과 로깅 기능은 유지하는 모드로, 릴리즈 모드에 준하는 속도를 내면서도 디버깅에 일부 도움을 받을 수 있다. | 핫 리로드나 핫 리스타트는 기기의 접속을 끊으면 변경된 내용이 반영되지 않으므로 변경된 내용을 기기에 완전히 심기 위해서는 실행을 중단시킨 다음 다시 컴파일해서 실행시키거나 프로파일 모드 또는 릴리즈 모드로 실행시켜야 한다. 참고로 프로파일 모드는 디버깅 정보가 그대로 다 뜨지는 않지만 앱 성능 측정과 로깅 기능은 유지하는 모드로, 릴리즈 모드에 준하는 속도를 내면서도 디버깅에 일부 도움을 받을 수 있다. | ||
===위젯=== | ===위젯=== | ||
43번째 줄: | 37번째 줄: | ||
===그밖에=== | ===그밖에=== | ||
각 OS의 네이티브에 붙어 있는 기능을 써야 할 때에는 그 부분만 네이티브로 개발해서 Flutter에 붙일 수도 있다. Flutter는 이를 위한 인터페이스를 제공한다. 단, 네이티브 부분은 [[안드로이드]]라면 [[자바]]나 [[코틀린]], iOS라면 오브젝티브C나 스위프트와 같이 각자의 네이티브 개발 언어를 써야 붙여줘야 한다. 카메라나 GPS처럼 | 각 OS의 네이티브에 붙어 있는 기능을 써야 할 때에는 그 부분만 네이티브로 개발해서 Flutter에 붙일 수도 있다. Flutter는 이를 위한 인터페이스를 제공한다. 단, 네이티브 부분은 [[안드로이드]]라면 [[자바]]나 [[코틀린]], iOS라면 오브젝티브C나 스위프트와 같이 각자의 네이티브 개발 언어를 써야 붙여줘야 한다. 카메라나 GPS처럼 공통으로 제공하는 하드웨어는 Flutter 지원 패키지로도 웬만큼은 다룰 수 있다. | ||
Flutter의 사용자층이 넓어지면서 Flutter는 물론 [[Dart]]의 기능을 확장해 주는 패키지들도 빠른 속도로 늘어나고 있다 | Flutter의 사용자층이 넓어지면서 Flutter는 물론 [[Dart]]의 기능을 확장해 주는 패키지들도 빠른 속도로 늘어나고 있다. [https://pub.dev pub.dev] 웹사이트에서 패키지를 검색해 볼 수 있다. 필요한 패키지는 pubspec.yaml 파일에 추가해서 flutter pub get 명령으로 받아올 수 있다. | ||
==성능== | ==성능== | ||
일반적으로 [[크로스 플랫폼]]으로 개발한 앱은 네이티브와 비교해서는 속도는 느리고, 메모리를 비롯한 자원은 많이 잡아먹는 것으로 알려져 있다. 이는 네이티브 UI를 최대한 활용하는 [[자마린]]이나 리액트 네이티브도 피해갈 수 없는 문제다. 그렇다면 Flutter는? 우크라이나에 소재를 둔 인베리타소프트라는 곳에서 [[크로스 플랫폼]]인 리액트 네이티브와 플러터, 그리고 네이티브로 iOS는 [[ | 일반적으로 [[크로스 플랫폼]]으로 개발한 앱은 네이티브와 비교해서는 속도는 느리고, 메모리를 비롯한 자원은 많이 잡아먹는 것으로 알려져 있다. 이는 네이티브 UI를 최대한 활용하는 [[자마린]]이나 리액트 네이티브도 피해갈 수 없는 문제다. 그렇다면 Flutter는? 우크라이나에 소재를 둔 인베리타소프트라는 곳에서 [[크로스 플랫폼]]인 리액트 네이티브와 플러터, 그리고 네이티브로 iOS는 [[오브젝티브 C]]와 [[스위프트]], [[안드로이드]]는 [[자바]]와 [[코틀린]]을 사용해서 성능 실험을 해 보았다. 원문은 [https://medium.com/swlh/flutter-vs-native-vs-react-native-examining-performance-31338f081980 여기]에서 확인할 수 있다. 메모리 위주 성능 측정을 위해서는 가우스-르장르드 알고리즘(Gauss–Legendre algorithm)을, CPU 위주 성능 측정에는 보웨인 알고리즘(Borwein algorithm)을 사용했다. 결과는? | ||
{| class="wikitable" | {| class="wikitable" | ||
63번째 줄: | 57번째 줄: | ||
| [[스위프트]] || style="text-align:right;" | 218.3 || style="text-align:right;" | 35.0 || style="text-align:right;" | — || style="text-align:right;" | — | | [[스위프트]] || style="text-align:right;" | 218.3 || style="text-align:right;" | 35.0 || style="text-align:right;" | — || style="text-align:right;" | — | ||
|- | |- | ||
| [[ | | [[오브젝티브 C]] || style="text-align:right;" | 127.5 || style="text-align:right;" | 16.7 || style="text-align:right;" | — || style="text-align:right;" | — | ||
|- | |- | ||
| [[자바]] || style="text-align:right;" | —|| style="text-align:right;" | — || style="text-align:right;" | 222.0 || style="text-align:right;" | 143.0 | | [[자바]] || style="text-align:right;" | —|| style="text-align:right;" | — || style="text-align:right;" | 222.0 || style="text-align:right;" | 143.0 | ||
76번째 줄: | 70번째 줄: | ||
==단점== | ==단점== | ||
문제점이라면 Flutter의 개발 언어인 [[Dart]]가 별 인기가 없다는 것... 원래는 [[자바스크립트]]를 대체할 언어로 들고 나왔지만 시장에서 완전히 파묻혔으며<ref>[[자바스크립트]]를 대체하려면 바로 [[HTML]] 안에 삽입해서 돌아갈 수 있도록 브라우저가 지원해줘야 하는데 구글이 만든 크롬 말고는 지원하는 브라우저가 없다. 물론 크롬의 점유율이 높긴 하지만 맥 사용자는 대부분 사파리를 쓰며 아이폰이나 아이패드는 닥치고 사파리, 그리고 파이어폭스도 어느 정도 사용자층을 가지고 있는 점을 생각해 보면 자바스크립트의 대안이라는 원래 목적은 실패에 가깝다.</ref>, [[자바스크립트]]의 대안은 [[MS]]가 들고 나온 [[타입스크립트]]가 잡고 있는 실정이다. [[Dart]]나 [[타입스크립트]]나 간단한 컴파일을 통해 [[자바스크립트]]로 번역되기 때문에 이미 상당히 성숙해 있으며 개발자 저변도 넓은 [[자바스크립트]]를 대체한다기보다는 보완하는 역할 정도인데, 여기서도 [[타입스크립트]]한테 완전히 밀려서 쓰레기 취급 받던 언어다. 기능 확장을 위한 패키지들도 [[파이썬]]이나 [[자바스크립트]]에 비하면 형편없이 부족하다. 아무튼 구글에서 그냥 파묻기에는 아까웠던 건지 Flutter를 통해 [[Dart]]를 부활시킨 셈이다. Flutter에 힘입어 Dart도 약진하고 있고, [[크로스 플랫폼]] 언어 시장에서는 리액트 네이티브와 치열한 1위 경쟁을 벌이는 수준까지 올라왔다.<ref>[https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/ "Cross-platform mobile frameworks used by software developers worldwide in 2019 and 2020"], Statista, 2 July 2020.</ref> | 문제점이라면 Flutter의 개발 언어인 [[Dart]]가 별 인기가 없다는 것... 원래는 [[자바스크립트]]를 대체할 언어로 들고 나왔지만 시장에서 완전히 파묻혔으며<ref>[[자바스크립트]]를 대체하려면 바로 [[HTML]] 안에 삽입해서 돌아갈 수 있도록 브라우저가 지원해줘야 하는데 구글이 만든 크롬 말고는 지원하는 브라우저가 없다. 물론 크롬의 점유율이 높긴 하지만 맥 사용자는 대부분 사파리를 쓰며 아이폰이나 아이패드는 닥치고 사파리, 그리고 파이어폭스도 어느 정도 사용자층을 가지고 있는 점을 생각해 보면 자바스크립트의 대안이라는 원래 목적은 실패에 가깝다.</ref>, [[자바스크립트]]의 대안은 [[MS]]가 들고 나온 [[타입스크립트]]가 잡고 있는 실정이다. [[Dart]]나 [[타입스크립트]]나 간단한 컴파일을 통해 [[자바스크립트]]로 번역되기 때문에 이미 상당히 성숙해 있으며 개발자 저변도 넓은 [[자바스크립트]]를 대체한다기보다는 보완하는 역할 정도인데, 여기서도 [[타입스크립트]]한테 완전히 밀려서 쓰레기 취급 받던 언어다. 기능 확장을 위한 패키지들도 [[파이썬]]이나 [[자바스크립트]]에 비하면 형편없이 부족하다. 아무튼 구글에서 그냥 파묻기에는 아까웠던 건지 Flutter를 통해 [[Dart]]를 부활시킨 셈이다. Flutter에 힘입어 Dart도 약진하고 있고, [[크로스 플랫폼]] 언어 시장에서는 리액트 네이티브와 치열한 1위 경쟁을 벌이는 수준까지 올라왔다.<ref>[https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/ "Cross-platform mobile frameworks used by software developers worldwide in 2019 and 2020"], Statista, 2 July 2020.</ref> | ||
[[Dart]]의 문법은 [[자바스크립트]]와 닮은 구석도 꽤 있고, 진입장벽이 낮기 때문에 [[자바스크립트]]나 [[자바]] 같은 언어들을 잘 알고 있다면 Flutter를 쓰기 위해서 [[Dart]]를 배우기 위해 시간을 많이 들일 필요는 없다. 그리고 [[Dart]] 자체도 기능이 형편 없거나 배우기가 지랄맞거나 한 언어는 절대로 아니며 처음에는 쉬워보이지만 쓰면 쓸수록 헷갈리기 쉬운 [[자바스크립트]]에 비하면 버그가 적고 깔끔한 코드를 만들 수 있다.<ref>[[MS]]가 내놓은 [[자바스크립트]]의 슈퍼셋인 [[타입스크립트]]도 변수에 유형을 지정함으로써 버그를 줄여주는 효과가 주된 목적이다. 아예 이름에 type(유형)이 들어가 있다.</ref> 또한 Flutter의 장점으로 손꼽히는 핫 리로드나 핫 리스타트는 그만큼 [[Dart]]가 잘 디자인된 언어라는 것을 보여주는 증거이기도 하다. 단지 [[자바스크립트]]를 대체하겠다는 욕심이 너무 컸던 것도 있고, 다른 웹 브라우저 입장에서 보면 크롬 웹 브라우저를 가지고 있는 구글에게 좋은 일을 굳이 해줄 이유도 없으니 이들에게 외면 받은 탓이 크다. 자세한 내용은 [[Dart]] 항목 참조. Flutter 덕분에 [[Dart]]가 재발견되고 사용층도 넓어지고 있는 추세이고 이를 지원하는 개발 도구도 늘어나고 있으며, 여러 가지 기능을 손쉽게 추가시킬 수 있는 패키지도 빠르게 늘고 있기 때문에 [[Dart]] 언어 자체도 여러 가지로 쓰기가 좋아지고 있으며 악평도 줄어들고 있다. 그래도 이미 세상에는 많은 [[C샵|C#]] 또는 [[자바스크립트]] 개발자들이 있고, 이들은 기존에 손에 익은 언어로 개발할 수 있는 플랫폼을 선호하기 때문에 이들보다 개발 인구가 훨씬 적은 [[Dart]]는 약점을 안고 있다. | [[Dart]]의 문법은 [[자바스크립트]]와 닮은 구석도 꽤 있고, 진입장벽이 낮기 때문에 [[자바스크립트]]나 [[자바]] 같은 언어들을 잘 알고 있다면 Flutter를 쓰기 위해서 [[Dart]]를 배우기 위해 시간을 많이 들일 필요는 없다. 그리고 [[Dart]] 자체도 기능이 형편 없거나 배우기가 지랄맞거나 한 언어는 절대로 아니며 처음에는 쉬워보이지만 쓰면 쓸수록 헷갈리기 쉬운 [[자바스크립트]]에 비하면 버그가 적고 깔끔한 코드를 만들 수 있다.<ref>[[MS]]가 내놓은 [[자바스크립트]]의 슈퍼셋인 [[타입스크립트]]도 변수에 유형을 지정함으로써 버그를 줄여주는 효과가 주된 목적이다. 아예 이름에 type(유형)이 들어가 있다.</ref> 또한 Flutter의 장점으로 손꼽히는 핫 리로드나 핫 리스타트는 그만큼 [[Dart]]가 잘 디자인된 언어라는 것을 보여주는 증거이기도 하다. 단지 [[자바스크립트]]를 대체하겠다는 욕심이 너무 컸던 것도 있고, 다른 웹 브라우저 입장에서 보면 크롬 웹 브라우저를 가지고 있는 구글에게 좋은 일을 굳이 해줄 이유도 없으니 이들에게 외면 받은 탓이 크다. 자세한 내용은 [[Dart]] 항목 참조. Flutter 덕분에 [[Dart]]가 재발견되고 사용층도 넓어지고 있는 추세이고 이를 지원하는 개발 도구도 늘어나고 있으며, 여러 가지 기능을 손쉽게 추가시킬 수 있는 패키지도 빠르게 늘고 있기 때문에 [[Dart]] 언어 자체도 여러 가지로 쓰기가 좋아지고 있으며 악평도 줄어들고 있다. 그래도 이미 세상에는 많은 [[C샵|C#]] 또는 [[자바스크립트]] 개발자들이 있고, 이들은 기존에 손에 익은 언어로 개발할 수 있는 플랫폼을 선호하기 때문에 이들보다 개발 인구가 훨씬 적은 [[Dart]]는 약점을 안고 있다. | ||
88번째 줄: | 80번째 줄: | ||
코드 스타일 면에서는 [[자바스크립트]]의 그 악명 높은 [[콜백 지옥]]<ref>이게 워낙 심각하다 보니 [[자바스크립트]]도 문제 해결에 많은 노력을 기울였고 ES6, ES7을 거치면서 promise 지원이나 await, async 같은 비동기 키워드 지원으로 상당 부분을 해소했다.</ref>을 방불케 하는 들여쓰기 지옥이 있다. 위젯을 만들 때에는 속성을 생성자의 매개변수로 전달하는 방식을 사용하는데, Flutter의 레이아웃은 위젯의 트리 구조로 이루어진다. 자식 위젯은 보통 부모 위젯의 child(단일 위젯) 또는 children(위젯의 배열) 속성으로 전달하는데, 레이아웃이 복잡해지면 그만큼 위젯의 계층 수도 늘어나고, 그러면 부모 위젯 생성자의 chlid 속성에 자식 위젯의 생성자가 들어가고, 그 자식 위젯의 생성자 child 속성에 손자 위젯의 생성자가 들어가고... 이런 식으로 이어진다. 또한 위젯의 여백을 준다든가, 테두리 모양을 바꾼다든가, 위젯들을 정렬한다든가, 사용자 입력 반응 기능이 없는 위젯에 이러한 기능을 부여한다든가 할 때에도 위젯을 사용하므로 위젯의 계층 수가 두 자릿수로 갈 수 있으며 이렇게까지 가면 [[콜백 지옥]] 저리가라 할 정도의 들여쓰기 지옥을 맛볼 수 있다. 이를 피하려면 build() 안에 모든 위젯 렌더링 코드를 넣지 말고 Widget 객체를 돌려주는 몇 개의 메서드로 쪼갠 다음 이를 build()에서 부르거나, 여러 클래스에 걸쳐 쓰인다면 별도로 위젯 클래스를 만들어서 분리하는 방법도 있다. | 코드 스타일 면에서는 [[자바스크립트]]의 그 악명 높은 [[콜백 지옥]]<ref>이게 워낙 심각하다 보니 [[자바스크립트]]도 문제 해결에 많은 노력을 기울였고 ES6, ES7을 거치면서 promise 지원이나 await, async 같은 비동기 키워드 지원으로 상당 부분을 해소했다.</ref>을 방불케 하는 들여쓰기 지옥이 있다. 위젯을 만들 때에는 속성을 생성자의 매개변수로 전달하는 방식을 사용하는데, Flutter의 레이아웃은 위젯의 트리 구조로 이루어진다. 자식 위젯은 보통 부모 위젯의 child(단일 위젯) 또는 children(위젯의 배열) 속성으로 전달하는데, 레이아웃이 복잡해지면 그만큼 위젯의 계층 수도 늘어나고, 그러면 부모 위젯 생성자의 chlid 속성에 자식 위젯의 생성자가 들어가고, 그 자식 위젯의 생성자 child 속성에 손자 위젯의 생성자가 들어가고... 이런 식으로 이어진다. 또한 위젯의 여백을 준다든가, 테두리 모양을 바꾼다든가, 위젯들을 정렬한다든가, 사용자 입력 반응 기능이 없는 위젯에 이러한 기능을 부여한다든가 할 때에도 위젯을 사용하므로 위젯의 계층 수가 두 자릿수로 갈 수 있으며 이렇게까지 가면 [[콜백 지옥]] 저리가라 할 정도의 들여쓰기 지옥을 맛볼 수 있다. 이를 피하려면 build() 안에 모든 위젯 렌더링 코드를 넣지 말고 Widget 객체를 돌려주는 몇 개의 메서드로 쪼갠 다음 이를 build()에서 부르거나, 여러 클래스에 걸쳐 쓰인다면 별도로 위젯 클래스를 만들어서 분리하는 방법도 있다. | ||
용량도 아직은 문제인데, 자체적으로 사용자 인터페이스를 렌더링하는 | 용량도 아직은 문제인데, 자체적으로 사용자 인터페이스를 렌더링하는 skia 엔진이 들어가므로 운영체제의 UI 관련 라이브러리를 불러다 쓰면 되는 네이티브보다는 덩치가 클 수밖에 없다. 릴리즈 모드로 컴파일 하면 skia 중에 실제 앱에서 쓰는 부분만 포함시키는 방식으로 크기를 줄이긴 하지만 그래도 네이티브와는 차이가 꽤 난다. 구글도 이 점은 알고 있기 때문에 버전을 올려 나가면서 앱의 크기를 줄이는 데 많이 신경쓰고 있다. 이런 문제는 다른 [[크로스 플랫폼]]도 안고 있다. 예를 들어 .NET 프레임워크의 [[크로스 플랫폼]] 버전인 모노 프레임워크를 안고 들어가야 하는 [[자마린]] 역시 'Hello world!' 하나 보여주는 앱도 용량이 장난 아니다. | ||
==개발 환경== | ==개발 환경== | ||
[[안드로이드 스튜디오]], IntelliJ IDEA<ref>무료로 쓸 있는 커뮤니티 에디션에서도 쓸 수 있다 | [[안드로이드 스튜디오]], IntelliJ IDEA<ref>무료로 쓸 있는 커뮤니티 에디션에서도 쓸 수 있다. [[안드로이드 스튜디오]] 자체가 IntelliJ IDEA 기반이다.</ref>, [[비주얼 스튜디오 코드]]에서 사용할 수 있다. 이들 모두는 기본 제공 기능이 아니며 플러그인을 설치하면 쓸 수 있다. 모두 크로스 플랫폼 개발 환경이므로 [[윈도우]], 맥, [[리눅스]]에서 개발할 수 있다. 다만 iOS용 실행 패키지를 빌드하려면 맥과 Xcode가 있어야 한다.<ref>빌드는 [[안드로이드 스튜디오]] 또는 [[비주얼 스튜디오 코드]]로 하지만 Xcode의 빌드 툴 체인이 있어야 빌드를 할 수 있기 때문이다. 어떤 애플 기반 개발 환경에서는 어떤 툴을 쓰든 마찬가지다. 하지만 Xcode는 무료 배포이므로 맥만 있으면 다운로드 받을 수 있다.</ref> 실행은 안드로이드라면 실제 기계가 없어도 안드로이드 SDK에서 제공하는 에뮬레이터를 사용하면 되지만 iOS는 에뮬레이터도 맥에서만 돌릴 수 있으므로 맥과 Xcode가 필요하다. | ||
[[안드로이드 스튜디오]]는 구글에서 공식 제공하는 툴이고 뛰어난 [[IDE]]로 정평이 나 있는 IntelliJ IDEA를 기반으로 한 만큼 좋은 개발 환경을 제공한다. 다만 덩치가 커서 저사양 컴퓨터에서는 부담스럽고, 원래 [[자바]] 또는 [[코틀린]]을 위한 툴이었기 때문에 [[Dart]] 지원은 좀 떨어지는 느낌이 있다. [[비주얼 스튜디오 코드]]에 구글이 공식 Flutter 플러그인을 제공하고 있으며, 이를 통해 코딩, 리팩토링, 디버깅은 웬만큼 할 수 있다. 무엇보다도 [[안드로이드 스튜디오]]보다는 가볍다는 게 확실한 장점이기 때문에 고급 개발자들 중에는 이쪽을 더 선호하는 이들도 많다. 물론 이쪽도 무료다. [[iOS]]용 앱 개발을 위해 맥과 | [[안드로이드 스튜디오]]는 구글에서 공식 제공하는 툴이고 뛰어난 [[IDE]]로 정평이 나 있는 IntelliJ IDEA를 기반으로 한 만큼 좋은 개발 환경을 제공한다. 다만 덩치가 커서 저사양 컴퓨터에서는 부담스럽고, 원래 [[자바]] 또는 [[코틀린]]을 위한 툴이었기 때문에 [[Dart]] 지원은 좀 떨어지는 느낌이 있다. [[비주얼 스튜디오 코드]]에 구글이 공식 Flutter 플러그인을 제공하고 있으며, 이를 통해 코딩, 리팩토링, 디버깅은 웬만큼 할 수 있다. 무엇보다도 [[안드로이드 스튜디오]]보다는 가볍다는 게 확실한 장점이기 때문에 고급 개발자들 중에는 이쪽을 더 선호하는 이들도 많다. 물론 이쪽도 무료다. [[iOS]]용 앱 개발을 위해 맥과 Xcode가 필요한 건 이쪽도 마찬가지다. | ||
[[윈도우]]든 맥이든 [[리눅스]]든 개발 자체는 가능하지만 문제는 테스트인데, 에뮬레이터든 실제 아이폰이든 [[iOS]]에 앱을 올려서 테스트해 보려면 반드시 Xcode가 필요하고, 폐쇄적인 정책으로 먹고사는 애플답게, Xcode는 맥OS에서만 쓸 수 있으므로<ref>[[iOS]]는 지원하지 않으므로 아이패드 혹은 아이패드 프로에서도 Xcode는 돌릴 수 없다.</ref> 반드시 맥이 필요하다. 반대로 맥에서는 안드로이드 에뮬레이터 사용에 제약이 없으므로 결국 크로스 플랫폼 개발을 위해서는 맥을 쓸 수밖에 없다. 당장 맥에 돈을 투자하기 어렵다면 Xcode가 돌아갈만한 맥을 중고든 뭐든 구한 다음, 개발 작업은 주로 다른 컴퓨터에서 하고 [[iOS]] 테스트만 맥에서 할 수도 있는데, 이러나 저러나 맥이 있긴 있어야 한다. | [[윈도우]]든 맥이든 [[리눅스]]든 개발 자체는 가능하지만 문제는 테스트인데, 에뮬레이터든 실제 아이폰이든 [[iOS]]에 앱을 올려서 테스트해 보려면 반드시 Xcode가 필요하고, 폐쇄적인 정책으로 먹고사는 애플답게, Xcode는 맥OS에서만 쓸 수 있으므로<ref>[[iOS]]는 지원하지 않으므로 아이패드 혹은 아이패드 프로에서도 Xcode는 돌릴 수 없다.</ref> 반드시 맥이 필요하다. 반대로 맥에서는 안드로이드 에뮬레이터 사용에 제약이 없으므로 결국 크로스 플랫폼 개발을 위해서는 맥을 쓸 수밖에 없다. 당장 맥에 돈을 투자하기 어렵다면 Xcode가 돌아갈만한 맥을 중고든 뭐든 구한 다음, 개발 작업은 주로 다른 컴퓨터에서 하고 [[iOS]] 테스트만 맥에서 할 수도 있는데, 이러나 저러나 맥이 있긴 있어야 한다. | ||
{{각주}} | {{각주}} |