Xamarin.iOS의 CloudKit
CloudKit 프레임워크는 iCloud에 액세스하는 애플리케이션 개발을 간소화합니다. 여기에는 애플리케이션 데이터 및 자산 권한 검색뿐만 아니라 애플리케이션 정보를 안전하게 저장할 수 있는 기능이 포함됩니다. 이 키트는 개인 정보를 공유하지 않고 iCloud ID로 애플리케이션에 액세스할 수 있도록 하여 사용자에게 익명의 계층을 제공합니다.
개발자는 클라이언트 쪽 애플리케이션에 집중하고 iCloud에서 서버 쪽 애플리케이션 논리를 작성할 필요가 없도록 할 수 있습니다. CloudKit은 인증, 프라이빗 및 퍼블릭 데이터베이스, 구조적 데이터 및 자산 스토리지 서비스를 제공합니다.
Important
Apple에서는 개발자가 유럽 연합의 GDPR(일반 데이터 보호 규정)을 제대로 처리하는 데 도움이 되는 도구를 제공합니다.
요구 사항
이 문서에 제시된 단계를 완료하려면 다음이 필요합니다.
- Xcode 및 iOS SDK – Apple의 Xcode 및 iOS 8 API를 설치하고 개발자 컴퓨터에 구성해야 합니다.
- Mac용 Visual Studio – 최신 버전의 Mac용 Visual Studio 사용자 디바이스에 설치하고 구성해야 합니다.
- iOS 8 디바이스 – 테스트를 위해 최신 버전의 iOS 8을 실행하는 iOS 디바이스입니다.
CloudKit란?
CloudKit는 개발자에게 iCloud 서버에 대한 액세스 권한을 부여하는 방법입니다. iCloud 드라이브 및 iCloud 사진 라이브러리의 기반을 제공합니다. CloudKit는 macOS 및 iOS 디바이스 모두에서 지원됩니다.
CloudKit는 iCloud 계정 인프라를 사용합니다. 디바이스에 iCloud 계정에 로그인한 사용자가 있는 경우 CloudKit는 해당 ID를 사용하여 사용자를 식별합니다. 사용할 수 있는 계정이 없으면 제한된 읽기 전용 액세스가 제공됩니다.
CloudKit는 공용 데이터베이스와 프라이빗 데이터베이스의 개념을 모두 지원합니다. 공용 데이터베이스는 사용자가 액세스할 수 있는 모든 데이터의 "수프"를 제공합니다. 프라이빗 데이터베이스는 특정 사용자에 바인딩된 프라이빗 데이터를 저장하기 위한 것입니다.
CloudKit는 구조화된 데이터와 대량 데이터를 모두 지원합니다. 대용량 파일 전송을 원활하게 처리할 수 있습니다. CloudKit는 백그라운드에서 iCloud 서버와 대용량 파일을 효율적으로 전송하여 개발자가 다른 작업에 집중할 수 있도록 합니다.
참고 항목
CloudKit은 전송 기술이라는 점에 유의해야 합니다. 지속성은 제공하지 않습니다. 애플리케이션이 서버에서 정보를 효율적으로 보내고 받을 수 있도록 합니다.
이 글을 쓰는 시점에서 Apple은 처음에 대역폭 및 스토리지 용량 모두에 대한 높은 제한으로 CloudKit을 무료로 제공하고 있습니다. 대규모 프로젝트 또는 큰 사용자 기반을 가진 애플리케이션의 경우 Apple은 저렴한 가격 책정 규모가 제공될 것임을 암시했습니다.
Xamarin 애플리케이션에서 CloudKit 사용
Xamarin 애플리케이션이 CloudKit 프레임워크를 활용하려면 먼저 기능 작업 및 권한 사용 가이드에 자세히 설명된 대로 애플리케이션을 올바르게 프로비전해야 합니다.
CloudKit에 액세스하려면 Entitlements.plist 파일에 iCloud 사용, 키-값 스토리지 및 CloudKit 권한이 포함되어야 합니다.
샘플 앱
샘플 앱은 Xamarin과 함께 CloudKit을 사용하는 방법을 보여 줍니다. 아래 단계에서는 샘플을 구성하는 방법을 보여 줍니다. CloudKit에만 필요한 것 이상으로 추가 설정이 필요합니다.
- Mac용 Visual Studio 또는 Visual Studio에서 프로젝트를 엽니다.
- 솔루션 탐색기 Info.plist 파일을 열고 번들 식별자가 프로비전 설정의 일부로 만든 앱 ID에 정의된 것과 일치하는지 확인합니다.
- Info.plist 파일의 아래쪽으로 스크롤하여 사용 가능한 백그라운드 모드, 위치 업데이트 및 원격 알림을 선택합니다.
- 솔루션에서 iOS 프로젝트를 마우스 오른쪽 단추로 클릭하고 옵션을 선택합니다.
- iOS 번들 서명을 선택하고 위에서 만든 개발자 ID 및 프로비저닝 프로필을 선택합니다.
- Entitlements.plist에 iCloud 사용, 키-값 스토리지 및 CloudKit가 포함되어 있는지 확인합니다.
- 애플리케이션에 대한 유비쿼터스 컨테이너 가 있는지 확인합니다. 예:
iCloud.com.your-company.CloudKitAtlas
- 변경 내용을 파일에 저장합니다.
이러한 설정이 준비되면 샘플 앱은 이제 CloudKit Framework API뿐만 아니라 백그라운드, 위치 및 알림 서비스에 액세스할 준비가 되었습니다.
CloudKit API 개요
Xamarin iOS 애플리케이션에서 CloudKit을 구현하기 전에 이 문서에서는 다음 항목을 포함하는 CloudKit 프레임워크의 기본 사항을 다룹니다.
- 컨테이너 – iCloud 통신의 격리된 사일로입니다.
- 데이터베이스 – 공용 및 프라이빗은 애플리케이션에서 사용할 수 있습니다.
- 레코드 – 구조적 데이터가 CloudKit 간 이동되는 메커니즘입니다.
- 레코드 영역 – 레코드 그룹입니다.
- 레코드 식별자 – 완전히 정규화되고 레코드의 특정 위치를 나타냅니다.
- 참조 – 지정된 데이터베이스 내의 관련 레코드 간에 부모-자식 관계를 제공합니다.
- 자산 – 구조화되지 않은 큰 데이터의 파일을 iCloud에 업로드하고 지정된 레코드와 연결할 수 있도록 허용합니다.
컨테이너
iOS 디바이스에서 실행되는 지정된 애플리케이션은 항상 해당 디바이스의 다른 애플리케이션 및 서비스를 따라 실행됩니다. 클라이언트 디바이스에서 애플리케이션은 어떤 식으로든 사일로 또는 샌드박스가 됩니다. 경우에 따라 이는 리터럴 샌드박스이고, 다른 경우에는 애플리케이션이 자체 메모리 공간에서 실행되고 있는 경우도 있습니다.
클라이언트 애플리케이션을 가져와서 다른 클라이언트와 분리하여 실행하는 개념은 매우 강력하며 다음과 같은 이점을 제공합니다.
- 보안 – 한 애플리케이션이 다른 클라이언트 앱 또는 OS 자체를 방해할 수 없습니다.
- 안정성 – 클라이언트 애플리케이션이 충돌하는 경우 OS의 다른 앱을 제거할 수 없습니다.
- 개인 정보 – 각 클라이언트 애플리케이션은 디바이스 내에 저장된 개인 정보에 대한 액세스가 제한됩니다.
CloudKit는 위에 나열된 것과 동일한 이점을 제공하고 클라우드 기반 정보 작업에 적용하도록 설계되었습니다.
애플리케이션이 디바이스에서 실행되는 일대다와 마찬가지로 iCloud 일대다와 애플리케이션의 통신도 마찬가지입니다. 이러한 각 통신 사일로를 컨테이너라고 합니다.
컨테이너는 클래스를 통해 CloudKit Framework에 CKContainer
노출됩니다. 기본적으로 한 애플리케이션은 하나의 컨테이너에 대해 이야기하고 이 컨테이너는 해당 애플리케이션에 대한 데이터를 분리합니다. 즉, 여러 애플리케이션이 동일한 iCloud 계정에 정보를 저장할 수 있지만 이 정보는 결코 섞여지지 않습니다.
iCloud 데이터의 컨테이너화를 사용하면 CloudKit에서 사용자 정보를 캡슐화할 수도 있습니다. 이러한 방식으로 애플리케이션은 사용자의 개인 정보 보호 및 보안을 유지하면서 iCloud 계정 및 저장된 사용자 정보에 대한 액세스가 제한됩니다.
컨테이너는 WWDR 포털을 통해 애플리케이션 개발자가 완전히 관리합니다. 컨테이너의 네임스페이스는 모든 Apple 개발자에게 전역적이므로 컨테이너는 지정된 개발자의 애플리케이션뿐만 아니라 모든 Apple 개발자 및 애플리케이션에 고유해야 합니다.
Apple은 애플리케이션 컨테이너에 대한 네임스페이스를 만들 때 역방향 DNS 표기법을 사용할 것을 제안합니다. 예: iCloud.com.company-name.application-name
컨테이너는 기본적으로 지정된 애플리케이션에 일대일로 바인딩되지만 애플리케이션 간에 공유할 수 있습니다. 따라서 여러 애플리케이션이 단일 컨테이너에서 조정할 수 있습니다. 단일 애플리케이션은 여러 컨테이너와 통신할 수도 있습니다.
데이터베이스
CloudKit의 주요 기능 중 하나는 애플리케이션의 데이터 모델을 사용하고 해당 모델을 iCloud 서버까지 복제본(replica). 일부 정보는 해당 정보를 만든 사용자를 위한 것이며, 다른 정보는 공용(예: 식당 리뷰)을 위해 사용자가 만들 수 있는 공개 데이터이거나 개발자가 애플리케이션에 대해 게시한 정보일 수 있습니다. 두 경우 모두 대상 그룹은 단일 사용자가 아니라 사용자 커뮤니티입니다.
컨테이너 내부는 무엇보다도 공용 데이터베이스입니다. 이것은 모든 공공 정보가 살고 공동 밍글하는 곳입니다. 또한 애플리케이션의 각 사용자에 대한 여러 개별 프라이빗 데이터베이스가 있습니다.
iOS 디바이스에서 실행하는 경우 애플리케이션은 현재 로그온한 iCloud 사용자의 정보에만 액세스할 수 있습니다. 따라서 애플리케이션의 컨테이너 보기는 다음과 같습니다.
현재 로그온한 iCloud 사용자와 연결된 공용 데이터베이스 및 프라이빗 데이터베이스만 볼 수 있습니다.
데이터베이스는 클래스를 통해 CloudKit Framework에 CKDatabase
노출됩니다. 모든 애플리케이션은 공용 데이터베이스와 프라이빗 데이터베이스의 두 데이터베이스에 액세스할 수 있습니다.
컨테이너는 CloudKit의 초기 진입점입니다. 다음 코드를 사용하여 애플리케이션의 기본 컨테이너에서 퍼블릭 및 프라이빗 데이터베이스에 액세스할 수 있습니다.
using CloudKit;
//...
public CKDatabase PublicDatabase { get; set; }
public CKDatabase PrivateDatabase { get; set; }
//...
// Get the default public and private databases for
// the application
PublicDatabase = CKContainer.DefaultContainer.PublicCloudDatabase;
PrivateDatabase = CKContainer.DefaultContainer.PrivateCloudDatabase;
다음은 데이터베이스 형식 간의 차이점입니다.
공용 데이터베이스 | 프라이빗 데이터베이스 | |
---|---|---|
데이터 형식 | 공유 데이터 | 현재 사용자의 데이터 |
할당량 | 개발자 할당량에 대한 계정 | 사용자 할당량에서 고려됨 |
기본 사용 권한 | 세계 읽기 가능 | 사용자가 읽을 수 있습니다. |
편집 권한 | 레코드 클래스 수준을 통한 iCloud 대시보드 역할 | 해당 없음 |
레코드
컨테이너는 데이터베이스를 보유하며 데이터베이스 내부는 레코드입니다. 레코드는 구조적 데이터가 CloudKit 간 이동되는 메커니즘입니다.
레코드는 키-값 쌍을 래핑하는 클래스를 CKRecord
통해 CloudKit Framework에 노출됩니다. 애플리케이션의 개체 인스턴스는 CloudKit의 인스턴스와 동일합니다 CKRecord
. 또한 각각 CKRecord
에는 개체의 클래스와 동일한 레코드 형식이 있습니다.
레코드에는 Just-In-Time 스키마가 있으므로 데이터는 처리를 위해 전달되기 전에 CloudKit에 설명됩니다. 이 시점부터 CloudKit은 정보를 해석하고 레코드 저장 및 검색의 로지스를 처리합니다.
클래스는 CKRecord
광범위한 메타데이터도 지원합니다. 예를 들어 레코드에는 레코드가 만들어진 시기와 레코드를 만든 사용자에 대한 정보가 포함됩니다. 레코드에는 마지막으로 수정된 시기와 수정한 사용자에 대한 정보도 포함됩니다.
레코드에는 변경 태그의 개념이 포함되어 있습니다. 지정된 레코드의 이전 버전입니다. 변경 태그는 클라이언트와 서버에 지정된 레코드의 동일한 버전이 있는지 여부를 확인하는 가벼운 방법으로 사용됩니다.
위에서 CKRecords
설명한 대로 키-값 쌍을 래핑하므로 다음과 같은 유형의 데이터를 레코드에 저장할 수 있습니다.
NSString
NSNumber
NSData
NSDate
CLLocation
CKReferences
CKAssets
단일 값 형식 외에도 레코드는 위에 나열된 형식 중 하나의 동일한 배열을 포함할 수 있습니다.
다음 코드를 사용하여 새 레코드를 만들고 데이터베이스에 저장할 수 있습니다.
using CloudKit;
//...
private const string ReferenceItemRecordName = "ReferenceItems";
//...
var newRecord = new CKRecord (ReferenceItemRecordName);
newRecord ["name"] = (NSString)nameTextField.Text;
await CloudManager.SaveAsync (newRecord);
레코드 영역
레코드는 지정된 데이터베이스 내에 단독으로 존재하지 않습니다. 레코드 그룹은 레코드 영역 내에 함께 존재합니다. 레코드 영역은 기존 관계형 데이터베이스의 테이블로 간주할 수 있습니다.
지정된 레코드 영역 내에는 여러 레코드가 있고 지정된 데이터베이스 내에는 여러 레코드 영역이 있을 수 있습니다. 모든 데이터베이스에는 기본 레코드 영역이 포함됩니다.
레코드가 기본적으로 저장되는 위치입니다. 또한 사용자 지정 레코드 영역을 만들 수 있습니다. 레코드 영역은 원자성 커밋 및 변경 내용 추적 수행되는 기본 세분성을 나타냅니다.
레코드 식별자
레코드 식별자는 클라이언트에서 제공한 레코드 이름과 레코드가 있는 영역을 모두 포함하는 튜플로 표시됩니다. 레코드 식별자에는 다음과 같은 특징이 있습니다.
- 클라이언트 애플리케이션에서 만들어집니다.
- 완전히 정규화되고 레코드의 특정 위치를 나타냅니다.
- 외부 데이터베이스에 있는 레코드의 고유 ID를 레코드 이름에 할당하여 CloudKit 내에 저장되지 않은 로컬 데이터베이스를 브리지하는 데 사용할 수 있습니다.
개발자는 새 레코드를 만들 때 레코드 식별자를 전달하도록 선택할 수 있습니다. 레코드 식별자를 지정하지 않으면 UUID가 자동으로 만들어지고 레코드에 할당됩니다.
개발자는 새 레코드 식별자를 만들 때 각 레코드가 속할 레코드 영역을 지정하도록 선택할 수 있습니다. 지정하지 않으면 기본 레코드 영역이 사용됩니다.
레코드 식별자는 클래스를 통해 CloudKit Framework에 CKRecordID
노출됩니다. 다음 코드를 사용하여 새 레코드 식별자를 만들 수 있습니다.
var recordID = new CKRecordID("My Record");
참조
참조는 지정된 데이터베이스 내의 관련 레코드 간 관계를 제공합니다.
위의 예제에서 부모는 자식이 부모 레코드의 자식 레코드가 되도록 자식을 소유합니다. 관계는 자식 레코드에서 부모 레코드로 이동하고 뒤로 참조라고 합니다.
참조는 클래스를 통해 CloudKit Framework에 CKReference
노출됩니다. iCloud 서버에서 레코드 간의 관계를 이해할 수 있도록 하는 방법입니다.
참조는 Cascading Deletes 뒤에 메커니즘을 제공합니다. 부모 레코드가 데이터베이스에서 삭제되면 모든 자식 레코드(관계에 지정된 대로)도 데이터베이스에서 자동으로 삭제됩니다.
참고 항목
CloudKit를 사용할 때는 현수 포인터가 발생할 수 있습니다. 예를 들어 애플리케이션이 레코드 포인터 목록을 가져오고 레코드를 선택한 다음 레코드를 요청할 때 레코드가 데이터베이스에 더 이상 존재하지 않을 수 있습니다. 이 상황을 정상적으로 처리하려면 애플리케이션을 코딩해야 합니다.
필수는 아니지만 CloudKit Framework로 작업할 때 백 참조를 사용하는 것이 좋습니다. Apple은 이 시스템을 가장 효율적인 참조 유형으로 만들기 위해 시스템을 미세 조정했습니다.
참조를 만들 때 개발자는 이미 메모리에 있는 레코드를 제공하거나 레코드 식별자에 대한 참조를 만들 수 있습니다. 레코드 식별자를 사용하고 지정된 참조가 데이터베이스에 없는 경우 현수 포인터가 만들어집니다.
다음은 알려진 레코드에 대한 참조를 만드는 예제입니다.
var reference = new CKReference(newRecord, new CKReferenceAction());
자산
자산을 사용하면 구조화되지 않은 큰 데이터의 파일을 iCloud에 업로드하고 지정된 레코드와 연결할 수 있습니다.
클라이언트 CKRecord
에서 iCloud 서버에 업로드될 파일을 설명하는 A가 만들어집니다. A CKAsset
는 파일을 포함하도록 만들어지고 이를 설명하는 레코드에 연결됩니다.
파일이 서버에 업로드되면 레코드가 데이터베이스에 배치되고 파일이 특수 Bulk Storage 데이터베이스에 복사됩니다. 레코드 포인터와 업로드된 파일 사이에 링크가 만들어집니다.
자산은 클래스를 통해 CloudKit Framework에 CKAsset
노출되며 구조화되지 않은 대규모 데이터를 저장하는 데 사용됩니다. 개발자는 메모리에 구조화되지 않은 큰 데이터를 갖고 싶지 않기 때문에 자산은 디스크의 파일을 사용하여 구현됩니다.
자산은 레코드가 소유하므로 iCloud에서 레코드를 포인터로 사용하여 자산을 검색할 수 있습니다. 이렇게 하면 자산을 소유한 레코드가 삭제될 때 서버에서 자산을 가비지 수집할 수 있습니다.
Apple은 대규모 데이터 파일을 처리하기 위한 것이므로 CKAssets
자산을 효율적으로 업로드하고 다운로드할 수 있도록 CloudKit을 설계했습니다.
다음 코드를 사용하여 자산을 만들고 레코드와 연결할 수 있습니다.
var fileUrl = new NSUrl("LargeFile.mov");
var asset = new CKAsset(fileUrl);
newRecord ["name"] = asset;
이제 CloudKit 내의 모든 기본 개체를 다루었습니다. 컨테이너는 애플리케이션에 연결되고 데이터베이스를 포함합니다. 데이터베이스에는 레코드 영역으로 그룹화되고 레코드 식별자가 가리키는 레코드가 포함됩니다. 부모-자식 관계는 참조를 사용하여 레코드 간에 정의됩니다. 마지막으로 자산을 사용하여 큰 파일을 업로드하고 레코드에 연결할 수 있습니다.
CloudKit 편의 API
Apple은 CloudKit 작업을 위한 두 가지 API 집합을 제공합니다.
- 운영 API – CloudKit의 모든 단일 기능을 제공합니다. 더 복잡한 애플리케이션의 경우 이 API는 CloudKit에 대한 세분화된 제어를 제공합니다.
- 편의 API – CloudKit 기능의 일반적인 미리 구성된 하위 집합을 제공합니다. iOS 애플리케이션에 CloudKit 기능을 포함하기 위한 편리하고 쉬운 액세스 솔루션을 제공합니다.
편의 API는 일반적으로 대부분의 iOS 애플리케이션에 가장 적합한 선택이며 Apple은 이를 시작하는 것이 좋습니다. 이 섹션의 나머지 부분에서는 다음과 같은 편의 API 항목을 다룹니다.
- 레코드 저장
- 레코드 가져오기
- 레코드를 업데이트합니다.
일반적인 설정 코드
CloudKit 편의 API를 시작하기 전에 몇 가지 표준 설정 코드가 필요합니다. 먼저 애플리케이션의 AppDelegate.cs
파일을 수정하고 다음과 같이 표시합니다.
using System;
using System.Collections.Generic;
using System.Linq;
using Foundation;
using UIKit;
using CloudKit;
namespace CloudKitAtlas
{
[Register ("AppDelegate")]
public partial class AppDelegate : UIApplicationDelegate
{
public override UIWindow Window { get; set;}
public CKDatabase PublicDatabase { get; set; }
public CKDatabase PrivateDatabase { get; set; }
public override bool FinishedLaunching (UIApplication application, NSDictionary launchOptions)
{
application.RegisterForRemoteNotifications ();
// Get the default public and private databases for
// the application
PublicDatabase = CKContainer.DefaultContainer.PublicCloudDatabase;
PrivateDatabase = CKContainer.DefaultContainer.PrivateCloudDatabase;
return true;
}
public override void RegisteredForRemoteNotifications (UIApplication application, NSData deviceToken)
{
Console.WriteLine ("Registered for Push notifications with token: {0}", deviceToken);
}
public override void FailedToRegisterForRemoteNotifications (UIApplication application, NSError error)
{
Console.WriteLine ("Push subscription failed");
}
public override void ReceivedRemoteNotification (UIApplication application, NSDictionary userInfo)
{
Console.WriteLine ("Push received");
}
}
}
위의 코드는 퍼블릭 및 프라이빗 CloudKit 데이터베이스를 바로 가기로 노출하여 나머지 애플리케이션에서 더 쉽게 작업할 수 있도록 합니다.
다음으로 CloudKit을 사용할 뷰 또는 뷰 컨테이너에 다음 코드를 추가합니다.
using CloudKit;
//...
public AppDelegate ThisApp {
get { return (AppDelegate)UIApplication.SharedApplication.Delegate; }
}
이렇게 하면 위에서 만든 공용 및 프라이빗 데이터베이스 바로 가기에 AppDelegate
액세스하고 액세스하는 바로 가기가 추가됩니다.
이 코드를 사용하여 Xamarin iOS 8 애플리케이션에서 CloudKit 편의 API를 구현하는 것을 살펴보겠습니다.
레코드 저장
레코드에 대해 논의할 때 위에 제시된 패턴을 사용하여 다음 코드는 새 레코드를 만들고 편의 API를 사용하여 공용 데이터베이스에 저장합니다.
private const string ReferenceItemRecordName = "ReferenceItems";
...
// Create a new record
var newRecord = new CKRecord (ReferenceItemRecordName);
newRecord ["name"] = (NSString)nameTextField.Text;
// Save it to the database
ThisApp.PublicDatabase.SaveRecord(newRecord, (record, err) => {
// Was there an error?
if (err != null) {
...
}
});
위의 코드에 대해 유의해야 할 세 가지 사항은 다음과 같습니다.
- 개발자는 메서드를
SaveRecord
PublicDatabase
호출하여 데이터를 보내는 방법, 데이터를 쓰는 영역 등을 지정할 필요가 없습니다. 편의 API는 이러한 모든 세부 정보 자체를 처리합니다. - 호출은 비동기적이며 호출이 완료되면 성공 또는 실패로 콜백 루틴을 제공합니다. 호출이 실패하면 오류 메시지가 제공됩니다.
- CloudKit는 로컬 스토리지/지속성을 제공하지 않습니다. 전송 매체입니다. 따라서 레코드를 저장하라는 요청이 있으면 즉시 iCloud 서버로 전송됩니다.
참고 항목
연결이 지속적으로 삭제되거나 중단되는 모바일 네트워크 통신의 "손실" 특성 때문에 CloudKit을 사용할 때 개발자가 고려해야 할 첫 번째 고려 사항 중 하나는 오류 처리입니다.
레코드 가져오기
레코드가 만들어지고 iCloud 서버에 성공적으로 저장되면 다음 코드를 사용하여 레코드를 검색합니다.
// Create a record ID and fetch the record from the database
var recordID = new CKRecordID("MyRecordName");
ThisApp.PublicDatabase.FetchRecord(recordID, (record, err) => {
// Was there an error?
if (err != null) {
...
}
});
레코드를 저장하는 것과 마찬가지로 위의 코드는 비동기적이고 간단하며 큰 오류 처리가 필요합니다.
레코드 업데이트
iCloud 서버에서 레코드를 가져온 후 다음 코드를 사용하여 레코드를 수정하고 변경 내용을 데이터베이스에 다시 저장할 수 있습니다.
// Create a record ID and fetch the record from the database
var recordID = new CKRecordID("MyRecordName");
ThisApp.PublicDatabase.FetchRecord(recordID, (record, err) => {
// Was there an error?
if (err != null) {
} else {
// Modify the record
record["name"] = (NSString)"New Name";
// Save changes to database
ThisApp.PublicDatabase.SaveRecord(record, (r, e) => {
// Was there an error?
if (e != null) {
...
}
});
}
});
FetchRecord
호출에 PublicDatabase
성공한 경우 반환되는 CKRecord
메서드입니다. 그런 다음 애플리케이션은 레코드를 수정하고 다시 호출 SaveRecord
하여 변경 내용을 데이터베이스에 다시 씁니다.
이 섹션에서는 CloudKit 편의 API를 사용할 때 애플리케이션에서 사용하는 일반적인 주기를 보여 했습니다. 애플리케이션은 iCloud에 레코드를 저장하고, iCloud에서 해당 레코드를 검색하고, 레코드를 수정하고, 해당 변경 내용을 iCloud에 다시 저장합니다.
확장성을 위한 디자인
지금까지 이 문서에서는 작업할 때마다 iCloud 서버에서 애플리케이션의 전체 개체 모델을 저장하고 검색하는 방법을 살펴보았습니다. 이 방법은 적은 양의 데이터와 매우 작은 사용자 기반에서 잘 작동하지만 정보 및/또는 사용자 기반의 양이 늘어나면 크기가 잘 조정되지 않습니다.
빅 데이터, 작은 디바이스
애플리케이션의 인기가 높아질수록 데이터베이스의 데이터가 늘어나고 디바이스에 해당 전체 데이터의 캐시가 있는 것이 덜 실현 가능합니다. 다음 기술을 사용하여 이 문제를 해결할 수 있습니다.
- 클라우드에서 큰 데이터 유지 – CloudKit는 큰 데이터를 효율적으로 처리하도록 설계되었습니다.
- 클라이언트는 해당 데이터의 조각만 볼 수 있어야 합니다. 지정된 시간에 작업을 처리하는 데 필요한 최소한의 데이터만 가져와야 합니다.
- 클라이언트 보기는 변경 될 수 있습니다. 각 사용자마다 기본 설정이 다르기 때문에 표시되는 데이터 조각이 사용자에서 사용자로 변경될 수 있으며 지정된 조각에 대한 사용자의 개별 보기는 다를 수 있습니다.
- 클라이언트는 쿼리를 사용하여 뷰포인트 에 초점을 맞춥니다. 쿼리를 사용하면 사용자가 클라우드 내에 있는 더 큰 데이터 세트의 작은 하위 집합을 볼 수 있습니다.
쿼리
위에서 설명한 대로 쿼리를 통해 개발자는 클라우드에 존재하는 더 큰 데이터 세트의 작은 하위 집합을 선택할 수 있습니다. 쿼리는 클래스를 통해 CloudKit Framework에 CKQuery
노출됩니다.
쿼리는 레코드 형식(), 조건자(RecordType
) 및 선택적으로 정렬 설명자(NSPredicate
NSSortDescriptors
)의 세 가지 항목을 결합합니다. CloudKit는 대부분의 .를 NSPredicate
지원합니다.
지원되는 조건자
CloudKit는 쿼리로 작업할 때 다음 유형을 NSPredicates
지원합니다.
이름이 변수에 저장된 값과 같은 레코드 일치:
NSPredicate.FromFormat(string.Format("name = '{0}'", recordName))
컴파일 시간에 키를 알 필요가 없도록 동적 키 값을 기반으로 일치를 허용합니다.
NSPredicate.FromFormat(string.Format("{0} = '{1}'", key, value))
레코드 값이 지정된 값보다 큰 레코드와 일치합니다.
NSPredicate.FromFormat(string.Format("start > {0}", (NSDate)date))
레코드의 위치가 지정된 위치에서 100미터 이내인 레코드 일치:
var location = new CLLocation(37.783,-122.404); var predicate = NSPredicate.FromFormat(string.Format("distanceToLocation:fromLocation(Location,{0}) < 100", location));
CloudKit는 토큰화된 검색을 지원합니다. 이 호출은 두 개의 토큰을 만듭니다. 하나는 for
after
및 다른 토큰에 대한 토큰입니다session
. 다음 두 토큰이 포함된 레코드를 반환합니다.NSPredicate.FromFormat(string.Format("ALL tokenize({0}, 'Cdl') IN allTokens", "after session"))
CloudKit는 연산자를 사용하여 조인된 복합 조건자를
AND
지원합니다.NSPredicate.FromFormat(string.Format("start > {0} AND name = '{1}'", (NSDate)date, recordName))
쿼리 만들기
다음 코드를 사용하여 Xamarin iOS 8 애플리케이션에서 만들 CKQuery
수 있습니다.
var recordName = "MyRec";
var predicate = NSPredicate.FromFormat(string.Format("name = '{0}'", recordName));
var query = new CKQuery("CloudRecords", predicate);
먼저 조건자를 만들어 지정된 이름과 일치하는 레코드만 선택합니다. 그런 다음 조건자와 일치하는 지정된 레코드 형식의 레코드를 선택하는 쿼리를 만듭니다.
쿼리 수행
쿼리가 만들어지면 다음 코드를 사용하여 쿼리를 수행하고 반환된 레코드를 처리합니다.
var recordName = "MyRec";
var predicate = NSPredicate.FromFormat(string.Format("name = {0}", recordName));
var query = new CKQuery("CloudRecords", predicate);
ThisApp.PublicDatabase.PerformQuery(query, CKRecordZone.DefaultRecordZone().ZoneId, (NSArray results, NSError err) => {
// Was there an error?
if (err != null) {
...
} else {
// Process the returned records
for(nint i = 0; i < results.Count; ++i) {
var record = (CKRecord)results[i];
}
}
});
위의 코드는 위에서 만든 쿼리를 가져와 공용 데이터베이스에 대해 실행합니다. 레코드 영역이 지정되지 않으므로 모든 영역이 검색됩니다. 오류가 발생하지 않으면 쿼리의 CKRecords
매개 변수와 일치하는 배열이 반환됩니다.
쿼리를 생각하는 방법은 설문 조사이며 큰 데이터 세트를 잘 조각화한다는 것입니다. 그러나 쿼리는 다음과 같은 이유로 인해 대용량 정적 데이터 세트에 적합하지 않습니다.
- 그들은 장치 배터리 수명에 대 한 나쁜.
- 네트워크 트래픽에 좋지 않습니다.
- 표시되는 정보는 애플리케이션이 데이터베이스를 폴링하는 빈도에 따라 제한되므로 사용자 환경에 좋지 않습니다. 현재 사용자는 변경되는 경우 푸시 알림을 기대합니다.
Abunələr
대용량 정적 데이터 세트를 처리할 때는 클라이언트 디바이스에서 쿼리를 수행해서는 안 되며 클라이언트를 대신하여 서버에서 실행되어야 합니다. 쿼리는 백그라운드에서 실행되어야 하며 현재 디바이스 또는 동일한 데이터베이스를 터치하는 다른 디바이스에 의해 저장될 때마다 실행되어야 합니다.
마지막으로 서버 쪽 쿼리를 실행할 때 데이터베이스에 연결된 모든 디바이스에 푸시 알림을 보내야 합니다.
구독은 클래스를 통해 CloudKit Framework에 CKSubscription
노출됩니다. 레코드 유형(), 조건자(RecordType
NSPredicate
) 및 Apple 푸시 알림(Push
)을 결합합니다.
참고 항목
CloudKit 푸시는 푸시의 원인과 같은 CloudKit 특정 정보를 포함하는 페이로드를 포함하므로 약간 보강됩니다.
구독 작동 방식
C# 코드에서 구독을 구현하기 전에 구독 작동 방식에 대한 간략한 개요를 살펴보겠습니다.
위의 그래프는 다음과 같이 일반적인 구독 프로세스를 보여 줍니다.
- 클라이언트 디바이스는 구독을 트리거하는 조건 집합과 트리거가 발생할 때 전송되는 푸시 알림을 포함하는 새 구독을 만듭니다.
- 구독은 기존 구독 컬렉션에 추가되는 데이터베이스로 전송됩니다.
- 두 번째 디바이스는 새 레코드를 만들고 해당 레코드를 데이터베이스에 저장합니다.
- 데이터베이스는 구독 목록을 검색하여 새 레코드가 해당 조건과 일치하는지 확인합니다.
- 일치 항목이 발견되면 푸시 알림이 트리거된 레코드에 대한 정보를 사용하여 구독을 등록한 디바이스로 전송됩니다.
이 정보를 사용하여 Xamarin iOS 8 애플리케이션에서 구독을 만드는 방법에 대해 살펴보겠습니다.
구독 만들기
다음 코드를 사용하여 구독을 만들 수 있습니다.
// Create a new subscription
DateTime date;
var predicate = NSPredicate.FromFormat(string.Format("start > {0}", (NSDate)date));
var subscription = new CKSubscription("RecordType", predicate, CKSubscriptionOptions.FiresOnRecordCreation);
// Describe the type of notification
var notificationInfo = new CKNotificationInfo();
notificationInfo.AlertLocalizationKey = "LOCAL_NOTIFICATION_KEY";
notificationInfo.SoundName = "ping.aiff";
notificationInfo.ShouldBadge = true;
// Attach the notification info to the subscription
subscription.NotificationInfo = notificationInfo;
먼저 구독을 트리거하는 조건을 제공하는 조건자를 만듭니다. 다음으로, 특정 레코드 형식에 대한 구독을 만들고 트리거가 테스트될 때의 옵션을 설정합니다. 마지막으로 구독이 트리거될 때 발생하는 알림 유형을 정의하고 구독에 연결합니다.
구독 저장
구독을 만들면 다음 코드가 데이터베이스에 저장됩니다.
// Save the subscription to the database
ThisApp.PublicDatabase.SaveSubscription(subscription, (s, err) => {
// Was there an error?
if (err != null) {
}
});
편의 API를 사용하여 호출은 비동기적이고 간단하며 쉬운 오류 처리를 제공합니다.
푸시 알림 처리
개발자가 이전에 APS(Apple Push Notifications)를 사용한 경우 CloudKit에서 생성된 알림을 처리하는 프로세스는 익숙해야 합니다.
AppDelegate.cs
에서 클래스를 다음과 같이 재정의 ReceivedRemoteNotification
합니다.
public override void ReceivedRemoteNotification (UIApplication application, NSDictionary userInfo)
{
// Parse the notification into a CloudKit Notification
var notification = CKNotification.FromRemoteNotificationDictionary (userInfo);
// Get the body of the message
var alertBody = notification.AlertBody;
// Was this a query?
if (notification.NotificationType == CKNotificationType.Query) {
// Yes, convert to a query notification and get the record ID
var query = notification as CKQueryNotification;
var recordID = query.RecordId;
}
}
위의 코드는 CloudKit에 userInfo를 CloudKit 알림으로 구문 분석하도록 요청합니다. 다음으로 경고에 대한 정보가 추출됩니다. 마지막으로 알림 유형이 테스트되고 그에 따라 알림이 처리됩니다.
이 섹션에서는 쿼리 및 구독을 사용하여 위에서 제시한 빅 데이터, 작은 디바이스 문제에 응답하는 방법을 보여 줍니다. 애플리케이션은 큰 데이터를 클라우드에 두고 이러한 기술을 사용하여 이 데이터 세트에 대한 뷰를 제공합니다.
CloudKit 사용자 계정
이 문서의 시작 부분에 설명된 대로 CloudKit은 기존 iCloud 인프라를 기반으로 빌드됩니다. 다음 섹션에서는 CloudKit API를 사용하여 계정이 개발자에게 노출되는 방법을 자세히 설명합니다.
인증
사용자 계정을 처리할 때 첫 번째 고려 사항은 인증입니다. CloudKit는 디바이스에서 현재 로그인한 iCloud 사용자를 통한 인증을 지원합니다. 인증은 백그라운드에서 수행되며 iOS에서 처리됩니다. 이러한 방식으로 개발자는 인증 구현의 세부 정보에 대해 걱정할 필요가 없습니다. 사용자가 로그온되었는지 확인하기 위해 테스트합니다.
사용자 계정 정보
CloudKit는 개발자에게 다음 사용자 정보를 제공합니다.
- ID – 사용자를 고유하게 식별하는 방법입니다.
- 메타데이터 – 사용자에 대한 정보를 저장하고 검색하는 기능입니다.
- 개인 정보 – 모든 정보는 개인 정보 보호에 민감한 관리자에서 처리됩니다. 사용자가 동의하지 않는 한 아무것도 노출되지 않습니다.
- 검색 – 사용자에게 동일한 애플리케이션을 사용하는 친구를 검색할 수 있는 기능을 제공합니다.
다음으로, 이러한 항목을 자세히 살펴보겠습니다.
ID
위에서 설명한 대로 CloudKit는 애플리케이션이 지정된 사용자를 고유하게 식별하는 방법을 제공합니다.
사용자의 디바이스 및 CloudKit 컨테이너 내의 모든 특정 사용자 프라이빗 데이터베이스에서 실행되는 클라이언트 애플리케이션이 있습니다. 클라이언트 애플리케이션은 해당 특정 사용자 중 하나에 연결됩니다. 디바이스에서 로컬로 iCloud에 로그인한 사용자를 기반으로 합니다.
iCloud에서 제공되므로 사용자 정보의 풍부한 백업 저장소가 있습니다. 또한 iCloud는 실제로 컨테이너를 호스팅하기 때문에 사용자와 상관 관계를 지정할 수 있습니다. 위의 그래픽에서 iCloud 계정이 user@icloud.com
현재 클라이언트에 연결된 사용자입니다.
컨테이너별 컨테이너에 따라 임의로 생성된 고유한 사용자 ID가 만들어지고 사용자의 iCloud 계정(이메일 주소)과 연결됩니다. 이 사용자 ID는 애플리케이션에 반환되며 개발자가 적합한 방식으로 사용할 수 있습니다.
참고 항목
동일한 iCloud 사용자에 대해 동일한 디바이스에서 실행되는 다른 애플리케이션은 서로 다른 CloudKit 컨테이너에 연결되어 있기 때문에 다른 사용자 ID를 갖습니다.
다음 코드는 디바이스에서 현재 로그인한 iCloud 사용자의 CloudKit 사용자 ID를 가져옵니다.
public CKRecordID UserID { get; set; }
...
// Get the CloudKit User ID
CKContainer.DefaultContainer.FetchUserRecordId ((recordID, err) => {
// Was there an error?
if (err!=null) {
Console.WriteLine("Error: {0}", err.LocalizedDescription);
} else {
// Save user ID
UserID = recordID;
}
});
위의 코드는 CloudKit 컨테이너에 현재 로그인한 사용자의 ID를 제공하도록 요청하는 것입니다. 이 정보는 iCloud 서버에서 제공되므로 호출은 비동기적이며 오류 처리가 필요합니다.
메타데이터
CloudKit의 각 사용자에게는 이를 설명하는 특정 메타데이터가 있습니다. 이 메타데이터는 CloudKit 레코드로 표시됩니다.
프라이빗 데이터베이스 내에서 컨테이너의 특정 사용자를 살펴보면 해당 사용자를 정의하는 레코드가 하나 있습니다. 공용 데이터베이스 내에는 컨테이너의 각 사용자에 대해 하나씩 많은 사용자 레코드가 있습니다. 이 중 하나에는 현재 로그온한 사용자의 레코드 ID와 일치하는 레코드 ID가 있습니다.
공용 데이터베이스의 사용자 레코드는 전 세계에서 읽을 수 있습니다. 대부분의 경우 일반 레코드로 처리되며 형식 CKRecordTypeUserRecord
이 있습니다. 이러한 레코드는 시스템에서 예약되며 쿼리에 사용할 수 없습니다.
다음 코드를 사용하여 사용자 레코드에 액세스합니다.
public CKRecord UserRecord { get; set; }
...
// Get the user's record
PublicDatabase.FetchRecord(UserID, (record ,er) => {
//was there an error?
if (er != null) {
Console.WriteLine("Error: {0}", er.LocalizedDescription);
} else {
// Save the user record
UserRecord = record;
}
});
위의 코드는 위에서 액세스한 ID의 사용자에 대한 사용자 레코드를 반환하도록 공용 데이터베이스에 요청하는 것입니다. 이 정보는 iCloud 서버에서 제공되므로 호출은 비동기적이며 오류 처리가 필요합니다.
개인 정보 보호
CloudKit은 기본적으로 현재 로그온한 사용자의 개인 정보를 보호하기 위해 설계되었습니다. 사용자에 대한 개인 식별 정보는 기본적으로 노출되지 않습니다. 애플리케이션에 사용자에 대한 제한된 정보가 필요한 경우가 있습니다.
이러한 경우 애플리케이션은 사용자에게 이 정보를 공개할 것을 요청할 수 있습니다. 사용자에게 계정 정보 노출을 옵트인하도록 요청하는 대화 상자가 표시됩니다.
검색
사용자가 애플리케이션에서 사용자 계정 정보에 대한 액세스를 제한하도록 옵트인한다고 가정하면 애플리케이션의 다른 사용자에게 검색할 수 있습니다.
클라이언트 애플리케이션이 컨테이너와 통신하고 컨테이너가 사용자 정보에 액세스하기 위해 iCloud를 통신하고 있습니다. 사용자는 이메일 주소를 제공할 수 있으며 검색을 사용하여 사용자에 대한 정보를 다시 가져올 수 있습니다. 필요에 따라 사용자 ID를 사용하여 사용자에 대한 정보를 검색할 수도 있습니다.
또한 CloudKit은 전체 주소록을 쿼리하여 현재 로그온한 iCloud 사용자의 친구일 수 있는 모든 사용자에 대한 정보를 검색하는 방법을 제공합니다. CloudKit 프로세스는 사용자의 연락처 책을 가져와서 전자 메일 주소를 사용하여 해당 주소와 일치하는 애플리케이션의 다른 사용자를 찾을 수 있는지 확인합니다.
이렇게 하면 애플리케이션에서 액세스 권한을 제공하거나 사용자에게 연락처에 대한 액세스를 승인하도록 요청하지 않고도 사용자의 연락처 북을 활용할 수 있습니다. 애플리케이션에서 사용할 수 있는 연락처 정보는 CloudKit 프로세스에만 액세스할 수 있습니다.
요약하자면 사용자 검색에 사용할 수 있는 세 가지 종류의 입력이 있습니다.
- 사용자 레코드 ID – 현재 로그인한 CloudKit 사용자의 사용자 ID에 대해 검색을 수행할 수 있습니다.
- 사용자 전자 메일 주소 – 사용자가 전자 메일 주소를 제공할 수 있으며 검색에 사용할 수 있습니다.
- 연락처록 – 사용자의 주소록을 사용하여 연락처에 나열된 것과 동일한 전자 메일 주소를 가진 애플리케이션 사용자를 검색할 수 있습니다.
사용자 검색은 다음 정보를 반환합니다.
- 사용자 레코드 ID - 공용 데이터베이스에 있는 사용자의 고유 ID입니다.
- 이름 및 성 - 공용 데이터베이스에 저장된 이름입니다.
이 정보는 검색을 옵트인한 사용자에 대해서만 반환됩니다.
다음 코드는 디바이스에서 현재 iCloud에 로그인한 사용자에 대한 정보를 검색합니다.
public CKDiscoveredUserInfo UserInfo { get; set; }
//...
// Get the user's metadata
CKContainer.DefaultContainer.DiscoverUserInfo(UserID, (info, e) => {
// Was there an error?
if (e != null) {
Console.WriteLine("Error: {0}", e.LocalizedDescription);
} else {
// Save the user info
UserInfo = info;
}
});
다음 코드를 사용하여 연락처록의 모든 사용자를 쿼리합니다.
// Ask CloudKit for all of the user's friends information
CKContainer.DefaultContainer.DiscoverAllContactUserInfos((info, er) => {
// Was there an error
if (er != null) {
Console.WriteLine("Error: {0}", er.LocalizedDescription);
} else {
// Process all returned records
for(int i = 0; i < info.Count(); ++i) {
// Grab a user
var userInfo = info[i];
}
}
});
이 섹션에서는 CloudKit에서 애플리케이션에 제공할 수 있는 사용자 계정에 대한 액세스의 네 가지 주요 영역을 설명했습니다. 사용자의 ID 및 메타데이터 가져오기부터 CloudKit에 기본 제공되는 개인 정보 보호 정책, 마지막으로 애플리케이션의 다른 사용자를 검색하는 기능까지.
개발 및 프로덕션 환경
CloudKit은 애플리케이션의 레코드 형식 및 데이터에 대해 별도의 개발 및 프로덕션 환경을 제공합니다. 개발 환경은 개발 팀의 구성원만 사용할 수 있는 보다 유연한 환경입니다. 애플리케이션이 레코드에 새 필드를 추가하고 해당 레코드를 개발 환경에 저장하면 서버는 스키마 정보를 자동으로 업데이트합니다.
개발자는 이 기능을 사용하여 개발 중에 스키마를 변경하여 시간을 절약할 수 있습니다. 한 가지 주의할 점은 레코드에 필드를 추가한 후에는 해당 필드와 연결된 데이터 형식을 프로그래밍 방식으로 변경할 수 없다는 것입니다. 필드의 형식을 변경하려면 개발자가 CloudKit 대시보드에서 필드를 삭제하고 새 형식으로 다시 추가해야 합니다.
애플리케이션을 배포하기 전에 개발자는 CloudKit 대시보드를 사용하여 해당 스키마 및 데이터를 프로덕션 환경으로 마이그레이션할 수 있습니다. 프로덕션 환경에 대해 실행할 때 서버는 애플리케이션이 프로그래밍 방식으로 스키마를 변경하지 못하도록 차단합니다. 개발자는 CloudKit 대시보드를 사용하여 계속 변경할 수 있지만 프로덕션 환경의 레코드에 필드를 추가하려고 하면 오류가 발생합니다.
참고 항목
iOS 시뮬레이터는 개발 환경에서만 작동합니다. 개발자가 프로덕션 환경에서 애플리케이션을 테스트할 준비가 되면 물리적 iOS 디바이스가 필요합니다.
CloudKit 사용 앱 배송
CloudKit를 사용하는 애플리케이션을 배송하기 전에 프로덕션 CloudKit 환경을 대상으로 구성해야 합니다. 그렇지 않으면 Apple에서 애플리케이션을 거부합니다.
다음을 수행하십시오:
Ma용 Visual Studio에서 릴리스>iOS 디바이스용 애플리케이션을 컴파일합니다.
빌드 메뉴에서 보관을 선택합니다.
보관 파일은 Mac용 Visual Studio 만들어지고 표시됩니다.
Xcode를 시작합니다.
창 메뉴에서 이끌이를 선택합니다.
애플리케이션의 보관 파일을 선택하고 내보내기... 단추를 클릭합니다.
내보낼 메서드를 선택하고 다음 단추를 클릭합니다.
드롭다운 목록에서 개발 팀을 선택하고 선택 단추를 클릭합니다.
드롭다운 목록에서 프로덕션을 선택하고 다음 단추를 클릭합니다.
설정을 검토하고 내보내기 단추를 클릭합니다.
결과 애플리케이션
.ipa
파일을 생성할 위치를 선택합니다.
이 프로세스는 애플리케이션을 iTunes 커넥트 직접 제출하는 것과 비슷하며 내보내기 대신 제출... 단추를 클릭하기만 하면 됩니다. 구성 도우미 창에서 보관 파일을 선택한 후
CloudKit를 사용하는 경우
이 문서에서 볼 수 있듯이 CloudKit는 애플리케이션이 iCloud 서버에서 정보를 저장하고 검색하는 쉬운 방법을 제공합니다. 즉, CloudKit는 기존 도구 또는 프레임워크를 더 이상 사용하지 않거나 사용되지 않습니다.
사용 사례
다음 사용 사례는 개발자가 특정 iCloud 프레임워크 또는 기술을 사용할 시기를 결정하는 데 도움이 됩니다.
- iCloud 키-값 저장소 – 적은 양의 데이터를 최신 상태로 비동기적으로 유지하며 애플리케이션 기본 설정 작업에 적합합니다. 그러나 매우 적은 양의 정보로 제한됩니다.
- iCloud 드라이브 – 기존 iCloud 문서 API를 기반으로 하며 파일 시스템에서 구조화되지 않은 데이터를 동기화하는 간단한 API를 제공합니다. Mac OS X에서 전체 오프라인 캐시를 제공하며 문서 중심 애플리케이션에 적합합니다.
- iCloud Core 데이터 – 모든 사용자의 디바이스 간에 데이터를 복제본(replica) 수 있습니다. 데이터는 단일 사용자이며 개인 구조화된 데이터를 동기화 상태로 유지하는 데 적합합니다.
- CloudKit – 구조와 대량의 공용 데이터를 제공하며 큰 데이터 세트와 큰 비정형 파일을 모두 처리할 수 있습니다. 사용자의 iCloud 계정에 연결되고 클라이언트에서 전송하는 데이터 전송을 제공합니다.
이러한 사용 사례를 염두에 두고 개발자는 올바른 iCloud 기술을 선택하여 현재 필요한 애플리케이션 기능을 모두 제공하고 향후 성장을 위한 우수한 확장성을 제공해야 합니다.
요약
이 문서에서는 CloudKit API에 대한 빠른 소개를 설명했습니다. CloudKit를 사용하도록 Xamarin iOS 애플리케이션을 프로비전하고 구성하는 방법을 보여 줬습니다. CloudKit 편의 API의 기능을 다루었습니다. 쿼리 및 구독을 사용하여 확장성을 위해 CloudKit 지원 애플리케이션을 디자인하는 방법을 보여 줍니다. 마지막으로 CloudKit에서 애플리케이션에 노출되는 사용자 계정 정보를 표시했습니다.