Objective-C’den XML’e Dönüştürücü
Objective-C arayüzlerini veya nesnelerini yapıştırın. Temiz XML geri alın.
Bu araç ne işe yarar
Bir Objective-C modeline uyacak bir XML yükünü elle kurmak zorunda kaldıysanız — eski bir SOAP servisi, bir plist dosyası, bir Cocoa yapılandırması ya da bir test fixture’ı için — bu işin tadını bilirsiniz. @property satırlarını sayarsınız, tip niteleyicilerini çıkarırsınız, hangilerinin NSArray kabı olduğunu hatırlamaya çalışırsınız ve şeklin tutmasını umarsınız. Objective-C’yi buraya yapıştırın, tek seferde iyi biçimli XML geri alın. Tek bir alloc/init parçası, birkaç @interface bloğu olan koca bir header dosyası ya da derinlemesine iç içe bir model — sonuç aynı.
Bu saf bir metin değiştirme değil. Dönüştürücü, Cocoa’nın XML’e gerçekten nasıl eşlendiğini takip ediyor. NSString değerleri (düzgün kaçışla) metin düğümü olur. NSNumber ve NSDecimalNumber sargısını bırakıp düz sayısal metne dönüşür — yani [NSDecimalNumber decimalNumberWithString:@"249.99"] çıktıda 249.99 olur. BOOL değerleri true / false, şemanız öyle bekliyorsa YES / NO varyantı olur. NSArray<OrderItem *>, öğe tipine göre adlandırılmış her öğe için bir çocuk içeren bir kap öğesine dönüşür — NSXMLElement ağaçlarının ürettiği biçimin aynısı.
Örnek değişkenleriyle arka alan da ele alınır. @property’niz @synthesize customerName = _customerName; kullansa bile öğenin adı _customerName değil, yine customerName olur — o iVar adlandırması bir uygulama detayıdır, tel formatın parçası değil. İç içe nesneler (Address @property’si olan bir Order gibi) yerinde açılır, nil değerleri biçim tutarlı kalsın diye boş öğe olur. Birden fazla @interface bloğu yapıştırırsanız hepsi çıktıya düşer. .h dosyanızda nasıl duruyorsa öyle yapıştırın — temizlemeye gerek yok — ve sonucu NSXMLDocument’ın üreteceğiyle karşılaştırın.
Nasıl kullanılır
Üç adım. İster tek bir sınıf, ister bütün bir header paketi yapıştırın — fark etmez.
Objective-C’nizi yapıştırın (ya da örneği deneyin)
Objective-C’yi olduğu gibi soldaki editöre atın. Bir @interface bloğu, bir alloc/init nesne literali, birden fazla sınıf ya da iç içe tipler — hepsi olur. Önce gerçekçi bir Order / OrderItem / Address örneği görmek için Örnek Yükle’ye basın.
@property özniteliklerini söküp atmanıza, pragma’ları kaldırmanıza veya import ifadelerini temizlemenize gerek yok. Kodu Xcode’daki hâliyle bırakın. Parser gerçek bir .h ya da .m dosyasını nasıl okuyacağını biliyor.
Dönüştür’e basın
Yeşil Dönüştür butonuna tıklayın. Araç Objective-C’yi okur, tüm @property’leri korur, iç içe nesneleri bozmadan tek seferde XML’i üretir. Bu sırada kısa bir yükleme göstergesi döner.
XML’i kopyalayın
Sağ panel, NSXMLParser dâhil standartlara uyan her parser’ın kabul edeceği girintili ve iyi biçimli XML’le dolar. Bir plist’e, bir SOAP istek gövdesine, bir test fixture’ına ya da dokümantasyonunuza kopyalayın.
Ne zaman işe yarar
iOS plist fixture’ları üretmek
Elinizde Objective-C modeli var ve onunla uyuşan bir Info.plist ya da veri seed plist’ine ihtiyacınız var. Sınıfı yapıştırın, XML’i alın, bundle’a atın — <code><dict></code> / <code><key></code> çiftlerini elle yazmayın.
Cocoa XML yapılandırma dosyaları
Eski masaüstü Cocoa uygulamaları hâlâ XML yapılandırmayla geliyor. <code>Settings</code> sınıfınızı düzenlemeye hazır bir şablona çevirin; yapılandırma, onu okuyan kodla birebir örtüşsün.
iOS’taki eski SOAP / WCF istemcileri
iOS uygulamanız hâlâ bir SOAP uç noktasıyla konuşuyorsa istek sözleşme sınıfını yapıştırıp XML envelope gövdesini alabilirsiniz — <code>NSXMLElement</code> ağaçlarını elle inşa etmekten çok daha kolay.
Mac OS XML akışlarını beslemek
Eski AppleScript / Automator / XML-RPC entegrasyonları XML bekler. Objective-C modelini yapıştırın, XML’i alın, akışa verin — manuel çeviri yok.
Sık sorulan sorular
Birden fazla @interface bildirimini aynı anda yapıştırabilir miyim?
Evet. Koca bir header dosyasını yapıştırın. Her @interface, iç içe tipleri açılmış hâlde geçer. @interface’ınız ivar’ları açıkça ({ } içinde) bildirse de modern yalnızca-@property stilini kullansa da ikisi de aynı şekilde çalışır.
@property öznitelikleri nasıl işleniyor?
(nonatomic, copy), (strong), (weak), (readonly) ve (assign) gibi öznitelikler çalışma zamanı için meta veridir — serileştirilen biçimi değiştirmez. Öğe adı, property adıdır. readonly property’ler yine de çıkışa yazılır (değerleri vardır). Özel getter’lardan gelen hesaplanmış property’ler de diğerleri gibi işlenir.
Peki iVar adlandırması — _alt çizgili öğeler çıkar mı?
Hayır. Property’nizin adı customerName ve onu destekleyen iVar _customerName ise XML öğesi <customerName> olur. Alt çizgi Objective-C geleneğidir, tel formatı değil. Bir öğeyi yeniden adlandırmak istiyorsanız @property’nin kendisini değiştirip tekrar yapıştırın.
NSString, NSNumber, NSDecimalNumber, BOOL ve NSDate nasıl ele alınıyor?
NSString doğru XML kaçışıyla bir metin düğümüne dönüşür. NSNumber ve NSDecimalNumber sargısını bırakır ve düz sayısal metin olur. BOOL, true / false olur (kaynak kod plist konvansiyonunu kullanıyorsa YES / NO). NSDate bir ISO-8601 dizgisi olarak çıkar. nil değerler silinmek yerine boş öğe olur.
NSArray, NSDictionary ve iç içe nesneler ne oluyor?
NSArray<OrderItem *>, öğe tipine göre adlandırılmış her öğe için bir çocuğu olan bir kap öğesine dönüşür: <items><OrderItem/><OrderItem/></items>. NSDictionary ise <entry><key/><value/></entry> kabı olur. İç içe nesneler (tipi başka bir @interface olan property’ler) tüm alanlar sağlam biçimde yerinde açılır.
Kodum saklanıyor mu?
Kodunuz dönüşüm için arka uca gönderiliyor ve kalıcı olarak tutulmuyor — yükü loglamıyoruz. Çevrimiçi araçlarda hep olduğu gibi, kod gerçekten hassassa yapıştırmadan önce bir göz gezdirin.
İşinize yarayabilecek diğer araçlar
Objective-C’den XML’e sadece yapbozun bir parçası. Bu araçlar onunla iyi gider: