Jak decydować między MonoTouch a Objective-C? [Zamknięte]


273

Po dzisiejszej sesji poświęconej Mono na lokalnym wydarzeniu .Net, wykorzystanie MonoTouch zostało „dotknięte” jako alternatywa dla rozwoju iPhone'a. Będąc bardzo wygodnym w C # i .Net, wydaje się być atrakcyjną opcją, pomimo pewnych dziwactwa stosu Mono. Ponieważ jednak MonoTouch kosztuje 400 USD, jestem nieco rozdarty, jeśli to jest droga do rozwoju iPhone'a.

Czy ktoś ma doświadczenie w programowaniu w MonoTouch i Objective-C, a jeśli tak, to czy programowanie w MonoTouch jest o wiele prostsze i szybsze niż nauka w Objective-C, a co za tym idzie warte 400 $?


13
Myślę, że wiele komentarzy na temat niemożności uruchomienia MonoTouch na iOS nie jest już aktualne, ponieważ Apple złagodziło ograniczenia narzędzi programistycznych. Zobacz: apple.com/pr/library/2010/09/09statement.html
sivabudh

Odpowiedzi:


520

Ostatnio widziałem to pytanie (i jego odmiany). Dziwi mnie to, jak często ludzie reagują, ale jak mało odpowiedzi .

Mam swoje preferencje (podobają mi się oba stosy), ale w tym przypadku większość „odpowiedzi” zaczyna się mylić. Nie powinno dotyczyć tego, czego chcę (ani tego, czego chce ktoś inny).

Oto, w jaki sposób przystąpiłbym do określania wartości MonoTouch - oczywiście nie mogę być obiektywny, ale myślę, że jest to dość wolne od zapału:

  • Czy to dla zabawy czy w interesach? Jeśli chcesz skorzystać z konsultacji w tej dziedzinie, możesz bardzo szybko odzyskać 399 USD.

  • Czy chcesz nauczyć się platformy od podszewki, czy „po prostu” chcesz dla niej pisać aplikacje?

  • Czy podoba Ci się .Net na tyle, że użycie innego stosu deweloperów zabrałoby Ci to przyjemność? Znów lubię oba zestawy (Apple i Mono), ale dla mnie MonoTouch sprawia, że ​​wrażenia są o wiele przyjemniejsze. Nie przestałem używać narzędzi Apple, ale głównie dlatego, że naprawdę lubię oba zestawy . Kocham iPhone'a i kocham .Net. W takim przypadku MonoTouch nie był dla mnie żadnym problemem.

  • Czy czujesz się komfortowo pracując z C? Nie mam na myśli Objective-C, ale C - ma to znaczenie, ponieważ Objective-C to C. Jest to przyjemna, fantazyjna, przyjazna wersja OO, ale jeśli wskazówki dadzą ci gęsią skórkę, MonoTouch jest twoim przyjacielem. I nie słuchaj naysayers, którzy myślą, że jesteś deweloperem, jeśli zdarzy się, że nie lubisz wskaźników (lub C itp.). Kiedyś chodziłem z kopią IBM ROM BIOS Pocket Reference, a kiedy pisałem asembler i zmuszałem komputer do śmiesznych trybów wideo oraz pisałem własne bity do renderowania czcionek i (co prawda tandetne) systemy okienkowe, nie zrobiłem tego. Uważam, że deweloperzy QuickBasic byli złośliwi. Ja byłamprogramista QuickBasic (oprócz reszty). Nigdy nie poddawaj się nerdom machismo. Jeśli nie lubisz C i jeśli nie lubisz wskaźników, i jeśli chcesz trzymać się jak najdalej od ręcznego zarządzania pamięcią (i, szczerze mówiąc, wcale nie jest tak źle w ObjC). .. MonoTouch. I nie bierz za to żadnych żartów.

  • Czy chcesz kierować reklamy do użytkowników lub firm? Nie ma to dla mnie większego znaczenia, ale wciąż istnieją ludzie na Edge, a faktem jest: możesz stworzyć znacznie mniejszy pakiet do pobrania, jeśli używasz stosu Apple. Bawiłem się MonoTouch i mam przyzwoitą małą aplikację, która po skompresowaniu zmniejsza się do około 2,7 MB (podczas przesyłania aplikacji do dystrybucji zamykasz ją - gdy aplikacje są pobierane ze sklepu, „ ponownie spakowane - więc kiedy zastanawiasz się, czy Twoja aplikacja ma wejść poniżej limitu 10 MB OTA, najpierw spakuj przyssawkę - MonoTouch będzie mile zaskoczony). Ale poza szczęściem MT, pół megapiksela w porównaniu do prawie trzech (na przykład) to coś, co może być dla Ciebie ważne, jeśli kierujesz reklamy do użytkowników końcowych. Jeśli myślisz o pracy w przedsiębiorstwie, kilka MB w ogóle nie będzie miało znaczenia. I, dla jasności - wkrótce zamierzam przesłać do sklepu aplikację opartą na MT i nie mam żadnych problemów z rozmiarem. Wcale mi to nie przeszkadza. Ale jeśli to będzie dotyczyłoty , a następnie stos Apple wygrywa ten.

  • Wykonujesz jakąkolwiek pracę XML? MonoTouch. Kropka.

  • Manipulacja ciągiem? Data manipulacji? Milion innych drobiazgów, do których przyzwyczailiśmy się w ramach .NET-wszystko-I-zlewozmywaki kuchenne? MonoTouch.

  • Usługi internetowe? MonoTouch.

  • Składniowo oba mają swoje zalety. Cel C jest bardziej szczegółowy , gdy trzeba go napisać . Przekonasz się, że piszesz kod w C #, którego nie musiałbyś pisać w ObjC, ale działa to w obie strony. Ten konkretny temat może wypełnić książkę. Wolę składnię C #, ale po przejściu przez moją początkową, nieziemską reakcję na Objective-C, nauczyłem się całkiem z tego korzystać. I śmieją się z niego trochę w rozmowach (to jest dziwne dla deweloperów, którzy są przyzwyczajeni do C # / Java / etc.), Ale prawda jest taka, że mam Objective-C w kształcie miejsce w moim sercu, że czyni mnie szczęśliwym.

  • Czy zamierzasz korzystać z Konstruktora interfejsów? Ponieważ nawet w tej wczesnej wersji robię znacznie mniej pracy, aby zbudować moje interfejsy użytkownika przy użyciu IB, a następnie użyć ich w kodzie. Wydaje się, że brakuje całego sposobu wykonywania rzeczy w Objective-C / IB i jestem prawie pewien, że dzieje się tak, ponieważ brakuje wszystkich kroków w sposobie wykonywania rzeczy w Objective-C / IB. Do tej pory i nie sądzę, że wystarczająco przetestowałem, ale do tej pory MonoTouch jest tutaj zwycięzcą o ile mniej pracy musisz wykonać.

  • Czy uważasz, że fajnie jest uczyć się nowych języków i platform? Jeśli tak, iPhone ma wiele do zaoferowania, a stos Apple prawdopodobnie wyciągnie cię ze strefy komfortu - co dla niektórych deweloperów jest fajne (Cześć - jestem jednym z tych deweloperów - żartuję z tego i daję Apple ma trudny czas, ale dobrze się bawiłem, ucząc się programowania iPhone'a za pomocą narzędzi Apple).

Jest tyle rzeczy do rozważenia. Wartość jest tak abstrakcyjna. Jeśli mówimy o kosztach i czy warto, odpowiedź sprowadza się do mojego pierwszego punktu: jeśli chodzi o interesy i jeśli możesz dostać pracę, natychmiast zwrócisz swoje pieniądze.

Więc ... to jest tak obiektywne, jak tylko mogę. Oto krótka lista pytań, które możesz sobie zadać, ale jest to punkt wyjścia.

Osobiście (porzućmy na chwilę obiektywizm), uwielbiam i używam obu. I cieszę się, że nauczyłem się najpierw stosu Apple. Łatwiej było mi zacząć korzystać z MonoTouch, kiedy znałem już świat Apple. Jak powiedzieli inni, nadal będziesz pracować z CocoaTouch - będzie to po prostu środowisko .Net.

Ale jest coś więcej. Ludzie, którzy nie korzystali z MonoTouch, zwykle się na tym kończą - „bla bla bla bla” - to nie jest MonoTouch.

MonoTouch daje dostęp do tego, co CocoaTouch ma do zaoferowania, a jednocześnie daje dostęp do tego, co (podzbiór) .Net ma do zaoferowania, IDE, z którym niektórzy czują się bardziej komfortowo (jestem jednym z nich), lepszą integrację z Konstruktorem interfejsów i chociaż nie zapomnisz całkowicie o zarządzaniu pamięcią, zyskujesz swobodę działania.

Jeśli nie jesteś pewien, chwyć stos Apple (jest bezpłatny) i chwyć stos ewaluacyjny MonoTouch (jest bezpłatny). Dopóki nie dołączysz do programu deweloperskiego Apple, oba będą działały tylko przeciwko symulatorowi, ale to wystarczy, aby dowiedzieć się, czy zdecydowanie wolisz jeden od drugiego, i możliwe, czy MonoTouch jest dla Ciebie wart 399 USD.

I nie słuchaj fanatyków - zwykle to oni nie korzystali z technologii, której się bronią :)


50
Wow, Rory, dziękuję za poświęcenie czasu na tak szczegółowe udzielenie odpowiedzi na moje pytanie. Z tego, co mogę powiedzieć, jesteś jedynym, który skorzystał z obu opcji, od którego szukałem odpowiedzi. Zdecydowanie spróbuję obu. BTW, słyszałem cię w najnowszym podcastu SO, prawda? Dobry towar. Dzięki jeszcze raz!
jamesaharvey

17
Dzięki za komentarze :) Sfrustrowałem się niektórymi nienawiściami do kolan, które widziałem. Ciągle w odpowiedzi na pytanie brzmi: „Ur idiota lurn, aby najpierw oblizać opurujący system !! ??”. Co jest nieprzydatne i obraźliwe. MonoTouch ma swoje ciężkie punkty, ale ci faceci mają genialne osiągnięcia. MT szybko się rozwija i każdego dnia jest piękniejsza. Ciągle powtarzam: dajcie im kilka miesięcy. Ostrożnie podchodzą do funkcji, ale myślę, że zobaczymy wielkie rzeczy. Uwielbiam stos Apple, ale mam teraz inny plac zabaw - to dobrze i mam zawroty głowy :)
Rory Blyth

4
@Stephan - Być może niewłaściwe jest powiedzenie, czego „brakuje” - mogę załatwić sprawę z kakao. To więcej o interfejsach API. O wiele łatwiej jest pracować z ciągami, datami, XML itp. Za pomocą .Net. Nie wiem, czy znasz sposób robienia tych rzeczy .Net, a także zakres wsparcia MonoTouch dla nich - jeśli nie zaglądałeś, powinieneś - po prostu to sprawdzić. Nie chcę powiedzieć, że są rzeczy, których nie można zrobić z Cocoa, ale jest wiele rzeczy, które można znacznie łatwiej zrobić z .Net. Przetwarzanie jest łatwiejsze na całej planszy - matematyka na randkach jest łatwiejsza na całym forum - itp.
Rory Blyth

3
Występuje również problem z ponownym użyciem własnego kodu w iPhonie / iPadzie z MT. Mamy trochę kodu kryptograficznego i kodu logiki biznesowej, działających na naszych serwerach i komputerach stacjonarnych, które możemy po prostu ponownie skompilować z MT i użyć w naszej aplikacji klienckiej na iOS. Może to być ważne w przypadku niektórych projektów.
Monoman

2
Warto również wziąć pod uwagę fakt, że chociaż licencja kosztuje 400 USD, istnieje również subskrypcja serwisowa, którą należy odnawiać (z oczywistych powodów) co roku - 250 USD. To prawdopodobnie uczciwa cena, ale nadal warto ją wziąć pod uwagę.
Amc_rtty

62

W tym poście jest wiele wiadomości od programistów, którzy nie wypróbowali MonoTouch i Objective-C. Wydaje się, że są to głównie programiści Objective-C, którzy nigdy nie próbowali MonoTouch.

Jestem oczywiście stronniczy, ale możesz sprawdzić, co porabiała społeczność MonoTouch:

http://xamarin.com

Znajdziesz tam kilka artykułów od programistów opracowanych zarówno w Objective-C, jak i C #.


29
@NSResponder - Czy korzystałeś z MonoTouch? Jest to wersja v1.x, praktycznie nowa i już jest niesamowita. Wypróbuj, zanim skomentujesz. Są duże zmiany (jego integracja z Konstruktorem interfejsów jest znacznie lepsza niż Xcode) i są niewielkie zmiany (na przykład porównaj sposób ObjC / Cocoa uzyskiwania folderu dokumentów użytkownika w porównaniu do MT). Nadal używam stosu Apple do niektórych rzeczy, ale MT jest piękny i pełen potencjału. Poważnie - po prostu spróbuj. Lub spójrz na to, jak interfejsy API Cocoa zostały powiązane - nie musisz go używać - po prostu nie niszcz pracy bez wiedzy o niej.
Rory Blyth,

Tak! Ponadto niektóre nowe funkcje C # 5.0 sprawiają, że kodowanie jest o wiele przyjemniejsze w porównaniu do celu-c.
harsimranb

39

Zatem moją odpowiedzią na poprzednie podobne pytanie jest poznanie Celu C. (Nie zapomnij także o obsłudze debugowania)

Prawdopodobnie urazi to niektórych, ale szczerze mówiąc, jeśli zamierzasz dokonać poważnego rozwoju, powinieneś nauczyć się Celu C. Brak znajomości Objective-C w rozwoju iPhone'a będzie tylko przeszkodą. Nie będziesz w stanie zrozumieć wielu przykładów; musisz poradzić sobie z dziwactwami Mono, a jeśli posiadasz praktyczną znajomość Celu C, możesz uzyskać znacznie więcej z dokumentacji platformy.

Osobiście nie rozumiem stanowiska, które mówi o zwiększeniu ilości informacji potrzebnych do korzystania z Mono w języku ojczystym platformy. Wydaje mi się to nieco bezproduktywne. Myślę, że jeśli jest to bardzo kosztowna propozycja (nauka nowego języka), warto poświęcić trochę czasu na podstawowe koncepcje programowania, aby nauka nowych języków była dość tanią propozycją.

Inny użytkownik również napisał to:


Monotouch jest teraz dla Ciebie łatwiejszy. Ale trudniej później.

Na przykład, co się stanie, gdy pojawią się nowe nasiona, z którymi musisz przetestować, ale z jakiegoś powodu złamać MonoTouch?

Trzymając się Mono, za każdym razem, gdy szukasz zasobów dla frameworków, musisz mentalnie przełożyć się na sposób, w jaki zamierzasz ich używać w Mono. Twoje pliki binarne aplikacji będą większe, czas programowania nie będzie dużo szybszy po kilku miesiącach w Objective-C, a inni programiści aplikacji będą mieli o wiele większą przewagę nad tobą, ponieważ korzystają z platformy natywnej.

Inną kwestią jest to, że chcesz używać C #, ponieważ znasz język bardziej niż Objective-C. Ale zdecydowana większość krzywej uczenia się dla iPhone'a nie jest Objective-C, to ramy, do których będziesz musiał się również odwoływać za pomocą C #.

Na każdej platformie powinieneś użyć platformy, która bezpośrednio wyraża filozofię projektowania tej platformy - na iPhonie, czyli Objective-C. Pomyśl o tym z odwrotnej strony, jeśli programista Linuksa przyzwyczajony do programowania w GTK chciałby pisać aplikacje dla systemu Windows, czy naprawdę poleciłbyś, aby nie używali C # i trzymali się GTK, ponieważ było im łatwiej?



12
Prawdopodobnie przypadkowo wprowadziłeś w błąd MT. To wcale nie jest - nie zdalnie - analogiczne do używania GTK do pisania aplikacji Win. Wiązania MT są bardzo wierne CocoaTouch. Naprawdę poprawili niektóre konwencje CT API. Ale nie piszesz aplikacji za pomocą, powiedzmy, abstrakcji opartej na Windows Forms nad CT. MT z MonoDevelop ma lepszą integrację z IB niż Xcode (jeśli chcesz) i często możesz zrobić to samo za połowę kodu lub mniej. Rozmiar binarny jest poprawiany, a narzędzia (generator bindowania itp.) Są coraz lepsze. Aplikacja MT to aplikacja natywna.
Rory Blyth,

7
Aby podać przykłady, a nie oczekiwać, że weźmiesz moją (oczywiście) opinię fanowską na MT, mogę robić takie rzeczy (a to tylko drobny zestaw zalet): Utwórz właściwość z jedną linią; pobierz odniesienie do folderu Dokument bez śmiesznego spelunkowania tablicy (aplikacja ma jeden folder docs, zawsze w tym samym miejscu - po co tyle dodatkowej pracy, aby go „znaleźć”?); użyj frameworku .Net, w którym kakao śmierdzi (NSDate, ktoś?); używać umiejętności towarowych do aplikacji korporacyjnych; używaj odpowiednich, nowoczesnych bitów XML (uwielbiam, gdy Cocoa cicho dusi postacie i po prostu zatrzymuje się - bez awarii - po prostu się zatrzymuje )
Rory Blyth,

8
Nie mówię, że użyję tego do wszystkiego. Lubię ObjC i nadal go używam. A jeśli wydajność stanowi problem, mam większą kontrolę nad tym, co się dzieje. Ale ... są chwile, kiedy MT będzie miało większy sens i myślę, że dzięki temu iPhone stanie się realną opcją dla rozwoju przedsiębiorstw. Rzuć kamień w powietrze, a trafisz dewelopera .Net. Większość firm nie ma własnych programistów ObjC. A do pracy w przedsiębiorstwie nie powinny. MT jest znacznie łatwiejsza do pracy z usługami internetowymi i bazami danych. Naprawdę możesz pisać wiele rodzajów aplikacji za pomocą MT z połową kodu, który zajmowałby w ObjC.
Rory Blyth,

8
Wreszcie (mógłbym kontynuować, ale myślę, że mam na myśli mt), zmiany, które „łamią” MonoTouch, prawdopodobnie są równie prawdopodobne, że zepsują aplikacje ObjC. Gdy Twoja aplikacja znajdzie się w sklepie, jest to natywna aplikacja na iPhone'a (tak jak musi być). Połączenia nie są ostatecznie niczym innym - tym samym środowiskiem uruchomieniowym, co aplikacje zbudowane na stosie Apple. Jeśli aplikacja MT ulegnie awarii z powodu zmiany środowiska wykonawczego, podobnie będą aplikacje zbudowane w ObjC. Zespół MT był na czele tego, szybko publikując aktualizacje i poprawki błędów. Wiązania MT są wystarczająco blisko odwzorowane na CT, że prawdopodobieństwo prawdziwych problemów jest niskie. Aight - zamknę się teraz :)
Rory Blyth

27

Używanie Mono nie jest kulą. Jest wiele rzeczy, które dodaje do iPhone OS. LINQ, WCF, wspólny kod między aplikacją Silverlight, stroną ASP.NET, aplikacją WPF, aplikacją Windows Form, a także mono na Androida i będzie działał również na Windows Mobile.

Możesz więc poświęcić sporo czasu na pisanie Objective-C (zobaczysz z wielu badań, gdzie dokładnie ten sam przykładowy kod w C # jest znacznie mniej do napisania niż OC), a następnie DUPLIKUJ to wszystko dla innych platform. Dla mnie wybrałem MonoTouch, ponieważ pisana przeze mnie aplikacja w chmurze będzie miała wiele interfejsów, a iPhone będzie tylko jednym z nich. Przesyłanie danych WCF z chmury do aplikacji MonoTouch jest niesamowicie proste. Mam podstawowe biblioteki, które są współużytkowane przez różne platformy, a następnie muszę tylko napisać prostą warstwę prezentacji dla wdrożeń iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Odtworzenie tego wszystkiego w Objective-C byłoby ogromną stratą czasu zarówno na początkowe tworzenie, jak i konserwację, ponieważ produkt nadal rozwija się, ponieważ cała funkcjonalność musiałaby być replikowana, a nie ponownie wykorzystywana.

Ludzie, którzy obrażają MonoTouch lub sugerują, że jego użytkownicy potrzebują kuli, nie mają dużego obrazu tego, co oznacza mieć platformę .NET na wyciągnięcie ręki i być może nie rozumieją właściwego oddzielenia logiki od prezentacji w sposób, który można ponownie wykorzystać na różnych platformach i urządzeniach.

Cel C jest interesujący i bardzo różni się od wielu popularnych języków. Lubię wyzwanie i uczę się różnych podejść ... ale nie wtedy, gdy to utrudnia moje postępy lub powoduje niepotrzebne ponowne kodowanie. Jest kilka naprawdę świetnych rzeczy na temat frameworku iPhone SDK, ale cała ta wielkość jest w pełni obsługiwana przez MonoTouch i odcina całe ręczne zarządzanie pamięcią, zmniejsza ilość kodu wymaganego do wykonywania tych samych zadań, pozwala mi ponownie używać moich zespołów, i utrzymuje moje opcje otwarte, aby móc przejść na inne urządzenia i platformy.


19

Zmieniłem. Monotouch pozwól mi pisać aplikacje co najmniej 3-4 razy szybciej (4 aplikacje na miesiąc w porównaniu do mojej starej 1 na miesiąc w Obj C)

Dużo mniej pisania.

Po prostu moje doświadczenie.


2
„4 aplikacje na miesiąc” - gdy ważniejsza jest ilość, np. Jakość. MT jest jak McDonalds. Ale dostajesz lepsze jedzenie w XCode-Restaurant.
netshark1000

2
Wyniki mówią jednak inaczej, Rdio i iCircuit to aplikacje MT pokazane przez Steve'a Jobsa. C # i MT pozbywają się prac hydraulicznych, które zmusza cię do wykonania obj-C.
Ian Vink

17

Jeśli jest to jedyna aplikacja na iPhone'a, którą kiedykolwiek stworzysz, a Ty też nigdy nie interesujesz się tworzeniem aplikacji dla komputerów Mac, to prawdopodobnie MonoTouch jest prawdopodobnie warte swojej ceny.

Jeśli sądzisz, że kiedykolwiek opracujesz więcej aplikacji na iPhone'a lub zechcesz zrobić natywne programowanie na Maca, prawdopodobnie warto nauczyć się Celu C i powiązanych platform. Ponadto, jeśli jesteś typem programisty, który lubi uczyć się nowych rzeczy, nauka nowego paradygmatu jest świetną zabawą.


6
Jeśli jest to jedyna aplikacja na iPhone'a, jaką kiedykolwiek stworzysz, 99 USD rocznie nie jest tego warte.
Dinah

Możesz używać tych samych narzędzi programistycznych C # do tworzenia aplikacji Mac. W rzeczywistości można kodować udostępnianie między aplikacjami iPhone C # i Mac C #. MonoTouch nazywa się teraz Xamarin
Ian Vink

9

Osobiście uważam, że lepiej będzie ci się uczyć Celu C.

W skrócie:

  • „Learning Objective-C” nie jest zniechęcającym, jak można by pomyśleć, możesz cieszyć się nim już po kilku pierwszych tygodniach
  • Znasz już składnię „stylu C” z dużą ilością * & () {}; wszędzie
  • Apple wykonało bardzo dobrą robotę dokumentowania
  • Będziesz wchodzić w interakcje z iPhone'em zgodnie z zamierzeniami Apple, co oznacza, że ​​będziesz czerpać korzyści bezpośrednio ze źródła, a nie przez jakiś filtr.

Przekonałem się, że projekty takie jak Unity i MonoTouch mają „oszczędzać czas”, ale ostatecznie i tak będziesz musiał nauczyć się języka specyficznego dla swojej domeny i czasami będziesz musiał iść krok dalej. Wszystko to prawdopodobnie zajmie Ci tyle czasu, ile nauczysz się języka, którego próbujesz uniknąć (w czasie kalendarzowym). W końcu nie oszczędzałeś czasu i jesteś ściśle powiązany z jakimś produktem.

EDYCJA: Nigdy nie chciałem sugerować niczego negatywnego na temat .NET. Jestem wielkim fanem tego. Chodzi mi o to, że dodanie większej liczby warstw złożoności tylko dlatego, że nie czujesz się jeszcze komfortowo z dziwną notacją nawiasową objc, nie ma dla mnie większego sensu.

Aktualizacja 2019: 7 lat później. Nadal czuję to samo, jeśli nie bardziej. Jasne, „język specyficzny dla domeny” może być niewłaściwym terminem, ale nadal uważam, że o wiele lepiej jest pisać bezpośrednio na platformę, z którą pracujesz i unikać warstw kompatybilności i abstrakcji w jak największym stopniu. Jeśli martwisz się o ponowne użycie kodu i jego ponowną pracę, ogólnie rzecz biorąc, jakąkolwiek funkcjonalność, którą musi wykonać aplikacja wieloplatformowa, można prawdopodobnie uzyskać za pomocą nowoczesnych technologii internetowych.


12
Po pierwsze, C # nie jest „językiem specyficznym dla domeny” - wręcz przeciwnie. To umiejętność towarowa. To część wartości MonoTouch. Można argumentować (niesprawiedliwie i niedokładnie), że ObjC jest DSL, ponieważ większość deweloperów (poza finansami i laboratoriami uniwersyteckimi i piwnicami) będzie go używać tylko do opracowywania systemu OS X lub iPhone'a. Ale tak nie jest. Podobnie jak C #, jest to uniwersalny język, który zasadniczo istnieje, abyś mógł skupić się na frameworkach, a nie na samym języku (myślę, że się tam zgadzamy). Pamiętaj jednak, że Twój kod ObjC zepsuje się wraz z aktualizacjami Apple. To nie jest problem związany z MT.
Rory Blyth,

3
MT może nawet uratować cię w niektórych przypadkach, ponieważ istnieje ta warstwa abstrakcji. Apple modyfikuje interfejs API? Cóż, twoja aplikacja ObjC i Twoja (udawajmy, że istnieje) odpowiednia aplikacja MT ulegnie awarii . MT faceci mogliby wydać rozwiązanie zatrzymujące, aby zmodyfikować sposób, w jaki MonoTouch API obsługuje połączenie za kulisami. Twój kod MT nie musiałby się zmieniać - możesz po prostu przebudować w stosunku do wydania stopgap MT. Tak: jest to brudna poprawka, która z łatwością może prowadzić do problemów, ale prawidłowe wycofanie stopgap MT API dałoby deweloperom czas na bezproblemową zmianę i kupno czasu na prawdziwą poprawkę.
Rory Blyth,

4
Ponadto, jako że nowy jest MT, w razie potrzeby tworzenie własnych wiązań stało się o wiele łatwiejsze (MT 1.2). Nie jesteś całkowicie zależne od ćwierkania MT robić wszystko, że praca (choć robi, że praca) i nigdy nie było. Mają bardzo proste sposoby tworzenia powiązań. Odsłaniają one wystarczająco dużo czasu działania ObjC z platformami MT, że nie jesteś zablokowany w ich sposobie robienia rzeczy. Ponownie wdrożyłem wiązania, aby zobaczyć, czy bardziej podoba mi się mój sposób. Możesz zignorować ramy MT i wysyłać i odbierać wiadomości „ręcznie”, jeśli chcesz, i to zajmuje niewiele kodu. To mądrzy ludzie. Zaufaj im :)
Rory Blyth,

2
Myślę, że slf nie zdaje sobie sprawy z faktu, że Monotouch to po prostu C # (z GC), który łączy się bezpośrednio z bibliotekami ObjC + opcjonalnymi bibliotekami .NET. Więc nadal korzystasz z API dostarczonego przez Apple. Ale z fajniejszą składnią i wyrzucaniem elementów bezużytecznych.
basarat

4

Aby dodać do tego, co już powiedzieli inni (cóż!): Mam wrażenie, że podwajasz liczbę błędów, o które musisz się martwić, dodając te w MonoTouch do tych, które są już w iPhone OS. Aktualizacja nowych wersji systemu operacyjnego będzie jeszcze bardziej bolesna niż zwykle. Fuj, dookoła.

Jedynym przekonującym przypadkiem, jaki widzę w MonoTouch, są organizacje, które mają mnóstwo programistów C # i kodu C #, które muszą wykorzystać na iPhonie. (Rodzaj sklepu, który nawet nie mrugnie za 3500 $.)

Ale dla każdego, kto zaczyna od zera, naprawdę nie uważam tego za wartościowe ani mądre.


-1: Co rozumiesz przez „więcej błędów”? Czy istnieje rażące niedopasowanie impedancji między Mono a Objective-C?
Jim G.

4

Trzy słowa: Linq do SQL

Tak, to jest warte $.


4
Dzięki powiązaniom klucza i wartości Objective-C i podstawowym danym otrzymujesz coś bardzo podobnego do Linq-to-SQL. Nie ten sam. Może nie tak potężny - ale obejmuje wiele tego samego terenu. Pamiętaj, że Core-Data nie jest obecnie obsługiwany przez MonoTouch
philsquared,

Czy Linq to SQL ma nawet znaczenie dla aplikacji na iPhone'a? Działa z SQLite?
bpapa,

1
I chcesz, aby użytkownicy dzielili się danymi przez sieć. Co robisz z SQL Lite?
Bryan,

„MonoTouch jest oparty na hybrydowym profilu API .NET 2.0 i Silverlight 2” Czy LINQ do obiektów jest obsługiwany?
Chris S

2

Coś, co chciałbym dodać, mimo że istnieje akceptowana odpowiedź - kto ma powiedzieć, że Apple nie tylko odrzuca aplikacje, które mają ślady budowy za pomocą Mono Touch?


Z pewnością powinni i powinni również odrzucić aplikacje Flash, ale ich warunki w App Store nie wykluczają ich używania.
NSResponder

3
@bpapa - to całkowicie uzasadniona obawa, ale: 1) Nie ma powodu, aby odrzucać aplikacje (użytkownicy nie dbają o to, z czym napisane są ich aplikacje - dbają o same aplikacje), oraz 2) MonoTouch ma duży potencjał w zakresie rozwoju korporacyjnego i dopóki masz konto deweloperskie, Apple nie może powstrzymać Cię od rozpowszechniania Twojej aplikacji. Apple akceptuje także gry zbudowane w oparciu o Unity. Ostatecznie MT przestrzega zasad. Proces Apple wydaje się czasami losowy, ale ... MT przestrzega zasad: |
Rory Blyth,

1
@bpapa - Nie wiem, jak bardzo tęskniłem za tym komentarzem, ale: 1) Mnóstwo aplikacji ObjC zostaje „wyeliminowanych” za używanie nieudokumentowanych („prywatnych”) API - FB, jak zauważyłeś, będąc jednym z nich, jeszcze FB wciąż żyje i jest dostępny do pobrania, 2) Problem Unity został szybko rozwiązany, a Unity powrócił. - Jeśli chodzi o to, że Apple chce, abyś używał swoich własnych rzeczy, nie zgodziłbym się, ale chęć i potrzeba są zupełnie inne. Jeśli chodzi o aplikacje dla przedsiębiorstw: możesz wdrożyć aplikacje dla przedsiębiorstw MT. To tylko natywne pliki binarne. Nie widzę problemu ani nie rozumiem, dlaczego jesteś tak przeciwny MT.
Rory Blyth,

1
Powinienem dodać, że nie chodzi o to, że „nienawidzę” składni ObjC, ale że wolę C #. Wolę także metody .Net Framework od Cocoa. Manipulowanie ciągami , przetwarzanie XML, cokolwiek związanego z datami itp. - Użyję powiązań MT CocoaTouch do pracy z interfejsem użytkownika, ale do większości innych zadań podzbiór frameworku .Net dostarczanego z MT znacznie ułatwia życie. Mógłbym bez przerwy (na przykład wolę znaleźć pewne błędy w czasie kompilacji ). Jestem krytyczny wobec stosu Apple, ale go nie lubię. Można polubić MT i ObjC / etc.
Rory Blyth,

1
Apple zmieniło zdanie i teraz akceptuje aplikacje w dowolnym języku / strukturze i określa bardziej „obiektywną” listę kryteriów akceptacji aplikacji w sklepie.
Monoman

2

Zainwestowałbym czas w Objective-C głównie ze względu na całą pomoc, jaką można uzyskać z takich stron. Jedną z mocnych stron Objective-C jest to, że można używać kodu C i C ++, a istnieje wiele dobrze przetestowanych projektów .

Inną rzeczą jest to, że Twój kod (wybrany język) będzie obsługiwany przez Apple. Co to na przykład iOS 5.x usuwa obsługę rozwiązań innych firm, takich jak MonoTouch? Co wtedy powiesz swoim klientom?

Może lepiej jest użyć niezależnego od platformy rozwiązania, takiego jak HTML5, jeśli nie jesteś gotowy do przejścia na Cel C?


Uważam argument, że przy użyciu MonoTouch zostajesz zablokowany na dostawcę, który Apple może przerwać, aby zezwolić / wspierać bardzo silnie. Możesz w końcu zainwestować w platformę, która jest na łasce Apple'a, który i tak ma własną platformę programistyczną ...
jl.

2

Korzystam z MonoTouch od kilku miesięcy, przeniosłem do połowy moją skończoną aplikację z ObjectiveC, aby w przyszłości móc obsługiwać Androida.

Oto moje doświadczenie:

Złe bity:

  • Xamarin Studio. Programiści z Indii, tacy jak ja, są zmuszeni do korzystania z Xamarin Studio. Z każdym tygodniem jest coraz lepiej, programiści są bardzo aktywni na forach, identyfikując i naprawiając błędy, ale wciąż jest bardzo wolny, często zawiesza się, ma wiele błędów i debugowanie jest również dość wolne.

  • Czas budowy Zbudowanie mojej dużej (połączonej) aplikacji do debugowania na urządzeniu może zająć kilka minut, w porównaniu do XCode, który wdraża się niemal natychmiast. Budowanie symulatora (niepowiązane) jest nieco szybsze.

  • Problemy z MonoTouch. Wystąpiły problemy z wyciekiem pamięci spowodowane obsługą zdarzeń i musiałem wprowadzić dość brzydkie obejścia, aby zapobiec wyciekom, takie jak dołączanie i odłączanie zdarzeń podczas wchodzenia i wychodzenia z widoków. Programiści Xamarin aktywnie analizują takie problemy.

  • Biblioteki stron trzecich. Spędziłem sporo czasu na konwertowaniu / wiązaniu bibliotek ObjectiveC do użycia w mojej aplikacji, chociaż jest to coraz lepsze w przypadku zautomatyzowanego oprogramowania, takiego jak Objective Sharpie.

  • Większe pliki binarne. Nie przeszkadza mi to, ale pomyślałem, że o tym wspomnę. IMO kilka dodatkowych Mb to w dzisiejszych czasach nic.

Dobre bity:

  • Wieloplatformowy. Mój przyjaciel z radością tworzy wersję mojej aplikacji na Androida z mojej podstawowej bazy kodu, rozwijamy się równolegle i oddajemy się do zdalnego repozytorium Git na Dropbox, wszystko idzie dobrze.

  • .Netto. Praca w C # .Net jest znacznie ładniejsza niż Objective C IMO.

  • MonoTouch. Prawie wszystko w iOS jest odzwierciedlone w .Net i jest całkiem proste, aby wszystko działało.

  • Xamarin. Widać, że ci faceci naprawdę pracują nad poprawą wszystkiego, dzięki czemu rozwój jest płynniejszy i łatwiejszy.

Zdecydowanie polecam Xamarin do programowania wieloplatformowego, szczególnie jeśli masz pieniądze na korzystanie z wersji Business lub Enterprise współpracujących z Visual Studio.

Jeśli tworzysz wyłącznie aplikację na iPhone'a, która nigdy nie będzie potrzebna na innej platformie, a jesteś programistą niezależnym, trzymałbym się na razie XCode i Objective C.


Szybka aktualizacja mojej odpowiedzi powyżej. Od czasu przejścia na szybszego Maca czasy kompilacji były znacznie szybsze, ale nadal nie jest tak szybki jak XCode, ale jest w porządku.
danfordham

1

Jako osoba z doświadczeniem zarówno w C #, jak i Objective-C, powiedziałbym, że dla większości ludzi Xamarin będzie wart swojej ceny.

C # jest naprawdę dobrze zaprojektowanym językiem, a API C # są również dobrze zaprojektowane. Oczywiście interfejsy API Cocoa Touch (w tym UIKit) mają również świetny wygląd, ale język można poprawić na kilka sposobów. Podczas pisania w C # będziesz prawdopodobnie bardziej produktywny w porównaniu do pisania tego samego kodu w Objective-C. Wynika to z kilku powodów, ale niektóre z nich to:

  • C # ma wnioskowanie typu . Wnioskowanie typu przyspiesza pisanie kodu, ponieważ nie musisz „znać” typu po lewej stronie zadania. Ułatwia to również refaktoryzację i pozwala zaoszczędzić pieniądze.

  • C # ma ogólne , które zmniejszą błędy w porównaniu do równoważnego kodu Objective-C (chociaż istnieją pewne obejścia w Objective-C, w większości sytuacji programiści będą ich unikać).

  • Ostatnio Xamarin dodał obsługę Async / Await , dzięki czemu pisanie kodu asynchronicznego jest bardzo łatwe.

  • Będziesz mógł ponownie wykorzystać część kodu źródłowego na iOS, Android i Windows Phone.

  • MonoTouch w dużej mierze implementuje API CocoaTouch w bardzo prosty sposób. Np .: jeśli masz doświadczenie z CocoaTouch, będziesz wiedział, gdzie znaleźć klasy dla kontrolek w MonoTouch (MonoTouch.UIKit zawiera klasy dla UIButton, UIView, UINavigationController itp.), Podobnie MonoTouch. Fundacja ma klasy dla NSString, NSData itp.).

  • Xamarin zapewni użytkownikom natywną obsługę, w przeciwieństwie do rozwiązań takich jak PhoneGap lub Titanium.

Teraz Objective-C ma pewne zalety w stosunku do C #, ale w większości sytuacji pisanie aplikacji w C # zwykle generuje mniej czasu opracowywania i czystszego kodu oraz mniej pracy przy przenoszeniu tej samej aplikacji na inne platformy. Jednym godnym uwagi wyjątkiem mogą być gry o wysokiej wydajności oparte na OpenGL.


-35

Koszt biblioteki MonoTouch jest całkowicie nie na miejscu. Powodem, dla którego nie powinieneś używać Mono do aplikacji na iPhone'a, jest to, że jest to kula. Jeśli nie możesz niepokoić się nauką natywnych narzędzi, nie mam powodu, by sądzić, że twój produkt jest wart pobrania.

Edycja: 14.04.2010 Aplikacje napisane za pomocą MonoTouch nie kwalifikują się do sklepu iTunes Store. Tak powinno być. Apple widział wiele płytkich portów na Macu, używając wieloplatformowych zestawów narzędzi, takich jak Qt, lub własnej częściowej re-implementacji zestawu narzędzi System 7 firmy Adobe.


14
Udział w rynku Mac OS X jest bardzo mały, więc iPhone jest z wielu jedynych istotnych powodów, dla których warto zastanowić się nad X-Code i ObjC. Oba były świetne ponad 15 lat temu, kiedy to był Project Builder i robił komplikacje międzyplatformowe i pakowanie, ale szczerze mówiąc - jako ktoś, kto korzysta z szeregu platform - z prawdopodobnie lepszymi narzędziami i językami, trudno się dziwić, że programiści chcą wykorzystać wspólny baza kodu i użyj alternatywnych narzędzi programistycznych. Nie oznacza to, że ich kreacje będą poniżej normy.
Iain Collins

37
Nie wiem, stary ... Myślę, że Objective-C i CocoaTouch są kulą. Jeśli nie piszesz asemblera, mam wrażenie, że nie przejmujesz się tym zbytnio i nie zamierzam pobierać Twojej aplikacji (ponieważ pierwszą rzeczą, którą robią użytkownicy, jest oczywiście sprawdzenie, jakie narzędzia były używane do zbudowania pobranej aplikacji symulującej wzdęcia).
Rory Blyth,

3
Andrzej, nie wiesz o czym mówisz. Cel-C nie oznacza cofki; stanowi trzon natywnego środowiska programistycznego dla komputerów Mac, iPhone i iPad.
NSResponder

5
Więc wybierasz jeden prosty przykład czegoś, co Apple wbudowało w strukturę, i twierdzisz, że jest lepszy, jednocześnie wygodnie ignorując te części ramy, które są znacznie bardziej nieprzyzwoite niż odpowiednik C #? Czy to nie jest coś ze słomkowego argumentu?
Andrew Rollings,

8
Przeszedłem na MonoTouch i do tej pory opublikowałem 47 aplikacji na 4.0. Robię to na pełny etat. Działa świetnie, szybko. Kiedyś pisałem w Objective C, ale C # z Linq znajdowałem szybciej i dużo mniej kodu do napisania.
Ian Vink
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.