SwiftUI를 통해 데이터 흐름 관리하기

안녕하세요 여러분. 제 이름은 콜이고, Apple 에서 핵심 기술 전도사로 일하고 있습니다. 오늘은 앱의 데이터에 대해 이야기해 보겠습니다. 그리고 그 결과를 SwiftUI 뷰로 어떻게 전달할지 알아보겠습니다. 위시리스트 앱은 제가 하루 종일 사용하는 훌륭한 예시입니다. 데이터를 접할 수 있는 몇 가지 방법을 보여드리겠습니다. SwiftUI 앱의 흐름.

위시리스트 앱도 비슷한 기능을 많이 제공합니다. 앱에 필요할 수 있는 데이터를 포함하고 있습니다. 또한, 데이터 유형에 따라 접근 방식이 달라집니다.

가장 중요한 몇 가지부터 설명드리겠습니다. 특정 장소들이 있습니다 이 앱에서는 인터페이스 상태가 변경됩니다. 누군가가 그것과 상호작용할 때. 예를 들어, 누군가가 여행 일정을 변경할 때, 앱은 사용자 인터페이스가 편집 모드인지 아닌지를 추적해야 합니다.

이런 상황이 발생할 수 있는 곳은 몇 군데 있습니다. 버튼을 누른 후 시트가 표시되는 시점을 추적하는 것과 같은 것 말입니다. 또는 경고 메시지를 표시해야 할 때. 저는 일반적으로 이러한 사례들을 뷰스테이트(Viewstate)라고 부르겠습니다.

이 앱에는 데이터 모델도 있습니다.

위시리스트 앱의 목표는 다음과 같습니다. 제가 다녀온 멋진 여행과 활동에서 얻은 풍부한 데이터를 모두 보여드리고 싶습니다. 예를 들어, 이번 교토 여행은 즐길 거리가 풍부하다는 것을 보여줍니다. 그곳에 있는 동안 사원을 탐험하는 것과 같은 경험을 할 수 있습니다. 해돋이 시간에 운하 산책로를 걷는 것 등. 그래서 앱에서 이 데이터를 모델링해야 합니다. 그리고 그 내용을 제 모든 SwiftUI 뷰에 반영합니다.

앱은 사용자가 설정한 선호 사항도 추적해야 합니다. 앱에서. 예를 들면, 앱에는 여행 일정 목록에 정렬 ​​버튼이 있습니다. 제목, 날짜 또는 활동 완료 여부별로 정렬할 수 있습니다. 앱은 사용자가 마지막으로 선택한 정렬 방식을 추적해야 합니다. 그러면 다음에 이 화면이 표시될 때 동일한 정렬 방식을 사용하게 됩니다.

그리고 마지막으로, 앱을 만들고 싶습니다. 아니, 죄송합니다. 저는 지속성을 위한 접근 방식을 구축하고 싶습니다. 지속성은 앱이 데이터를 저장할 수 있도록 하는 접근 방식입니다. 기기의 저장소에 파일처럼 저장됩니다. 그러면 다음에 누군가가 앱에 다시 접속했을 때, 앱이 재출시되더라도 모든 변경 사항은 그대로 유지됩니다.

이번 시간에는 이러한 사용 사례들을 각각 자세히 살펴보겠습니다. 자세히 설명드리겠습니다. 여기에는 뷰 상태에 필요한 데이터, 풍부한 데이터 모델 구축 등이 포함됩니다. 환경 설정 및 구성 관리, 그리고 영구 저장을 위한 몇 가지 기술.

이번 회기가 끝날 때쯤에는, 여러분은 이러한 각 사용 사례에 대해 논리적으로 추론할 수 있는 능력을 갖추게 될 것입니다. 그러면 여러분은 따라할 수 있는 패턴을 알게 될 것입니다. 여러분의 앱에서도 비슷한 요구 사항을 해결하기 위해서입니다. 먼저 Viewstate부터 시작하겠습니다.

앞서 말씀드렸듯이, 앱은 때때로 단순히 데이터 조각을 생성해야 할 때가 있습니다. 인터페이스 자체의 상태를 추적하기 위해서입니다. 이러한 현상은 대개 일시적이며, 뷰가 사라지면 안전하게 재설정할 수 있습니다. 예를 들어, 샘플 앱은 여행이 편집 모드인지 여부를 추적합니다. 아니면 아닐 수도 있습니다. 누군가가 이 여정에서 벗어나 다른 길로 이동한다면. 그러다가 나중에 다시 그 문제로 돌아온다. 사용자 인터페이스가 더 이상 편집 모드가 아닌 것은 당연합니다. 완료 버튼을 누르지 않았더라도요.

인터페이스에서 추적해야 하는 상태의 또 다른 예가 여기 있습니다. 이 앱의 위시리스트 탭에 있는 툴바에 추가 버튼이 있습니다. 커트가 앞서 애니메이션을 다듬을 때 이 버튼에 대해 이야기했었죠. 이 버튼을 누르면 누군가가 작업을 시작할 수 있는 시트가 나타납니다. 앱에 추가할 새로운 여행의 세부 정보를 입력하고 있습니다.

따라서 앱은 상태를 추적하기 위한 데이터가 필요할 것입니다. 현재 화면에 시트가 표시되어 있는지 여부.

또한, 스프레드시트 자체에 변경 사항을 저장하거나 여행 추가를 취소하는 버튼이 있습니다. 따라서 시트 내의 해당 작업들은 상태를 업데이트할 수 있는 방법이 필요합니다. SwiftUI 시트를 닫도록 하기 위함입니다.

SwiftUI 에서 시트를 사용하여 추가 버튼을 구현하는 방법은 다음과 같습니다.

위시리스트 보기 본문에 있습니다. 심볼 레이블이 있는 SwiftUI 버튼이 있습니다. 그리고 시트를 표시하기 위해 버튼 동작에 코드를 추가해야 합니다.

자료 자체를 제시하기 위해. 뷰에 추가되는 시트의 Ispresented 수정자를 사용해야 합니다.

자, 이 코드를 완성하기 전에 SwiftUI 결정을 내려야 합니다. 추적하는 데이터는 무엇입니까? 아니면 이 시트가 지금 화면에 실제로 표시되어 있는 건가요?

이건 at state API를 활용하기에 아주 좋은 사례네요. 작동 방식은 다음과 같습니다. '여행 추가'라는 새 속성을 만들겠습니다. 그리고 at 상태를 사용하여 장식하며 기본값은 false입니다.

`at` 상태를 사용합니다. SwiftUI 지속되는 새로운 데이터를 생성하도록 지시합니다. 이 견해가 유효한 한.

이 값의 수명에 대해서는 조금 후에 더 자세히 설명드리겠지만, 지금은 다음과 같습니다. 이제 정의를 마쳤으니 뷰의 나머지 부분에서 사용할 수 있습니다.

버튼 동작에서 '여행 추가'를 true로 설정할 것입니다. 버튼을 누르면 항상 시트가 나타나야 하므로, 만약 해당 스프레드시트가 이미 표시 중이라면 버튼을 비활성화하겠습니다. 상태를 disabled 한정자에 전달함으로써.

뷰 본문이 다음을 읽기 때문에 이 점에 유의하십시오. 이 수정자처럼 여행 가치를 추가하는 것을 보여주고 있나요? 위시리스트 보기에서는 언제든지 이 값에 대한 종속성을 설정할 수 있습니다. 여행 일정 변경 사항을 추가하고 있습니다. SwiftUI 이 뷰를 업데이트합니다.

또한 "여행 추가" 속성을 시트 수정자에게 전달하겠습니다. 이 달러 기호 표기법을 사용하면 이 상태에 대한 바인딩을 전달할 수 있습니다. 이 코드가 해당 값을 시트와 공유하도록 하여 둘 다 읽을 수 있도록 합니다. 그리고 그것을 수정하세요. 바인딩에 대해서는 잠시 후에 더 자세히 설명해 드리겠습니다.

부동산을 꾸미는 것 at state는 SwiftUI 이 속성이 포함하는 뷰의 소유임을 알려줍니다.

이 속성의 가치는 뷰가 존재하는 한 존재합니다.

그리고 이것은 제가 앞서 언급했던 중요한 점입니다. 상태 속성은 인터페이스에서 뷰의 수명과 일치합니다. 뷰 구조체 자체의 수명과는 무관합니다. 그럼 이게 실제로 어떻게 작동하는지 좀 더 자세히 알아볼게요. 오늘 레아가 앞서 이야기했듯이, SwiftUI 뷰는 템플릿처럼 수명이 짧은 설명일 뿐입니다. 위시리스트 보기 화면이 인터페이스에 나타나면, SwiftUI 화면의 UI를 업데이트하기 위해 본문을 실행합니다. 하지만 그러면 해당 인스턴스가 삭제됩니다.

그리고 이 과정은 SwiftUI 뷰를 렌더링할 때마다 반복됩니다.

그렇다면 왜 '여행 추가' 속성이 초기화되지 않는 걸까요? 기본값이 false이므로 이 뷰가 다시 초기화될 때마다 발생하는 문제인가요?

네, 그건 SwiftUI 특별한 처리를 해주기 때문입니다. 이와 같은 국유 재산에서.

SwiftUI 내부적으로 자체 데이터 저장소를 사용합니다. 국가 소유의 모든 관점에 대해. SwiftUI 이 뷰를 처음 인스턴스화할 때, 내부 저장소에 공간을 할당합니다. 이 부동산은 다른 관점과 함께 국가가 소유한 모든 부동산과 함께 고려됩니다.

이 저장소는 뷰의 식별자로 인덱싱됩니다.

그 항등식을 대응하는 것으로 생각해 보세요. 이 뷰의 렌더링 결과가 화면에 표시되는 수명에 해당합니다. SwiftUI 뷰를 처음 렌더링할 때, 뷰에 고유한 식별자를 할당합니다.

그리고 누군가가 이 화면에서 벗어나 다른 화면으로 이동하면, SwiftUI 저장소에서 해당 항목을 삭제합니다. 만약 그들이 나중에 그 관점으로 돌아온다면, SwiftUI 새로운 식별자를 할당하고 저장소에 새 항목을 추가합니다.

자, 이제 시트를 보여주는 제 버튼이 어떻게 작동하는지 보여드리겠습니다. 누군가가 위시리스트 보기로 처음 이동할 때 탭합니다. SwiftUI 저장 공간을 할당합니다. 이 뷰는 기본값을 사용하여 여행 상태 속성을 추가하는 방법을 보여줍니다. false의 값.

그런 다음 구조체를 인스턴스화하고 값을 설정합니다. 현재 표시 중입니다. Swiftui의 내부 저장소와 일치하도록 여행을 추가하세요. 그런 다음 위시리스트 뷰의 본문을 실행하여 화면에 렌더링합니다.

그런 다음 뷰 인스턴스를 버립니다. 앱 사용자가 버튼을 탭하면. 액션 클로저 실행 설정에서 '여행 추가'를 true로 설정하고 있습니다. 하지만 이곳은 국가 소유 재산이기 때문에, 이 과제는 Swiftui의 내부 저장소를 수정합니다. 뷰의 본문이 이 상태에 의존하기 때문에 SwiftUI 업데이트를 트리거합니다. 새로운 뷰 구조체를 생성하고 해당 값을 채워 여행을 추가합니다. 내부 저장소에서 얻은 새로운 진정한 가치로. 달리기 전 몸 상태.

SwiftUI 이러한 내부 저장소를 통해 상태를 유지합니다. 인터페이스에서 뷰가 표시되는 동안. 구조체 자체는 일시적이지만 말입니다.

네, 그럼 이 내부 저장소는 상태 속성이 SwiftUI 에 어떻게 요청되는지 설명해 드리겠습니다. 인터페이스에서 이 뷰의 수명 동안 부울 값을 추적합니다.

하지만 상태는 단일 뷰 선언 내에서만 유용한 것은 아닙니다. 또한 바인딩이라는 것을 사용하여 다른 뷰와 공유할 수도 있습니다.

시트 수정자에 있는 이 달러 기호를 사용하면 바인딩에 접근할 수 있습니다. 이것은 여행 상태 추가를 보여줍니다.

바인딩이란 앱의 특정 상태에 대한 읽기/쓰기 참조를 의미합니다.

뷰를 만들 때 특히 유용합니다. 바깥쪽 뷰에서 값을 읽으려면, 그리고 그 값을 변경해야 할 수도 있습니다.

바인딩은 SwiftUI 전반에서 사용됩니다. 해당 설정은 토글 버튼과 텍스트 필드의 매개변수에서 찾을 수 있습니다. 시트 수정 기능 등도 포함됩니다.

이것들은 해당 데이터에 의존하고 이를 수정할 수 있는 캡슐화된 제어 기능입니다. 필요할 때. 예를 들어, 다음은 여행 추가 화면의 일부입니다. 이는 시트 자체 내부의 모습입니다.

이는 바인딩을 사용하여 바깥쪽 뷰로부터 참조를 받습니다. 뷰 본문에 시트가 표시되는지 여부를 추적하는 상태로 이동합니다. 스프레드시트를 닫을 수 있는 버튼이 있습니다. 이를 위해 Ispresented 바인딩 값을 false로 설정했습니다. 그들의 행동 마무리에서.

이로 인해 SwiftUI 해당 뷰에 의존하는 모든 뷰를 업데이트하게 됩니다. 저와 같은 주에서요. 화면을 닫으면 시트가 닫힙니다.

제가 단순히 진행 상황을 추적하고 싶은 시트 같은 곳들이요. 누군가가 인터페이스와 상호 작용할 때, 그것은 아주 적합합니다. 현재 상태입니다. 이는 뷰가 사라지면 초기화되는 임시 데이터입니다. 또는 뷰가 존재하는 동안에만 존재해야 하는 객체가 있는 경우입니다.

하지만 상태 정보는 제 데이터 모델과 같은 다른 유형의 데이터에는 가장 적합하지 않습니다. 그러한 경우에는 상태 유형을 표현하는 방법이 필요할 것입니다. 다른 코드 부분에서 소유하고 있는 SwiftUI 대해, UI 자체에서 소유하는 것이 아닙니다.

그래서 다음 사용 사례인 위시리스트의 데이터 모델로 넘어가겠습니다. 데이터 모델은 이 앱의 핵심이자 영혼입니다. 여기에는 사람들이 앱으로 다시 돌아오도록 유도하는 데 필요한 모든 정보가 포함되어 있습니다. 예를 들어, 여행마다 이름, 사진, 활동 내역 등을 기록하고 싶어서요. 이 예시처럼, 여행 객체의 이름은 페루 오프로드입니다. 그리고 이와 관련된 멋진 사진이 있습니다.

이러한 객체들 사이에도 관계가 존재합니다. 예를 들어, 여행에는 여러 가지 활동과 프로그램이 포함될 수 있습니다. 이름과 같은 고유한 속성을 가지고 있습니다. 그리고 활동이 완료되었는지 여부를 추적하는 부울 값입니다.

그래서 저는 여행을 나타내기 위해 클래스를 사용하는 데이터 모델을 만들었습니다. 이 앱의 활동 및 기능.

각 클래스는 이름, 사진, 날짜와 같은 속성을 저장하는 속성을 가지고 있습니다.

또한 서로에 대한 참조를 순서대로 저장합니다. 이러한 객체들 간의 관계를 모델링하기 위해서입니다. 예를 들어, 여행 객체에는 여러 개의 활동이 연결될 수 있습니다. activities 속성에 해당 항목에 대한 참조를 저장함으로써 이를 활용할 수 있습니다.

그리고 이러한 객체들은 편집도 가능합니다. 사용자가 UI에서 이러한 속성을 변경할 수 있기 때문입니다. 예를 들어 누군가가 텍스트 입력란에서 여행 이름을 수정할 때처럼요.

저는 DataSource라는 클래스도 만들었습니다. 앱 내에서 이러한 모든 객체를 관리하기 위해서입니다. 앱이 필요한 모든 객체를 찾아볼 수 있는 단일 장소입니다. 사용자 인터페이스에 표시하기 위해, 예를 들어 모든 여행 목록을 가져오는 것과 같은 기능을 합니다.

이와 같은 데이터 모델을 갖는 것은 훌륭한 출발점입니다. 하지만 SwiftUI 에서 이 데이터 모델을 제대로 사용하려면 한 가지 간단한 작업을 추가해야 합니다.

데이터 모델은 속성 변화가 언제 발생하는지 알 수 있어야 합니다. SwiftUI UI를 업데이트할 수 있도록 하기 위함입니다. 이것이 바로 관찰 가능한 매크로의 용도입니다. 이 한 줄의 코드로, SwiftUI 속성 간의 종속성을 설정할 수 있는 권한을 부여할 수 있습니다. 수업 시간에요.

관찰 가능한 매크로는 각 클래스 속성에 업데이트 추적 기능을 추가합니다. 사용하려면 각 클래스에 `at observable` 매크로를 추가하기만 하면 됩니다.

이제 데이터 모델을 관찰할 수 있게 되었으니, SwiftUI 이제 모델 속성에 대한 종속성을 직접 설정할 수 있습니다.

이 예시에서 여행 카드 보기는 참조를 사용합니다. 여행 객체에 표시되어야 합니다.

at 상태나 at 바인딩이 없다는 점에 유의하세요. 사실 이 참고 자료에는 장식이 전혀 없습니다. 이 뷰가 작동하는 이유는 뷰 본문 내부에 다음과 같은 내용이 있기 때문입니다. 여행 사진 URL 속성입니다. 이는 SwiftUI 여행 카드에 필요한 것이 무엇인지 알려줍니다. 이 관찰 가능한 클래스의 사진 URL 속성이 변경될 때마다 업데이트합니다.

그리고 이것은 계산된 속성을 통해서도 작동합니다. 예를 들어, 임시 사진을 사용하고 싶다고 가정해 보겠습니다. 아직 사진이 저장되지 않은 여행의 경우. 이를 사용자 인터페이스에서 처리하기 위해서입니다. 여행 정보에 사진 URL 또는 플레이스홀더라는 이름의 계산 속성을 정의할 수 있습니다. 이 계산 속성은 정의된 사진이 없는 경우 자리 표시자 사진을 반환합니다. 여행을 위해서요. 그리고 나서 새로 계산된 속성을 사용합니다. 사진 URL 대신 뷰 본문에 표시합니다.

SwiftUI 기본 속성인 사진 URL이 읽혔는지 확인할 수 있습니다. 이 뷰 본문에서 계산된 속성에 접근할 때. 따라서 SwiftUI 기본 사진 URL이 변경될 때마다 여행 카드를 업데이트합니다.

자, 정리하자면, 이 앱은 여행 정보를 구조화된 데이터 모델로 표현합니다. 및 활동 객체.

각 객체를 모델링하기 위해 참조 타입 또는 클래스를 사용합니다. 이렇게 하면 참조를 사용하여 이러한 객체 간의 관계를 모델링할 수 있습니다. 또한 이러한 속성은 사용자 인터페이스 어디에서든 쉽게 편집할 수 있습니다.

이러한 클래스의 데이터가 SwiftUI 로 전달되도록 하려면, 각 정의에 관찰 가능한 매크로를 추가하기만 하면 됩니다. 그러면 SwiftUI 뷰에서 뷰 본문의 속성을 직접 읽을 수 있습니다.

이제 제가 해야 할 일이 하나 더 남았습니다. 지금까지 보여드린 방법은 아주 잘 작동합니다. 뷰가 이미 여행과 같은 객체에 대한 참조를 가지고 있는 경우.

앞서 말씀드렸듯이 이 모든 물건들은 다음 사람들의 소유입니다. 데이터 소스 클래스, 하지만 뷰에서 어떤 데이터 소스 인스턴스를 사용해야 하는지 어떻게 알려줄 수 있을까요?

음, 사실 저는 이미 이 방법을 사용하는 한 가지 방법에 대해 설명드렸습니다. 그리고 그것은 주(州)에서 시작됩니다.

우리가 특정 상태에서 생성할 객체는 그 객체가 존재하는 동안 계속 존재한다는 것을 기억하십시오. 내 앱 상단의 뷰처럼 말이죠. 데이터 소스 객체를 저장하는 at 상태 속성을 만들 수 있습니다. 이 앱 선언에 상태를 넣으면 일정 기간 동안 존재하는 객체가 생성됩니다. 앱이 하는 것처럼 처리한 다음 뷰로 전달할 수 있습니다.

이 방식은 뷰 계층 구조가 매우 간단한 경우에는 잘 작동할 수 있습니다. 하지만 이 앱에서는 그렇지 않습니다. 사용자 인터페이스의 여러 부분에서 데이터 소스에 접근해야 할 수 있습니다. 예를 들어, 전체 여행 목록을 보려면 그리고 매우 간단한 뷰 계층 구조를 가지고 있습니다. 데이터 소스와 같은 객체를 그대로 전달하는 것은 지극히 합리적입니다. 그것을 필요로 하는 사람들에게.

하지만 앱이 복잡해짐에 따라, 이러한 접근 방식은 번거로워지기 시작할 수 있습니다. 뷰가 여러 겹으로 중첩된 앱은 결국 특정 조건을 충족해야 할 수도 있습니다. 데이터 소스에 대한 참조를 저장합니다. 더 깊은 관점을 필요로 하는 사람들에게 전달할 수 있도록 하기 위해서입니다.

이러한 문제를 피하려면, 이러한 사례는 해당 환경에 잘 어울릴 수 있습니다.

환경을 필수적인 속성으로 생각하십시오. 앱의 일부를 구성하는 설정이며, 자주 변경되지 않습니다.

이 경우, 저는 상태를 나타내는 데이터 소스 객체를 생성하겠습니다. 그리고 해당 객체를 뷰 환경에 설정하겠습니다. 이 설정은 데이터 소스가 필요한 뷰를 구성합니다. 이 특정 사례에서는 그렇습니다.

데이터 소스 객체 자체가 교체되지 않으므로 안전합니다. 아주 자주 발생합니다. 관찰 가능합니다. 그리고 다양한 견해들이 존재합니다. 제 앱에서 해당 항목에 대한 참조가 필요할 수도 있습니다. 따라서 데이터 소스를 환경에 배치함으로써, 참조가 필요한 뷰는 해당 참조를 직접 가져올 수 있습니다.

환경 설정은 적용되는 전체 뷰 계층 구조를 통해 흐릅니다. 여러분 중 누구든 환경으로부터 가치를 요구하기만 하면 됩니다. 그리고 SwiftUI 그것을 제공할 것입니다.

예를 들어, 뷰 계층 구조에서 더 깊은 곳에는, 최근 여행 페이지 조회 시 참조가 추가됩니다. 속성에 데코레이터를 추가하여 데이터 소스에 적용합니다. 환경 변수에서 SwiftUI 이 참조의 값을 채웁니다. 환경에서 일치하는 유형의 객체와 함께.

데이터 소스는 관찰 가능하므로, 뷰는 종속성을 설정할 수 있습니다. 뷰 본체 내부에서부터 해당 속성에 대한 정보를 얻을 수 있습니다. 여기서는 최근에 추가된 Trips 속성이 이 뷰 본문에서 읽힙니다. 따라서 최근 여행 페이지 보기는 새로운 여행 정보가 추가될 때마다 업데이트됩니다. 여행 일정이 앱에 추가되었습니다.

그래서 뷰 ​​상태와 데이터 모델이 제가 필요로 하는 데이터 흐름의 상당 부분을 커버합니다. 이 앱에서는 현재까지는 이 정도지만, 다른 몇 가지 활용 사례가 더 있습니다. 약간 다른 접근 방식을 취합니다. 그럼 이제 선호도에 대해 계속 이야기해 보겠습니다. 이 앱의 설정 및 구성.

앞서 언급했듯이 누군가가 여행을 탭하면, 표시되는 활동 목록을 이름순으로 정렬할 수 있습니다. 또는 완료 여부에 따라.

앱은 이 설정을 저장해야 합니다. 그래서 누군가가 이러한 견해를 갖게 될 때마다, 그들이 선호하는 정렬 방식을 사용합니다.

지금으로서는 선호도가 잘 맞지 않습니다. 앞서 설명한 데이터 모델 내부로 들어가 보겠습니다. 왜냐하면 이것은 여행 자체와는 사실상 아무런 관련이 없기 때문입니다. 사람들의 선호도를 추적하는 것입니다. 앱의 다양한 기능을 사용하기 위해서입니다.

따라서 이 정렬 기능을 구축하려면 다음과 같은 단계를 거쳐야 합니다. at state를 사용하여 새로운 상태를 정의하는 것으로 시작할 수 있습니다. 어떤 정렬 방법이 사용되고 있는지 추적하기 위해서입니다.

이 예시에서는 '정렬 옵션'이라고 합니다. 그리고 나서 활동이 시작됩니다. 서브뷰는 액티비티를 배치할 때 정렬 옵션을 읽습니다.

이제 제대로 작동하고, 활동들이 사용자가 선택한 순서대로 정렬됩니다. 메뉴에 있습니다.

하지만 이와 같은 상태 속성은 저장만 된다는 점을 기억하세요. 그 전망이 지속되는 동안. 그래서 누군가가 이 화면을 떠났다가 다시 돌아오면, 정렬은 항상 기본 정렬 방식인 제목순으로 되돌아갑니다. 누군가가 여행 상세 정보 보기 화면으로 다시 돌아올 때마다 다음과 같은 일이 발생하도록 하고 싶습니다. 이전에 선택했던 방식 그대로 정렬되어 있습니다.

이렇게 하려면 앱 저장소의 상태를 변경해야 합니다. 또한 설정에 대한 고유 식별자를 제공합니다.

앱 저장소는 상태 저장소와 매우 유사하게 작동합니다. 이는 앱 전체에 적용되는 전역 상태 변수를 선언합니다. 그리고 이는 간단한 코딩 가능한 유형에서 가장 잘 작동합니다.

앱의 저장 공간 값은 실제로 내부적으로 자동으로 디스크에 저장됩니다. 이 기능은 Apple 플랫폼에서 Userdefaults라는 API를 사용합니다. 앱에 사용할 키와 값 집합을 저장하는 곳입니다.

그리고 이곳은 설정하기에 아주 좋은 장소입니다. 환경 설정 및 앱 구성 세부 정보.

이제 정렬 기본 설정을 앱 저장소 속성에 저장함으로써, 활동 목록입니다. 이제 항상 누군가가 마지막으로 선택한 옵션을 기준으로 정렬하세요. 다양한 여정을 탐색하는 동안에도 시야를 확보하고 있습니다.

마지막으로 오늘 논의하고 싶은 마지막 사용 사례는 영구 저장입니다.

방금 보여드린 예시에서 정렬 설정을 저장했습니다. 앱 저장소를 사용하는 것은 실제로 지속성의 한 예입니다. SwiftUI Userdefaults API를 자동으로 사용합니다. 디스크에서 이 키의 값을 얻으려면, 그런 다음 뷰의 값을 그에 맞게 설정합니다.

정렬 옵션에 다른 값이 할당되면, 앱 저장소는 해당 새 값을 Userdefaults에 저장합니다. 그래서 누군가가 하루 뒤에 다시 앱에 접속하더라도, 혹은 일주일 후 또는 한 달 후에, 정렬 옵션 속성은 변경될 때까지 그대로 유지됩니다.

하지만 물론, 당신이 고수하고 싶은 것은 단지 선호도만이 아닐 수도 있습니다. 이 앱은 풍부한 데이터 모델을 가지고 있습니다. 사람들은 분명히 며칠 동안 위시리스트를 저장해 두고 싶어할 겁니다. 또는 몇 주 이상.

앱에서 영구 저장 기능을 갖춘 이러한 데이터 모델을 구축하려면 다음과 같이 하면 됩니다. Swift Data는 훌륭한 선택지 중 하나입니다. Swift Data는 앱에 데이터 영구 저장 기능을 빠르게 추가할 수 있도록 해주는 프레임워크입니다. 최소한의 코드로 외부 의존성 없이 작동합니다.

이 앱은 매크로 및 속성 래퍼와 같은 최신 Swift 언어 기능을 사용합니다. 이를 통해 Swift 코드만으로 모델을 설명할 수 있습니다.

기본적으로 Core Data의 검증된 영구 저장 기능을 활용합니다. Swift 데이터의 기술과 모델은 모두 자동으로 관찰 가능합니다.

Swift 데이터에 대해 더 자세히 알아보려면 다음 영상을 시청하세요. Swift 데이터 소개 Swift Data를 사용하여 앱을 구축해 보세요. 앞서 말씀드렸듯이 데이터 모델은 몇 가지 클래스로 구성되어 있습니다. 그리고 그것의 각 속성 그리고 서로 간의 관계는 속성으로 저장됩니다. 각 수업에 대해. 현재 이러한 클래스에는 observable 매크로가 적용되어 있습니다.

하지만 Swift 데이터를 사용하여 해당 데이터를 영구 저장하고 싶다면, 관찰 가능한 매크로를 모델 매크로로 바꾸기만 하면 됩니다.

모델 매크로는 이러한 클래스를 Swift 데이터 모델로 변환합니다. 그리고 다시 말하지만, 이렇게 하면 자동으로 관찰 가능해집니다.

재미 삼아 한번 해 볼까요? 샘플 코드가 제공되면 다운로드하여 사용해 보실 수 있습니다. 이 앱을 Swift Data로 이전하기 위해 몇 가지 단계를 거치고 있습니다. 관심 있는 분들을 위해, 코드에서 변경해야 할 몇 가지 핵심 사항을 설명해 드리겠습니다. 먼저 모델에 메타데이터를 추가해야 합니다. 앱의 뷰 내부에서 데이터를 가져오거나 쿼리하는 방식을 개선할 수 있습니다. 그리고 모델을 저장할 컨테이너를 설정하게 됩니다. 그럼 각 단계를 간단히 설명드리겠습니다.

첫째, 모델을 Observable 모델에서 App 모델로 전환한 후, 모델들을 차례로 살펴보게 될 겁니다. 원하는 위치에 속성에 주석을 추가하세요. Swift 데이터에 그들에 대한 더 많은 정보를 제공하기 위해서입니다. 예를 들어, 통행 모델에서, 활동 속성에 대한 관계를 사용할 수 있습니다. 여행과 활동 간의 관계를 정의하기 위해. 여기서는 삭제 규칙을 연쇄적으로 설정하여 여행이 삭제될 때, 해당 계정의 모든 활동 내역도 삭제됩니다.

또한 여행 속성에 대한 역관계를 "죄송합니다"로 설정했습니다. 여행 속성과 활동 간의 역관계. 즉, 이러한 활동의 ​​여행 속성은 항상 이전 위치를 가리킨다는 의미입니다. 그것이 속한 여행에.

이제 Swift 데이터를 사용하면 뷰 내에서 모델을 가져와 표시하는 것이 매우 쉬워졌습니다. `at` 쿼리를 사용하면 Swift 데이터에 정렬된 모델 배열을 간단히 요청할 수 있습니다. 원하는 방식으로 필터링할 수 있습니다.

이 코드 조각에서는 앞서 보여드렸던 최근 여행 페이지 보기 화면을 업데이트했습니다. 예전에는 데이터 소스 객체를 사용했습니다. 최근 추가된 여행 목록을 보려면, 하지만 Swift 데이터를 사용하면 쿼리를 바로 사용할 수 있습니다.

이 쿼리는 Swift Data에 정렬된 여행 목록 배열을 제공하도록 요청합니다. 생성일자를 기준으로 내림차순으로 정렬합니다.

뷰 본문은 최근에 추가된 여행 배열을 사용합니다. 각 항목에 대해 Swift 데이터는 쿼리 결과가 변경될 경우 이 뷰를 업데이트합니다. 새로운 여행 일정이 보기에 추가될 때.

마지막으로 앱 선언에서, 앱을 구성할 때 모델을 저장할 컨테이너를 사용하게 됩니다. 모델 컨테이너 수정자를 추가하여 그리고 모델 유형의 이름을 전달합니다. 앱은 모델에 기본 컨테이너를 사용합니다.

그래서 이 세 가지 변화가 있습니다. 속성 메타데이터 추가, 쿼리 개선 그리고 모델 컨테이너를 추가하는 것이 시작하는 데 핵심입니다. 이로써 Swift Data의 강력한 데이터 영구 저장 기능이 이와 같은 앱에 적용됩니다.

자, 이제 위시리스트 앱의 데이터 흐름 사용 사례를 모두 살펴보았습니다. 그리고 여러분은 SwiftUI 앱에서도 이와 유사한 접근 방식을 취할 수 있습니다. 앱의 뷰가 간단한 UI 상태만 추적하면 되는 경우, 마치 버튼을 눌렀을 때처럼요. 상태를 사용한 다음 바인딩을 사용하여 다른 뷰에서 사용할 수 있도록 합니다. 또는 제어 장치들이 해당 상태의 일부를 공유합니다. 풍부한 데이터 모델을 구축할 때 관찰 가능한 매크로를 사용하는 것을 고려해 보세요. 클래스와 같은 참조 타입을 사용하는 경우. 데이터를 저장하고 싶을 때. 그러니 데이터를 저장 장치에 저장하여 영구적으로 보관하세요. 앱 저장 공간은 설정 및 환경설정과 같은 작은 파일들을 저장하는 데 사용하세요. 모델 데이터에는 Swift 데이터 프레임워크를 고려해 보세요. 시간 내주셔서 감사합니다. 남은 행사도 즐겁게 보내시길 바랍니다. 그리고 다시 리아에게로 돌아가죠.