Xamarin 2.0 vs Appcelerator Titanium vs PhoneGap

Depois de todas as evoluções do IDE (todas as plataformas no tópico foram alteradas) deste ano, estou procurando entender qual é o estado da tecnologia para essas plataformas.

Quais são os pontos fortes e fracos de cada um? Existem algumas limitações de uma dessas abordagens?

Eu tenho uma boa experiência em C # e Javascript, do que não há influência de linguagem programática que poderia se inclinar para um lado.

Visão geral

Conforme relatado por Tim Anderson

O desenvolvimento de plataforma cruzada é um grande negócio , e continuará sendo assim até o dia em que todos usarem a mesma plataforma. Android? HTML? WebKit? iOS? Janelas? Xamarin? Titanum PhoneGap? Corona? ecc.

Às vezes, ouço dizer que há basicamente duas abordagens para aplicativos móveis entre plataformas. Você pode usar um controle de navegador incorporado e escrever um aplicativo da Web incluído como um aplicativo nativo , como no Adobe PhoneGap / Cordova ou a abordagem semelhante adotada pelo Sencha, ou usar uma ferramenta de plataforma cruzada que cria aplicativos nativos , como o Xamarin. Studio, Appcelerator Titanium ou Embarcardero FireMonkey.

Dentro da segunda categoria, porém, há diversidade. Em particular, variam em relação à extensão em que abstraem a interface do usuário.

Aqui está o trade-off. Se você projetar sua estrutura de plataforma cruzada, poderá fazer com que seu aplicativo funcione quase da mesma maneira em todas as plataformas. Se você estiver compartilhando o design da interface do usuário em todas as plataformas, será difícil fazer com que seu design pareça igualmente correto em todos os casos. Talvez seja melhor adotar a abordagem adotada pela maioria dos jogos, usando um design que seja diferente de seu aplicativo e que seja uma virtude de sua consistência entre plataformas, mesmo que não tenha a aparência e a aparência nativas em qualquer plataforma.

editar Xamarin v3 em 2014 começou a oferecer escolha de Xamarin.Forms , bem como nativo puro que ainda segue a filosofia mencionada aqui (tomou liberdade de edição inline porque uma resposta tão grande)

O Xamarin Studio, por outro lado, não faz nenhuma tentativa de fornecer uma estrutura de GUI compartilhada:

Não tentamos fornecer uma camada de abstração de interface de usuário que funcione em todas as plataformas. Achamos que essa é uma abordagem ruim que leva a interfaces de usuário de menor denominador comum. (Nat Friedman para Tim Anderson)

Isso está certo; mas a desvantagem é o esforço envolvido na manutenção de dois ou mais designs de interface de usuário para seu aplicativo.

Comparação sobre o PhoneGap e Titanium é bem relatado no blog Kevin Whinnery .

PhoneGap

O objective do PhoneGap é permitir que aplicativos da Web baseados em HTML sejam implantados e instalados como aplicativos nativos . Os aplicativos da web PhoneGap são agrupados em um shell de aplicativo nativo e podem ser instalados por meio das lojas de aplicativos nativas para várias plataformas. Além disso, o PhoneGap se esforça para fornecer um conjunto de API nativo comum que normalmente não está disponível para aplicativos da Web, como access básico à câmera, contatos do dispositivo e sensores ainda não expostos no navegador.

Para desenvolver aplicativos PhoneGap, os desenvolvedores criarão arquivos HTML, CSS e JavaScript em um diretório local, bem como o desenvolvimento de um site estático. Aproximar -se do desempenho de qualidade nativa da interface do usuário no navegador é uma tarefa não trivial – o Sencha emprega uma grande equipe de especialistas em programação da Web dedicados em tempo integral à solução desse problema. Mesmo assim, na maioria das plataformas, na maioria dos navegadores atuais, alcançar o desempenho e a capacidade de resposta da qualidade original da interface do usuário simplesmente não é possível , mesmo com uma estrutura tão avançada quanto o Sencha Touch. O navegador já é “bom o suficiente”? Depende de seus requisitos e sensibilidades, mas é inquestionavelmente menos bom que a interface do usuário nativa. Às vezes muito pior, dependendo do navegador.

O PhoneGap não é tão multi-plataforma quanto se pode acreditar, nem todos os resources são igualmente suportados em todas as plataformas.

  • Javascript não é uma linguagem de programação em escala de aplicativos, muitas interações de escopo global, bibliotecas diferentes nem sempre coexistem muito bem. Passamos muitas horas tentando fazer o knockout.js e o jQuery.mobile tocarem bem juntos, e ainda temos problemas.

  • Paisagem fragmentada para estruturas e bibliotecas. Muitas escolhas, e muitas não são maduras o suficiente.

  • Estranhamente, para as necessidades do nosso aplicativo, um desempenho decente poderia ser alcançado (não com o jQuery.Mobile, no entanto). Nós tentamos jqMobi (não muito maduro, mas rápido).

  • Capacidade muito limitada de interação com outros aplicativos ou capacidades de cdevice, e isso não seria de qualquer maneira, já que não existem padrões em HTML5, exceto alguns, como geolocalização, câmera e bancos de dados locais.

por Karl Waclawek

Titcelerator Titanium

O objective do Titanium Mobile é fornecer um tempo de execução JavaScript de alto nível e API para desenvolvimento móvel (atualmente suportamos iOS, Android e Windows Phone. O Titanium na verdade tem mais em comum com MacRuby / Hot Cocoa, PHP ou nó. js do que com o PhoneGap, o Adobe AIR, o Corona ou o Rhomobile O Titanium é baseado em duas afirmações sobre desenvolvimento móvel: – Há um núcleo de APIs de desenvolvimento móvel que podem ser normalizadas em todas as plataformas. – Existem APIs específicas da plataforma, convenções de interface do usuário e resources que os desenvolvedores devem incorporar ao desenvolver para essa plataforma.Um código específico da plataforma deve existir para esses casos de uso para fornecer a melhor experiência possível.

Então, por essas razões, o Titanium não é uma tentativa de “escrever uma vez, rodar em qualquer lugar” . O mesmo que Xamarin.

O titânio vai dar mais um passo na direção semelhante ao de Xamarin. Na prática, eles farão duas camadas de diferentes profundidades: a camada Titanium (em JS), que lhe dá uma abelha JS-of-Titanium. Se você quiser ir mais baixo nível, ter criado uma camada adicional (chamada Hyperloop), onde (sempre com JS) para chamá-lo de volta diretamente para APIs nativas de SO

Xamarin (+ MVVMCross)

AZDevelop.net

A Xamarin (originalmente uma divisão da Novell) nos últimos 18 meses trouxe para o mercado seu próprio IDE e snap-in para o Visual Studio. A premissa subjacente do Mono é criar aplicativos móveis distintos usando C #, mantendo as estratégias de desenvolvimento da interface do usuário nativas.

Além de criar uma plataforma de design visual para desenvolver aplicativos nativos, eles têm suítes de testes integradas, suporte a bibliotecas nativas incorporadas e um repository de componentes estilo Nuget. Recentemente, eles forneceram o design visual do iOS por meio de seu IDE, liberando o desenvolvedor da abertura do XCode. No Visual Studio, todas as três plataformas agora são suportadas e um conjunto de testes na nuvem está no horizonte.

Desde o início, a Xamarin forneceu uma rica experiência em design visual Android. Eu ainda tenho que baixar ou abrir o Eclipse ou qualquer outro IDE além do Xamarin. O que é verdadeiramente surpreendente é que eu sou capaz de usar o LINQ para trabalhar com collections, bem como criar delegates personalizados e events que me liberem das limitações de object-C e Java. Muitas das bibliotecas com as quais tenho sido mimadas, como Newtonsoft JSON.Net, funcionam perfeitamente em todos os três ambientes.

Na minha opinião, existem várias vantagens ENORMES, incluindo

  • desempenho nativo
  • mais fácil de ler código (IMO)
  • testabilidade
  • código compartilhado entre cliente e servidor
  • suporte (embora Xam poderia fazer melhor no bugzilla)

Upgrade para mim é usar Xamarin e MVVMCross combinados. Ainda é um framework bastante novo, mas nasce da experiência de vários outros frameworks (como o MvvmLight e o monocross) e agora ele tem sido usado em vários projetos multi-plataforma lançados.

Conclusão

Minha escolha depois de conhecer todos esses framwework, foi selecionar ferramenta de desenvolvimento com base nas necessidades do produto . Em geral, no entanto, se você começar a usar uma ferramenta com a qual se sinta confortável (mesmo que exija uma sobrecarga inicial maior) depois de usá-la para sempre.

Eu escolhi Xamarin + MVVMCross e devo dizer para ser feliz com esta escolha. Eu não tenho medo de abordagem do SDK nativo para atualizações de software ou ver a funcionalidade limitada de um sistema ou a coisa mais trivial de um recurso gráfico. Escrever código razoavelmente estruturado (DDD + SOA) é muito útil para ter um projeto central compartilhado com a implementação de visualizações C # nativas.

Referências e links

Eu não trabalhei muito com o Appcelerator Titanium, mas vou colocar minha compreensão sobre isso no final.

Eu posso falar um pouco mais sobre as diferenças entre o PhoneGap e o Xamarin, pois eu trabalho com esses dois (ou mais) dias por semana.

Se você já está familiarizado com C # e JavaScript, então a questão que eu acho é que a lógica de negócios está em uma área mais adequada para JavaScript ou C #?

PhoneGap

O PhoneGap é projetado para permitir que você escreva seus aplicativos usando JavaScript e HTML , e grande parte da funcionalidade que eles fornecem é projetada para imitar as especificações atuais propostas para a funcionalidade que eventualmente estará disponível com HTML5. O grande benefício do PhoneGap, na minha opinião, é que desde que você está fazendo a interface do usuário com HTML, pode ser facilmente transportado entre plataformas . A desvantagem é que, como você está portando a mesma interface do usuário entre as plataformas, não se sentirá como em casa em nenhum deles. O que significa que, sem mais ajustes, você não pode ter um aplicativo que se sente totalmente em casa no iOS e no Android , o que significa que ele tem o estilo iOS e Android. A maioria de sua lógica pode ser escrita usando JavaScript, o que significa que ela também pode ser portada entre plataformas . Se a API atual do PhoneGap fizer a maior parte do que você deseja, é muito fácil começar a usar. Se, no entanto, existem coisas que você precisa do dispositivo que não estão na API, então você começa a se divertir com o Plugin Development , que estará na linguagem de escolha de desenvolvimento do dispositivo nativo (com uma ressalva, mas Isso significa que você provavelmente precisaria se atualizar rapidamente em Objective-C, Java, etc. O bom desse modelo é que você geralmente pode adaptar muitas bibliotecas nativas diferentes para servir à sua finalidade, e muitas bibliotecas já têm Plugins do PhoneGap . Embora você possa não ter muita experiência com esses idiomas, haverá pelo menos uma infinidade de exemplos para trabalhar.

Xamarin

Xamarin.iOS e Xamarin.Android (também conhecido como MonoTouch e MonoDroid), são projetados para permitir que você tenha uma biblioteca de lógica de negócios , e use isso dentro de seu aplicativo, e conecte-a à sua interface do usuário. Como ele é baseado no .NET 4.5, você obtém notações lambda incríveis , LINQ e um monte de outras maravilhas do C #, o que pode tornar a escrita da sua lógica de negócios menos dolorosa. A desvantagem aqui é que Xamarin espera que você queira fazer com que seus aplicativos realmente se tornem nativos no dispositivo, o que significa que você provavelmente acabará reescrevendo sua UI para cada plataforma , antes de conectá-la à lógica de negócios. Eu ouvi falar sobre o MvvmCross , que é projetado para tornar isso mais fácil para você , mas ainda não tive a oportunidade de analisá-lo. Se você estiver familiarizado com o sistema MVVM em C #, convém dar uma olhada nisso. Quando se trata de bibliotecas nativas, o MonoTouch se torna interessante. O MonoTouch requer uma biblioteca Binding para informar seu código C # sobre como vincular o código Objective-C e Java subjacente . Algumas dessas bibliotecas já terão ligações, mas se a sua não tiver, criar uma pode ser interessante. Xamarin fez uma ferramenta chamada Objective Sharpie para ajudar com este processo, e na maior parte, você terá 95% do caminho até lá . Os 5% restantes provavelmente levarão 80% do seu tempo tentando ligar uma biblioteca.

Atualizar

Conforme observado nos comentários abaixo, a Xamarin lançou o Xamarin Forms, que é uma abstração de plataforma cruzada em torno dos componentes de interface do usuário específicos da plataforma. Definitivamente vale a pena olhar.

PhoneGap / Xamarin Hybrid

Agora, porque eu disse que iria chegar lá, a ressalva mencionada no PhoneGap acima, é uma abordagem híbrida , em que você pode usar o PhoneGap para uma parte e o Xamarin para uma parte. Eu tenho um pouco de experiência com isso, e gostaria de alertá-lo contra isso . Altamente O problema com isso é que é uma terra tão desconhecida que, se você se deparar com problemas, quase ninguém chegará perto do que está fazendo e questionará o que você está tentando fazer muito. É factível, mas definitivamente não é divertido .

Titcelerator Titanium

Como eu mencionei antes, eu não trabalhei muito com o Appcelerator Titanium. Então, pelas diferenças entre eles, eu sugiro que você compare Comparação entre Titanium e Phonegap ou Comparison entre Corona, Phonegap, Titanium, pois ele tem uma descrição completa das diferenças. . Basicamente, parece que, embora ambos usem JavaScript , a interpretação do JavaScript é um pouco diferente. Com o Titanium, você estará escrevendo seu JavaScript para o Titanium SDK , enquanto que com o PhoneGap, você escreverá seu aplicativo usando a API PhoneGap . Como o PhoneGap é muito compatível com os padrões HTML5 e JavaScript, você pode usar praticamente todas as bibliotecas JavaScript que desejar, como o JQuery. Com o PhoneGap, sua interface de usuário será composta de HTML e CSS. Com o Titanium, você se beneficiará do XML multiplataforma, que parece gerar componentes nativos . Isso significa que definitivamente terá uma aparência e comportamento nativos.

Eu trabalhei com Xamarin. Aqui estão os pontos positivos e negativos que encontrei:

Positivos

  1. Fácil de codificar, o C # facilita o trabalho
  2. O desempenho não será uma preocupação
  3. IU nativa
  4. Bom IDE, muito parecido com o Xcode e o Visual Studio.
  5. Depurador Xamarin
  6. O Xamarin SDK é gratuito e de código aberto. Wiki

Negativos

  1. Você precisa conhecer a API de cada plataforma que deseja segmentar (iOS, Android, WP8). No entanto, você não precisa conhecer o Objective-C ou o Java.
  2. O Xamarin compartilha apenas algumas coisas nas plataformas (coisas como bancos de dados e serviços da web).
  3. Você tem que projetar a interface do usuário de cada plataforma separadamente (isso pode ser uma bênção ou uma maldição).

O Phonegap é bem lento: clicar em um botão pode levar até 3 segundos para exibir a próxima canvas. O iscroll é lento e saltitante.

Há outros bugs e problemas engraçados que eu pude superar, mas no total – não totalmente amadurecidos.

EDIT: Por comentário Grumpy, não é Phonegap que é realmente lento, é o mecanismo nativo JS / Navegador

Há também AppGyver Steroids que une PhoneGap e Native UI bem.

Com os esteróides você pode adicionar coisas como guias nativas, barra de navegação nativa, animações nativas e transições, janelas modais nativas, gaveta / painel nativos (menu lateral do facebook) etc. para o seu aplicativo PhoneGap.

Aqui está uma demonstração: http://youtu.be/oXWwDMdoTCk?t=20m17s

Como alternativa, você pode querer verificar o BridgeIt em bridgeit.mobi. Código-fonte aberto, resolveu o problema de desempenho / consistência do navegador discutido acima, na medida em que aproveita o navegador padrão no dispositivo em comparação com o navegador de exibição da web. Ele também permite que você acesse os resources nativos sem ter que se preocupar com implantações de armazenamento de aplicativos e / ou contêineres nativos.

Eu usei se para access à câmera simples e access ao scanner e funciona bem para aplicativos simples. A documentação é um pouco leve. Não sei como isso seria em aplicativos mais complexos.