Como decidir entre o MonoTouch e o Objective-C? [fechadas]

273

Depois de assistir a uma sessão hoje no Mono em um evento .Net local, o uso do MonoTouch foi 'abordado' como uma alternativa para o desenvolvimento do iPhone. Sendo muito confortável em C # e .Net, parece uma opção atraente, apesar de algumas peculiaridades da pilha Mono. No entanto, como o MonoTouch custa US $ 400, estou um pouco decepcionado se esse é o caminho a seguir para o desenvolvimento do iPhone.

Alguém tem uma experiência desenvolvendo com o MonoTouch e o Objective-C e, em caso afirmativo, está desenvolvendo com o MonoTouch muito mais simples e rápido do que aprender o Objective-C e, por sua vez, vale os US $ 400?

c# objective-c mono xamarin.ios jamesaharvey
fonte
13
Eu acho que muitos comentários sobre o MonoTouch não poder ser executado no iOS não são mais válidos, já que a Apple relaxou sua restrição de ferramentas de desenvolvimento. Veja: apple.com/pr/library/2010/09/09statement.html
sivabudh

Respostas:

520

Ultimamente tenho visto essa pergunta (e variações nela). O que me surpreende é a frequência com que as pessoas respondem, mas o número de respostas .

Tenho minhas preferências (gosto das duas pilhas), mas é aqui que a maioria das "respostas" começa a dar errado. Não deve ser sobre o que eu quero (ou o que mais alguém quer).

Aqui está como eu determinaria o valor do MonoTouch - obviamente, não posso ser objetivo, mas acho que isso é bastante isento de zelos:

  • Isso é para diversão ou negócios? Se você quiser entrar em consultoria nessa área, poderá recuperar os seus US $ 399 rapidamente.

  • Deseja aprender a plataforma de dentro para fora ou "apenas" deseja criar aplicativos para ela?

  • Você gosta do .Net o suficiente para usar uma pilha de desenvolvimento diferente para tirar a diversão dele? Mais uma vez, gosto das duas pilhas (Apple e Mono), mas para mim o MonoTouch torna a experiência muito mais divertida. Não parei de usar as ferramentas da Apple, mas é principalmente porque eu realmente gosto das duas pilhas . Eu amo o iPhone e amo .Net. Nesse caso, para mim, o MonoTouch não era acéfalo.

  • Você se sente confortável trabalhando com C? Não me refiro ao Objective-C, mas C - importa porque o Objective-C é C. É uma versão OO agradável, chique e amigável, mas se os indicadores lhe derem heebie-jeebies, o MonoTouch é seu amigo. E não ouça os pessimistas que pensam que você é um covarde, se acontecer de não gostar de ponteiros (ou C, etc.). Eu costumava andar por aí com uma cópia do IBM ROM BIOS Pocket Reference, e quando eu escrevia assembly e forçava meu computador a modos de vídeo engraçados e escrevia meus próprios bits de renderização de fonte para eles e sistemas de janelas (reconhecidamente inúteis), eu não ' acho que os desenvolvedores do QuickBasic eram covardes. Eu estavaum desenvolvedor QuickBasic (além do restante). Nunca ceda ao machismo nerd. Se você não gosta de C e não gosta de ponteiros, e se deseja ficar o mais longe possível do gerenciamento manual de memória (e, para ser justo, não é ruim no ObjC), então. .. MonoTouch. E não se importe com isso.

  • Deseja segmentar usuários ou empresas? Não importa muito para mim, mas ainda existem pessoas no Edge, e o fato é: você pode criar um pacote de download muito menor se usar a pilha da Apple. Ando brincando com o MonoTouch e tenho um pequeno aplicativo decente que, uma vez compactado, fica em torno de 2,7 MB (ao enviar seu aplicativo para distribuição, você o fecha - quando os aplicativos são baixados da loja, eles ' é compactado novamente. Portanto, ao descobrir se seu aplicativo está abaixo do limite de 10 MB da OTA, primeiro aperte o botão - você ficará surpreso com o MonoTouch. Mas, à parte a felicidade do MT, meio megas versus quase três (por exemplo) é algo que pode ser importante para você se você estiver segmentando usuários finais. Se você está pensando no trabalho da empresa, alguns MB não importarão nada. E, só para esclarecer: vou enviar um aplicativo baseado em MT para a loja rapidamente, e não tenho nenhum problema com o tamanho. Não me incomoda nada. Mas se isso é algo que preocupariavocê , então a pilha da Apple vence esta.

  • Algum XML funciona? MonoTouch. Período.

  • Manipulação de cordas? Manipulação de datas? Um milhão de outras pequenas coisas com as quais nos acostumamos às estruturas de tudo-e-a-cozinha-da-net. MonoTouch.

  • Serviços web? MonoTouch.

  • Sintaticamente, ambos têm suas vantagens. O Objetivo-C tende a ser mais detalhado onde você deve escrevê-lo . Você se encontrará escrevendo código com C #, não precisaria escrever com ObjC, mas é nos dois sentidos. Este tópico em particular pode preencher um livro. Eu prefiro a sintaxe C #, mas depois de superar minha reação inicial do outro mundo ao Objective-C, aprendi a gostar um pouco. Eu zoo um pouco disso nas conversas ( é estranho para desenvolvedores que estão acostumados a C # / Java / etc.), Mas a verdade é que eu tenho um ponto em forma de Objective-C no meu coração que me faz feliz.

  • Você planeja usar o Interface Builder? Porque, mesmo nesta versão inicial, eu me vejo fazendo muito menos trabalho para criar minhas UIs com o IB e depois usá-las no código. Parece que etapas inteiras estão faltando na maneira de fazer as coisas do Objective-C / IB, e tenho certeza que é porque faltam etapas inteiras na maneira de fazer as coisas do Objective-C / IB. Até agora, e acho que não testei o suficiente, mas até agora , o MonoTouch é o vencedor por quanto menos trabalho você tem que fazer.

  • Você acha divertido aprender novos idiomas e plataformas? Nesse caso, o iPhone tem muito a oferecer, e a pilha da Apple provavelmente o tirará da sua zona de conforto - o que, para alguns desenvolvedores, é divertido (Oi - eu sou um desses desenvolvedores - eu brinco com isso e dou É difícil para a Apple, mas me diverti muito aprendendo o desenvolvimento do iPhone através das ferramentas da Apple).

Há tantas coisas a considerar. O valor é tão abstrato. Se estamos falando de custo e se vale a pena, a resposta se resume ao meu primeiro item: se isso é para negócios e se você pode obter o trabalho, você ganhará seu dinheiro de volta.

Então ... isso é tão objetivo quanto eu posso ser. Esta é uma pequena lista do que você pode se perguntar, mas é um ponto de partida.

Pessoalmente (vamos deixar cair a objetividade por um momento), eu amo e uso os dois. E fico feliz por ter aprendido a pilha da Apple primeiro. Era mais fácil para mim começar a operar com o MonoTouch quando eu já sabia o que fazer no mundo da Apple. Como já foi dito, você ainda estará trabalhando com o CocoaTouch - ele estará apenas em um ambiente com rede.

Mas há mais do que isso. As pessoas que não usaram o MonoTouch tendem a parar por aí - "É um invólucro blá blá blá" - esse não é o MonoTouch.

O MonoTouch oferece acesso ao que o CocoaTouch tem a oferecer e também ao que (um subconjunto de) .Net tem a oferecer, um IDE com o qual algumas pessoas se sentem mais confortáveis ​​(eu sou um deles), melhor integração com o Interface Builder , e embora você não consiga esquecer completamente o gerenciamento de memória, você tem um bom grau de margem de manobra.

Se você não tiver certeza, pegue a pilha da Apple (é grátis) e pegue a pilha de avaliação MonoTouch (é grátis). Até você ingressar no programa de desenvolvimento da Apple, os dois só rodam no simulador, mas isso é suficiente para ajudá-lo a descobrir se você prefere muito um ao outro e possível se o MonoTouch vale para você US $ 399.

E não dê ouvidos aos fanáticos - eles tendem a ser os que não usaram a tecnologia contra a qual se opõem :)

Rory Blyth
fonte
50
Uau, Rory, obrigado por dedicar um tempo para responder à minha pergunta com tanto detalhe. Pelo que posso dizer, você é o único que usou as duas opções, que é quem eu estava procurando por uma resposta. Definitivamente vou tentar os dois a partir daí. Aliás, ouvi você no podcast SO mais recente, certo? Coisa boa. Obrigado novamente!
jamesaharvey
17
Obrigado pelos comentários :) Fiquei frustrado com alguns dos ódios que já vi. Uma e outra vez a pergunta é respondida com "Você é um idiota para ritar o sistema opurante primeiro perdedor !! ??" O que é inútil e insultuoso. O MonoTouch tem seus pontos difíceis, mas esses caras têm um histórico de gênio. O MT avançou rapidamente e é mais bonito todos os dias. Eu continuo dizendo: dê a eles alguns meses. Eles estão sendo prudentes em relação aos recursos, mas acho que veremos grandes coisas. Eu amo pilha da Apple, mas eu tenho um outro parque agora - que é uma coisa boa e eu sou tonta :)
Rory Blyth
4
@ Stephan - Pode não ser certo dizer o que está "faltando" - posso fazer o trabalho com o cacau. É mais sobre as APIs. É muito mais fácil trabalhar com strings, datas, XML, etc., com .Net. Não sei se você está familiarizado com a maneira .Net de fazer essas coisas, bem como com a extensão do suporte do MonoTouch para elas - se você ainda não analisou, deveria fazer - apenas para conferir. Não quero dizer que há coisas que você não pode fazer com o cacau, mas há muitas que são muito mais fáceis de fazer com o .Net. Análise é mais fácil em toda a linha - data matemática é fácil através da placa - etc.
Rory Blyth
3
Também há a questão de sua própria reutilização de código no iPhone / iPad com o MT. Temos alguns códigos criptográficos e de lógica de negócios em execução em nossos servidores e computadores, que poderíamos recompilar com o MT e usar em nosso aplicativo cliente iOS. Isso pode ser importante para alguns projetos.
Monoman
2
Também vale a pena considerar o fato de que, embora a licença custe US $ 400, também há uma assinatura de manutenção que você deve renovar (por razões óbvias) a cada ano - US $ 250. Provavelmente é um preço justo, mas ainda vale a pena levar em consideração.
Amc_rtty
62

Há muito boato neste post de desenvolvedores que não experimentaram o MonoTouch e o Objective-C. Parece ser principalmente desenvolvedores de Objective-C que nunca experimentaram o MonoTouch.

Eu sou obviamente tendencioso, mas você pode conferir o que a comunidade MonoTouch está fazendo:

http://xamarin.com

Lá você encontrará vários artigos de desenvolvedores desenvolvidos em Objective-C e C #.

miguel.de.icaza
fonte
29
@NSResponder - Você já usou o MonoTouch? É uma versão v1.x, praticamente nova e já é incrível. Experimente antes de comentar. Existem grandes mudanças (a integração do Interface Builder é muito melhor que a do Xcode) e poucas (compare a maneira ObjC / Cocoa de obter a pasta de documentos do usuário em comparação com as da MT, por exemplo). Eu ainda uso a pilha da Apple para algumas coisas, mas o MT é bonito e cheio de potencial. Sério - apenas tente. Ou veja como as APIs do Cocoa foram vinculadas - você não precisa usá-lo - apenas não lide com o trabalho sem aprender .
Rory Blyth
Sim! Além disso, alguns dos novos recursos do C # 5.0 tornam a codificação muito mais divertida em comparação ao objetivo-c.
harsimranb
39

Portanto, minha resposta a uma pergunta semelhante anterior é aprender o Objective-C. (Além disso, não se esqueça do suporte à depuração)

Isso provavelmente ofenderá alguns, mas, para ser sincero, se você quiser desenvolver algo sério, deve aprender o Objective-C. Não conhecer o Objective-C no desenvolvimento do iPhone será apenas um obstáculo. Você não será capaz de entender muitos exemplos; você precisa lidar com as peculiaridades do Mono, enquanto que se tivesse um conhecimento prático do Objective-C, poderia obter muito mais da documentação da plataforma.

Pessoalmente, não entendo a posição que diz aumentar a quantidade de informações necessárias em favor do uso do Mono sobre o idioma nativo da plataforma. Parece um pouco contraproducente para mim. Acho que se essa é uma proposta muito cara (aprender um novo idioma), pode valer a pena gastar algum tempo com conceitos fundamentais de programação, para que o aprendizado de novos idiomas seja uma proposta bastante barata.

Outro usuário também escreveu isso:

Monotouch é mais fácil para você agora. Mas mais difícil depois.

Por exemplo, o que acontece quando novas sementes são lançadas contra as quais você precisa testar, mas interromper o MonoTouch por algum motivo?

Ao aderir ao Mono, sempre que você estiver procurando recursos para estruturas, você deve traduzir mentalmente como vai usá-los com o Mono. Seus binários de aplicativos serão maiores, seu tempo de desenvolvimento não será muito mais rápido após alguns meses do Objective-C, e outros desenvolvedores de aplicativos terão muito mais vantagens sobre você, porque estão usando a plataforma nativa.

Outra consideração é que você deseja usar o C # porque está mais familiarizado com o idioma que o Objective-C. Mas a grande maioria da curva de aprendizado do iPhone não é Objective-C, são os frameworks - com os quais você também precisará usar o C #.

Para qualquer plataforma, você deve usar a plataforma que expressa diretamente a filosofia de design dessa plataforma - no iPhone, que é o Objective-C. Pense nisso do ponto de vista inverso, se um desenvolvedor Linux acostumado a programar no GTK desejasse escrever aplicativos do Windows, seriamente recomendável que eles não usassem C # e se atendessem ao GTK porque era "mais fácil" fazer isso?

BobbyShaftoe
fonte
12
Você, provavelmente sem querer, deturpou o MT. Não é nada análogo ao uso do GTK para escrever aplicativos Win. As ligações do MT são muito fiéis ao CocoaTouch. Eles realmente aprimoraram algumas das convenções da API do CT. Mas você não está escrevendo seus aplicativos usando, por exemplo, uma abstração baseada em Windows Forms por CT. O MT com MonoDevelop tem uma melhor integração com o IB do que o Xcode (se você quiser), e muitas vezes você pode fazer o mesmo com metade do código ou menos. O tamanho binário está sendo aprimorado e as ferramentas (gerador de encadernação etc.) ficam melhores o tempo todo. Um aplicativo MT é um aplicativo nativo.
Rory Blyth
7
Para dar exemplos, em vez de esperar que você tome a minha opinião (obviamente) do MT-fanboy por conta própria, eu posso fazer coisas como (e este é apenas um pequeno subconjunto de vantagens): Crie uma propriedade com uma linha; pegue uma referência à pasta Documento sem spelunking de matriz ridículo (um aplicativo tem uma pasta docs, sempre no mesmo local - por que todo o trabalho extra para "encontrá-la"?); use a estrutura .Net onde o cacau fede (NSDate, alguém?); usar habilidades de commodity para aplicativos corporativos; use bits XML modernos e adequados (eu adoro quando o Cocoa silenciosamente engasga com os caracteres e apenas para - sem travamento - apenas para ).
Rory Blyth
8
Não estou dizendo que eu o usaria para tudo. Eu gosto do ObjC e ainda o uso. E, se o desempenho for um problema, tenho um controle mais granular sobre o que está acontecendo. Mas ... há momentos em que o MT fará mais sentido, e acho que fará do iPhone uma opção viável para o desenvolvimento empresarial. Jogue uma pedra no ar e você atingirá um desenvolvedor .Net. A maioria das empresas não possui desenvolvedores ObjC internos. E para o trabalho empresarial, eles não deveriam. O MT é muito mais fácil para trabalhar com serviços da Web e bancos de dados. Você realmente pode escrever muitos tipos de aplicativos com o MT com metade do código necessário no ObjC.
Rory Blyth
8
Por fim (eu poderia continuar, mas acho que estou fazendo mt point), as alterações que "quebram" o MonoTouch provavelmente têm a mesma probabilidade de quebrar os aplicativos ObjC. Quando seu aplicativo está na loja, ele é um aplicativo nativo do iPhone (como deve ser). As chamadas não são diferentes - o mesmo tempo de execução dos aplicativos criados com a pilha da Apple. Se o seu aplicativo MT for interrompido devido a uma alteração no ambiente de tempo de execução, os aplicativos criados com o ObjC também serão. E a equipe de MT está no topo disso, lançando atualizações e correções de bugs rapidamente. As ligações da MT são mapeadas suficientemente perto das da CT, para que a probabilidade de qualquer problema real seja baixa. Aight - Vou calar a boca agora :)
Rory Blyth
27

Usar o Mono não é uma muleta. Há muitas coisas que ele adiciona ao iPhone OS. LINQ, WCF, código compartilhável entre um aplicativo Silverlight, uma página ASP.NET, um aplicativo WPF, um aplicativo Windows Form e também há mono para Android e funcionará também para o Windows Mobile.

Portanto, você pode gastar muito tempo escrevendo Objective-C (você verá em muitos estudos onde exatamente o mesmo código de exemplo em C # é significativamente menor para escrever que OC) e depois DUPLICATE tudo para outras plataformas. Para mim, escolhi o MonoTouch porque o aplicativo em nuvem que estou escrevendo terá muitas interfaces, sendo o iPhone apenas uma delas. A transmissão de dados WCF da nuvem para o aplicativo MonoTouch é incrivelmente simples. Eu tenho bibliotecas principais que são compartilhadas entre as várias plataformas e só preciso escrever uma camada de apresentação simples para as implantações do iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Recriar tudo no Objective-C seria um enorme desperdício de tempo, tanto para o desenvolvedor inicial quanto para a manutenção, pois o produto continua avançando, já que toda a funcionalidade precisa ser replicada e não reutilizada.

As pessoas que estão insultando o MonoTouch ou insinuando que seus usuários precisam de uma muleta não têm uma visão geral do que significa ter a estrutura .NET ao seu alcance e talvez não entendam a separação adequada da lógica da apresentação feita de uma maneira que pode ser reutilizado em plataformas e dispositivos.

O Objective-C é interessante e muito diferente de muitos idiomas comuns. Gosto de um desafio e de aprender abordagens diferentes ... mas não quando isso impede o meu progresso ou cria uma recodificação desnecessária. Existem algumas coisas realmente excelentes sobre a estrutura do iPhone SDK, mas toda essa grandeza é totalmente suportada pelo MonoTouch e corta todo o gerenciamento manual de memória, reduz a quantidade de código necessária para executar as mesmas tarefas, permite reutilizar meus assemblies e mantém minhas opções em aberto para poder mudar para outros dispositivos e plataformas.

Paulo
fonte
19

Eu troquei. Monotouch, deixe-me escrever aplicativos pelo menos 3-4 vezes mais rápido (4 aplicativos por mês em comparação com o antigo 1 por mês no Obj C)

Muito menos digitação.

Apenas minha experiência.

Ian Vink
fonte
2
"4 aplicativos por mês" - quando a quantidade é mais importante, como a qualidade. MT é como McDonalds. Mas você obtém comida melhor no XCode-Restaurant.
precisa saber é o seguinte
2
Embora os resultados sejam diferentes, o Rdio e o iCircuit são aplicativos MT demonstrados por Steve Jobs. C # e MT se livram do trabalho de encanamento que a obj-C obriga a fazer.
precisa
17

Se esse é o único aplicativo para iPhone que você desenvolverá, e você também não tem interesse em desenvolver aplicativos para Mac, então o MonoTouch provavelmente vale o custo.

Se você pensa que algum dia desenvolverá mais aplicativos para iPhone ou desejará desenvolver algum desenvolvimento nativo para Mac, provavelmente vale a pena aprender o Objective-C e as estruturas associadas. Além disso, se você é do tipo de programador que gosta de aprender coisas novas, é um novo paradigma divertido de se estudar.

phoebus
fonte
6
Se esse é o único aplicativo para iPhone que você desenvolverá, os US $ 99 / ano também não valerão a pena.
Dinah
Você pode usar as mesmas ferramentas de desenvolvimento em C # para criar aplicativos para Mac. Na verdade, você pode codificar o compartilhamento entre os aplicativos iPhone C # e Mac C #. MonoTouch é agora chamado Xamarin
Ian Vink
9

Pessoalmente, acho que você terá um tempo melhor aprendendo o Objective-C.

Em resumo:

  • "Objetivo de Aprendizagem-C" não é assustador, como você pode imaginar, você pode até se divertir depois das primeiras semanas
  • Você já está familiarizado com a sintaxe "estilo C" com muitos * & () {}; em toda parte
  • A Apple fez um bom trabalho ao documentar as coisas
  • Você estará interagindo com o iPhone da maneira que a Apple pretendia, o que significa que você obterá os benefícios diretamente da fonte, não através de algum filtro.

Descobri que projetos como o Unity e o MonoTouch "economizam seu tempo", mas, no final das contas, você precisará aprender o idioma específico de seu domínio e, às vezes, precisará dar um passo adiante. Tudo o que provavelmente levará o tempo necessário para aprender o idioma que você estava tentando evitar aprender (no horário do calendário). No final, você não economizou tempo e está fortemente acoplado a algum produto.

Edição: Eu nunca quis implicar nada negativo sobre o .NET. Eu sou um grande fã disso. O que quero dizer é que adicionar mais camadas de complexidade só porque você ainda não se sente confortável com a notação peculiar bracket objc realmente não faz muito sentido para mim.

Atualização de 2019: são 7 anos depois. Eu ainda me sinto da mesma forma, se não mais. Certamente, 'idioma específico do domínio' pode ter sido o termo errado a ser usado, mas ainda acredito que é muito melhor escrever diretamente para a plataforma com a qual você está trabalhando e evitar camadas e abstrações de compatibilidade o máximo possível. Se você estiver preocupado com a reutilização e re-trabalho do código, geralmente qualquer funcionalidade que seu aplicativo multiplataforma precise executar provavelmente poderá ser realizada com as modernas tecnologias da web.

slf
fonte
12
Primeiro, o C # não é uma "linguagem específica de domínio" - longe disso. É uma habilidade de commodity. Isso faz parte do valor do MonoTouch. Pode-se argumentar (de forma injusta e imprecisa) que a ObjC é uma DSL, na medida em que a maioria dos desenvolvedores (fora de laboratórios e porões de finanças e universidades) só a utilizará para o desenvolvimento do OS X ou iPhone. Mas não é. Como o C #, é uma linguagem versátil que existe basicamente para permitir que você se concentre nas estruturas e não na própria linguagem (acho que concordamos lá). Mas lembre-se de que seu código ObjC quebrará com as atualizações da Apple. Esse não é um problema específico do MT.
Rory Blyth
3
O MT pode até salvá-lo em alguns casos, porque existe essa camada de abstração. Apple modifica uma API? Bem, seu aplicativo ObjC e seu aplicativo MT equivalente (vamos fingir que existe) serão interrompidos. O pessoal do MT poderia lançar uma solução de interrupção para modificar como a API MonoTouch lida com a chamada nos bastidores. Seu código de MT não precisaria ser alterado - você poderia apenas reconstruir com o lançamento do MT. Sim: essa é uma correção suja que pode facilmente levar a problemas, mas descontinuar adequadamente a API MT de interrupção daria aos desenvolvedores tempo para lidar com a mudança sem problemas e ganhar tempo para uma correção real .
Rory Blyth
4
Além disso, por mais novo que seja o MT, ficou muito mais fácil criar suas próprias ligações, se necessário (MT 1.2). Você não é completamente dependente das espreitadelas do MT para fazer todo esse trabalho (apesar de estarem fazendo esse trabalho), e nunca foi. Eles têm maneiras simples de criar ligações. Eles expõem o suficiente do tempo de execução do ObjC com as estruturas MT, para que você não fique preso à maneira deles de fazer as coisas. Reimplementei as ligações apenas para ver se eu gosto mais do meu caminho. Você pode ignorar as estruturas do MT e enviar e receber mensagens "manualmente", se desejar, e isso requer pouco código. Eles são pessoas inteligentes. Confie neles :)
Rory Blyth
2
Eu acho que o slf não está ciente do fato de que o Monotouch é apenas C # (com GC) que se liga diretamente às bibliotecas ObjC + bibliotecas .NET opcionais. Então você ainda usa a API fornecida pela apple. Mas com uma sintaxe mais limpa e uma coleta de lixo.
basarat
4

Para adicionar ao que os outros já disseram (bem!): Minha sensação é de que você basicamente está dobrando o número de bugs com os quais precisa se preocupar, adicionando os do MonoTouch aos já existentes no iPhone OS. A atualização para novas versões do sistema operacional será ainda mais dolorosa do que o normal. Eca, por toda parte.

O único caso convincente que eu posso ver para o MonoTouch são as organizações que possuem muitos programadores e código C # por aí, que eles devem aproveitar no iPhone. (O tipo de loja que nem sequer pisca em US $ 3.500.)

Mas para quem está começando do zero, realmente não posso ver isso como algo que valha a pena ou que seja sensato.

Sixten Otto
fonte
-1: O que você quer dizer com "mais bugs"? Existe uma incompatibilidade evidente de impedância entre Mono e Objective-C?
Jim G.
4

Três palavras: Linq to SQL

Sim, vale bem a pena o dólar.

Bryan
fonte
4
Com as Ligações de valor-chave e os dados principais do Objective-C, você obtém algo muito semelhante ao Linq-to-SQL. Não é o mesmo. Talvez não tão poderoso - mas cobrindo muito do mesmo terreno. Observe que o Core-Data atualmente não é suportado pelo MonoTouch
philsquared 26/10/09
O Linq to SQL é relevante para um aplicativo para iPhone? Funciona com SQLite?
bpapa
1
E você deseja que seus usuários compartilhem dados em uma rede. O que você está fazendo com o SQL Lite?
Bryan
"O MonoTouch é baseado em um perfil de API híbrido .NET 2.0 e Silverlight 2" O LINQ to objects é suportado?
Chris S
2

Algo que eu gostaria de acrescentar, mesmo que haja uma resposta aceita - quem pode dizer que a Apple não rejeitará apenas aplicativos que tenham sinais de serem criados com o Mono Touch?

bpapa
fonte
Eles certamente deveriam e também deveriam rejeitar aplicativos Flash, mas seus termos da App Store não impedem o uso deles.
NSResponder
3
@bpapa - essa é uma preocupação totalmente válida, mas: 1) Não há motivo para rejeitar os aplicativos (os usuários não se importam com o que eles escrevem - eles se preocupam com os aplicativos) e 2) o MonoTouch tem muito potencial para desenvolvimento corporativo , e desde que você tenha uma conta de desenvolvedor corporativo, a Apple não poderá impedi-lo de distribuir seu aplicativo. Além disso, a Apple aceita jogos criados com o Unity. Por fim, o MT segue as regras. O processo da Apple parece aleatório às vezes, mas ... MT segue as regras: |
Rory Blyth
1
@bpapa - Não sei como perdi esse comentário por tanto tempo, mas: 1) Toneladas de aplicativos ObjC ficam "bloqueadas" por usar APIs não documentadas ("privadas") - o FB, como você observou, sendo um deles, ainda O FB ainda está ativo e disponível para download. 2) O problema do Unity foi rapidamente resolvido e o Unity está de volta. - Na medida em que a Apple deseja que você use seu próprio material, eu não discordo, mas o desejo e a exigência são muito diferentes. Quanto aos aplicativos corporativos: você pode implantar aplicativos corporativos MT. Eles são apenas binários nativos. Não vejo o problema, nem entendo por que você é tão anti-MT.
Rory Blyth
1
Devo acrescentar que não é que eu "odeie" a sintaxe do ObjC, mas prefiro muito o C #. Também prefiro as maneiras do quadro .Net do cacau. Manipulação de string, XML de processamento, qualquer coisa que envolva datas, etc. - Usarei as ligações do MT CocoaTouch para o trabalho da interface do usuário, mas para a maioria das outras tarefas, o subconjunto da estrutura .Net que acompanha o MT facilita muito a vida. Eu poderia continuar e continuar (como minha preferência por encontrar certos bugs no momento da compilação ). Eu critico a pilha da Apple, mas não a detesto. É possível gostar do MT e ObjC / etc.
Rory Blyth
1
A Apple mudou de idéia e agora aceita aplicativos em qualquer idioma / estrutura e estabeleceu uma lista mais 'objetiva' de critérios para aceitar aplicativos na loja.
Monoman 22/09/10
2

Investiria o tempo no Objective-C principalmente por causa de toda a ajuda que você pode obter de sites como este. Um dos pontos fortes do Objective-C é que você pode usar o código C e C ++, e há muitos projetos por aí que são bem testados .

Outra coisa é que seu código (idioma de escolha) será suportado pela apple. O que o iOS 5.x, por exemplo, remove o suporte para uma solução de terceiros como o MonoTouch? O que você dirá a seus clientes?

Talvez seja melhor usar uma solução independente de plataforma como HTML5, se você não estiver totalmente pronto para ir para o Objective-C?

Konrad77
fonte
Acho que, ao usar o MonoTouch, você fica preso a um fornecedor que a Apple pode interromper para permitir / oferecer suporte muito forte. Você pode acabar investindo em uma plataforma que está à mercê de uma Apple que tem sua própria plataforma de desenvolvimento ...
jl.
2

Estou usando o MonoTouch há alguns meses, enviei meu aplicativo pela metade do ObjectiveC para poder oferecer suporte ao Android em algum momento no futuro.

Aqui está a minha experiência:

Bits ruins:

  • Xamarin Studio. Desenvolvedores independentes, como eu, somos forçados a usar o Xamarin Studio. Está ficando melhor a cada semana, os desenvolvedores são muito ativos nos fóruns, identificando e corrigindo bugs, mas ainda é muito lento, geralmente trava, tem muitos bugs e a depuração é bem lenta também.

  • Tempos de construção. A criação do meu aplicativo grande (vinculado) para depuração em um dispositivo pode levar alguns minutos; isso é comparado ao XCode, que é implantado quase imediatamente. Construir para o simulador (não vinculado) é um pouco mais rápido.

  • Problemas com o MonoTouch. Eu experimentei problemas de vazamento de memória causados ​​pela manipulação de eventos e tive que colocar algumas soluções bastante feias para evitar vazamentos, como anexar e desanexar eventos ao entrar e sair de visualizações. Os desenvolvedores do Xamarin estão analisando ativamente problemas como este.

  • Bibliotecas de terceiros. Passei bastante tempo convertendo / vinculando bibliotecas ObjectiveC para usar no meu aplicativo, embora isso esteja melhorando com software automatizado como o Objective Sharpie.

  • Binários maiores. Isso realmente não me incomoda, mas pensei em mencionar. OMI um par de Mb extra não é nada nos dias de hoje.

Bons bits:

  • Multi plataforma. Meu amigo está feliz em criar uma versão Android do meu aplicativo a partir da minha base de código principal, estamos desenvolvendo em paralelo e comprometendo-nos com um repositório Git remoto no Dropbox, está indo bem.

  • .Internet. Trabalhar em C # .Net é muito melhor do que o Objective C IMO.

  • MonoTouch. Praticamente tudo no iOS é espelhado no .Net e é bastante simples fazer as coisas funcionarem.

  • Xamarin. Você pode ver que esses caras estão realmente trabalhando para melhorar tudo, tornando o desenvolvimento mais fácil e fácil.

Definitivamente, recomendo o Xamarin para o desenvolvimento de várias plataformas, especialmente se você tiver dinheiro para usar as edições Business ou Enterprise que funcionam com o Visual Studio.

Se você estiver criando apenas um aplicativo para iPhone que nunca será necessário em outra plataforma, e você for um desenvolvedor independente, eu ficaria com o XCode e o Objective C por enquanto.

Danfordham
fonte
Uma atualização rápida na minha resposta acima. Desde que mudei para um Mac mais rápido, achei os tempos de compilação muito mais rápidos, ainda não é instantâneo como o XCode, mas está bem.
danfordham
1

Como alguém com experiência em C # e Objective-C, eu diria que para a maioria das pessoas, o Xamarin valerá a pena.

C # é uma linguagem realmente boa e as APIs de C # também são bem projetadas. É claro que as APIs do Cocoa Touch (incluindo o UIKit) também têm um ótimo design, mas o idioma pode ser aprimorado de várias maneiras. Ao escrever em C #, você provavelmente será mais produtivo em comparação com o mesmo código em Objective-C. Isso ocorre por vários motivos, mas alguns seriam:

  • C # tem inferência de tipo . A inferência de tipo torna a escrita do código mais rápida, pois você não precisa "conhecer" o tipo no lado esquerdo de uma tarefa. Também torna a refatoração mais fácil e mais econômica.

  • O C # possui genéricos , o que reduzirá os erros em comparação com o código Objective-C equivalente (embora haja algumas soluções alternativas no Objective-C, na maioria das situações os desenvolvedores os evitarão).

  • Recentemente, o Xamarin adicionou suporte ao Async / Await , o que facilita a gravação de código assíncrono.

  • Você poderá reutilizar parte da base de código no iOS, Android e Windows Phone.

  • O MonoTouch implementa amplamente as APIs do CocoaTouch de maneira muito direta. Por exemplo: se você tiver experiência com o CocoaTouch, saberá onde encontrar classes para controles no MonoTouch (o MonoTouch.UIKit contém classes para UIButton, UIView, UINavigationController, etc. NSData, etc ...).

  • O Xamarin dará aos usuários uma experiência nativa, ao contrário de soluções como PhoneGap ou Titanium.

Agora, o Objective-C tem algumas vantagens sobre o C #, mas na maioria das situações, escrever aplicativos em C # geralmente resultará em menos tempo de desenvolvimento e código mais limpo e menos trabalho para portar o mesmo aplicativo para outras plataformas. Uma exceção notável pode ser jogos de alto desempenho que dependem do OpenGL.

Wolfgang Schreurs
fonte
-35

O custo da biblioteca MonoTouch está totalmente fora de questão. A razão pela qual você não deve usar o Mono para seus aplicativos para iPhone é que é uma muleta. Se você não pode se incomodar em aprender as ferramentas nativas, não tenho motivos para acreditar que vale a pena fazer o download do seu produto.

Edit: 14/04/2010 Os aplicativos criados com o MonoTouch não são elegíveis para a iTunes Store. É assim que deve ser. A Apple viu muitas portas rasas no Mac, usando kits de ferramentas de plataforma cruzada, como o Qt, ou a reimplementação parcial da própria Adobe da caixa de ferramentas do System 7, e o longo e curto disso é que eles simplesmente não são bons o suficiente.

NSResponder
fonte
14
A participação de mercado no Mac OS X é muito pequena e, portanto, o iPhone é, por muitos, o único motivo convincente para se preocupar em se preocupar com o X-Code e o ObjC. Ambos eram ótimos há mais de 15 anos atrás, quando era o Project Builder e realizavam complicação e empacotamento de plataforma cruzada, mas, francamente - como alguém que usa uma variedade de plataformas - com ferramentas e linguagens sem dúvida melhores por aí agora, não é de surpreender que os desenvolvedores desejem aproveitar um ambiente comum codebase e use ferramentas alternativas de desenvolvimento. Isso não significa que suas criações estarão abaixo do par.
Iain Collins
37
Eu não sei, cara ... Eu acho que Objective-C e CocoaTouch são uma muleta. Se você não está escrevendo montagem, sinto que você não se importava muito e não baixava seu aplicativo (porque a primeira coisa que os usuários fazem, é claro, é verificar quais ferramentas foram usado para criar o aplicativo de simulação de flatulência que eles estão baixando).
Rory Blyth
3
Andrew, você não sabe do que fala. Objetivo-C não é remanescente; é a espinha dorsal do ambiente de desenvolvimento nativo para Mac, iPhone e iPad.
NSResponder
5
Então, você escolhe um exemplo simples de algo que a Apple incorporou à estrutura e reivindica superioridade, ignorando convenientemente as partes da estrutura que são muito mais desajeitadas que o equivalente em C #? Isso não é um argumento de palha?
Andrew Rollings
8
Mudei para o MonoTouch e publiquei 47 aplicativos até agora no 4.0. Eu faço isso em tempo integral. Funciona muito bem, rápido. Eu costumava escrever no Objective C, mas localizava o C # com o Linq mais rapidamente, com muito menos código para escrever.
quer