[SwiftUI, 상태관리][0편] 스위프트UI 에서의 상태관리

수년간 iOS/Flutter 개발자로 현업을 이어오고 있다.

21년 초, Flutter로 넘어오면서 큰 프로젝트의 메인으로써 개발을 이어나가다 보니, SwiftUI와 UIKit 과도기 사이에서 SwiftUI로 넘어오지 않고 Flutter 개발에 집중하고 있었다.

이제는 앱도 출시됐고, 앞으로 iOS AR 개발을 해 나가야된다.

Flutter에서 PlatformView를 통해서 AR을 띄울 화면을 개발해야하기 때문에 AR개발에 앞서 SwiftUI을 적응하고자 한다.

사실 PlatformView에서 SwiftUI가 작동하는지 여부는 확인하지 않았다. SwiftUI도 이제는 3년차의 프레임워크이기 때문에 별다른 조사 없이 공부를 시작한다. (안되면, UIKit 사용하지 뭐..)

 

이번엔, 간단하게 모바일앱에서의 상태관리 자체에 대해서 설명하면서 대략적인 SwiftUI에서의 상태관리에 대해서 알아보고자 한다.

요즘엔, 모바일앱에서는 크게 두가지 정도의 상태관리 모양이 있는데

1. 원하는 파트를 지정하여 업데이트

2. 변수들을 트래킹하여 변수가 변하면, 변수가 포함되는 부분을 인식하고 업데이트

정도이다.

 

좀 더 이해하기 쉽게 표현하면 

1. 지정하여 업데이트 (이벤트를 발생시켜서)

2. 자동인식하여 업데이트 (변화되었는지 트래킹할 부분을 미리 지정)

라고 할 수 있을 것 같다.

 

플랫폼들에 따라서 그 모양과 사용방식이 다르기도 하고, 두개 다 사용한다거나 하는 경우도 있고 그렇다.

 

선언형의 구조를 가진 경우에는 대게 2번의 상태관리 모양을 가지게 되는데, 화면들이 모두 종속적이지 않은 구조를 가지는 것인지 있어서 가능한 게 아닌가 싶다. 깊게 이해하는 것은 다음에 있을 워크샵에서 동료 개발자와 얘기하면서 알아나가면 머리도 덜 아프고 좋을 것 같다...

 

UIKit에서는 1번이었다. delegate로 연결해두고, 변경할 부분을 지정하여 변경시키는 느낌이었다.

Flutter에서는 기본 State는 1번, Provider나 GetX 같은 3rd-party 상태관리 라이브러리 같은 경우에는 2번이었다. 나는 처음부터 Provider를 3개월 정도 사용하고, 앱서비스를 피봇팅하면서 완전히 처음부터 다시 개발해야될 때 GetX로 넘어왔기 때문에 Flutter를 개발할 때는 거의 2번을 사용했다. 하지만 일부 상황에서는 1번처럼 2번 방식을 강제적으로 활용하여 사용하는 경우도 있다.

지금까지 공부한 바로는 SwiftUI의 상태관리는 Flutter의 3rd-party들과 아주 흡사하다. 

Flutter에서 가장 편했던 것이 바로 변수가 변하면 자동으로 화면들이 업데이트 되는 것이었는데, SwiftUI도 같은 상태관리 모양을 가진다. 세부적으로는 광역적인지 지역적인지 같은 다양한 옵션들이 있는데, 그런 것들은 직접 개발을 해보면서 차근차근 포스팅 해보겠다.