Aracılığıyla paylaş

Platformlar Arası Uygulamalarda Yerel Türlerle Çalışma

  • Makale

Bu makale, kodun Android veya Windows Telefon işletim sistemi gibi iOS dışı cihazlarla paylaşıldığı platformlar arası bir uygulamada yeni iOS Birleşik API Yerel türlerini (nint, nuint, nfloat) kullanmayı kapsar.

64 türdeki yerel türler iOS ve Mac API'leriyle çalışır. Android veya Windows üzerinde de çalışan paylaşılan kod yazıyorsanız, Birleşik türlerin paylaşabileceğiniz normal .NET türlerine dönüştürülme işlemini yönetmeniz gerekir.

Bu belgede, paylaşılan/ortak kodunuzdan Birleşik API ile birlikte çalışmanın farklı yolları ele alınmaktadır.

Yerel Türler Ne Zaman Kullanılır?

Xamarin.iOS ve Xamarin.Mac Birleşik API'leri yine , ve veri türlerinin yanı RectangleFsıra , SizeF ve PointF türlerini içerirint.floatuint Bu mevcut veri türleri paylaşılan, platformlar arası kodlarda kullanılmaya devam etmelidir. Yeni Yerel veri türleri yalnızca, mimari algılamalı türler için destek gerektiren bir Mac veya iOS API'sine çağrı yapılırken kullanılmalıdır.

Paylaşılmakta olan kodun yapısına bağlı olarak, platformlar arası kodun ile nuint ve nfloat veri türleriyle ilgilenmesi nintgereken zamanlar olabilir. Örneğin: Daha önce bir uygulamanın Xamarin.iOS ve Xamarin.Android sürümleri arasında işlevselliği paylaşmak için kullanılan System.Drawing.RectangleF dikdörtgen verilerdeki dönüştürmeleri işleyen bir kitaplığın, iOS'ta Yerel Türleri işleyecek şekilde güncelleştirilmesi gerekir.

Bu değişikliklerin nasıl işlendiği, aşağıdaki bölümlerde göreceğimiz gibi uygulamanın boyutuna ve karmaşıklığına ve kullanılan kod paylaşımı biçimine bağlıdır.

Kod Paylaşımında Dikkat Edilmesi Gerekenler

Paylaşım Kodu Seçenekleri belgesinde belirtildiği gibi, platformlar arası projeler arasında kod paylaşmanın iki ana yolu vardır: Paylaşılan Projeler ve Taşınabilir Sınıf Kitaplıkları. İki türden hangisi kullanıldı, platformlar arası kodda Yerel veri türlerini işlerken sahip olduğumuz seçenekleri sınırlayacaktır.

Taşınabilir Sınıf Kitaplığı Projeleri

Taşınabilir Sınıf Kitaplığı (PCL), desteklemek istediğiniz platformları hedeflemenize ve platforma özgü işlevler sağlamak için arabirimleri kullanmanıza olanak tanır.

PCL Projesi türü a'ya .DLL kadar derlendiğinden ve Birleşik API'yi anlamadığından, PCL kaynak kodundaki mevcut veri türlerini (int, uint, float) kullanmaya devam etmek zorunda kalırsınız ve çağrıları ön uç uygulamalarında PCL'nin sınıflarına ve yöntemlerine yayınlarsınız. Örneğin:

using NativePCL;
...

CGRect rect = new CGRect (0, 0, 200, 200);
Console.WriteLine ("Rectangle Area: {0}", Transformations.CalculateArea ((RectangleF)rect));

Paylaşılan Projeler

Paylaşılan Varlık Projesi türü, kaynak kodunuzu platforma özgü ön uç uygulamalarına dahil edilen ve derlenen ayrı bir projede düzenlemenize ve platforma özgü gereksinimleri yönetmek için gereken derleyici yönergelerini kullanmanıza #if olanak tanır.

Platformlar arası Paylaşılan Varlık Projesinde Yerel veri türleri için destek yöntemi seçilirken, paylaşılan kodu kullanan ön uç mobil uygulamalarının boyutu ve karmaşıklığı ile paylaşılmakta olan kodun boyutu ve karmaşıklığı dikkate alınmalıdır.

Bu faktörlere bağlı olarak, kodda Birleştirilmiş API'ye özgü değişiklikleri işlemek için derleyici yönergeleri kullanılarak if __UNIFIED__ ... #endif aşağıdaki çözüm türleri uygulanabilir.

Yinelenen Yöntemleri Kullanma

Yukarıda verilen dikdörtgen veriler üzerinde dönüştürmeler yapan bir kitaplık örneğini inceleyin. Kitaplıkta yalnızca bir veya iki çok basit yöntem varsa, Xamarin.iOS ve Xamarin.Android için bu yöntemlerin yinelenen sürümlerini oluşturmayı seçebilirsiniz. Örneğin:

using System;
using System.Drawing;

#if __UNIFIED__
using CoreGraphics;
#endif

namespace NativeShared
{
    public class Transformations
    {
        #region Constructors
        public Transformations ()
        {
        }
        #endregion

        #region Public Methods
        #if __UNIFIED__
            public static nfloat CalculateArea(CGRect rect) {

                // Calculate area...
                return (rect.Width * rect.Height);

            }
        #else
            public static float CalculateArea(RectangleF rect) {

                // Calculate area...
                return (rect.Width * rect.Height);

            }
        #endif
        #endregion
    }
}

Yukarıdaki kodda, yordam çok basit olduğundan CalculateArea koşullu derleme kullandık ve yöntemin ayrı bir Birleşik API sürümünü oluşturduk. Öte yandan, kitaplıkta birçok yordam veya çeşitli karmaşık yordamlar varsa, değişiklikler veya hata düzeltmeleri için tüm yöntemleri eşitlenmiş durumda tutan bir sorun ortaya çıkardığından bu çözüm uygun olmaz.

Yöntem Aşırı Yüklemelerini Kullanma

Bu durumda çözüm, 32 bit veri türlerini kullanarak yöntemlerin aşırı yükleme sürümünü oluşturmak, böylece artık parametre ve/veya dönüş değeri olarak almaları CGRect , bu değeri bir RectangleF değerine dönüştürmeleri (dönüştürmenin kayıplı bir dönüştürme olduğunu nfloatfloat bilerek) ve gerçek işi yapmak için yordamın özgün sürümünü çağırmak olabilir. Örneğin:

using System;
using System.Drawing;

#if __UNIFIED__
using CoreGraphics;
#endif

namespace NativeShared
{
    public class Transformations
    {
        #region Constructors
        public Transformations ()
        {
        }
        #endregion

        #region Public Methods
        #if __UNIFIED__
            public static nfloat CalculateArea(CGRect rect) {

                // Call original routine to calculate area
                return (nfloat)CalculateArea((RectangleF)rect);

            }
        #endif

        public static float CalculateArea(RectangleF rect) {

            // Calculate area...
            return (rect.Width * rect.Height);

        }

        #endregion
    }
}

Duyarlık kaybı uygulamanızın özel ihtiyaçlarına yönelik sonuçları etkilemediği sürece bu da iyi bir çözümdür.

Diğer Ad Yönergelerini Kullanma

Duyarlık kaybının bir sorun olduğu alanlarda başka bir olası çözüm de, aşağıdaki kodu paylaşılan kaynak kodu dosyalarının en üstüne ekleyerek ve gerekli , veya değerlerini öğesine dönüştürerek Native ve CoreGraphics veri türleri için bir diğer ad oluşturmak için nuintnintyönergeleri kullanmaktır usingnfloat.floatuintint

#if __UNIFIED__
    // Mappings Unified CoreGraphic classes to MonoTouch classes
    using RectangleF = global::CoreGraphics.CGRect;
    using SizeF = global::CoreGraphics.CGSize;
    using PointF = global::CoreGraphics.CGPoint;
#else
    // Mappings Unified types to MonoTouch types
    using nfloat = global::System.Single;
    using nint = global::System.Int32;
    using nuint = global::System.UInt32;
#endif

Böylece örnek kodumuz şu hale gelir:

using System;
using System.Drawing;

#if __UNIFIED__
    // Map Unified CoreGraphic classes to MonoTouch classes
    using RectangleF = global::CoreGraphics.CGRect;
    using SizeF = global::CoreGraphics.CGSize;
    using PointF = global::CoreGraphics.CGPoint;
#else
    // Map Unified types to MonoTouch types
    using nfloat = global::System.Single;
    using nint = global::System.Int32;
    using nuint = global::System.UInt32;
#endif

namespace NativeShared
{

    public class Transformations
    {
        #region Constructors
        public Transformations ()
        {
        }
        #endregion

        #region Public Methods
        public static nfloat CalculateArea(RectangleF rect) {

            // Calculate area...
            return (rect.Width * rect.Height);

        }
        #endregion
    }
}

Burada yöntemini standart floatyerine bir nfloat döndürecek şekilde değiştirdiğimize CalculateArea dikkat edin. Bu, hesaplamamızın sonucunu örtük olarak dönüştürmeye nfloat çalışan bir derleme hatası almamak için yapıldı (çarpılan her iki değer de türünde nfloatolduğundan) dönüş float değerine.

Kod derlenir ve Birleşik olmayan bir API cihazında çalıştırılırsa , using nfloat = global::System.Single; öğesini ile eşler nfloatSingle ve bu, kullanan ön uç uygulamasının değiştirmeden yöntemini çağırmasına CalculateArea izin veren bir float öğesine örtük olarak dönüştürülür.

Ön Uç Uygulamasında Tür Dönüştürmelerini Kullanma

Ön uç uygulamalarınızın paylaşılan kod kitaplığınıza yalnızca birkaç çağrı yapması durumunda, başka bir çözüm de kitaplığı değiştirmeden bırakmak ve mevcut yordamı çağırırken Xamarin.iOS veya Xamarin.Mac uygulamasında tür ataması yapmak olabilir. Örneğin:

using NativeShared;
...

CGRect rect = new CGRect (0, 0, 200, 200);
Console.WriteLine ("Rectangle Area: {0}", Transformations.CalculateArea ((RectangleF)rect));

Tüketen uygulama paylaşılan kod kitaplığına yüzlerce çağrı yaparsa, bu da iyi bir çözüm olmayabilir.

Uygulamamızın mimarisine bağlı olarak, platformlar arası kodumuzda Yerel Veri Türlerini (gerektiğinde) desteklemek için yukarıdaki çözümlerden birini veya daha fazlasını kullanmayı tercih edebiliriz.

Xamarin.Forms Uygulamaları

BirLeştirilmiş API uygulamasıyla da paylaşılacak platformlar arası URI'ler için Xamarin.Forms'u kullanmak için aşağıdakiler gereklidir:

  • Çözümün tamamı Xamarin.Forms NuGet Paketinin 1.3.1 (veya üzeri) sürümünü kullanıyor olmalıdır.
  • Tüm Xamarin.iOS özel işlemeleri için, kullanıcı arabirimi kodunun nasıl paylaşıldığına (Paylaşılan Proje veya PCL) bağlı olarak yukarıda sunulan çözüm türlerini kullanın.

Standart bir platformlar arası uygulamada olduğu gibi, mevcut 32 bit veri türleri çoğu durumda paylaşılan, platformlar arası kodlarda kullanılmalıdır. Yeni Yerel Veri Türleri yalnızca, mimari algılamalı türler için destek gerektiren bir Mac veya iOS API'sine çağrı yapılırken kullanılmalıdır.

Diğer ayrıntılar için Mevcut Xamarin.Forms Uygulamalarını Güncelleştirme belgelerimize bakın.

Özet

Bu makalede, Birleştirilmiş API uygulamasında Yerel Veri Türlerinin ne zaman kullanılacağını ve bunların platformlar arası etkilerini gördük. Yeni Yerel Veri Türlerinin platformlar arası kitaplıklarda kullanılması gereken durumlarda kullanılabilecek çeşitli çözümler sunduk. Ayrıca, Xamarin.Forms platformlar arası uygulamalarda Birleşik API'leri desteklemeye yönelik hızlı bir kılavuz gördük.