PreferenceKey는 하위 뷰에서 상위 뷰로 데이터를 전달하기 위한 메커니즘입니다. 일반적으로 SwiftUI는 데이터가 상위 뷰에서 하위 뷰로 전달되는 구조를 따르지만, PreferenceKey는 그 반대 흐름을 가능하게 해줍니다.PreferenceKey의 주요 구성 요소PreferenceKey는 다음과 같이 세 가지 주요 요소로 이루어집니다:키 등록: PreferenceKey 프로토콜 준수 및 타입 정의값 송신: 하위 뷰에서 preference 메소드를 통해 값 전달값 수신: 상위 뷰에서 onPreferenceChange 메소드를 통해 값 수신PreferenceKey 프로토콜 구조SwiftUI에서 PreferenceKey는 아래와 같은 프로토콜로 정의됩니다.public protocol Prefer..
앱 내에서 새로운 친구를 맺을 때, 링크를 통해 친구를 맺고, 만약 다운받지않은 유저라면 앱스토어로 이동하도록 구현을 해야했다. 그러면 어떻게 공유할 수 있을까? 카카오 API의 방법도 있지만 애플로그인으로 하는 경우에는 사용하지 못한다. 그래서 우리는 iOS16이전까지는 위의 기능을 UIKit을 이용해야 했지만 이후에서는 ShareLink를 통해 자체적으로 SwiftUI에서 사용할수 있기에 위의 기능을 사용하기로 했다.아주 쉽다. 그 전에 ShareLink를 통해 데이터를 내보낼 수 있는데 해당 데이터(Item) Transferable 프로토콜을 준수해야한다.ShareLink(item: subject: message:): subject는 제목으로 공유대상이 이메일, 메시지 앱 등일때 필드들이 미리 채워..
이전까지는 테스트코드나 프리뷰 코드 없이 오직 Dependency의 라이브밸류를 통해서만 개발을 테스트하고 진행했다. 하지만 이렇게 하다보니 계속 빌드를 해야한다는 단점이 있었고 원하는 플로우를 보기위해 과정이 커질수록 시간이 오래걸리고 임의의 값을 넣어 테스트하기도 힘들었다. 그래서 드디어 테스트 코드와 프리뷰코드를 공부해보려 한다. ㅠㅠㅠ 늦었따!https://axiomatic-fuschia-666.notion.site/Chapter-9-TCA-Testable-Code-ad3924113fbb4f89a06f30ddb8e884f7 Chapter 9. TCA와 Testable Code | Notion9.1 유닛 테스트axiomatic-fuschia-666.notion.site역시나 노션문서를 통해 참고하여..
이전까지 글을 쓰고 글을 토대로 뷰와 Feature들에 대해 개발을 진행을 하였다. 규모가 점차 커졌고 나의 앱에서는 내가 여행중인 상태일때 coreLocation을 이용하여 특정한 위치에 갓을때 어떠한 이벤트를 주어야하기에 DI, DIP에 신경을 써야했다. 현재는 얼렁뚱땅 기존처럼 manager파일로 관리를 하였지만 TCA에서는 client라는 이름을 붙혀 외부 의존성을 추상화하고 관리하는 역할을 한다고 한다. Dependency?- 먼저 의존성이 뭔지를 알아야 한다 . 한 객체에서 다른 객체의 기능을 필요로 할때 -> 그 객체에 의존하고 있다. ex) 어떠한 뷰모델에서 다른 뷰모델의 기능이 필요할때가 있다. 그래서 다른 뷰모델을 해당 뷰모델에서 생성하고 기능을 사용할 수 있다. 이를 의존하고 있다고 ..
Dependency?= 의존성네트워크 통신, 유저디펄트, 키체인 등 의존성에 대한 관리 -> app 개발 전반에 영향을 미침을 우리는 알고 있다.스유의 프리뷰를 사용해보면 알겠지만 프리뷰에도 의존성을 주입해주어야 프리뷰를 사용할 수 있다. TCA Dependency는 개발에서 더 쉽게 관리할수 있도록 도와주는 라이브러리가 있다.먼저 요즘껏들을 알기 위해서는 역사를 알야아한다.ReducerProtocol 이전Environment라는 구조체에서 의존성 관리를 하였다. 우리가 아는 흔한 하나의 구조체에 사용해야되는 기능들을 다 넣어놓고 의존해주는 형식. 문제점: 어떤 뷰에서는 사용하지 않고 어떤 하위뷰에서 사용하더라도 여기 안에 넣어놔야한다. ㅏㅗ 귀차나.새로운 의존성을 추가할때도 선언부터 초기화까지 수정하고..
이전의 글에서 Store는 런타임동안 Reducer의 인스턴스를 관리하는 참조타입의 객체라고 하였다. 결국 상태, 액션에 대한 반응까지 모두 포함한 역할을 한다. 그렇다면 이 Store를 뷰에서는 어떻게 사용해야할까?Storelet store: StoreOfScope : 하위 State 및 Action을 다루는 스토어로 변환 ㄱㄴ. 2가지 인자를 받는다. 1. State: 상태 추출할 keypath 2. Action: 액션 추출할 Keypath. -> 즉 전체의 상태에서 너 필요한거만 Store로 줄께. => View는 필요한 상태와 액션만 접근할 수 있게된다. 모듈화, 유연성 굿(자연스럽게 유닛테스트도)ViewStoreView에 필요한 상태만 구독하고 업데이트하는 역할. 하나의 스토어에서 또 많은 작업..
처음에 UIkit을 했을때는 MVC 패턴이였다. 하지만 점점 ViewController가 하는게 많아지고 양방향이기에 유지보수도 힘들어지고 테스트도 어려웠다. 그래서 점차 MVVM 패턴으로 바뀌고 실제로 나의 사이드 거닐다 프로젝트에서는 MVVM + Combine으로 프로젝트를 하였다. ViewModel에서 input과 ouput을 View와 binding하여 뷰를 업데이트하기에 코드의 양도 줄일 수 있고, 뷰모델이 뷰와 독립적인 코드의 구조로(뷰모델이 뷰에 대한 의존성이 없다), 자체 테스트도 용이해진다. 하지만 SwiftUI를 MVVM으로 했을때는 항상 팀원하고 이야기하던게 있었다. 우리가 하는 것이 진짜 MVVM이 맞는가..?ViewModel은 State-binding을 통해 관리를 해주었지만 sw..
어떠한 프로젝트를 만들면 항상 App파일과 ContentView가 만들어진다. 그리고 WindowGroup안에는 ContentView가 들어있다. 이것은 어떻게 작동하는 방식일까? @main은 Type 기반 프로그램 엔트리포인트로 아 너가 앱이 최초 시작점이자 진입점이구나를 알수 있다. 보면 이 구조체는 App프로토콜을 채택하고 있다 이 프로토콜은 시스템이 앱을 실행하기 위해 호출하는 main() 메서드의 기본 구현을 제공합니다. 모든 앱 파일 중 정확히 하나의 진입점을 가질 수 있습니다. 또 다른게 body를 보면 Scene 프로토콜이 있다. 씬은 뷰계층구조의 루트뷰를 포함하고 있고 시스템에 의해 관리되는 라이프사이클을 가지고 잇다. setting과 같은 구체화된 Scene type을 줄 수 도 있다...
제일 먼저 swiftui로 app을 만들면 만나는 코드! 그런데 우리는 과연 이 코드를 정확히 이해하고 사용하는 것일까??다른 사람은 모르겠지만 저는 일단 NOPE!!Somestruct ContentView : View { var body : Text { Text("Hello World")}}위의 코드는 에러를 표출하지 않고 정상 작동한다. 하지만 body에 text이외의 다른 타입이 들어가게 되면 에러가 뜬다.이럴때 사용하는 것이 some View. 다양한 view 프로토콜을 준수하는 구조체들을 마음껏 사용할 수 있게 된다. 아주아주아주 중요한 키워드니까 꼭 기억해야 할것!func maxT>(_ x: T, _ y: T) -> T where T: Comparable { ... } 요것이 일반적인 ..
What is @StateObject???? 우리의 G선생 왈 ObservableObject protocol을 따르는 객체의 생명주기를 관리하는데 쓰이는 프로퍼티 wrapper라고 한다. stateobject를 지정하는 순간 스유(swiftui)가 뷰계층구조가 살아있는동안 유지되도록 보장한다. >> 이것은 다른 화면으로 넘어갔다가 오더라도 객체는 지속된다는 뜻이다 객체를 생성하고 객체 관리, 뷰의 수명동안 새로운 인스턴스를 한번만 찍어냄. 이 찍어내는 타이밍은 뷰에서 생성자 처음 호출할때 그때 한번!!! 그때 stateObject생성자 한번찍힌다고 생각하면 된다. 그러면 어떻게 사용할까요? 1. 이런식으로 클래스 인스턴스 한번 찍어낼때 struct MyView: View { @StateObject pri..