［勉強会］Potatotips ＃77
코시국이고 오프라인 스터디도 비활성화 되어있고 부모님이랑 같이 사니 외출하는 것도 조심스럽다.
최근 connpass 라는 온라인 스터디 사이트에서 potatotips 라는 그룹에 참가했다.
iOS/Android 개발 Tip 공유회이다.
potatotips
분기에 1~2회씩 온/오프라인으로 진행하는 것 같다.
벌써 77회차라니 의도치않게 장수하는 그룹을 발견했다..;
아무튼 타이밍이 좋아 77회차에 참여할 수 있게 되었다. (약 90명정도 참가한 듯)
안드로이드, iOS 현직자 각각 5명씩 자신들이 최근 흥미있게 개발하거나 관심이 있는 분야에 대해 소개하는 시간을 가졌다.
iOS 분야에서 발표해주신 내용 중 흥미있는(어쩌면 기술적으로 조금이나마 이해한) 부분을
완벽하게 이해하기엔 경험치가 부족하지만서도 정리해보고자 한다🥲
부족한 내용이나 틀린 내용이 있다면 지적해주시면 감사하겠습니다.
맨 처음 발표를 해주신 분은 ANDPAD라는 건설 현장 프로젝트 툴을 운영하는 ANDPAD라는 기업의 야마시타라는 분이다.
FSM(Finite State Machine)이라는 주제를 갖고 나왔다.
iOS의 MVVM 패턴의 문제점 시작으로 서로 역할이 엉켜 스파게티 코드가 되기 쉬운 것을 단점으로 주장했다.
(나도 MVC 패턴은 너무 ViewController에만 위임하는 거 같아 최근에 공부하는 맛을 느끼는중,,ㅎ)
SwiftUI + Combine + FSM 조합으로 시험해보았다는데,,, 내용이 솔직히 어려워서 전부 다 이해하진 못했다.
FSM이 뭔데?
FSM에 대해 찾아보니 한국어로는 '유한 상태 기계'라고 한다.
컴퓨터 프로그램을 설계할 때 쓰이는 모델이며,
컴퓨터 내에 유한한 상태를 가지는 기계가 있다고 가정하고,
컴퓨터는 오로지 하나의 상태만 갖고 있을 수 있으며
각 상태별 동작과 상태끼리의 전이에 대한 내용을 설계하게 된다.
대학 때 전자공학 수업시간에 배운 논리회로와 이미지가 비슷해보인다.
Moore FSM & Mealy FSM
Moore FSM
상태에 따라 순서가 결정된다.
Mealy FSM
상태(state)와 입력에 따라 순서가 결정된다.
시스템이 복잡해지면 복잡해질 수록 밀리 쪽은 신경 써야할 것도 많아지고 감당하기 어려워지기 때문에 무어 FSM을 사용한다.
야마시타상이 발표한 주제에서는 상태 관리(State Management)만 언급했으므로 아마 무어 FSM이 아닐까싶다 ㅎㅅㅎ
또한 .idle, .invaild, .loading, .error의 상태를 봐서는 무어 FSM이 확실한 거 같다.
앞서 SwiftUI + Combine + FSM 조합을 사용했다고 했는데..
State Management 적용을 Combine Feedback을 이용했다고 했다.
Combine Feedback이 뭔데... 어떻게 하는건데...
단방향 반응형(리액티브) 아키텍처라고 함
만들어진 계기를 보면..
iOS 앱에 대한 요구사항들이 점점 거대해짐에 따라, 우리들의 코드는 엄청나게 많은 상태 변화에 대한 관리를 해야한다.
예를 들어 서버로부터의 응답이나 UI 상태, routing과 같이...
리액티브 프로그래밍이 도움을 줄 수 있지만 잘못하다간 코드 베이스를 완전히 망쳐놓을 수도 있다.
아무튼 코드로 상태 관리하는 데 도움을 준다는 얘기군..
State
State는 시스템 상태를 나타내며 Swift Type이다.
한 상태에서 다른 상태로 전환하는 유일한 방법은 이벤트를 내보내는 것이다.
Event
새로운 상태를 만들 가능성이 있는 모든 이벤트를 나타냄.
Reducer
Reducer는 상태 변화를 유발하는 이벤트를 실행하는 순수 함수.
상태 변경이 일어날 수 있는 유일한 장소라고 함 -_-
Feedback
Feedback은 대충 주상태를 변경하지 않는다.
대신, 이벤트만 방출하여 reducer 안에서 상태 변화가 일어나도록 한다.
아직 배우진 않았지만 Combine에 대해
정의: 이벤트 처리 연산자를 통해 비동기 이벤트들을 핸들링할 수 있게 함
Let's see...😧
이 비동기 이벤트를 이 Combine을 통해 처리할 수 있다는 말인가?
시간의 흐름에 따라 발생하는 이벤트를 처리하기 위한 API
등 검색해보니 말들이 다양하다 -ㅅ-
찝찝하니 좀만 더.. 알아보자..
Combine에는 이벤트를 발생시키는 Publisher, 이벤트를 소비하는 Subscriber가 있다.
그 사이에는 데이터를 가공해주는 Operator라는 대리자, 연산자가 있다.
Publisher & Subscriber protocol
얘는 시간에 따른 값의 흐름을 전달하는 프로토콜이다.
Publisher는 Subscriber로부터 처음 전달되어 Operator를 거쳐 값을 받아 다시 전달한다.
즉, Subscriber의 요청이 없으면 값을 보내지 않음!
Publisher와 Subscriber가 주고받는 데이터 타입은 두 가지가 존재한다.
Publisher 입장에는 Output, Failure 두 가지 타입이다.
그럼 Subscriber는 자동으로 Input, Failure 두 타입을 갖겠지?
//10개의 데이터를 공급할 publisher입니다.
//sink(Subscriber)가 연결되기전까지는 데이터를 발행하지 않습니다.
let provider = (1...10).publisher
provider.sink(receiveCompletion: {_ in
print("데이터 전달이 끝났습니다.")
}, receiveValue: {data in
print(data)
})
provider인 publisher는
If the publisher stops publishing, it calls receive(completion:), using a parameter of type Subscribers. Completion to indicate whether publishing completes normally or with an error.
Subscriber가 요청을 중지하면, Publisher는 문서에 따라 정상적으로 완료되거나 에러 상태를
Subscribers 유형과 같은 매개변수를 사용하여 receive(completion:) 메소드를 호출한다.
따라서 결과값은
1
2
..중략..
9
10
"데이터 전달이 끝났습니다"
결론
야마시타상이 말한 SwiftUI + Combine + FSM을 종합해보면
위와 같은 논리도가 나오게된다.
이렇게 하면 장점은
View - ViewModel - Model 간의 역할이 명확해진다.
반면에 화면이 복잡해진다면, 각 state 상태를 어떻게 정의해야할지 ?
--> 하지만 State의 흐름이 보기좋게 정해지는 것 같아 정의만 가능하다면 기분은 좋을지도..?
구글링을 좀 해보니 Combine이라는 용어는 RxSwift나 ReactiveSwift 사용되는 것 같다.
야마시타상이 발표한 내용은 15분정도인데 왜 정리하는데는 3시간이 걸린걸까
후기
처음으로 외국인 스터디에 참가해봤다.
새로운 세계를 찾은 느낌이다.
세상에는 정말 대단하고 똑똑한 사람들이 많다...
기술적인 내용이 많아 언어적으로 치이기보다 지식으로 압도당했다..
오늘 발표자중엔 버츄얼 캐릭터를 입혀놓고 발표하는 사람도 있었따...
앞으로도 시간내서 다른 그룹도 참가해봐야지 🤓
お疲れ様でしたん〜
