Come decidere tra MonoTouch e Objective-C? [chiuso]


273

Dopo aver partecipato a una sessione su Mono in occasione di un evento .Net locale, l'uso di MonoTouch è stato "accennato" come alternativa allo sviluppo di iPhone. Essendo molto a suo agio in C # e .Net, sembra un'opzione allettante, nonostante alcune delle stranezze dello stack Mono. Tuttavia, poiché MonoTouch costa $ 400, sono un po 'sconvolto se questa è la strada da percorrere per lo sviluppo di iPhone.

Qualcuno ha un'esperienza di sviluppo con MonoTouch e Objective-C, e in tal caso lo sviluppo con MonoTouch è molto più semplice e veloce dell'apprendimento di Objective-C, e a sua volta vale $ 400?


13
Penso che molti commenti sul fatto che MonoTouch non sia in grado di funzionare su iOS non siano più validi poiché Apple ha attenuato la limitazione degli strumenti di sviluppo. Vedi: apple.com/pr/library/2010/09/09statement.html
sivabudh

Risposte:


520

Ho visto questa domanda (e variazioni su di essa) molto ultimamente. Ciò che mi stupisce è la frequenza con cui le persone rispondono, ma quanto pochi rispondono .

Ho le mie preferenze (mi piacciono entrambe le pile), ma è qui che la maggior parte delle "risposte" iniziano a sbagliare. Non dovrebbe riguardare ciò che voglio (o ciò che qualcun altro vuole).

Ecco come farei per determinare il valore di MonoTouch: ovviamente non posso essere obiettivo, ma penso che sia abbastanza privo di zelo:

  • È per divertimento o per affari? Se volessi entrare in consulenza in questo settore, potresti recuperare i tuoi $ 399 molto rapidamente.

  • Vuoi imparare la piattaforma al rovescio o vuoi "solo" scrivere app per essa?

  • Ti piace abbastanza .Net che usare uno stack di sviluppo diverso ti farebbe divertire? Ancora una volta, mi piacciono entrambe le pile (Apple e Mono), ma per me MonoTouch rende l'esperienza molto più divertente. Non ho smesso di usare gli strumenti di Apple, ma principalmente perché mi piacciono davvero entrambi gli stack . Adoro l'iPhone e adoro .Net. In quel caso, per me, MonoTouch è stato un gioco da ragazzi.

  • Ti senti a tuo agio a lavorare con C? Non intendo Objective-C, ma C - è importante perché Objective-C è C. È una versione OO simpatica, elegante e amichevole, ma se i puntatori ti danno i heebie-jeebies, MonoTouch è tuo amico. E non ascoltare gli oppositori che pensano che tu sia un fan degli sviluppatori se succede che non ti piacciono i puntatori (o C, ecc.). Ero solito andare in giro con una copia di IBM ROM BIOS Pocket Reference, e quando stavo scrivendo assembly e costringendo il mio computer a divertenti modalità video e scrivendo i miei bit di rendering dei font per loro e, ammettendo, i sistemi di finestre, non lo facevo Penso che gli sviluppatori QuickBasic fossero dei wuss. Lo erouno sviluppatore QuickBasic (oltre al resto). Non cedere mai al nerd machismo. Se non ti piace C, e se non ti piacciono i puntatori, e se vuoi stare il più lontano possibile dalla gestione manuale della memoria (e, per essere onesti, non è affatto male in ObjC), allora. .. MonoTouch. E non prenderti in giro.

  • Desideri scegliere come target utenti o aziende? Non importa molto per me, ma ci sono ancora persone là fuori su Edge, e il fatto è: puoi creare un pacchetto di download molto più piccolo se usi lo stack di Apple. Ho giocato con MonoTouch e ho una piccola app decente che, una volta compressa, scende a circa 2,7 MB (quando si invia l'app per la distribuzione, la si comprime - quando le app vengono scaricate dallo store, esse ' re zippato - quindi quando capisci se la tua app arriverà sotto il limite OTA di 10 MB, chiudi prima la cerniera - rimarrai piacevolmente sorpreso da MonoTouch). Ma a parte la felicità di MT, mezzo mega contro quasi tre (per esempio) è qualcosa che potrebbe essere importante per te se stai prendendo di mira gli utenti finali. Se stai pensando al lavoro aziendale, pochi MB non contano affatto. E, solo per essere chiari - invierò presto un'app basata su MT allo store e non ho alcun problema con le dimensioni. Non mi disturba affatto. Ma se è qualcosa che potrebbe interessaretu , allora lo stack di Apple vince questo.

  • Funziona XML? MonoTouch. Periodo.

  • Manipolazione delle stringhe? Manipolazione della data? Un milione di altre piccole cose a cui ci siamo abituati con i framework .Net tutto-E-il-lavello della cucina? MonoTouch.

  • Servizi web? MonoTouch.

  • Sintatticamente, entrambi hanno i loro vantaggi. Objective-C tende ad essere più dettagliato dove devi scriverlo . Ti ritroverai a scrivere codice con C # che non dovresti scrivere con ObjC, ma va in entrambe le direzioni. Questo particolare argomento potrebbe riempire un libro. Preferisco la sintassi C #, ma dopo aver superato la mia reazione iniziale, questo ultraterreno, all'Obiettivo-C, ho imparato a divertirmi un po '. Mi diverto un po 'nei discorsi ( è strano per gli sviluppatori che sono abituati a C # / Java / ecc.), Ma la verità è che ho un punto a forma di Obiettivo-C nel mio cuore che mi rende felice.

  • Intendi utilizzare Interface Builder? Perché, anche in questa prima versione, mi ritrovo a fare molto meno lavoro per costruire le mie UI con IB e poi usarle nel codice. Sembra che nel modo Objective-C / IB manchino interi passi, e sono quasi sicuro che manchino interi passi nel modo Objective-C / IB. Finora, e non credo di aver provato a sufficienza, ma finora , MonoTouch è il vincitore qui per quanto meno lavoro devi fare.

  • Pensi che sia divertente imparare nuove lingue e piattaforme? In tal caso, l'iPhone ha molto da offrire e lo stack di Apple probabilmente ti farà uscire dalla tua zona di comfort - che, per alcuni sviluppatori, è divertente (Ciao - Sono uno di quegli sviluppatori - Ci scherzo e do Apple è un momento difficile, ma mi sono divertito molto a imparare lo sviluppo dell'iPhone attraverso gli strumenti di Apple).

Ci sono così tante cose da considerare. Il valore è così astratto. Se parliamo di costi e se ne vale la pena, la risposta arriva al mio primo punto elenco: se questo è per affari e se riesci a ottenere il lavoro, ti farai guadagnare i soldi.

Quindi ... questo è il più obiettivo possibile. Questa è una breve lista di ciò che potresti chiederti, ma è un punto di partenza.

Personalmente (lasciamo cadere l'oggettività per un momento), adoro e uso entrambi. E sono contento di aver imparato prima lo stack Apple. Per me è stato più semplice iniziare a utilizzare MonoTouch quando già conoscevo il mondo di Apple. Come altri hanno già detto, continuerai a lavorare con CocoaTouch - sarà solo in un ambiente .Net.

Ma c'è di più. Le persone che non hanno usato MonoTouch tendono a fermarsi qui - "È un wrapper blah blah blah" - non è MonoTouch.

MonoTouch ti dà accesso a ciò che CocoaTouch ha da offrire dandoti anche l'accesso a ciò che (un sottoinsieme di) .Net ha da offrire, un IDE con cui alcune persone si sentono più a proprio agio (io sono uno di loro), una migliore integrazione con Interface Builder e sebbene non ti dimentichi completamente della gestione della memoria, ottieni un buon margine di manovra.

Se non sei sicuro, prendi lo stack di Apple (è gratuito) e prendi lo stack di MonoTouch eval (è gratuito). Fino a quando non ti unirai al programma di sviluppo di Apple, entrambi funzioneranno solo contro il simulatore, ma è abbastanza per aiutarti a capire se preferisci enormemente l'uno all'altro e possibile se MonoTouch valga, per te, il valore di $ 399.

E non ascoltare gli zeloti: tendono ad essere quelli che non hanno usato la tecnologia contro cui stanno correndo :)


50
Wow, Rory, grazie per aver dedicato del tempo a rispondere alla mia domanda in modo così dettagliato. Da quello che posso dire che sei l'unico che ha usato entrambe le opzioni, da chi cercavo una risposta. Da lì proverò sicuramente entrambi. A proposito, ti ho sentito sul podcast SO più recente, giusto? Roba buona. Grazie ancora!
Jamesaharvey,

17
Grazie per i commenti :) Mi sono frustrato con l'odiare un istante che ho visto. Più e più volte si risponde alla domanda con "Ur una scema idiota per rompere il sistema opurante prima più sciolto !! ??" Che è inutile e offensivo. MonoTouch ha i suoi punti difficili, ma quei ragazzi hanno una storia di genio. MT è avanzato rapidamente ed è più bello ogni giorno. Continuo a dire: dagli un paio di mesi. Sono prudenti riguardo alle funzionalità, ma penso che vedremo grandi cose. Adoro lo stack di Apple, ma ora ho un altro parco giochi - è una buona cosa e sono stordito :)
Rory Blyth,

4
@Stephan - Potrebbe non essere giusto dire cosa manca "- Posso fare il lavoro con Cocoa. Riguarda maggiormente le API. È molto più semplice lavorare con stringhe, date, XML, ecc. Con .Net. Non so se hai familiarità con il modo .Net di fare queste cose, così come l'estensione del supporto di MonoTouch per loro - se non lo hai guardato, dovresti - solo per provarlo. Non intendo dire che ci sono cose che non puoi fare con Cocoa, ma ci sono molte cose che sono molto più facili da fare con .Net. L'analisi è più semplice su tutta la linea - la matematica della data è più semplice su tutta la linea - ecc.
Rory Blyth

3
Inoltre c'è il problema del riutilizzo del proprio codice nell'iPhone / iPad con MT. Abbiamo un po 'di codice crittografico e codice di logica aziendale, in esecuzione sui nostri server e controparti desktop, che potremmo semplicemente ricompilare con MT e utilizzare nella nostra app client iOS. Questo può essere importante per alcuni progetti.
Monoman,

2
Vale anche la pena considerare il fatto che, sebbene la licenza costa $ 400, c'è anche un abbonamento di manutenzione che è necessario rinnovare (per ovvi motivi) ogni anno - $ 250. È probabilmente un prezzo equo, ma vale comunque la pena prendere in considerazione.
Amc_rtty,

62

C'è molto sentito dire in questo post da sviluppatori che non hanno provato MonoTouch e Objective-C. Sembra essere principalmente sviluppatori Objective-C che non hanno mai provato MonoTouch.

Sono ovviamente di parte, ma puoi vedere cosa ha fatto la community di MonoTouch:

http://xamarin.com

Lì troverai diversi articoli di sviluppatori sviluppati in Objective-C e C #.


29
@NSResponder - Hai usato MonoTouch? È una versione v1.x, praticamente nuova di zecca ed è già sorprendente. Provalo prima di commentarlo. Ci sono grandi cambiamenti (la sua integrazione con Interface Builder è di gran lunga migliore di quella di Xcode) e ci sono piccoli cambiamenti (confronta il modo ObjC / Cocoa di ottenere la cartella documenti dell'utente rispetto a quella di MT, per esempio). Uso ancora lo stack di Apple per alcune cose, ma MT è bello e pieno di potenzialità. Seriamente, provalo. Oppure guarda come sono state legate le API di Cocoa - non devi usarlo - semplicemente non cestinare il lavoro senza conoscerlo .
Rory Blyth,

Sì! Inoltre, alcune delle nuove funzionalità di C # 5.0 rendono la codifica ancora più divertente rispetto a goal-c.
Harsimranb,

39

Quindi, la mia risposta a una precedente domanda simile è imparare Objective-C. (Inoltre, non dimenticare il supporto per il debug)

Questo probabilmente offenderà alcuni, ma ad essere onesti, se hai intenzione di fare uno sviluppo serio, dovresti imparare Objective-C. Non conoscere Objective-C nello sviluppo di iPhone sarà solo un ostacolo. Non sarai in grado di comprendere molti esempi; devi affrontare le stranezze di Mono, mentre se avessi una conoscenza pratica di Objective-C potresti ottenere molto di più dalla documentazione della piattaforma.

Personalmente, non capisco la posizione che dice che aumenta la quantità di informazioni necessarie a favore dell'utilizzo di Mono sulla lingua madre della piattaforma. Mi sembra controproducente. Penso che se questa è una proposta molto costosa (apprendimento di una nuova lingua), potrebbe valere la pena dedicare un po 'di tempo a concetti di programmazione fondamentali in modo che l'apprendimento di nuove lingue sia una proposta abbastanza economica.

Un altro utente ha anche scritto questo:


Monotouch è più facile per te ora. Ma più difficile dopo.

Ad esempio, cosa succede quando escono nuovi semi che devi provare ma rompere MonoTouch per qualche motivo?

Rimanendo con Mono, ogni volta che cerchi risorse per i framework devi tradurre mentalmente come li userai con Mono. I file binari delle tue app saranno più grandi, il tuo tempo di sviluppo non sarà molto più veloce dopo alcuni mesi in Objective-C e altri sviluppatori di app avranno un vantaggio molto maggiore su di te perché utilizzano la piattaforma nativa.

Un'altra considerazione è che stai cercando di usare C # perché hai più familiarità con il linguaggio di Objective-C. Ma la stragrande maggioranza della curva di apprendimento per l'iPhone non è Objective-C, sono i framework - che dovrai chiamare anche con C #.

Per qualsiasi piattaforma, dovresti usare la piattaforma che esprime direttamente la filosofia progettuale di quella piattaforma - su iPhone, ovvero Objective-C. Pensateci dal punto di vista opposto, se uno sviluppatore Linux abituato alla programmazione in GTK volesse scrivere app per Windows raccomandereste seriamente di non usare C # e attenersi a GTK perché per loro era "più facile" farlo?



12
Probabilmente hai involontariamente travisato MT. Non è affatto - non da remoto - analogo all'utilizzo di GTK per scrivere app Win. Le associazioni di MT sono molto fedeli a CocoaTouch. In realtà sono migliorate su alcune convenzioni dell'API CT. Ma non stai scrivendo le tue app usando, diciamo, un'astrazione basata su Windows Form su CT. MT con MonoDevelop ha una migliore integrazione con IB rispetto a Xcode (se lo desideri) e spesso puoi fare le stesse cose a metà del codice o meno. Le dimensioni binarie vengono migliorate e gli strumenti (generatore di rilegatura, ecc.) Sono sempre migliori. Un'app MT è un'app nativa.
Rory Blyth,

7
Per dare esempi piuttosto che aspettarti che tu prenda da solo la mia (ovviamente) opinione di MT-fanboy, posso fare cose come (e questo è solo un sottoinsieme di vantaggi per adolescenti): Creare una proprietà con una riga; prendi un riferimento alla cartella Documenti senza una ridicola spelunking di array (un'app ha una cartella documenti, sempre nello stesso posto - perché tutto il lavoro extra per "trovarla"?); usa il framework .Net dove puzza Cocoa (NSDate, chiunque?); utilizzare le competenze sui prodotti per le app aziendali; usa bit XML propri e moderni (mi piace quando Cocoa soffoca silenziosamente i personaggi e si ferma , senza crash, si ferma ).
Rory Blyth,

8
Non dicendo che lo userei per tutto. Mi piace ObjC e lo uso ancora. E, se le prestazioni sono un problema, ho un controllo più granulare su ciò che sta succedendo. Ma ... ci sono momenti in cui MT avrà più senso e penso che renderà l'iPhone un'opzione praticabile per lo sviluppo aziendale. Lancia un sasso in aria e colpirai un dev .Net. La maggior parte delle aziende non ha sviluppatori ObjC interni. E per il lavoro aziendale, non dovrebbero farlo. MT è molto più semplice per lavorare con servizi Web e DB. Puoi davvero scrivere molti tipi di app con MT con metà del codice che prenderebbe in ObjC.
Rory Blyth,

8
Infine (potrei continuare, ma penso che sto facendo il punto mt), le modifiche che "rompono" MonoTouch hanno probabilmente le stesse probabilità di rompere le app ObjC. Una volta che la tua app è nel negozio, è un'app nativa per iPhone (come deve essere). Alla fine le chiamate non sono diverse: lo stesso runtime delle app costruite con lo stack di Apple. Se l'app MT si interrompe a causa di una modifica dell'ambiente di runtime, lo saranno anche le app create con ObjC. E il team di MT è stato in cima a queste cose, rilasciando rapidamente aggiornamenti e correzioni di bug. I collegamenti di MT sono abbastanza vicini a quelli di CT che la probabilità di problemi reali è bassa. Aight - Adesso sto zitto :)
Rory Blyth il

27

L'uso di Mono non è una stampella. Ci sono molte cose che aggiunge al sistema operativo iPhone. LINQ, WCF, codice condivisibile tra un'app Silverlight, una pagina ASP.NET, un'app WPF, un'app di Windows Form e c'è anche mono per Android e funzionerà anche per Windows Mobile.

Quindi, puoi dedicare un sacco di tempo a scrivere Objective-C (vedrai da molti studi in cui lo stesso codice di esempio esatto in C # è significativamente inferiore per scrivere rispetto a OC) e quindi DUPLICARE tutto per altre piattaforme. Per me, ho scelto MonoTouch perché l'app Cloud che sto scrivendo avrà molte interfacce, l'iPhone è solo una di queste. Avere lo streaming di dati WCF dal cloud all'app MonoTouch è follemente semplice. Ho librerie core che sono condivise tra le varie piattaforme e quindi ho solo bisogno di scrivere un semplice livello di presentazione per le distribuzioni iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Ricreare tutto in Objective-C sarebbe un'enorme perdita di tempo sia per lo sviluppo iniziale che per la manutenzione, poiché il prodotto continua ad andare avanti poiché tutte le funzionalità dovrebbero essere replicate anziché riutilizzate.

Le persone che stanno insultando MonoTouch o insinuando che gli utenti hanno bisogno di una stampella mancano del quadro generale di ciò che significa avere il framework .NET a portata di mano e forse non capiscono la corretta separazione della logica dalla presentazione in un modo che può essere riutilizzato su piattaforme e dispositivi.

Objective-C è interessante e molto diverso da molti linguaggi comuni. Mi piace una sfida e l'apprendimento di approcci diversi ... ma non in questo modo impedisce i miei progressi o crea ricodifiche inutili. Ci sono alcune cose davvero straordinarie sul framework SDK per iPhone, ma tutta quella grandezza è pienamente supportata da MonoTouch e taglia tutta la gestione manuale della memoria, riduce la quantità di codice richiesta per eseguire le stesse attività, mi permette di riutilizzare i miei assembly e mantiene aperte le mie opzioni per poter passare ad altri dispositivi e piattaforme.


19

Ho cambiato. Monotouch fammi scrivere app almeno 3-4 volte più velocemente (4 app al mese rispetto al mio vecchio 1 al mese in Obj C)

Molto meno digitando.

Solo la mia esperienza.


2
"4 app al mese" - Quando la quantità è più importante della qualità. MT è come McDonalds. Ma ottieni cibo migliore al ristorante XCode.
netshark1000,

2
I risultati però parlano in modo diverso, Rdio e iCircuit sono app MT dimostrate da Steve Jobs. C # e MT si liberano del lavoro idraulico che obj-C ti costringe a fare.
Ian Vink,

17

Se questa è l'unica app per iPhone che svilupperai mai e hai anche zero interesse nello sviluppo di applicazioni Mac, allora MonoTouch probabilmente vale il costo.

Se pensi che svilupperai mai più app per iPhone, o vorrai mai fare un po 'di sviluppo nativo per Mac, probabilmente vale la pena imparare Objective-C e i framework associati. Inoltre, se sei il tipo di programmatore a cui piace imparare cose nuove, è un nuovo paradigma divertente da studiare.


6
Se questa è l'unica app per iPhone che svilupperai, anche i $ 99 / anno non ne valgono la pena.
Dinah,

Puoi utilizzare gli stessi strumenti di sviluppo C # per creare app per Mac. In effetti puoi condividere il codice tra le app per iPhone C # e Mac C #. Ora MonoTouch si chiama Xamarin
Ian Vink il

9

Personalmente penso che ti divertirai solo imparando Objective-C.

In breve:

  • "Learning Objective-C" non è scoraggiante come potresti pensare, potresti persino godertelo dopo solo le prime settimane
  • Hai già familiarità con la sintassi "stile C" con molti * & () {}; ovunque
  • Apple ha fatto un ottimo lavoro nel documentare le cose
  • Interagirai con l'iPhone come previsto da Apple, il che significa che otterrai i benefici direttamente dalla fonte e non attraverso alcuni filtri.

Ho scoperto che i progetti come Unity e MonoTouch dovrebbero "farti risparmiare tempo" ma alla fine dovrai comunque imparare la loro lingua specifica del dominio e, a volte, dovrai fare un passo avanti. Probabilmente tutto ciò ti richiederà quanto basta per imparare la lingua che stavi cercando di evitare di apprendere (in tempo di calendario). Alla fine non hai risparmiato tempo e sei strettamente associato ad alcuni prodotti.

EDIT: Non ho mai avuto intenzione di implicare qualcosa di negativo su .NET. Mi capita di esserne un grande fan. Il punto è che aggiungere più livelli di complessità solo perché non ti senti ancora a tuo agio con la bizzarra notazione di parentesi objc non ha molto senso per me.

Aggiornamento 2019: sono trascorsi 7 anni. Mi sento ancora allo stesso modo, se non di più. Certo, "linguaggio specifico del dominio" potrebbe essere stato il termine sbagliato da usare, ma credo ancora che sia molto meglio scrivere direttamente per la piattaforma con cui stai lavorando ed evitare il più possibile livelli di compatibilità e astrazioni. Se sei preoccupato per il riutilizzo e la rielaborazione del codice, in generale qualsiasi funzionalità che la tua app multipiattaforma deve eseguire può probabilmente essere realizzata con le moderne tecnologie web.


12
Prima di tutto, C # non è un "linguaggio specifico di dominio" - tutt'altro. È un'abilità di merce. Fa parte del valore di MonoTouch. Si potrebbe sostenere (ingiustamente e in modo inesatto) che ObjC è un DSL in quanto la maggior parte degli sviluppatori (al di fuori dei laboratori universitari e delle finanze) lo utilizzerà sempre e solo per lo sviluppo di OS X o iPhone. Ma non lo è. Come C #, è un linguaggio versatile che praticamente esiste per permetterti di concentrarti sui framework piuttosto che sul linguaggio stesso (penso che siamo d'accordo lì). Ma tieni presente che il tuo codice ObjC si romperà con gli aggiornamenti Apple. Questo non è un problema specifico di MT.
Rory Blyth,

3
MT potrebbe anche salvarti in alcuni casi perché c'è questo strato di astrazione. Apple modifica un'API? Bene, la tua app ObjC e la tua app MT equivalente (supponiamo che esista) si romperanno. I ragazzi di MT potrebbero rilasciare una soluzione di stopgap per modificare il modo in cui l'API MonoTouch gestisce la chiamata dietro le quinte. Il tuo codice MT non dovrebbe cambiare - potresti semplicemente ricostruire contro la versione MT di stopgap. Sì: questa è una soluzione sporca che potrebbe facilmente portare a problemi, ma deprecare correttamente l'API MT di stopgap darebbe agli sviluppatori il tempo di gestire la modifica senza problemi e guadagnare tempo per una soluzione reale .
Rory Blyth,

4
Inoltre, nuovo com'è MT, è ancora più semplice creare i propri attacchi, se necessario (MT 1.2). Non sei completamente dipendente dagli sbirri di MT per fare tutto quel lavoro (anche se lo stanno facendo), e non lo sono mai stato. Hanno modi estremamente semplici di creare associazioni. Espongono abbastanza del runtime di ObjC con i framework MT che non sei bloccato nel loro modo di fare le cose. Ho reimplementato i collegamenti solo per vedere se mi piace la mia strada migliore. Puoi ignorare i framework MT e inviare e ricevere messaggi "manualmente" se vuoi, e ci vuole poco codice. Sono persone intelligenti. Fidati di loro :)
Rory Blyth,

2
Penso che slf non sia a conoscenza del fatto che Monotouch è solo C # (con GC) che si collega direttamente alle librerie ObjC + librerie .NET opzionali. Quindi usi ancora l'API fornita da Apple. Ma con una sintassi più ordinata e la raccolta dei rifiuti.
basarat,

4

Per aggiungere ciò che altri hanno già detto (bene!): La mia sensazione è che stai praticamente raddoppiando il numero di bug di cui ti devi preoccupare, aggiungendo quelli in MonoTouch a quelli già presenti nel sistema operativo iPhone. L'aggiornamento per le nuove versioni del sistema operativo sarà ancora più doloroso del normale. Yuck, tutto intorno.

L'unico caso interessante che posso vedere per MonoTouch sono le organizzazioni che hanno un sacco di programmatori C # e codice C # in giro che devono sfruttare su iPhone. (Il tipo di negozio che non batterà nemmeno le palpebre a $ 3500.)

Ma per chiunque inizi da zero, non riesco davvero a vederlo come utile o saggio.


-1: Cosa intendi con "più bug"? Esiste un'evidente discrepanza di impedenza tra Mono e Objective-C?
Jim G.

4

Tre parole: Linq a SQL

Sì, vale la pena $.


4
Con i Key-Value Bindings e Core Data di Objective-C ottieni qualcosa di molto simile a Linq-to-SQL. Non lo stesso. Forse non è altrettanto potente - ma copre molto dello stesso terreno. Si noti che Core-Data non è attualmente supportato da
MonoTouch

Linq to SQL è rilevante anche per un'app per iPhone? Funziona con SQLite?
bpapa,

1
E vuoi che i tuoi utenti condividano i dati su una rete. Cosa stai facendo con SQL Lite?
Bryan,

"MonoTouch si basa su un profilo API .NET 2.0 e Silverlight 2 ibrido" LINQ to gli oggetti è supportato?
Chris S,

2

Qualcosa che vorrei aggiungere, anche se c'è una risposta accettata: chi può dire che Apple non rifiuterà solo le app che hanno segni di essere costruite con Mono Touch?


Dovrebbero certamente, e dovrebbero anche rifiutare le app Flash, ma i termini dell'App Store non precludono il loro utilizzo.
NSResponder,

3
@bpapa - questa è una preoccupazione totalmente valida, ma: 1) Non c'è motivo di rifiutare le app (agli utenti non importa con cosa sono scritte le loro app - si preoccupano delle app stesse), e 2) MonoTouch ha molto potenziale per lo sviluppo aziendale e finché hai un account di sviluppo aziendale, Apple non può impedirti di distribuire la tua app. Inoltre, Apple accetta giochi creati con Unity. Alla fine, MT segue le regole. Il processo di Apple a volte sembra casuale, ma ... MT segue le regole: |
Rory Blyth,

1
@bpapa - Non so come ho perso questo commento per così tanto tempo, ma: 1) Tonnellate di app ObjC vengono "sballate" per l'utilizzo di API non documentate ("private") - FB, come hai notato, essendo ancora una di queste FB è ancora vivo e disponibile per il download, 2) Il problema di Unity è stato risolto rapidamente e Unity è tornato là fuori. - Per quanto riguarda Apple che desidera che tu usi le proprie cose, non sarei in disaccordo, ma voglio e richiedo sono molto diversi. Per quanto riguarda le app aziendali: è possibile distribuire app enterprise MT. Sono solo binari nativi. Non vedo il problema, né capisco perché sei così anti-MT.
Rory Blyth,

1
Dovrei aggiungere che non è che "odio" la sintassi di ObjC, ma che preferisco di gran lunga C #. Preferisco anche i modi del framework .Net a quelli di Cocoa. Manipolazione di stringhe, elaborazione di XML, qualsiasi cosa che coinvolga date, ecc. - Userò i binding MT CocoaTouch per il lavoro dell'interfaccia utente, ma per la maggior parte delle altre attività, il sottoinsieme del framework .Net fornito con MT semplifica la vita. Potrei andare avanti all'infinito (come la mia preferenza per trovare alcuni bug in fase di compilazione ). Sono critico nei confronti dello stack di Apple, ma non mi dispiace. È possibile apprezzare MT e ObjC / ecc.
Rory Blyth,

1
Apple ha cambiato idea e ora accetta app in qualsiasi lingua / framework e stabilisce un elenco più "oggettivo" di criteri per l'accettazione delle app nello store.
Monoman,

2

Vorrei investire il tempo in Objective-C principalmente a causa di tutto l'aiuto che puoi ottenere da siti come questo. Uno dei punti di forza di Objective-C è che puoi usare il codice C e C ++ e ci sono molti progetti là fuori che sono ben testati .

Un'altra cosa è che il tuo codice (lingua preferita) sarà supportato da apple. Che cosa iOS 5.x ad esempio rimuove il supporto per una soluzione di terze parti come MonoTouch? Cosa dirai ai tuoi clienti allora?

Forse è meglio usare una soluzione indipendente dalla piattaforma come HTML5 se non sei completamente pronto per passare a Objective-C?


Trovo l'argomento secondo cui utilizzando MonoTouch si viene bloccati in un fornitore che Apple potrebbe interrompere per consentire / supportare molto forte. Potresti finire per investire in una piattaforma che è in balia di una Apple che ha la sua piattaforma di sviluppo comunque ...
jl.

2

Sto usando MonoTouch da alcuni mesi, ho portato la mia app per metà da ObjectiveC in modo da poter supportare Android ad un certo punto in futuro.

Ecco la mia esperienza:

Bit errati:

  • Xamarin Studio. Gli sviluppatori indipendenti come me sono costretti a utilizzare Xamarin Studio. Sta migliorando ogni settimana, gli sviluppatori sono molto attivi nei forum per identificare e correggere i bug, ma è ancora molto lento, spesso si blocca, ha molti bug e anche il debugging è piuttosto lento.

  • Tempi di costruzione. Costruire la mia grande app (collegata) per eseguire il debug su un dispositivo può richiedere alcuni minuti, questo viene confrontato con XCode che viene distribuito quasi immediatamente. Costruire per il simulatore (non collegato) è un po 'più veloce.

  • Problemi di MonoTouch. Ho riscontrato problemi di perdita di memoria causati dalla gestione degli eventi e ho dovuto inserire alcune soluzioni piuttosto brutte per prevenire le perdite, come collegare e scollegare gli eventi quando si entra e si esce dalle viste. Gli sviluppatori di Xamarin stanno esaminando attivamente problemi come questo.

  • Librerie di terze parti. Ho trascorso parecchio tempo a convertire / associare le librerie ObjectiveC da utilizzare nella mia app, anche se questo sta migliorando con software automatizzati come Objective Sharpie.

  • Binari più grandi. Questo non mi disturba davvero, ma ho pensato di menzionarlo. IMO un paio di Mb extra non è niente in questi giorni.

Pezzi positivi:

  • Multi piattaforma. Il mio amico sta felicemente creando una versione Android della mia app dal mio codice base, stiamo sviluppando in parallelo e ci stiamo impegnando in un repository Git remoto su Dropbox, sta andando bene.

  • .Netto. Lavorare in C # .Net è molto più bello di Objective C IMO.

  • MonoTouch. Praticamente tutto in iOS è rispecchiato in .Net ed è abbastanza semplice far funzionare le cose.

  • Xamarin. Puoi vedere che questi ragazzi stanno davvero lavorando per migliorare tutto, rendendo lo sviluppo più semplice e agevole.

Consiglio vivamente Xamarin per lo sviluppo multipiattaforma, soprattutto se hai i soldi per usare le edizioni Business o Enterprise che funzionano con Visual Studio.

Se stai solo creando un'app per iPhone che non sarà mai necessaria su un'altra piattaforma, e sei uno sviluppatore Indie, per il momento continuerei con XCode e Objective C.


Un rapido aggiornamento sulla mia risposta sopra. Da quando mi sono trasferito su un Mac più veloce ho trovato che i tempi di costruzione sono molto più rapidi, non è ancora istantaneo come XCode ma va bene.
Danfordham,

1

Come qualcuno con esperienza sia in C # che in Objective-C, direi che per la maggior parte delle persone Xamarin varrà la pena.

C # è un linguaggio davvero ben progettato e anche le API di C # sono ben progettate. Ovviamente anche le API Cocoa Touch (incluso UIKit) hanno un ottimo design, ma il linguaggio potrebbe essere migliorato in diversi modi. Quando scrivi in ​​C # probabilmente sarai più produttivo rispetto a scrivere lo stesso codice in Objective-C. Ciò è dovuto a diversi motivi, ma alcuni potrebbero essere:

  • C # ha l' inferenza del tipo . L'inferenza del tipo rende più veloce la scrittura del codice, poiché non è necessario "conoscere" il tipo sul lato sinistro di un compito. Inoltre, rende il refactoring più semplice e più sicuro.

  • C # ha generici , che ridurranno gli errori rispetto al codice Objective-C equivalente (anche se ci sono alcune soluzioni alternative in Objective-C, nella maggior parte dei casi gli sviluppatori li eviteranno).

  • Recentemente Xamarin ha aggiunto il supporto per Async / Await , il che rende molto semplice la scrittura di codice asincrono.

  • Sarai in grado di riutilizzare parte della base di codice su iOS, Android e Windows Phone.

  • MonoTouch implementa ampiamente le API di CocoaTouch in modo molto semplice. Ad esempio: se hai esperienza con CocoaTouch, saprai dove trovare le classi per i controlli in MonoTouch (MonoTouch.UIKit contiene classi per UIButton, UIView, UINavigationController, ecc ..., allo stesso modo MonoTouch.Foundation ha classi per NSString, NSData, ecc ...).

  • Xamarin offrirà agli utenti un'esperienza nativa, a differenza di soluzioni come PhoneGap o Titanium.

Ora Objective-C presenta alcuni vantaggi rispetto a C #, ma nella maggior parte dei casi la scrittura di app in C # generalmente comporta meno tempo di sviluppo e codice più pulito e meno lavoro per il porting della stessa app su altre piattaforme. Una notevole eccezione potrebbe essere rappresentata dai giochi ad alte prestazioni che si basano su OpenGL.


-35

Il costo della libreria MonoTouch è interamente a parte. Il motivo per cui non dovresti usare Mono per le tue app per iPhone è che è una stampella. Se non ti preoccupi di apprendere gli strumenti nativi, non ho motivo di credere che valga la pena scaricare il tuo prodotto.

Modifica: 14/04/2010 Le applicazioni scritte con MonoTouch non sono idonee per iTunes Store. Questo è come dovrebbe essere. Apple ha visto un sacco di porte poco profonde sul Mac, utilizzando toolkit multipiattaforma come Qt, o la parziale reimplementazione di Adobe della toolbox System 7, e il lungo e il breve è che non sono abbastanza buoni.


14
La quota di mercato per Mac OS X è molto ridotta e quindi l'iPhone è per molti l'unico motivo convincente per prendere in considerazione l'idea di preoccuparsi di X-Code e ObjC. Entrambi sono stati fantastici oltre 15 anni fa quando era Project Builder e faceva complicazione e packaging multipiattaforma ma francamente - come qualcuno che utilizza una gamma di piattaforme - con strumenti e linguaggi probabilmente migliori là fuori ora non è sorprendente che gli sviluppatori vogliano sfruttare un base di codice e utilizzare strumenti di sviluppo alternativi. Ciò non implica che le loro creazioni saranno al di sotto della media.
Iain Collins,

37
Non lo so, amico ... Penso che Objective-C e CocoaTouch siano una stampella. Se non stai scrivendo assembly, sentirò che non ti importava così tanto e non scaricherò la tua app (perché la prima cosa che gli utenti fanno, ovviamente, è controllare quali strumenti erano utilizzato per creare l'app di simulazione di flatulenza che stanno scaricando).
Rory Blyth,

3
Andrew, non sai di cosa parli. Obiettivo-C non è arretrato; è la spina dorsale dell'ambiente di sviluppo nativo per Mac, iPhone e iPad.
NSResponder,

5
Quindi scegli un semplice esempio di qualcosa che Apple ha incorporato nel framework e rivendichi la superiorità, ignorando convenientemente le parti del framework che sono molto più clunkier dell'equivalente C #? Non è forse una discussione da pagliaccio?
Andrew Rollings,

8
Sono passato a MonoTouch e finora ho pubblicato 47 app anche su 4.0. Lo faccio a tempo pieno. Funziona alla grande, veloce. Scrivevo in Objective C ma trovavo C # con Linq più veloce con molto meno codice da scrivere.
Ian Vink,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.