22.06.26 flutter I/O Extended Korea 2022 오프라인 참석기
오늘은 건국대학교에서 진행되는 google i/o 컨퍼런스의 연장선인 Flutter I/O Extended Korea 2022 참석하게 되었다.
flutter 3.0의 업데이트 소식이 지난달 google i/o를 통해서 발표 되었던 내용을 flutter korea에서 다시 내용을 복기 해보며 동시에 몇몇 오프라인 세션을 통해서 실습을 기회를 제공하는 행사이다.
역시 구글 프로젝트라는 느낌이 강하게 드는 스티커들이 즐비해 있다.
플로터 keynote -> jaichangpark ->githu -> connect
1.google I/O에서 발표한 flutter desktop의 변경점 및 개선점
mac os linux os지원 확대를 진행 했다. -> 이전에는 winodws에서만 beta 느낌으로 지원 되었다면 3.0에서는 stable version으로 os 지원이 확대 되었다.
canconical.com 고마워요!!
위 내용이 주된 부분에 해당 된다.
자세한 부분은 codelab을 통해서 확인 해보면 된다.
https://flutter-ko.dev/docs/codelabs
Codelabs
Codelabs help you quickly get started programming Flutter.
flutter-ko.dev
2. 플로터 데스크톱?
좀더 대중적이고 높은 생산성을 가지는 ui toolkit을 제작하고 배포하는 것을 목표로 개발 되었다.
넓은 호환성을 가지고 있다는 것이 다른 개발 언어들이나 플랫폼들에 비해 장점으로 적용 될 것으로 생각된다.
19년도 에는 preview로 등장했던 다른 os 지원들이 이번 google i/o에서 stable 버전으로 올라간것이다.
3. 리눅스에서 데스크톱 셋업하는 방법
apple slicon도 지원 하기 시작했다.(뭐 ARM32에서도 돌아가게 하는 방법도 있었으니 빠르게 적용된 것 같다...)
기본적인 flutter를 설치하면 다음과 같이 사용 가능한 버전 및 기능들이 등장한다.
desktop 의 경우 따로 config를 통해서 desktop을 활성화 해줘야 사용이 가능하다.
materials 3는 use materials true만 적어주면 사용이 가능하며 아직 모든 환경에서 사용할 수 없는 것 같다.
어떻게 이런 기능들이 각 plaform에서 동일하게 적용이 되는 것일까?
windows에서는 엔젤이 엔진으로 작동하며 다른 os 에서는 skia 가 해당 기능들을 동작하게 된다. 2D graphics library로 open source 로 현재 flutter 모바일 데스크톱에서 사용중이다.
angle의 경우 google에서 제작중인 것으로 skia와 기능적인 표현은 비슷하다.
3.linux flutter desktop setup
linux의 경우 jetson nano에서도 돌아갈 정도로 가벼운것 같다.
-> 나중에 내 jetson nano에도 설치 해봐야 겠다.
flutter docotor
flutter run
위 명령어를 통해서 arm32 시스템에 필요한 빌드툴들이 설치되고 구동된다.
4. ros?
robot operating system으로 미들웨어 단에서 로봇이 동작하고 모니터링 하기 위한 라이브러리들을 가지고 있다.
현 추세는 Ros2로 넘어가고 있는 추세이다.(아직 1 쓰는 기업체들이 많다.)
5월 23일 릴리즈 -> 거북이의 날 stable version 업로드 된다. 이거 중요 ㅋㅋ
ROS1 -> ROS2
Data Distribution의 차이를 보면 될것이다.
ros는 각 개인의 구동 부분의 메세지를 규격화 하여 각각의 기능을 통일하고 합치는데 큰 역활을 기여한다.
QT를 사용하던.. ROS의 UI는 상당히 공대틱한 감성을 가진다.
여기서 flutter desktop 심지어 linux 버전을 적용한다면? 좀더 클라이언트 및 사용자 친화적 ui로 다가갈 수 있다.
물론 flutter는 오픈 소스라 제품 서비스 단계로 넘어갈때 비용이 없다. QT는 돈내야 한다....
5. how to interface with ROS using flutter
여러 로봇들은 임베디드 시스템을 채택하고 있다.
jetpack + ubuntu + flutter + ROS gui가 필요한 환경에서
+ ubuntu 20.04가 jetson 에 등장하였다. -> 이것도 확인 해봐야 겠다.
웹소켓 포트 9090을 이용하면 된다, -> foxy 괜춘 할지도?
json parsing과 ros bridge를 이용하면 각 노드들 값을 받아 올 수 있다.
->websocket 라이브러리 가져와서 사용가능하다.
메모리가 문제가 된다. -> 자비아 추천(애도 위 내용 프로젝트 간단하게 사용할때 빠르게 만들다간 30분만에 뻑날 수 있다.)
Session 2
생산성 향상을 위한 언어 기능 추가
Enhanced Enum with members | super initializer | named parameters everywhere
Enhanced Enum with members
extension 사용해서 가져왔지만 이번에 3.0 넘어오면서 enum 안에 멤버 변수, 함수 내부에 선언 가능해졌다.
super initializer
상속 변수를 수동으로 전달 해줬다면 -> super 매개 변수로 한번에 글로벌 선언이 가능해 졌다. 그저 super만 붙이면 할당 시킬 수 있다.
named parameters everywhere
선택 매개변수는 항상 마지막에 - > 선택 매개 변수 내가 원하는 대로 선언이 가능해 졌다.
생산성 도구 강화
flutter lints 2.0 - Dart | flutter lints 2.0 - flutter | source sockets | Dart Doc
lints의 경우 커맨드 업그레이드를 통해 사용이 가능하다.
1. 핵심 라이브러리 샘플코드 추가
2. dart.io라이브러에서 deprecated된 코드 약 230줄 제거
3. dartdoc 커맨드제거, dart doc 커맨드 추가
4. Depercated CLI pub 툴 제거 , dart pub / flutter pub으로 나누어 기능 제공
플랫폼 통합 및 지원 확대
1. Dart FFI
-c/native 코드와 소통하기 위한 장치(Win 32 APIs)
-더 쉽게 FFI 플러그인을 제작할 수 있게 탬플릿을 제공
-windows / MacOS 응용프로그램 codeSigning 지원
- finalizable 마커를 통한 dart와 native 코드 사이의 메모리 관리 효율화
2.RISC-V(리스크 파이브) 아키텍쳐 테스트 지원
Enum 실프로젝트 적용
코드 카테고리가 매우 많이 줄어든 모습을 볼 수 있다.
그 외 기능들은 차차 써보면서 느껴봐야 할것 같다. -> 하지만 dart의 기능은 크고 작게 변경 되고 있다는 것은 확실하게 느껴지고 있다.
플러그인 추천
3부 멀티 모듈을 활용한 플러터 클린 아키텍쳐
클린 아키텍쳐?
-> Robert C Martin이 제안한 아키텍쳐(이렇게 하면 좋더라 츄라이?)
프로그램의 구성요소를 정렬하고 조립하는 방법에 대한 규칙은 보편적이며 시간이 흐름에 따라 변하지 않았다.
->보편적 규칙이 존재함
->클린 아키텍처를 통해 이규칙을 학습
만약 제대로 된 소프트웨어를 만들면, 소수의 인력으로 프로그램을 지속시킬 수 있다.
인력 최소화 = 개발 효율화 -> 개발 비용을 높이는 요소를 제거
개발 비용을 높이는 요소
-> 지속적인 변경 요청 -> 소프트웨어 구조의 복잡도는 시간이 지날 수록 증가 -> 복잡도가 증가할 수로고 변경 비용은 증가
=> 변경에 잘 대응한다는 것이 결국 개발 비용을 낮출 수 있는 것을 의미한다.
추상적인것 (일찍 결정해야 함) ->비즈니스 규칙 (what)
저장 -> 주문 내역 저장
입출력 - > 주문 양을 입력
구체적인 것(늦게 결정해도 됨) -> 도구(how)
데이터베이스 -> mysql
화면 -> textfield를 활용해 주문양을 입력
->플러그인 아키텍처를 통해 늦게 결정해도 되는 요소를 미룸
*구체적인 것과 추상적인 것들을 독립 시킨다면 변수에 대응하거나 돌발상황에서 유연하게 대처가 가능할 확률이 높아진다.
인프라 영역 의존성을 flutter가 dart에게 주입해줘야 하는 부분이다.
경계의 의미
경계선 긋기
모놀리틱
app에서 domain으로 의존성 방향이 갈 수 있지만 반대 경우는 진행 될 수 없다.
이런 규칙이 깨지는 것을 아키텍쳐의 오염이라고 부르면 다음과 같이 진행 되면 향후 개발에 차질이 생길 수 있으며 -> 개발 비용이 높아지는 요소가 될 수 있다.
막는 법
강력한 정책
코드 리뷰
정적 검사
-> human error가 발생할 수 있으며 사후적 대처에 그치지 않는다.
경계의 선을 긋는 것이 위 방법 보다 더욱 간결하고 접근 자체를 원척적으로 막을 수 있게 된다.
import 자체적으로 막을 수 있다는 것을 확인 할 수 있다.
이외에도 다양한 내용이 진행 되었지만...
hands on 에서 기초적인 내용을 듣고 오느라... 나중에 영상이 공개로 전환 되면 링크도 추후 첨부할 예정이다.