MonoTouch ve Objective-C arasında nasıl karar verilir? [kapalı]


273

Bugün Mono'da yerel bir .Net etkinliğinde bir oturumda oturduktan sonra, iPhone geliştirmeye alternatif olarak MonoTouch kullanımı `` ele alındı ​​''. C # ve .Net'te çok rahat olmak, Mono yığınının bazı tuhaflıklarına rağmen çekici bir seçenek gibi görünüyor. Ancak, MonoTouch'ın 400 $ 'a mal olması nedeniyle, iPhone geliştirme için bu yolun bir yolu olup olmadığımı biraz yırttı.

Herkes MonoTouch ve Objective-C ile geliştirme deneyimine sahiptir ve eğer öyleyse MonoTouch ile Objective-C öğrenmekten çok daha basit ve daha hızlı ve 400 $ değerinde geliştirme?


13
Apple'ın dev araçları kısıtlamasını gevşettiğinden MonoTouch'ın iOS'ta çalışamamasıyla ilgili birçok yorum artık geçerli olmadığını düşünüyorum. Bkz. Apple.com/pr/library/2010/09/09statement.html
sivabudh

Yanıtlar:


520

Bu soruyu (ve bununla ilgili varyasyonları) son zamanlarda çok gördüm. Beni şaşırtan şey insanların ne sıklıkta yanıt verdiği , ancak ne kadar az cevap verdiği .

Tercihlerim var (her iki yığının da tadını çıkarıyorum), ancak çoğu "yanıtın" yanlış gitmeye başladığı yer burası. Ne istediğim (ya da başka birinin ne istediği) ile ilgili olmamalı.

İşte MonoTouch'ın değerini belirlemeye nasıl devam edeceğim - Açıkçası objektif olamıyorum, ama bunun oldukça zealotry içermediğini düşünüyorum:

  • Bu eğlence veya iş için mi? Bu alanda danışmanlık almak istiyorsanız, 399 $ 'ınızı çok hızlı bir şekilde geri alabilirsiniz.

  • Platformu içten dışa öğrenmek mi istiyorsunuz yoksa "sadece" bunun için uygulamalar mı yazmak istiyorsunuz?

  • Farklı bir dev yığını kullanmanın eğlenceyi sizin için çıkarmasına yetecek kadar Net'i seviyor musunuz? Yine, her iki yığını da (Apple ve Mono) seviyorum, ama benim için MonoTouch deneyimi çok daha eğlenceli hale getiriyor. Apple'ın araçlarını kullanmayı bırakmadım, ancak bunun nedeni esasen her iki yığının da tadını çıkarmam . İPhone'u ve .Net'i seviyorum. Bu durumda, benim için MonoTouch beyinsizdi.

  • C ile çalışmak rahat mı? Ben Objective-C ortalama yok ama C - Objective-C, çünkü bu konularda olduğu işaretçileri size içini karartmak eğer C. adlı, fantezi, dost OO versiyonu, ama, MonoTouch arkadaşın güzel bir. Ve sen bu durumda size bir dev ödlek olduğunu düşünüyorum Muhaliflere dinlemiyorum yok işaretçiler (veya C, vs.) gibi. IBM ROM BIOS Pocket Reference'ın bir kopyasıyla dolaşıyordum ve montaj yazarken ve bilgisayarımı komik video modlarına zorlarken ve onlar için kendi yazı tipi oluşturma bitlerimi ve (kuşkusuz değersiz) pencereleme sistemlerini yazarken, QuickBasic geliştiricilerinin wusses olduğunu düşünüyorum. Ben olduQuickBasic geliştiricisi (diğerlerine ek olarak). Asla nerd machismo'ya vermeyin. C'yi sevmiyorsanız ve işaretçileri sevmiyorsanız ve manuel bellek yönetiminden mümkün olduğunca uzak kalmak istiyorsanız (ve adil olmak gerekirse, ObjC'de hiç de fena değil). .. MonoTouch. Ve bunun için hiç bir şey yapma.

  • Kullanıcıları veya işletmeleri hedeflemek ister misiniz? Benim için çok önemli değil, ama Edge'de hala insanlar var ve gerçek şu ki: Apple'ın yığınını kullanıyorsanız çok daha küçük bir indirme paketi oluşturabilirsiniz. MonoTouch ile oynuyorum ve sıkıştırıldıktan sonra yaklaşık 2,7 MB'a inen iyi bir küçük uygulamam var (uygulamanızı dağıtım için gönderirken, fermuarlıyorsunuz - uygulamalar mağazadan indirildiğinde, yeniden sıkıştırılmış - yani uygulamanızın 10MB OTA sınırının altına girip girmeyeceğini çözerken, önce enayi sıkıştırın - MonoTouch ile hoş bir sürpriz olacaksınız). Ancak, MT mutluluğu bir yana, yarım meg ve neredeyse üç (örneğin), son kullanıcıları hedefliyorsanız sizin için önemli olabilecek bir şeydir. Kurumsal çalışmayı düşünüyorsanız, birkaç MB hiç önemli olmayacaktır. Ve, sadece net olmak gerekirse - yakında MT tabanlı bir uygulamayı mağazaya göndereceğim ve boyutla ilgili herhangi bir sorunum yok. Beni hiç rahatsız etmiyor. Ama bu endişelenecek bir şeyseEğer , daha sonra Apple'ın yığını bunu kazanır.

  • XML çalışıyor mu? MonoTouch. Dönemi.

  • Dize düzenleme? Tarih manipülasyonu? .Net'in mutfak lavabosu her şeyi ile alıştığımız bir milyon küçük şey daha var mı? MonoTouch.

  • Ağ hizmetleri? MonoTouch.

  • Sözdizimsel olarak, her ikisinin de avantajları vardır. Objective-C yazmanız gereken yerde daha ayrıntılı olma eğilimindedir . Kendinizi ObjC ile yazmak zorunda kalmayacağınız C # ile kod yazarken bulacaksınız, ancak her iki şekilde de gider. Bu konu bir kitabı doldurabilir. C # sözdizimini tercih ederim, ancak Objective-C'ye bu ilk dünya-ötesi tepkimi aştıktan sonra biraz keyif almayı öğrendim. Ben (o bunu tekrarlamak eğlenceli görüşmelerinde biraz yapmak olduğunu C # / Java / vb alıştığınız cihazlarý garip.), Ama gerçek şu ki bir Objective-C beni mutlu ediyor kalbimde nokta şeklinde olması.

  • Interface Builder'ı kullanmayı planlıyor musunuz? Çünkü, bu erken versiyonda bile, kendimi UI'larımı IB ile oluşturmak ve daha sonra kodda kullanmak için çok daha az iş yapıyor buluyorum. Bu, tüm adımların bir şeyler yapmanın Objective-C / IB tarzında eksik olduğu hissine kapılır ve bunun eminim çünkü tüm adımlar bir şeyler yapmanın Objective-C / IB tarzında eksiktir. Şimdiye kadar ve yeterince test ettiğimi sanmıyorum, ancak şimdiye kadar , MonoTouch ne kadar az iş yapmanız gerektiğinin galibi.

  • Yeni diller ve platformlar öğrenmek eğlenceli mi? Öyleyse, iPhone'un sunacağı çok şey var ve Apple'ın yığını sizi muhtemelen konfor alanınızdan çıkaracak - ki bu, bazı geliştiriciler için eğlenceli (Merhaba - Ben bu geliştiricilerden biriyim - şaka yapıyorum ve verdim Apple zor zamanlar geçirdi, ancak Apple'ın araçları aracılığıyla iPhone geliştirmeyi öğrenirken çok eğlendim).

Dikkate alınacak çok şey var. Değer çok soyut. Maliyetten ve buna değip değmeyeceğinden bahsedersek, cevap ilk mermi kalemime gelir: eğer bu iş içinse ve işi alabiliyorsanız, paranızı hemen geri alacaksınız.

Yani ... bu olabildiğince objektif. Bu, kendinize ne sorabileceğinizin kısa bir listesidir, ancak bu bir başlangıç ​​noktasıdır.

Şahsen (nesnelliği bir anlığına bırakalım), ikisini de seviyorum ve kullanıyorum. Öncelikle Apple yığınını öğrendiğime sevindim. Apple'ın dünyasında yolumu zaten bildiğimde MonoTouch ile çalışmaya başlamak benim için daha kolaydı. Diğerlerinin söylediği gibi, hala CocoaTouch ile çalışacaksınız - sadece .Net-izled bir ortamda olacak.

Ama bundan daha fazlası var. MonoTouch kullanmayan insanlar orada durma eğilimindedir - "Bu bir sarıcı falan falan filan" - bu MonoTouch değil.

MonoTouch size CocoaTouch'ın neler sunduğuna erişmenizi sağlarken aynı zamanda (bir alt küme) neler sunabileceğinize de erişmenizi sağlar. ve bellek yönetimini tamamen unutamasanız da, güzel bir derece elde edersiniz.

Emin değilseniz, Apple'ın yığınını (ücretsiz) ve MonoTouch eval yığınını (ücretsiz) alın. Apple'ın dev programına katılıncaya kadar, her ikisi de sadece simülatöre karşı çalışır, ancak birini diğerini büyük ölçüde tercih edip etmediğinizi ve MonoTouch'ın sizin için 399 $ değerinde olup olmadığını anlamanıza yardımcı olmak için yeterlidir.

Ve zelotları dinlemeyin - korkuluk ettikleri teknolojiyi kullanmayanlar olma eğilimindedirler :)


50
Vay canına, Rory, sorumu bu kadar ayrıntılı cevaplamaya zaman ayırdığın için teşekkürler. Söyleyebileceğim kadarıyla, her iki seçeneği de kullanan tek kişi sensin, bu da cevap aradığım kişiydi. Ben kesinlikle oradan bir deneyin bir vereceğim. BTW, seni en son SO podcast'te duydum, değil mi? İyi şeyler. Tekrar teşekkürler!
jamesaharvey

17
Yorumlar için teşekkürler :) Bazı diz pislik nefret gördüğüm ile sinirli oldum. Tekrar tekrar soruya "Ur ilk önce gevşetici sistemi ayıklamak için aptal bir istek!" Hangi yararsızdır ve hakarettir. MonoTouch'ın kaba noktaları var, ancak bu adamların dahi sicili var. MT hızla gelişti ve her gün daha güzel. Söylemeye devam ediyorum: Onlara birkaç ay ver. Özellikler konusunda ihtiyatlı davranıyorlar, ancak bence büyük şeyler göreceğiz . Apple'ın yığınını seviyorum, ama şimdi başka bir oyun alanım var - bu iyi bir şey ve başım dönüyor :)
Rory Blyth

4
@Stephan - Neyin "eksik" olduğunu söylemek doğru olmayabilir - Cocoa ile işi halledebilirim. Daha çok API'lar hakkında. .Net ile dizeler, tarihler, XML vb. İle çalışmak çok daha kolaydır. Eğer bunları yapmak için .Net'in yolunu ve MonoTouch'ın onlara verdiği desteğin kapsamını biliyorsanız - eğer ona bakmadıysanız, kontrol etmelisiniz. Kakao ile yapamayacağınız şeyler olduğunu söylemek istemiyorum, ancak .Net ile çok daha kolay yapılan birçok şey var. Ayrıştırma tahtada daha kolay - tarih matematik tahtada daha kolay - vb.
Rory Blyth

3
Ayrıca MT ile iPhone / iPad'de kendi kodunuzu yeniden kullanma sorunu var. Sunucumuzda ve masaüstü meslektaşlarımızda çalışan ve MT ile yeniden derleyebileceğimiz ve iOS istemci uygulamamızda kullanabileceğimiz bazı kripto kodlarımız ve iş mantık kodumuz var. Bu bazı projeler için önemli olabilir.
Monoman

2
Ayrıca, lisansın 400 $ 'a mal olmasına rağmen, her yıl yenilemeniz gereken bir bakım aboneliği de vardır (bariz nedenlerle) - 250 $. Muhtemelen adil bir fiyat, ama yine de dikkate almaya değer.
Amc_rtty

62

Bu yazıda MonoTouch ve Objective-C'yi denememiş geliştiricilerden çok fazla kulak misafiri var . MonoTouch'ı hiç denememiş olan çoğunlukla Objective-C geliştiricileri gibi görünüyor.

Açıkça önyargılıyım, ancak MonoTouch topluluğunun neler yaptığını kontrol edebilirsiniz:

http://xamarin.com

Orada geliştiricilerin Objective-C ve C # geliştirmiş birkaç makale bulacaksınız.


29
@NSResponder - MonoTouch kullandınız mı? Bu bir v1.x sürümü, neredeyse yepyeni ve zaten şaşırtıcı. Üzerinde yorum yapmadan önce deneyin. Büyük değişiklikler var (Arayüz Oluşturucu entegrasyonu Xcode'lardan çok daha iyi) ve küçük değişiklikler var (örneğin, kullanıcının belgeleri klasörünü MT'lere kıyasla almanın ObjC / Cocoa yolunu karşılaştırın). Hala Apple'ın yığınını bazı şeyler için kullanıyorum, ancak MT güzel ve potansiyel dolu. Cidden - sadece dene. Ya da Kakao API'lerinin nasıl bağlandığına bakın - onu kullanmak zorunda değilsiniz - sadece öğrenmeden işi çöp kutusuna atmayın .
Rory Blyth

Evet! Ayrıca, bazı yeni C # 5.0 özellikleri, kodlamayı objektif-c'ye kıyasla çok daha eğlenceli hale getiriyor.
harsimranb

39

Yani, daha önceki benzer bir soruya cevabım Objective-C öğrenmek. (Ayrıca, hata ayıklama desteğini de unutmayın)

Bu muhtemelen biraz rahatsız edecek, ancak dürüst olmak gerekirse, ciddi bir gelişme yapacaksanız, Objective-C öğrenmelisiniz. İPhone geliştirmede Objective-C bilmemek sadece bir engel olacaktır. Pek çok örneği anlayamayacaksınız; Eğer Objective-C hakkında çalışma bilginiz varsa, platform belgelerinden çok daha fazlasını elde edebilirsiniz Mono tuhaflıkları ile uğraşmak zorunda.

Şahsen, Mono'yu platformun ana dili üzerinde kullanmak için ihtiyacınız olan bilgi miktarını artırmayı söyleyen konumu anlamıyorum. Bana biraz zarar veriyor gibi görünüyor. Bence bu çok pahalı bir teklifse (yeni bir dil öğrenmek), temel programlama kavramlarına biraz zaman ayırmaya değer olabilir, böylece yeni dilleri öğrenmek oldukça ucuz bir tekliftir.

Başka bir kullanıcı da şunu yazdı:


Monotouch artık sizin için daha kolay. Ama daha sonra.

Örneğin, yeni tohumlar ortaya çıktığında ne denemeniz gerekiyorsa MonoTouch'ı denemeniz gerekiyorsa ne olur?

Mono'ya bağlı kalarak, çerçeveler için kaynak ararken, zihinsel olarak bunları Mono ile nasıl kullanacağınıza çevirmeniz gerekir. Uygulama ikili dosyalarınız daha büyük olacak, geliştirme süreniz birkaç ay sonra Objective-C'ye o kadar hızlı değil ve diğer uygulama geliştiricileri, yerel platformu kullandıkları için size göre çok daha fazla avantaj sağlayacak.

Başka bir husus, C # 'ı kullanmak istediğinizdir, çünkü dile Objective-C'den daha aşinadır. Ancak iPhone için öğrenme eğrisinin büyük çoğunluğu Objective-C değil, C # ile de çağırmanız gereken çerçeveler.

Herhangi bir platform için, bu platformun tasarım felsefesini doğrudan ifade eden platformu kullanmalısınız - iPhone'da, Objective-C. Bunu ters açıdan düşünün, eğer GTK'da programlama için kullanılan bir Linux geliştiricisi Windows uygulamaları yazmak istiyorsa, C # kullanmamalarını ve GTK'ya bağlı kalmamalarını şiddetle tavsiye eder misiniz, çünkü bunu yapmak daha kolaydı?



12
Muhtemelen istemeden MT'yi yanlış temsil ettiniz. Win uygulamaları yazmak için GTK'yi kullanmaya hiç benzemiyor - uzaktan değil. MT'nin bağlantıları CocoaTouch'a çok sadık. Bazı CT API sözleşmelerinde gerçekten düzeldi . Ancak uygulamalarınızı, örneğin CT üzerinden Windows Forms tabanlı bir soyutlama kullanarak yazmıyorsunuz. MonoDevelop ile MT, IB ile Xcode'dan daha iyi bir entegrasyona sahiptir (isterseniz) ve aynı şeyleri genellikle kodun yarısında veya daha azında yapabilirsiniz. İkili boyut geliştirilmektedir ve araçlar (bağlayıcı üreteci vb.) Her zaman daha iyidir. Bir MT uygulaması olan bir yerleşik uygulaması.
Rory Blyth

7
MT-fanboy fikrimi tek başına almanızı beklemek yerine örnekler vermek için, (ve bu sadece avantajların ufacık bir alt kümesidir): Bir satırla bir özellik oluşturun; saçma dizi spelunking olmadan Belge klasörüne bir referans kapmak (bir uygulama her zaman aynı yerde bir dokümanlar klasörü vardır - neden tüm ekstra çalışma "bulmak" onu?); Kakao kokuyorsa .Net çerçevesini kullanın (NSDate, kimse?); kurumsal uygulamalar için emtia becerilerini kullanmak; uygun, modern XML bitleri kullanın (Cocoa sessizce karakterleri boğduğunda ve durduğunda seviyorum - çökme yok - sadece durur ).
Rory Blyth

8
Her şey için kullanacağımı söylemiyorum. ObjC'yi seviyorum ve hala kullanıyorum. Performans bir sorunsa, olup bitenler üzerinde daha ayrıntılı bir kontrole sahibim. Ama ... MT'nin daha anlamlı olacağı zamanlar var ve bence iPhone'u kurumsal gelişim için uygun bir seçenek haline getirecek . Havaya bir kaya atın ve bir .Net dev. Çoğu şirketin şirket içi ObjC geliştiricileri yoktur. Ve kurumsal işler için, buna gerek yok. MT, web hizmetleri ve DB'lerle çalışmak için çok daha kolaydır. ObjC'de alacağı kodun yarısı ile MT ile birçok uygulama türü yazabilirsiniz.
Rory Blyth

8
Sonunda (devam edebilirim, ama sanırım mt noktası yapıyorum), MonoTouch'ın "kırılması" ile ilgili değişiklikler muhtemelen ObjC uygulamalarını kırma olasılığı taşıyor. Uygulamanız mağazaya girdikten sonra, yerel bir iPhone uygulamasıdır (olması gerektiği gibi). Aramalar sonuçta farklı değil - Apple'ın yığını ile oluşturulan uygulamalarla aynı çalışma zamanı. MT uygulamanız çalışma zamanı ortamındaki bir değişiklik nedeniyle bozulursa, ObjC ile oluşturulan uygulamalar da aynı şekilde olur. Ve MT ekibi, güncellemelerin ve hata düzeltmelerinin hızlı bir şekilde yayınlanmasıyla birlikte bu konuların başında geldi. MT'nin bağlantıları CT'lere yeterince yakındır ve herhangi bir gerçek sorun olma olasılığı düşüktür. Aight - Şimdi kapatacağım :)
Rory Blyth

27

Mono kullanmak bir koltuk değneği değildir. İPhone işletim sistemine eklediği birçok şey var. LINQ, WCF, Silverlight uygulaması, ASP.NET sayfası, WPF uygulaması, Windows Form uygulaması arasında paylaşılabilir kod ve Android için mono var ve Windows Mobile için de çalışacak.

Böylece, bir sürü zaman harcayarak Objective-C yazabilirsiniz (C # 'da aynı örnek kodun yazılması OC'den önemli ölçüde daha az olduğu birçok çalışmadan göreceksiniz) ve sonra diğer platformlar için hepsini DUPLICATE. Benim için MonoTouch'ı seçtim çünkü yazdığım Cloud Uygulaması'nın birçok arayüzü olacak, iPhone bunlardan sadece biri. Buluttan MonoTouch uygulamasına akış yapan WCF verilerinin olması son derece basittir. Çeşitli platformlar arasında paylaşılan çekirdek kütüphanelerim var ve daha sonra sadece iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET dağıtımları için basit bir sunum katmanı yazmam gerekiyor. Her şeyi Objective-C'de yeniden oluşturmak , ürün geliştirilmeye devam ettiği için hem ilk geliştirici hem de bakım için muazzam bir zaman kaybı olacaktır, çünkü tüm işlevler yeniden kullanmak yerine çoğaltılmak zorunda kalacaktır.

MonoTouch'a hakaret eden veya kullanıcıların bir koltuk değerine ihtiyaç duyduğunu ima eden insanlar, .NET çerçevesini parmaklarınızın ucuna getirmenin ne anlama geldiğinin Büyük Resminden yoksundur ve belki de mantığın sunumdan uygun şekilde ayrılmasını anlamıyor olabilir. platformlarda ve cihazlarda yeniden kullanılabilir.

Objective-C ilginç ve birçok ortak dilden çok farklı. Bir meydan okumayı ve farklı yaklaşımları öğrenmeyi seviyorum ... ama bunu yaparken ilerlememi engellemez veya gereksiz yeniden kodlama oluşturmaz. İPhone SDK çerçevesi hakkında gerçekten harika şeyler var, ancak tüm bu büyüklük MonoTouch ile tamamen destekleniyor ve tüm manuel bellek yönetimini kesiyor, aynı görevleri gerçekleştirmek için gereken kod miktarını azaltıyor, montajlarımı yeniden kullanmama izin veriyor ve diğer cihazlara ve platformlara geçebilmek için seçeneklerimi açık tutar.


19

Ben değiştirdim. Monotouch, uygulamaları en az 3-4 kat daha hızlı yazmama izin verin (Obj C'deki eski 1 aylık sürüme kıyasla ayda 4 uygulama)

Çok daha az yazarak.

Sadece benim deneyimim.


2
"Ayda 4 uygulama" - Miktar kalite gibi daha önemli olduğunda. MT McDonalds gibidir. Ama XCode-Restaurant'ta daha iyi yiyecekler alıyorsunuz.
netshark1000

2
Sonuçlar farklı konuşsa da, Rdio ve iCircuit Steve Jobs tarafından sunulan MT uygulamalarıdır. C # ve MT, obj-C'nin sizi yapmaya zorladığı sıhhi tesisat işlerinden kurtulur.
Ian Vink

17

Bu şimdiye kadar geliştireceğiniz tek iPhone uygulamasıysa ve Mac uygulamaları geliştirmeye de hiç ilginiz yoksa, MonoTouch muhtemelen maliyete değer.

Daha fazla iPhone uygulaması geliştireceğinizi veya Mac yerel gelişimi yapmak isteyeceğinizi düşünüyorsanız, Objective-C ve ilgili çerçeveleri öğrenmek muhtemelen buna değer. Ayrıca, yeni şeyler öğrenmekten hoşlanan bir programcıysanız, çalışmak eğlenceli yeni bir paradigmadır.


6
Bu şimdiye kadar geliştireceğiniz tek iPhone uygulamasıysa, 99 $ / yıl buna değmez.
Dinah

Mac uygulamaları oluşturmak için aynı C # geliştirme araçlarını kullanabilirsiniz. Aslında iPhone C # ve Mac C # uygulamaları arasındaki paylaşımı kodlayabilirsiniz. MonoTouch şimdi Xamarin
Ian Vink olarak

9

Şahsen ben sadece Objective-C öğrenmek için daha iyi bir zaman olacağını düşünüyorum.

Kısacası:

  • "Öğrenme Hedefi-C" düşündüğünüz gibi göz korkutucu değil, sadece ilk birkaç haftadan sonra tadını çıkarabilirsiniz
  • Çok sayıda * & () {} içeren "C stili" sözdizimini zaten biliyorsunuz; her yerde
  • Apple işleri belgelemek için çok iyi bir iş çıkardı
  • İPhone ile Apple'ın tasarladığı şekilde etkileşime gireceksiniz, bu da avantajları bazı filtrelerden değil doğrudan kaynaktan elde edeceğiniz anlamına gelir.

Unity ve MonoTouch gibi projelerin "size zaman kazandıracağını" bulduk, ancak sonuçta alan adına özel dillerini öğrenmeniz ve zaman zaman yan adım atmanız gerekecek. Tüm bunlar muhtemelen öğrenmekten kaçınmaya çalıştığınız dili (takvim zamanında) öğrenecek kadar uzun sürecektir. Sonunda zamandan tasarruf etmediniz ve bir ürüne sıkı sıkıya bağlısınız.

EDIT: Ben asla .NET hakkında olumsuz bir şey ima etmek istemiyordu Ben onun büyük bir hayranı olur. Demek istediğim, ilginç objc dirsek gösterimi ile henüz rahat olmadığınız için daha fazla karmaşıklık katmanı eklemenin benim için gerçekten bir anlamı yok.

2019 güncellemesi: 7 yıl sonra. Daha fazla değilse hala aynı şekilde hissediyorum. Elbette, 'alana özgü dil' kullanmak için yanlış terim olabilir, ancak yine de birlikte çalıştığınız platform için doğrudan yazmanın ve uyumluluk katmanlarından ve soyutlamalardan mümkün olduğunca kaçınmanın daha iyi olduğuna inanıyorum. Kodun yeniden kullanımı ve yeniden çalışması konusunda endişeleriniz varsa, genel olarak çapraz platform uygulamanızın gerçekleştirmesi gereken herhangi bir işlevsellikten bahsederseniz, muhtemelen modern web teknolojileri ile gerçekleştirilebilir.


12
Öncelikle, C # değil bir "alan belirli bir dil" - çok ondan. Bu bir emtia becerisidir. Bu MonoTouch'ın değerinin bir parçası. ObjC'nin çoğu geliştiricinin (finans ve üniversite laboratuvarları ve bodrumları) yalnızca OS X veya iPhone geliştirme için kullanacağı bir DSL olduğu iddia edilebilir (haksız ve yanlış). Ama değil. C # gibi, temelde dilin kendisinden ziyade çerçevelere odaklanmanıza izin veren çok yönlü bir dildir (sanırım orada anlaşıyoruz). Ancak ObjC kodunuzun Apple güncellemeleriyle kesileceğini unutmayın . Bu MT'ye özgü bir sorun değil.
Rory Blyth

3
MT bazı durumlarda sizi kurtarabilir, çünkü bu soyutlama katmanı vardır. Apple bir API değiştirir mi? Peki, ObjC uygulamanız ve ( varsayalım ) eşdeğer MT uygulamanız kırılacak. MT adamları, MonoTouch API'sının sahne arkasındaki çağrıyı nasıl ele alacağını değiştirmek için bir stopgap çözümü yayınlayabilir. MT kodunuzun değişmesi gerekmez - stopgap MT sürümüne karşı yeniden inşa edebilirsiniz. Evet: Bu, sorunlara kolayca yol açabilecek kirli bir düzeltmedir, ancak stopgap MT API'sini düzgün bir şekilde reddetmek, geliştiricilerin değişikliği sorunsuz bir şekilde ele alması ve gerçek bir düzeltme için zaman satın alması için zaman verecektir .
Rory Blyth

4
Ayrıca, MT gibi yeni, gerektiğinde kendi bağlarınızı oluşturmak çok daha kolay hale geldi (MT 1.2). Tüm bu işleri yapmak için MT peep'lerine tamamen bağımlı değilsiniz ( o işi yapıyor olsalar da ) ve asla olmadılar. Bağlamaları yaratmanın basit yolları var. ObjC çalışma zamanını, bir şeyler yapma yoluna kilitlenmediğiniz MT çerçeveleriyle yeterince ortaya çıkarırlar. Sadece yolumu daha iyi beğenip beğenmediğimi görmek için bağlamaları yeniden uyguladım. MT çerçevelerini yok sayabilir ve isterseniz "el ile" ileti gönderebilir ve alabilirsiniz ve çok az kod alır. Onlar akıllı insanlar. Güven onlara :)
Rory Blyth

2
Bence slf Monotouch sadece ObjC kütüphaneleri + isteğe bağlı .NET kütüphanelerine doğrudan bağlanan sadece C # (GC ile) farkında değildir. Yani hala apple tarafından sağlanan API'yı kullanıyorsunuz. Ama daha temiz bir sözdizimi ve çöp toplama ile.
1212'de basarat

4

Başkalarının zaten söylediklerine eklemek için (iyi!): Benim düşüncem, temel olarak endişelenmeniz gereken böcek sayısını iki katına çıkarmanız ve MonoTouch'taki olanları iPhone OS'de bulunanlara eklemenizdir. Yeni işletim sistemi sürümleri için güncelleme normalden daha acı verici olacaktır. Yuck, her yerde.

Ben MonoTouch için görebildiğim tek zorlayıcı durum çok ve C # programcıları ve onlar ortalıkta C # kodu çok var örgütlerdir gerekir iPhone'da kaldıraç. (3500 $ 'da yanıp sönmeyecek bir dükkan.)

Ama sıfırdan başlayan herkes için, gerçekten değerli veya akıllıca göremiyorum.


-1: "Daha fazla böcek" ile ne demek istiyorsun? Mono ve Objective-C arasında göze çarpan bir empedans uyuşmazlığı var mı?
Jim G.

4

Üç kelime: Linq to SQL

Evet iyi $ değer.


4
Objective-C'nin Anahtar-Değer Bağlamaları ve Temel Verileri ile Linq-to-SQL'e çok benzer bir şey elde edersiniz. Aynı değil. Belki o kadar güçlü değil - ama aynı zemini çok fazla kaplıyor. Core-Data'nın şu anda MonoTouch tarafından desteklenmediğini unutmayın
philsquared

Linq to SQL bir iPhone uygulaması için bile alakalı mı? SQLite ile çalışır?
bpapa

1
Ayrıca kullanıcılarınızın bir ağ üzerinden veri paylaşmasını istiyorsunuz. SQL lite ile ne yapıyorsunuz?
Bryan

"MonoTouch, hibrit bir .NET 2.0 ve Silverlight 2 API profilini temel alır" LINQ nesnelere destekleniyor mu?
Chris S

2

Eklemek istediğim bir şey, kabul edilmiş bir cevap olmasına rağmen - Apple'ın sadece Mono Touch ile oluşturulduğunu gösteren uygulamaları reddetmeyeceğini kim söyleyecek?


Kesinlikle yapmalılar ve Flash uygulamalarını da reddetmelidirler, ancak App Store terimleri bunları kullanmayı engellemez.
NSResponder

3
@bpapa - bu tamamen geçerli bir endişe, ancak: 1) Uygulamaları reddetmek için bir neden yok (kullanıcılar uygulamalarının ne ile yazıldığını umursamıyorlar - uygulamaların kendileriyle ilgileniyorlar) ve 2) MonoTouch'ın çok fazla potansiyeli var kurumsal geliştirme için ve bir kurumsal geliştirici hesabınız olduğu sürece, Apple uygulamanızı dağıtmanızı engelleyemez. Ayrıca Apple, Unity ile oluşturulan oyunları kabul eder. Sonuçta, MT kurallara uyar. Apple'ın süreci zaman zaman rastgele görünüyor, ama ... MT kurallara uyar: |
Rory Blyth

1
@bpapa - Bu yorumu bu kadar uzun süre nasıl kaçırdığımı bilmiyorum, ancak: 1) ObjC uygulamalarının tonları, belgelenmemiş ("özel") API'leri kullanmak için "yakalandı" - FB, belirttiğiniz gibi, bunlardan biri olarak, henüz FB hala yaşıyor ve indirilebilir, 2) Unity'nin sorunu hızla ele alındı ​​ve Unity geri döndü. - Apple kendi eşyalarını kullanmanı istediğinde, katılmıyorum, ama istemek ve talep etmek çok farklı. Kurumsal uygulamalara gelince: MT kurumsal uygulamalarını dağıtabilirsiniz. Onlar sadece yerli ikilikler. Sorunu görmüyorum, neden MT karşıtı olduğunuzu anlamıyorum.
Rory Blyth

1
Ben ObjC sözdizimi "nefret" değil, ama ben C # tercih olduğunu eklemeliyim. .Net çerçevesinin Kakao'ya Giden Yollarını da tercih ediyorum. Dize düzenleme, XML işleme, tarihleri ​​içeren herhangi bir şey vb. - UI çalışması için MT CocoaTouch bağlarını kullanacağım, ancak diğer birçok görev için MT ile birlikte gelen .Net çerçevesinin alt kümesi hayatı çok daha kolay hale getirir. Ben devam (ve derleme zamanında belirli hataları bulma tercihim gibi ) devam edebilir. Apple'ın yığınını eleştiriyorum, ama sevmiyorum. MT ve ObjC / vb.
Rory Blyth

1
Apple zihnini değiştirdi ve şimdi uygulamaları herhangi bir dilde / çerçevede kabul ediyor ve mağazadaki uygulamaları kabul etmek için daha 'objektif' bir kriter listesi oluşturuyor.
Monoman

2

Çoğunlukla böyle sitelerden alabileceğiniz tüm yardımlardan dolayı Objective-C'ye zaman ayırırım. Objective-C'nin güçlü yönlerinden biri, C ve C ++ kodunu kullanabilmenizdir ve orada iyi test edilmiş birçok proje vardır .

Başka bir şey, kodunuzun (seçtiğiniz dil) elma tarafından desteklenmesidir. Örneğin iOS 5.x, MonoTouch gibi bir üçüncü taraf çözümünün desteğini kaldırıyor mu? O zaman müşterilerinize ne söyleyeceksiniz?

Objective-C'ye taşınmaya hazır değilseniz HTML5 gibi platformdan bağımsız bir çözüm kullanmak daha iyi olabilir mi?


MonoTouch kullanarak, Apple'ın çok güçlü izin vermeyi / desteklemeyi bırakabileceği bir satıcıya kilitlendiğinizi iddia ediyorum. Zaten kendi geliştirme platformuna sahip bir Apple'ın merhametinde olan bir platforma yatırım yapabilirsiniz ...
jl.

2

MonoTouch'ı birkaç aydır kullanıyorum, yarı bitmiş uygulamamı ObjectiveC'den taşıdım, böylece gelecekte Android'i destekleyebilirim.

İşte benim deneyimim:

Bozuk bitler:

  • Xamarin Studio. Benim gibi bağımsız geliştiriciler Xamarin Studio'yu kullanmaya zorlanıyor. Her hafta daha iyi oluyor, geliştiriciler hataları belirleyen ve düzelten forumlarda çok aktif, ancak hala çok yavaş, sık sık asılı, çok fazla hata var ve hata ayıklama da oldukça yavaş.

  • Derleme süreleri. Benim Bina büyük bir cihazda debug (bağlantılı) uygulamasını birkaç dakika sürebilir, bu hemen dağıtır hangi XCode ile karşılaştırılır. Simülatör için bina (bağlantısız) biraz daha hızlıdır.

  • MonoTouch sorunları. Olay işlemeden kaynaklanan bellek sızıntısı sorunları yaşadım ve görünümlere girerken ve çıkarken olayları ekleme ve çıkarma gibi sızıntıları önlemek için bazı çirkin geçici çözümler koymak zorunda kaldım. Xamarin geliştiricileri aktif olarak bunun gibi konuları araştırıyor.

  • 3. taraf kütüphaneler. Objective Sharpie gibi otomatik yazılımlarla daha da iyileşiyor olsa da, benim app kullanmak için ObjectiveC kütüphaneleri dönüştürme / bağlama oldukça zaman geçirdim.

  • Daha büyük ikili dosyalar. Bu beni gerçekten rahatsız etmiyor ama bundan bahsedeceğimi düşündüm. IMO birkaç ekstra Mb bugünlerde bir şey değil.

İyi bitler:

  • Çoklu platform. Arkadaşım, temel kod tabanımdan uygulamamın Android sürümünü mutlu bir şekilde oluşturuyor, paralel olarak gelişiyoruz ve Dropbox'ta uzak bir Git deposuna bağlıyız, iyi gidiyor.

  • .Ağ. C # .Net içinde çalışmak Objective C IMO'dan çok daha hoş.

  • MonoTouch. İOS'taki hemen hemen her şey .Net'e yansıtılır ve işlerin çalışmasını sağlamak oldukça kolaydır.

  • Xamarin. Bu adamların gerçekten her şeyi iyileştirmek için çalıştıklarını, gelişimi daha pürüzsüz ve kolay hale getirdiğini görebilirsiniz.

Özellikle Visual Studio ile çalışan Business veya Enterprise sürümlerini kullanmak için paranız varsa, çapraz platform geliştirme için Xamarin'i kesinlikle tavsiye ederim.

Yalnızca başka bir platformda asla gerekli olmayacak bir iPhone uygulaması oluşturuyorsanız ve bir Indie geliştiricisiyseniz, şimdilik XCode ve Objective C ile yapışırdım.


Yukarıdaki cevabımda hızlı bir güncelleme. Daha hızlı bir Mac'e geçildiğinden, yapım sürelerini çok daha hızlı bulduğumdan, hala XCode gibi anında değil ama iyi.
danfordham

1

Hem C # hem de Objective-C ile deneyimi olan biri olarak, çoğu insan için Xamarin iyi paraya değer olacağını söyleyebilirim.

C # gerçekten iyi tasarlanmış bir dildir ve C # API'leri de iyi tasarlanmıştır. Tabii ki Cocoa Touch API'leri (UIKit dahil) de harika bir tasarıma sahip, ancak dil çeşitli şekillerde geliştirilebilir. C # 'da yazarken, aynı kodu Objective-C'de yazmaya kıyasla daha verimli olacaksınız. Bu birkaç nedenden kaynaklanmaktadır, ancak bazı nedenler şunlar olabilir:

  • C #, tür çıkarımına sahiptir . Tür çıkarımı yazma kodunu daha hızlı hale getirir, çünkü ödevin sol tarafındaki türü "bilmek" zorunda kalmazsınız. Ayrıca yeniden düzenlemeyi daha kolay ve daha güvenli hale getirir.

  • C #, eşdeğer Objective-C koduna kıyasla hataları azaltacak jeneriklere sahiptir (Objective-C'de bazı geçici çözümler olsa da, çoğu durumda geliştiriciler bunlardan kaçınır).

  • Son zamanlarda Xamarin, zaman uyumsuz kod yazmayı çok kolaylaştıran Async / Await için destek ekledi .

  • Kod tabanının bir kısmını iOS, Android ve Windows Phone'da yeniden kullanabileceksiniz.

  • MonoTouch, CocoaTouch API'lerini büyük ölçüde basit bir şekilde uygular. Örneğin: CocoaTouch ile ilgili deneyiminiz varsa, MonoTouch'da (MonoTouch.UIKit, UIButton, UIView, UINavigationController, vb. İçin sınıflar içerir, aynı şekilde MonoTouch.Foundation'ın NSString için sınıfları olduğunu, NSData vb.).

  • Xamarin, PhoneGap veya Titanium gibi çözümlerin aksine kullanıcılara yerel bir deneyim sunacak.

Şimdi Objective-C'nin C # üzerinde bazı avantajları vardır, ancak çoğu durumda C # 'da uygulama yazmak genellikle daha az geliştirme süresi ve daha temiz kod ve aynı uygulamayı diğer platformlara taşımak için daha az çalışma ile sonuçlanır. Dikkate değer bir istisna, OpenGL'ye dayanan yüksek performanslı oyunlar olabilir.


-35

MonoTouch kütüphanesinin maliyeti tamamen noktanın yanındadır. İPhone uygulamalarınız için Mono'yu kullanmamanızın nedeni, bir koltuk değneği olmasıdır. Yerel araçları öğrenmekle uğraşmazsanız, ürününüzün indirmeye değer olduğuna inanmak için hiçbir nedenim yok.

Edit: 4/14/2010 MonoTouch ile yazılmış uygulamalar iTunes Store için uygun değil. Bu olması gerektiği gibi. Apple, Mac'te Qt gibi platformlar arası araç kitleri veya Adobe'nin System 7 araç kutusunun kısmi olarak yeniden uygulanmasını kullanarak çok sayıda sığ bağlantı noktası gördü ve uzun ve kısa olanı yeterince iyi değil.


14
Mac OS X için pazar payı çok küçüktür ve bu nedenle iPhone, X-Code ve ObjC ile uğraşmayı düşünmenin tek zorlayıcı sebebidir. Her ikisi de 15+ yıl önce Proje Oluşturucu olduğu zaman ve platform karmaşası ve paketlemesi yaptıklarında harikaydı ama açıkçası - bir dizi platform kullanan biri olarak - tartışmasız daha iyi araçlar ve dillerle, şimdi geliştiricilerin ortak bir güçten yararlanmak istemedikleri pek de şaşırtıcı değil kod tabanı ve alternatif geliştirme araçlarını kullanır. Onların yarattıkları eşit olacak anlamına gelmez.
Iain Collins

37
Bilmiyorum dostum ... Bence Objective-C ve CocoaTouch koltuk değneği. Montaj yazmıyorsanız, çok fazla umursamadığınızı hissedeceğim ve uygulamanızı indirmeyeceğim (çünkü kullanıcıların yaptığı ilk şey, elbette, hangi araçların olduğunu kontrol etmektir. indirdikleri şişkinlik-simülasyon uygulamasını oluştururken kullanılır).
Rory Blyth

3
Andrew, nerede konuştuğunu bilmiyorsun. Objective-C durgun su değildir; Mac, iPhone ve iPad için yerel geliştirme ortamının belkemiğidir.
NSResponder

5
Yani, Apple'ın çerçeveye inşa ettiği bir şeyin basit bir örneğini seçiyor ve üstünlük iddiasında bulunurken, çerçevenin C # eşdeğerinden çok daha karmaşık olan kısımlarını görmezden geliyor musunuz? Bu bir strawman argümanı değil mi?
Andrew Rollings

8
MonoTouch'a geçtim ve şimdiye kadar 4.0'da 47 uygulama yayınladım. Tam zamanlı yapıyorum. Harika, hızlı çalışır. Ben Objective C yazmak için kullanılan ama yazmak için çok daha az kod ile Linq ile daha hızlı C # bulmak.
Ian Vink
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.