Unified API 개요Unified API Overview

Xamarin의 Unified API를 사용 하면 Mac과 iOS 간에 코드를 공유 하 고, 32 및 64 비트 응용 프로그램을 동일한 이진으로 지원할 수 있습니다.Xamarin's Unified API makes it possible to share code between Mac and iOS and support 32 and 64-bit applications with the same binary. Unified API은 기본적으로 새 Xamarin.ios 및 Xamarin.ios 프로젝트에서 사용 됩니다.The Unified API is used by default in new Xamarin.iOS and Xamarin.Mac projects.

중요

Unified API 앞에 있는 Xamarin Classic API은 더 이상 사용 되지 않습니다.The Xamarin Classic API, which preceded the Unified API, has been deprecated.

  • Classic API (monotouch.dialog)를 지원 하기 위한 최신 버전의 Xamarin.ios는 Xamarin.ios 9.10입니다.The last version of Xamarin.iOS to support the Classic API (monotouch.dll) was Xamarin.iOS 9.10.
  • Xamarin.ios는 여전히 Classic API을 지원 하지만 더 이상 업데이트 되지 않습니다.Xamarin.Mac still supports the Classic API, but it is no longer updated. 개발자는 더 이상 사용 되지 않으므로 응용 프로그램을 Unified API로 이동 해야 합니다.Since it is deprecated, developers should move their applications to the Unified API.

Classic API 기반 앱 업데이트Updating Classic API-based Apps

플랫폼과 관련 된 지침을 따르세요.Follow the relevant instructions for your platform:

코드를 Unified API로 업데이트하는 팁Tips for Updating Code to the Unified API

마이그레이션하는 응용 프로그램에 관계 없이 Unified API로 업데이트 하는 데 도움이 되는 다음 팁 을 확인 하세요.Regardless of what applications you are migrating, check out these tips to help you successfully update to the Unified API.

라이브러리 분할Library Split

이 시점부터 Api는 다음과 같은 두 가지 방법으로 표시 됩니다.From this point on, our APIs will be surfaced in two ways:

  • Classic API: 32 비트 (만)로 제한 되 고 monotouch.dllXamMac.dll 어셈블리에 노출 됩니다.Classic API: Limited to 32-bits (only) and exposed in the monotouch.dll and XamMac.dll assemblies.
  • Unified API: Xamarin.iOS.dllXamarin.Mac.dll 어셈블리에서 사용할 수 있는 단일 API를 사용 하 여 32 및 64 비트 개발을 모두 지원 합니다.Unified API: Support both 32 and 64 bit development with a single API available in the Xamarin.iOS.dll and Xamarin.Mac.dll assemblies.

즉, 엔터프라이즈 개발자 (앱 스토어를 대상으로 하지 않음)의 경우 계속 해 서 계속 유지 관리 하거나 새 Api로 업그레이드할 수 있으므로 기존 클래식 Api를 계속 사용할 수 있습니다.This means that for Enterprise developers (not targetting the App Store), you can continue using the existing Classic APIs, as we will keep maintaining them forever, or you can upgrade to the new APIs.

네임 스페이스 변경Namespace Changes

Mac 및 iOS 제품 간에 코드를 공유 하는 충돌을 줄이기 위해 제품의 Api에 대 한 네임 스페이스를 변경 합니다.To reduce the friction to share code between our Mac and iOS products, we are changing the namespaces for the APIs in the products.

IOS 제품의 접두사 "Monotouch.dialog"와 데이터 형식에 대 한 Mac 제품의 "MonoMac"를 삭제 합니다.We are dropping the prefix "MonoTouch" from our iOS product and "MonoMac" from our Mac product on the data types.

이렇게 하면 조건부 컴파일을 수행 하지 않고 Mac 및 iOS 플랫폼 간에 코드를 보다 간단 하 게 공유할 수 있으며, 소스 코드 파일의 맨 위에 노이즈가 줄어듭니다.This makes it simpler to share code between the Mac and iOS platforms without resorting to conditional compilation and will reduce the noise at the top of your source code files.

  • Classic API: 네임 스페이스는 MonoTouch. 또는 MonoMac. 접두사를 사용 합니다.Classic API: Namespaces use MonoTouch. or MonoMac. prefix.
  • Unified API: 네임 스페이스 접두사가 없습니다.Unified API: No namespace prefix

런타임 기본값Runtime Defaults

기본적으로 Unified API는 개체 소유권 추적을 위해 SGen 가비지 수집기 및 새 참조 계산 시스템을 사용 합니다.The Unified API by default uses the SGen garbage collector and the New Reference Counting system for tracking object ownership. 이와 동일한 기능이 Xamarin.ios로 이식 되었습니다.This same feature has been ported to Xamarin.Mac.

이는 개발자가 이전 시스템에 직면 하 고 메모리 관리를 용이 하 게 하는 다양 한 문제를 해결 합니다.This solves a number of problems that developers faced with the old system and also ease memory management.

Classic API에 대해서도 새 Refcount를 사용 하도록 설정할 수 있지만 기본값은 보수적인 이며 사용자가 변경할 필요가 없습니다.Note that it is possible to enable New Refcount even for the Classic API, but the default is conservative and does not require users to make any changes. Unified API를 통해 기본값을 변경 하 고 개발자가 코드를 리팩터링 하 고 다시 테스트할 때 모든 기능을 동시에 제공할 수 있습니다.With the Unified API, we took the opportunity of changing the default and give developers all the improvements at the same time that they refactor and re-test their code.

API 변경API Changes

Unified API는 더 이상 사용 되지 않는 메서드를 제거 하 고, 클래식 Api에서 원래 Monotouch.dialog 및 MonoMac 네임 스페이스에 바인딩되는 경우 API 이름에 오타가 있는 몇 가지 인스턴스가 있습니다.The Unified API removes deprecated methods and there are a few instances where there were typos in the API names when they were bound to the original MonoTouch and MonoMac namespaces in the Classic APIs. 이러한 인스턴스는 새로운 통합 Api에서 수정 되었으며 구성 요소, iOS 및 Mac 응용 프로그램에서 업데이트 해야 합니다.These instances have been corrected in the new Unified APIs and will need to be updated in your component, iOS and Mac applications. 다음은 실행할 수 있는 가장 일반적인 항목 목록입니다.Here is a list of the most common ones you might run into:

Classic API 메서드 이름Classic API Method Name Unified API 메서드 이름Unified API Method Name
UINavigationController.PushViewControllerAnimated() UINavigationController.PushViewController()
UINavigationController.PopViewControllerAnimated() UINavigationController.PopViewController()
CGContext.SetRGBFillColor() CGContext.SetFillColor()
NetworkReachability.SetCallback() NetworkReachability.SetNotification()
CGContext.SetShadowWithColor CGContext.SetShadow
UIView.StringSize UIKit.UIStringDrawing.StringSize

클래식에서 Unified API로 전환할 때 전체 변경 내용 목록은 클래식 (monotouch.dialog) Vs 통합 (xamarin.ios) API 차이점 설명서를 참조 하세요.For a full list of changes when switching from the Classic to the Unified API, please see our Classic (monotouch.dll) vs Unified (Xamarin.iOS.dll) API differences documentation.

통합으로 업데이트Updating to Unified

클래식 의 여러 이전/중단/사용 되지 않는 Api는 통합 api에서 사용할 수 없습니다.Several old/broken/deprecated API in classic are not available in the Unified API. [Obsolete] 특성 메시지 (경고의 일부)를 제공 하 여 올바른 API를 안내 하므로 (수동 또는 자동) 업그레이드를 시작 하기 전에 CS0616 경고를 수정 하는 것이 더 쉬울 수 있습니다.It can be easier to fix the CS0616 warnings before starting your (manual or automated) upgrade since you'll have the [Obsolete] attribute message (part of the warning) to guide you to the right API.

프로젝트 업데이트 전이나 후에 사용할 수 있는 클래식 및 통합 API 변경 내용의 차이 를 게시 하 고 있습니다.Note that we are publishing a diff of the classic vs unified API changes that can be used either before or after your project updates. 클래식에서 obsoletes 호출을 수정 하는 것은 종종 시간 보호기 (문서 조회 감소)입니다.Still fixing the obsoletes calls in Classic will often be a time saver (less documentation lookups).

다음 지침에 따라 기존 iOS 앱또는 Mac 앱 을 Unified API로 업데이트 합니다.Follow these instructions to update existing iOS apps, or Mac apps to the Unified API. 코드 마이그레이션에 대 한 자세한 내용은이 페이지의 나머지 부분을 검토 하 고 이러한 팁 을 참조 하십시오.Review the remainder of this page, and these tips for additional information on migrating your code.

NuGetNuGet

이전에 Monotouch10 플랫폼 모니커를 사용 하 여 어셈블리를 게시 한 Classic API 통해 xamarin.ios를 지 원하는 NuGet 패키지입니다.NuGet packages that previously supported Xamarin.iOS via the Classic API published their assemblies using the Monotouch10 platform moniker.

Unified API에는 호환 되는 패키지 ( iOS10)에 대 한 새 플랫폼 식별자가 도입 되었습니다.The Unified API introduces a new platform identifier for compatible packages - Xamarin.iOS10. Unified API에 대해 빌드하여 기존 NuGet 패키지를 업데이트 하 여이 플랫폼에 대 한 지원을 추가 해야 합니다.Existing NuGet packages will need to be updated to add support for this platform, by building against the Unified API.

중요

"오류 3"에 ' monotouch.dialog ' 및 ' monotouch.dialog '가 모두 포함 될 수 없습니다. ' xamarin.ios '는 명시적으로 참조 되는 반면 ' '는 ' xxx, Version = 0.0.000, Culture =에 의해 참조 됩니다. 중립, PublicKeyToken = null ' " 응용 프로그램을 통합 된 api로 변환한 후에는 일반적으로 Unified API로 업데이트 되지 않은 구성 요소 또는 NuGet 패키지가 프로젝트에 포함 되어 있기 때문입니다.If you have an error in the form "Error 3 Cannot include both 'monotouch.dll' and 'Xamarin.iOS.dll' in the same Xamarin.iOS project - 'Xamarin.iOS.dll' is referenced explicitly, while 'monotouch.dll' is referenced by 'xxx, Version=0.0.000, Culture=neutral, PublicKeyToken=null'" after converting your application to the Unified APIs, it is typically due to having either a component or NuGet Package in the project that has not been updated to the Unified API. 기존 component/NuGet을 제거 하 고, 통합 Api를 지 원하는 버전으로 업데이트 하 고, 클린 빌드를 수행 해야 합니다.You'll need to remove the existing component/NuGet, update to a version that supports the Unified APIs and do a clean build.

64 비트로 이동The Road to 64 Bits

32 및 64 비트 응용 프로그램 지원에 대 한 배경 및 프레임 워크에 대 한 정보는 32 및 64 Bit 플랫폼 고려 사항을 참조 하세요.For background on supporting 32 and 64 bit applications and information about frameworks see the 32 and 64 bit Platform Considerations.

새 데이터 형식New Data Types

차이점의 핵심에서 Mac 및 iOS Api는 모두 32 비트 플랫폼의 경우 항상 32 비트이 고 64 비트 플랫폼에서는 64 비트가 있는 아키텍처 관련 데이터 형식을 사용 합니다.At the core of the difference, both Mac and iOS APIs use an architecture-specific data types that are always 32 bit on 32 bit platforms and 64 bit on 64 bit platforms.

예를 들어, 목표-C는 32 비트 시스템의 int32_tNSInteger 데이터 형식을 매핑하고 64 비트 시스템에서 int64_t 합니다.For example, Objective-C maps the NSInteger data type to int32_t on 32 bit systems and to int64_t on 64 bit systems.

이 동작을 일치 시키기 위해 Unified API의 이전 int 사용 (.NET은 항상 System.Int32로 정의 됨)을 새 데이터 형식 (System.nint)으로 바꿉니다.To match this behavior, on our Unified API, we are replacing the previous uses of int (which in .NET is defined as always being System.Int32) to a new data type: System.nint. "N"을 의미 "native"로 간주할 수 있으므로 플랫폼의 네이티브 정수 형식입니다.You can think of the "n" as meaning "native", so the native integer type of the platform.

nint, nuintnfloat를 소개 하 고, 필요한 경우 위에 구축 된 데이터 형식을 제공 합니다.We are introducing nint, nuint and nfloat as well providing data types built on top of them where necessary.

이러한 데이터 형식 변경에 대해 자세히 알아보려면 네이티브 형식 문서를 참조 하세요.To learn more about these data type changes, see the Native Types document.

IOS 앱의 아키텍처를 검색 하는 방법How to detect the architecture of iOS apps

응용 프로그램이 32 비트 또는 64 비트 iOS 시스템에서 실행 되 고 있는지 확인 해야 하는 경우가 있을 수 있습니다.There might be situations where your application needs to know if it is running on a 32 bit or a 64 bit iOS system. 아키텍처를 확인 하는 데 사용할 수 있는 코드는 다음과 같습니다.The following code can be used to check the architecture:

if (IntPtr.Size == 4) {
    Console.WriteLine ("32-bit App");
} else if (IntPtr.Size == 8) {
    Console.WriteLine ("64-bit App");
}

배열 및 System.objectArrays and System.Collections.Generic

인덱서에 C# 는int형식이 필요 하기 때문에 컬렉션 또는 배열의 요소에 액세스 하려면 nint값을int로 명시적으로 캐스팅 해야 합니다.Because C# indexers expect a type of int, you'll have to explicitly cast nint values to int to access the elements in a collection or array. 예를 들면,For example:

public List<string> Names = new List<string>();
...

public string GetName(nint index) {
    return Names[(int)index];
}

이는 예상 된 동작입니다. int에서 nint로의 캐스팅이 64 비트의 손실 이기 때문에 암시적 변환이 수행 되지 않습니다.This is expected behavior, because the cast from int to nint is lossy on 64 bit, an implicit conversion is not done.

DateTime을 NSDate로 변환Converting DateTime to NSDate

통합 Api를 사용 하는 경우 DateTimeNSDate 값으로 암시적으로 변환 하는 것이 더 이상 수행 되지 않습니다.When using the Unified APIs, the implicit conversion of DateTime to NSDate values is no longer performed. 이러한 값은 한 형식에서 다른 형식으로 명시적으로 변환 해야 합니다.These values will need to be explicitly converted from one type to another. 다음 확장 메서드를 사용 하 여이 프로세스를 자동화할 수 있습니다.The following extension methods can be used to automate this process:

public static DateTime NSDateToDateTime(this NSDate date)
{
    // NSDate has a wider range than DateTime, so clip
    // the converted date to DateTime.Min|MaxValue.
    double secs = date.SecondsSinceReferenceDate;
    if (secs < -63113904000)
        return DateTime.MinValue;
    if (secs > 252423993599)
        return DateTime.MaxValue;
    return (DateTime) date;
}

public static NSDate DateTimeToNSDate(this DateTime date)
{
    if (date.Kind == DateTimeKind.Unspecified)
        date = DateTime.SpecifyKind (date, /* DateTimeKind.Local or DateTimeKind.Utc, this depends on each app */)
    return (NSDate) date;
}

사용 되지 않는 Api 및 오타가 있습니다.Deprecated APIs and Typos

Xamarin.ios 클래식 API (monotouch.dialog) 내에서 [Obsolete] 특성은 다음 두 가지 방법으로 사용 되었습니다.Inside Xamarin.iOS classic API (monotouch.dll) the [Obsolete] attribute was used in two different ways:

  • 사용 되지 않는 IOS API: 이는 Apple 힌트가 API 사용을 중지 하는 것입니다 .이는 새 항목으로 대체 되기 때문입니다.Deprecated iOS API: This is when Apple hints to you to stop using an API because it's being superseded by a newer one. 이전 버전의 iOS를 지 원하는 경우에는 Classic API 계속 해 서 필요한 경우가 많습니다.The Classic API is still fine and often required (if you support the older version of iOS). 이러한 API (및 [Obsolete] 특성)는 새 Xamarin.ios 어셈블리에 포함 됩니다.Such API (and the [Obsolete] attribute) are included into the new Xamarin.iOS assemblies.
  • 잘못 된 API 일부 API는 이름에 오타가 있습니다.Incorrect API Some API had typos on their names.

원본 어셈블리 (monotouch.dialog 및 XamMac)의 경우 이전 코드를 호환성에 사용할 수 있도록 유지 했지만 Unified API 어셈블리 (Xamarin.ios 및 Xamarin.ios)에서 제거 되었습니다.For the original assemblies (monotouch.dll and XamMac.dll) we kept the old code available for compatibility but they have been removed from the Unified API assemblies (Xamarin.iOS.dll and Xamarin.Mac)

NSObject 서브 클래스 .ctor (IntPtr)NSObject subclasses .ctor(IntPtr)

모든 NSObject 서브 클래스에는 IntPtr를 허용 하는 생성자가 있습니다.Every NSObject subclass has a constructor that accepts an IntPtr. 이는 네이티브 ObjC 핸들에서 새로운 관리 되는 인스턴스를 인스턴스화할 수 있는 방법입니다.This is how we can instantiate a new managed instance from a native ObjC handle.

클래식에서는 public 생성자 였습니다.In classic this was a public constructor. 그러나 사용자 코드에서이 기능을 사용 하는 것은 간단 합니다. 예 를 들어 단일 ObjC 인스턴스에 대해 여러 개의 관리 되는 인스턴스를 만들거나 필요한 관리 되는 상태 (서브 클래스의 경우)가 없는 관리 되는 인스턴스를 만들 수 있습니다.However it was easy to misuse this feature in user code, e.g. creating several managed instances for a single ObjC instance or creating a managed instance that would lack the expected managed state (for subclasses).

이러한 종류의 문제를 방지 하기 위해 IntPtr 생성자는 이제 통합 API에서 protected 하 여 서브클래싱에만 사용할 수 있습니다.To avoid those kind of problems the IntPtr constructors are now protected in unified API, to be used only for subclassing. 이렇게 하면 올바른/안전 API를 사용 하 여 핸들에서 관리 되는 인스턴스를 만들 수 있습니다. 즉,This will ensure the correct/safe API is used to create managed instance from handles, i.e.

var label = Runtime.GetNSObject<UILabel> (handle);

이 API는 기존 관리 되는 인스턴스를 반환 하거나 (이미 있는 경우) 새 인스턴스 (필요한 경우)를 만듭니다.This API will return an existing managed instance (if it already exists) or will create a new one (when required). 클래식 API와 통합 API 모두에서 이미 사용할 수 있습니다.It is already available in both classic and unified API.

이제 .ctor(NSObjectFlag) protected 수도 있지만이는 하위 클래스 외부에서 거의 사용 되지 않았습니다.Note that the .ctor(NSObjectFlag) is now also protected but this one was rarely used outside of subclassing.

NSAction이 작업으로 대체 됨NSAction Replaced with Action

통합 Api를 사용 하면 표준 .NET Action를 위해 NSAction 제거 되었습니다.With the Unified APIs, NSAction has been removed in favor of the standard .NET Action. 이는 Action 일반적인 .NET 형식 이지만 NSAction는 Xamarin.ios와 관련 되어 있기 때문에 크게 향상 된 기능입니다.This is a big improvement because Action is a common .NET type, whereas NSAction was specific to Xamarin.iOS. 두 항목은 모두 정확히 동일한 작업을 수행 하지만 형식이 서로 다르며 호환 되지 않는 형식 이므로 동일한 결과를 얻기 위해 더 많은 코드를 작성 해야 했습니다.They both do exactly the same thing, but they were distinct and incompatible types and resulted in more code having to be written to achieve the same result.

예를 들어 기존 Xamarin 응용 프로그램에 다음 코드가 포함 된 경우입니다.For example, if your existing Xamarin application included the following code:

UITapGestureRecognizer singleTap = new UITapGestureRecognizer (new NSAction (delegate() {
    ShowDropDownAnimated (tblDataView);
}));

이제 간단한 람다로 바꿀 수 있습니다.It can now be replaced with a simple lambda:

UITapGestureRecognizer singleTap = new UITapGestureRecognizer (() => ShowDropDownAnimated(tblDataView));

이전에는 Action NSAction에 할당할 수 없기 때문에 컴파일러 오류가 발생 했지만 UITapGestureRecognizer 이제는 통합 Api에서 유효한 NSAction 대신 Action를 사용 합니다.Previously that would be a compiler error because an Action can't be assigned to NSAction, but since UITapGestureRecognizer now takes an Action instead of an NSAction it is valid in the Unified APIs.

사용자 지정 대리자를 작업<T로 대체 >Custom delegates replaced with Action<T>

통합 된 몇 가지 간단한 (예: 하나의 매개 변수) .net 대리자는 Action<T>로 대체 되었습니다.In unified some simple (e.g. one parameter) .net delegates were replaced with Action<T>. 예:E.g.

public delegate void NSNotificationHandler (NSNotification notification);

이제를 Action<NSNotification>사용할 수 있습니다.can now be used as an Action<NSNotification>. 이 코드를 승격 하면 Xamarin.ios와 사용자 고유의 응용 프로그램 내에서 코드 중복을 다시 사용 하 고 줄일 수 있습니다.This promote code reuse and reduce code duplication inside both Xamarin.iOS and your own applications.

작업<bool >는 Task < Boolean, NSError >로 바뀝니다 >Task<bool> replaced with Task<Boolean,NSError>>

클래식 에는 Task<bool>를 반환 하는 비동기 api가 있었습니다.In classic there were some async APIs returning Task<bool>. 그러나이 중 일부는 NSError 시그니처의 일부일 때를 사용할 수 있습니다. 즉, bool 이미 true 되었으며 NSError를 얻기 위해 예외를 catch 해야 합니다.However some of them where are to use when an NSError was part of the signature, i.e. the bool was already true and you had to catch an exception to get the NSError.

일부 오류는 매우 일반적 이며 반환 값은 유용 하지 않기 때문에 Task<Tuple<Boolean,NSError>>를 반환 하도록 통합 에서이 패턴이 변경 되었습니다.Since some errors are very common and the return value was not useful this pattern was changed in unified to return a Task<Tuple<Boolean,NSError>>. 이렇게 하면 비동기 호출 중에 발생 했을 수 있는 성공 및 오류를 모두 확인할 수 있습니다.This allows you to check both the success and any error that could have happened during the async call.

NSString vs 문자열NSString vs string

일부 경우에는 일부 상수를 string에서 NSString으로 변경 해야 했습니다 (예: UITableViewCellIn a few cases some constants had to be changed from string to NSString, e.g. UITableViewCell

기존Classic

public virtual string ReuseIdentifier { get; }

통합형Unified

public virtual NSString ReuseIdentifier { get; }

일반적으로 .NET System.String 형식을 선호 합니다.In general we prefer the .NET System.String type. 그러나 Apple 지침에도 불구 하 고, 일부 네이티브 API는 상수 포인터 (문자열 자체 아님)를 비교 하며이는 상수를 NSString으로 노출 하는 경우에만 작동할 수 있습니다.However, despite Apple guidelines, some native API are comparing constant pointers (not the string itself) and this can only work when we expose the constants as NSString.

목표-C 프로토콜Objective-C Protocols

원래 Monotouch.dialog는 ObjC 프로토콜에 대 한 완전 한 지원을 제공 하지 않았으며, 가장 일반적인 시나리오를 지원 하기 위해 최적화 되지 않은 몇 가지 API가 추가 되었습니다.The original MonoTouch did not have full support for ObjC protocols and some, non-optimal, API were added to support the most common scenario. 이러한 제한 사항은 더 이상 존재 하지 않지만 이전 버전과의 호환성을 위해 monotouch.dllXamMac.dll내부에 몇 가지 Api가 유지 됩니다.This limitation does not exists anymore but, for backward compatibility, several APIs are kept around inside monotouch.dll and XamMac.dll.

이러한 제한 사항은 통합 Api에서 제거 되 고 정리 되었습니다.These limitations have been removed and cleaned up on the Unified APIs. 대부분의 변경 내용은 다음과 같습니다.Most changes will look like this:

기존Classic

public virtual AVAssetResourceLoaderDelegate Delegate { get; }

통합형Unified

public virtual IAVAssetResourceLoaderDelegate Delegate { get; }

I 접두사는 지정 된 형식 대신 ObjC 프로토콜에 대 한 인터페이스 를 제공 하 는 것을 의미 합니다.The I prefix means unified expose an interface, instead of a specific type, for the ObjC protocol. 이렇게 하면 Xamarin.ios에서 제공 하는 특정 형식을 서브 클래스 하지 않으려고 할 수 있습니다.This will ease cases where you do not want to subclass the specific type that Xamarin.iOS provided.

또한 일부 API는 보다 정확 하 고 사용 하기 쉽습니다. 예를 들면 다음과 같습니다.It also allowed some API to be more precise and easy to use, e.g.:

기존Classic

public virtual void SelectionDidChange (NSObject uiTextInput);

통합형Unified

public virtual void SelectionDidChange (IUITextInput uiTextInput);

이러한 API는 이제 설명서를 참조 하지 않고 더 쉽게 사용할 수 있으며, IDE 코드 완성 기능을 통해 프로토콜/인터페이스를 기반으로 하는 더 유용한 제안 사항을 제공할 수 있습니다.Such API are now easier to us, without referring to documentation, and your IDE code completion will provide you with more useful suggestions based on the protocol/interface.

NSCoding 프로토콜NSCoding Protocol

원래 바인딩에는 NSCoding 프로토콜을 지원 하지 않는 경우에도 모든 형식에 대 한 .ctor (NSCoder)가 포함 되어 있습니다.Our original binding included an .ctor(NSCoder) for every type - even if it did not support the NSCoding protocol. 개체를 인코딩하기 위해 NSObject에 단일 Encode(NSCoder) 메서드가 있습니다.A single Encode(NSCoder) method was present in the NSObject to encode the object. 그러나이 메서드는 인스턴스가 NSCoding 프로토콜에 맞춘 경우에만 작동 합니다.But this method would only work if the instance conformed to NSCoding protocol.

Unified API에서는이 문제를 해결 했습니다.On the Unified API we have fixed this. 형식이 NSCoding를 따르는 경우에만 새 어셈블리에 .ctor(NSCoder) 있습니다.The new assemblies will only have the .ctor(NSCoder) if the type conforms to NSCoding. 또한 이러한 형식에는 이제 INSCoding 인터페이스를 따르는 Encode(NSCoder) 메서드가 있습니다.Also such types now have an Encode(NSCoder) method which conforms to the INSCoding interface.

낮은 영향: 대부분의 경우이 변경은 이전에 제거 된 생성자를 사용할 수 없기 때문에 응용 프로그램에 영향을 주지 않습니다.Low Impact: In most cases this change won’t affect applications as the old, removed, constructors could not be used.

추가 팁Further Tips

에 대해 알아 두어야 할 추가 변경 내용은 Unified API 앱을 업데이트 하기 위한 팁에 나와 있습니다.Additional changes to be aware of are listed in the tips for updating apps to the Unified API.

샘플 코드Sample Code

7 월 31 일까 지 monotouch.dialogmagic-types 분기에서 iOS 샘플의 포트를이 새 API에 게시 했습니다.As of July 31st, we have published ports of the iOS samples to this new API on the magic-types branch at monotouch-samples.

Mac의 경우, mac 샘플 리포지토리 (Mavericks/Yosemite의 새 api 표시) 뿐만 아니라 매직 유형의 분기 Mac-샘플에서 32/64 비트 샘플에 대 한 샘플을 확인 하 고 있습니다.For Mac, we are checking samples in both the mac-samples repo (showing new APIs in Mavericks/Yosemite) as well as 32/64 bit samples in the magic-types branch mac-samples.