Comparação entre Corona, PhoneGap, Titanium

StackOverflow https://stackoverflow.com/questions/1482586

Pergunta

Eu sou um desenvolvedor web e eu quero mover meus produtos da Internet para iPhone. Um dos produtos é como o Google Maps:. Mostrar mapa na tela do telefone, você pode arrastar ou redimensionar o mapa e visualizar algumas informações que adicionar ao mapa

Eu sei que existem algumas tecnologias que permite que você use HTML, CSS e Javascript para desenvolver aplicativos para iPhone nativas. Eu identifiquei alguns:

Existem outros produtos similares? Quais são as diferenças entre eles? Qual eu devo escolher?

Foi útil?

Solução

Eu registrado com stackoverflow apenas com a finalidade de comentar a sua maioria votou resposta no topo. A única coisa ruim é stackoverflow não permite que novos membros para postar comentários. Então eu tenho que fazer este comentário mais parecido com uma resposta.

A resposta de Rory Blyth contém alguns pontos válidos sobre as duas estruturas móveis javascript. No entanto, seus pontos-chave estão incorrectos. A verdade é que Titanium e PhoneGap são mais semelhantes do que diferentes. Ambos expor funções de telefonia móvel através de um conjunto de APIs JavaScript e lógica do aplicativo (html, css, javascript) é executado dentro de um controle WebView nativa.

  1. PhoneGap não é apenas um invólucro nativo de um aplicativo web. Através de APIs do PhoneGap javascript, o "web app" tem acesso às funções de telefonia móvel como a geolocalização, acelerômetro Camera, Contatos, banco de dados, sistema de arquivos, etc. Basicamente, qualquer função que o SDK do telefone móvel fornece pode ser "ponte" para o mundo javascript. Por outro lado, um aplicativo web normal que é executado no navegador web móvel não tem acesso à maioria destas funções (sendo a segurança o principal motivo). Portanto, um aplicativo PhoneGap é mais de um aplicativo móvel do que um aplicativo web. Você certamente pode usar PhoneGap para embrulhar um aplicativo web que não usa qualquer APIs PhoneGap em tudo, mas não é isso que PhoneGap foi criada.

  2. Titânio não compilar seu html, css ou código javascript em "bits nativos". Eles são empacotados como recursos para o pacote executável, bem como um arquivo de imagem incorporado. Quando a aplicação é executada, estes recursos são carregados para um controlo UIWebView e executar há (como JavaScript, não bits de nativos, é claro). Não existe tal coisa como um compilador JavaScript-to-código nativo (ou-to Objective-C). Isso é feito da mesma maneira em PhoneGap também. Do ponto de vista arquitectónico, estas duas estruturas são muito semelhantes.

Agora, eles são diferentes? Sim. Primeiro, Titanium parece ser mais rico em recursos do que PhoneGap colmatando as funções do telefone mais móveis para javascript. Mais notavelmente, PhoneGap não expõe muitos (se houver) componentes de UI nativa do javascript. Titanium, por outro lado, tem uma APIs de UI abrangentes que podem ser chamados em javascript para criar e controlar todos os tipos de controles de UI nativa. Utilizaing essas APIs da interface do usuário, um aplicativo Titanium pode parecer mais "nativa" do que um aplicativo PhoneGap. Em segundo lugar, PhoneGap suporta plataformas de telefones móveis mais do que Titanium faz. APIs PhoneGap são mais genéricas e podem ser usados ??em diferentes plataformas, como iPhone, Android, Blackberry, Symbian, etc. Titanium tem como alvo principalmente iPhone e Android, pelo menos por agora. Algumas de suas APIs são plataforma específica (como as APIs do iPhone UI). O uso dessas APIs irá reduzir a capacidade multi-plataforma de sua aplicação.

Assim, se sua preocupação para seu aplicativo é torná-lo mais "nativa" olhando, Titanium é uma escolha melhor. Se você quer ser capaz de "port" a sua aplicação para outra plataforma com mais facilidade, PhoneGap será melhor.

Atualizado 2010/08/13: Link para um a resposta de empregado de titânio à pergunta de Mickey.

Atualizado 12/04/2010: Eu decidi dar este post uma revisão anual para manter sua atual informações. Muitas coisas têm mudanças em um ano em que fez algumas das informações no post inicial ultrapassada.

A maior mudança veio de titânio. No início deste ano, Appcelerator Titanium lançado 1.0, que partiu drasticamente de suas versões anteriores do ponto de vista arquitectónico. Em 1,0, o controlo UIWebView já não está em utilização. Em vez disso, você chama APIs de titânio para quaisquer funções de interface do usuário. Esta mudança significa um par de coisas:

  1. Seu UI aplicativo se torna completamente nativa. Não há mais UI web em seu aplicativo desde o Tita nativaAPIs nium assumir o controle de todas as suas necessidades de interface do usuário. Titanium merece muito crédito pelo pioneirismo na fronteira "Cross-Platform nativo UI". Ele dá aos programadores que preferem a aparência de UI nativa, mas não gostam da linguagem de programação oficial uma alternativa.

  2. Você não será capaz de usar HTML ou CSS em seu aplicativo, como a visão de web está desaparecido. (Nota: você ainda pode criar vista web em Titanium Mas há poucos Titanium características que você pode tirar vantagem de na vista web..) Titanium Q & a: O que aconteceu com HTML & CSS

  3. Você não será capaz de usar populares JS bibliotecas como JQuery que supor a existência de um objeto DOM. Você continuar a usar JavaScript como o idioma de codificação. Mas isso é praticamente a única tecnologia web que você pode utilizar se você vir a Titanium 1.0 como um programador web.

Titanium vídeo:. O que há de novo no Titanium 1.0

Agora, faz Titanium 1.0 compilar seu JavaScript em "bits nativos"? Não Appcelerator finalmente veio limpo sobre esta questão com este desenvolvedor blog: Titanium Projeto Guias:. JS Ambiente Nós programadores são pessoas mais genuínos do que aqueles no departamento de marketing, não estamos? :-)

Mover para PhoneGap. Não há muitas coisas novas a dizer sobre PhoneGap. Minha percepção é que o desenvolvimento PhoneGap não era muito ativo até IBM saltou a bordo ainda este ano. Algumas pessoas ainda argumentou que a IBM está contribuindo mais código para PhoneGap de Nitobi é. Sendo verdade ou não, é bom saber que PhoneGap é ser ativo desenvolvido.

PhoneGap continua a basear-se em tecnologias web, ou seja, HTML, CSS e JavaScript. Ele não se parece com PhoneGap tem qualquer plano para colmatar recursos de interface do usuário nativas para JavaScript como Titanium está fazendo. Enquanto Web UI ainda fica atrás UI nativa no desempenho e look and feel nativo, tal lacuna está sendo rapidamente fechado. Há duas tendências em tecnologias web que garantam recurso brilhante para UI web móvel em termos de desempenho:

  1. motor de JavaScript que se deslocam de um intérprete para uma máquina virtual. JavaScript JIT compilado em código nativo para execução mais rápida. motor Safari JS: SquirrelFish extrema

  2. página Web tornando movendo-se de contar com CPU a usar a aceleração GPU. tarefas intensivas gráficos como página de transição e animação 3D se tornar um suave muito com a ajuda de aceleração de hardware. GPU Accelerated Compositing no Chrome

Tais melhorias que são originadas a partir de navegadores de desktop estão sendo entregues para os navegadores móveis rapidamente. Na verdade, desde iOS 3.2 e Android 2.0, o controlo de vista de web móvel tornou-se muito mais realizando e HTML5 amigável. O futuro da web móvel é tão promissor que tem atraído um grande garoto à cidade:. JQuery anunciou recentemente a sua framework web móvel com o jQuery mobile fornecendo dispositivos de interface do usuário, e PhoneGap fornecendo funcionalidades do telefone, eles dois combinados cria uma plataforma perfeita web móvel na minha opinião.

Gostaria também de mencionar Sencha Touch como outro enquadramento dispositivo UI web móvel. Sencha Touch versão 1.0 foi lançado recentemente sob um modelo dual de licenciamento que inclui GPLv3. Sencha Touch funciona bem com PhoneGap assim como jQuery Mobile faz.

Se você é um programador GWT (como eu), você pode querer verificar para fora GWT móvel , um projeto open source para a criação de aplicações web móveis com GWT. Ele inclui um invólucro PhoneGap GWT que permite o uso de PhoneGap em GWT.

Outras dicas

Desde que eu recolhi, aqui estão algumas diferenças entre os dois:

  • PhoneGap basicamente gera wrappers nativas para o que ainda são web apps . Ele cospe um projeto WhateverYourPlatformIs, você construir e implantar. Se nós estamos falando sobre o iPhone (que é onde eu gasto meu tempo), não parece muito diferente de criar um lançador de aplicativo web (um atalho que recebe o seu próprio ícone Springboard, para que possa lançá-lo como ( como ) um aplicativo nativo). O "app" em si ainda é html / js / etc., E é executado dentro de um controle de navegador hospedado. O PhoneGap fornece além disso é uma ponte entre JavaScript e APIs nativas do dispositivo. Então, você escreve JavaScript contra APIs PhoneGap, e PhoneGap, em seguida, faz a apropriada chamada nativa correspondente. A esse respeito, ele é diferente de implantação de um aplicativo web antigo simples.

  • fonte de titânio é compilado para baixo em pedaços nativas. Ou seja, o seu html / js / etc. não são simplesmente ligado a um projeto e, em seguida, hospedado dentro de um controle de navegador web - eles estão se transformou em aplicativos nativos. Isso significa, por exemplo, que a interface de seu aplicativo será composto por componentes nativos UI. Existem maneiras de obter look-and-feel nativo sem ter um aplicativo nativo, mas ... bem ... o que é um pesadelo que normalmente acaba por ser.

Os dois são semelhantes em que você escreve todas as suas coisas usando tecnologias web típicas (html / js / css / blah blah blah), e que você tenha acesso à funcionalidade nativa através personalizados APIs JavaScript.

Mas, novamente, PhoneGap Apps (PhonGapps eu não sei ... é que um nome estúpido É mais fácil dizer? - Eu sei que muito) começam suas vidas como aplicações web e terminam suas vidas como aplicações web. No iPhone, seu html / js / etc. é apenas executado dentro de um controle UIWebView, e as APIs JavaScript PhoneGap seus js chamadas são encaminhadas para APIs nativas.

aplicativos Titanium tornar aplicativos nativos - eles estão apenas desenvolvido usando dev web tecnologia

.

O que isso realmente média ?

  1. aplicativo Um Titanium irá olhar como um aplicativo "real", porque, em última análise, é a "real" app.

  2. A PhoneGap aplicativo será semelhante a um aplicativo web que está sendo hospedado em um controle de navegador porque, em última análise, é uma aplicação web que está sendo hospedado em um controle de navegador.

O que é certo para você?

  • Se você quiser escrever aplicativos nativos usando habilidades dev web, Titanium é a sua melhor aposta.

  • Se você quiser escrever um aplicativo usando as habilidades dev web que você poderia realmente implantar em múltiplas plataformas (iPhone, Android, Blackberry, e qualquer outra coisa que decidir incluir), e se você quer acesso a um subconjunto de recursos da plataforma nativa (GPS, acelerômetro, etc.) através de uma API JavaScript unificada, PhoneGap é provavelmente o que você quer.

Você pode estar perguntando: Por que eu iria querer escrever uma PhoneGapp (eu decidi usar o nome) em vez de uma aplicação web que está hospedado na web? não pode ainda acessar algum dispositivo nativo apresenta dessa maneira, mas também tem a conveniência da verdadeira implantação da web ao invés de forçar o usuário a baixar meu aplicativo "nativo" e instalá-lo?

A resposta é: Porque você pode enviar seu PhoneGapp para a App Store e cobrar por ele. Você também terá esse ícone lançador, o que torna mais difícil para o usuário esquecer sua aplicação (eu sou muito mais propensos a esquecer-se sobre um marcador do que um ícone do aplicativo).

Você certamente poderia cobrar pelo acesso ao seu aplicativo web web-hospedado, mas quantas pessoas estão realmente indo para passar pelo processo de fazer isso? Com a App Store, eu pegar um aplicativo, toque no botão "Comprar", digite uma senha, e eu sou feito. Ele instala. Segundos mais tarde, eu estou usando. Se eu tive que usar outra pessoa one-off interface de transação web móvel, que meios prováveis ??ter que bater para fora o meu nome, endereço, número de telefone, número de CC, e outras coisas que eu não quero bater para fora, eu quase certamente wouldn' t passar com ele. Eu tambémconfiança Apple -. Estou confiante de Steve Jobs não vai fazer logon meu informações e, em seguida, cobrar um monte de assinaturas de revistas impertinentes ao meu CC para pontapés

De qualquer forma, exceto pelo fato de que a tecnologia dev web está envolvido, PhoneGap e Titanium são muito diferentes - a ponto de ser apenas superficialmente comparável

.

Eu odeio aplicações web, a propósito, e se você ler iTunes App Store comentários, os usuários são muito bons em detectá-las. Não vou citar nomes, mas eu tenho um par de "apps" no meu telefone que olhar e funcionar como lixo, e isso é porque eles são aplicativos web que são hospedados dentro casos UIWebView. Se eu quisesse usar um aplicativo web, eu abrir o Safari e, você sabe, navegue para um. Eu comprei um iPhone porque eu quero as coisas que são iPhone-y. Não tenho nenhum problema com, digamos, um snazzy web app Google dentro Safari, mas eu sentir enganado se o Google simplesmente escapado um marcador para Springboard, apresentando uma aplicação web como um nativo.

tem que ir agora. Minha namorada tem que podia-you-favor--stop utilizando-que-computador-para-três segundos olhar em seu rosto.

Estou fazendo um curso de Android desenvolvimento / iPhone e passamos 8 semanas com Titanium (não em tempo integral) (Versão era Titanium 1.4.2 eo tempo era por volta de novembro de 2010). Aqui é a minha experiência.

iPhone Android dupla segmentação

Mesmo que as guias da API afirmam que a funcionalidade está disponível tanto para Android e iPhone, este não é o caso. Grande parte do material simplesmente não funcionam em uma das plataformas. Algumas coisas funciona de forma diferente.

Um monte de pessoas na classe fez aplicações para o iPhone, e eles não podem fazê-los funcionar com o Android sem grandes regravações. Eu desenvolvi uma simples crianças aplicativo chamado Animap (veja android market / Appstore na Suécia) e começou a desenvolver no Windows. Uma vez que o alvo Android estava trabalhando eu abri o projeto no OS X. Ele não mostra qualquer material de construção para iPhone, apenas para Android. Você precisa para começar um projeto de destino dupla sob OS X. (Ok, eu copiou os arquivos relevantes para um novo projeto). Próximo ao problema - é que as animações não funciona no iPhone (que funciona em Android). se os eventos de rolagem não funcionam da mesma no iPhone. (Isto é, no Android você começa o evento untouch quando o usuário deixa de se mover e lança seu dedo da tela, isso não acontece no iPhone).

Uma vez que este não é mencionado em algum lugar você basicamente precisa fazer julgamento e programação erro na primeira plataforma um, em seguida, na outra plataforma. Por tentativa e erro eu quero dizer que vai demorar cerca de dois dias para obter um tão simples App como Animap trabalhando em outra plataforma. Você também precisará ter if (android), então ... ou se (iphone) ... todo o seu código ...

Faça o download e instalação

Você deve seguir as instruções ao pé da letra. Não tente usar java 64 bit. Ele não irá compilar o aplicativo demo KitchenSink 1.4.0. (1.3 funciona OK!) Você deve colocar os arquivos diretamente na unidade C como longos caminhos fará com que o programa externo não receber todos os parâmetros de linha de comando, se ficar muito tempo. (Belas para pequenos programas embora) 1/3 das vezes, o conjunto de ferramentas simplesmente pára e você deve pressionar 'lançamento' novamente. Em seguida, ele provavelmente irá funcionar ... muito confiável. O simulador não será encontrado na inicialização e, em seguida, você deve simplesmente matar de adb.exe com Ctrl + Alt + Delete e tente novamente.

Conexão de rede

Em um wi-fi à rede que, por vezes, perde a conexão ao vivo e Titanium bate em você (o / interface de compilação de implantação) Se você não tem uma conexão com a internet não vai começar, uma vez que não é possível fazer-se para seus servidores.

API

CSS, HTML e jQuery é uma brisa comparado a este. Titanium se assemelha a qualquer outro GUI API de idade, e você precisa definir algumas propriedades para cada botão / campo single / etc. Conseguir um errado campo é apenas para fácil, lembrando todas as propriedades que deve ser definido? Você soletrá-lo com letras maiúsculas no lugar certo? (Como este não é pego pelo compilador, mas será visto como um erro de execução se você tiver sorte para testar essa parte)

coisas em titânio simplesmente quebrar quando você adiciona uma outra visão em cima de um controle ou clique em outro lugar no GUI.

Documentação

Várias páginas API carregam o símbolo Android, mas só retornará um nulo quando você tenta criar o controle. Eles simplesmente não estão disponíveis na plataforma Android, apesar dos símbolos. Às vezes Android é menção não apoiar um método particular, mas, em seguida, toda a API está faltando.

KitchenSink

A aplicação de demonstração. Eu mencionei que não compilar se você colocá-lo na pasta do projeto Eclipse porque o caminho fica muito tempo? Deve ser colocado na sua unidade C na pasta raiz. Eu uso atualmente um link Symbolik (mklink / J ...)

métodos indocumentados

Você deve propably usar coisas como label.setText ( 'Olá Mundo') para alterar confiável um rótulo, mas isso não está documentado em tudo.

Depuração

Titanium.API.info ( 'As impressões são a única forma de depurar');

Editing

As APIs não estão disponíveis em qualquer formato boa para que você não pode obter o código-conclusão comum com a ajuda etc. no Eclipse. Aptana ajudar por favor!

Hardware

Parece que o compilador / ferramentas não são de vários segmentos para que um computador rápido com um disco rígido rápido é uma obrigação, como você deve fazer um monte de tentativa e erro. Eu mencionei a documentação pobre? Você deve experimentar tudo o que há como você não pode confiar nele!

Algumas coisas positivas

  • Open Source

  • A partir projetos anteriores eu prometi a mim mesmo nunca usar código fechado novamente como você não pode simplesmente corrigir as coisas simplesmente jogando horas e mão de obra para ele. Importante quando você está atrasado no projeto e precisa entregar para um prazo rígido. Esta é open source e eu fui capaz de ver porque a cadeia ferramenta breaks e realmente corrigi-lo também.

  • Bugdatabase

  • É também aberto. Você pode simplesmente ver que o seu não está sozinho e fazer uma solução alternativa, em vez de mais 4 horas gastas na tentativa e erro.

  • Comunidade

  • Parece ser ativo em seus fóruns.

Bugs

    Não
  • Titanium 1.4 é threadsafe . Isso significa que se você fizer uso de threads (usar a url: propriedade em uma chamada createWindow) e programa como os fios estão trabalhando e eventos de envio com dados e para trás você topar com um monte de muito, coisas muito estranhas - manipuladores perdidas, janelas, muitos eventos, muito poucos eventos, etc. etc. Isso tudo é dependente do tempo, colocando as linhas de código em ordem diferente pode falhar ou curar a sua aplicação. Adicionando uma janela em outro file.js quebra seu execução app.js ... Isso também trashes datastructures internos em Titanium, como às vezes pode atualizar datastructures internos em paralelo, substituindo um valor apenas mudou com outra coisa.

A maior parte dos problemas que tive com Titanium vem da minha formação em sistemas de tempo real, como OSE que suportam centenas de fios, eventos e passagem de mensagens. Isto é suposto para trabalhar em Titanium 1.4, mas ele simplesmente não fazê-lo de forma confiável.

  • Javascript (que é novo para mim) morre silenciosamente em erros de execução. Isto também significa que as pequenas e comuns erros, como erro ortográfico um nome de variável ou ler em um nulo ponteiro não falhar quando ele deve assim você pode depurá-lo. Em vez partes do seu programa simplesmente parar de funcionar, por exemplo, um eventhandler, porque você extraviado / misstyped um personagem.

  • Então nós temos erros mais simples em titânio, como alguns parâmetros que não trabalham nas funções (o que é bastante comum na plataforma Android, pelo menos).

  • Tentativa e depuração de erros velocidade do ciclo Tendo executado Titnium desenvolvedor em vários computadores, notei que o gargalo é o disco rígido. Uma unidade SSD em um laptop faz com que o ciclo de acumulação de cerca de 3-5 vezes mais rápido do que em uma unidade de 4200 rpm. Em um desktop, tendo discos duplos em RAID 1 (modo de distribuição) faz a construir cerca de 25 por cento mais rápido do que em uma única unidade com um CPU um pouco mais rápido e também bate o laptop drive SSD.

Resumo

  • A partir dos comentários neste tópico, parece haver uma luta para o número de plataformas de uma ferramenta como esta pode entregar app para. O número de API parece ser o ponto de venda fundamental.

Esta brilha muito quando você começar a usá-lo. Se você olhar para o bugtracker aberta que você vê que o número de erros continua a aumentar mais rapidamente do que o número de bugs corrigidos. Isso geralmente é um sinal de que os desenvolvedores continuar a adicionar mais funcionalidades, ao invés de se concentrar em obter o número de bugs para baixo.

Como consultor tentando entregar aplicativos bastante simples para Multiplataformas para um cliente - não estou certo de que este é realmente mais rápido do que fazendo o desenvolvimento de aplicativo nativo em duas plataformas. Isto é devido ao fato de que quando você está em velocidade de cruzeiro você é rápido com Titanium, mas de repente você olha para baixo e encontrar o seuelf em um buraco tão profundo que você não sabe quantas horas deve ser gasto para uma solução alternativa. Você simplesmente não pode prometer uma certa funcionalidade para um prazo determinado / tempo / custo.

Sobre mim: Vindo a utilizar Python por dois anos com wxPython. (Que GUI é inconsistentes, mas nunca quebra como este. Pode ser-me que não entenderam o modelo de segmentação usado por Javascript e Titanium, mas eu não estou sozinho de acordo com os seus fóruns de discussão abertos, objetos GUI de repente estão usando o contexto errado / não atualizar .. ???) antes que eu tenho experiência em C e ASM programação para dispositivos móveis.

[editar - acrescentou parte com os erros e não ser thread-safe] [Edit - agora tendo trabalhado com ele por um mês +, principalmente em PC, mas alguns no OS X também. iPhone acrescentado e Android dupla segmentação. Adicionado tentativa e erro velocidade do ciclo de depuração.]

O Corona SDK (Ansca Mobile) usa Lua como sua linguagem de codificação. Veja lua.org para saber mais sobre Lua.

Enquanto planejamos adicionar uma maior integração web e elementos-UI nativa, nosso foco tende a ser em aplicativos gráficos, tais como o desenvolvimento do jogo, ao contrário de tecnologias baseadas na web. Em outras palavras, nós não encaramos as pessoas escrevendo Corona aplicativos inteiramente em JavaScript / HTML / CSS.

Eu tenho trabalhado com titânio para mais de uma semana agora e sinto que tenho uma boa sensação sobre sua fraqueza.

1) Se você esperando que você usar o mesmo código em múltiplas plataformas boa sorte! Você verá algo como backgroundGradient e se surpreender até você descobrir versão android não apoiá-lo. Então tem que voltar a usar uma imagem de gradiente, bem como poderia usá-lo para ambas as versões para tornar o código mais fácil né?

2) Um monte de comportamentos estranhos, por Titanium SDK para Android, você precisa entender o que é uma janela "pesado" é apenas para obter o botão de volta ao trabalho, ou ainda melhor acompanhamento de eventos de orientação. Isto não é como a plataforma Android é realmente, é apenas como Titanium tenta fazer o seu trabalho API.

3) O seu jogado no escuro, as coisas vão falhar e você tem que começar a código de comentário e, em seguida, quando você encontrá-lo, nunca usá-lo. Há certos erros óbvios, como orientação e porcentagens sobre android que têm sido um problema há mais de seis meses.

4) Erros .... há um monte de erros e eles serão relatados, sente-se em torno de meses, ficar fixo em poucos dias. Estou surpreso eles ainda estão planejando lançar um SDK móvel black berry quando há tantos outros problemas com android.

5) Titanium Iphone contra máquinas Titanium Android javascript são completamente diferentes. Na versão android você pode baixar arquivos remoto javascript, incluir e bibliotecas do uso como mootools, jQuery e assim por diante. Eu estava no céu quando eu descobri isso porque eu não tenho que manter compilar meu aplicativo android. O processo de instalação apk android leva tanto tempo! Iphone nada disso é possível, também a versão do iPhone tem um motor muito mais rápido javascript.

Se você ficar longe de um monte de peças de UI nativa, ou seja, em vez usar setInterval para detectar mudanças de orientação, furando com imagens de gradiente, esqueça o botão voltar, construir suas próprias animações, esqueça cabeçalho da janela, barras de ferramentas e painel de instrumentos. Você realmente pode fazer uma API que funciona tanto que não requer de muita reescrita. Mas pelo que os pontos de sua tão lento como um webapp.

Assim, vale a pena? Depois de toda a dor, o que vale cada minuto. Você pode abstrair a lógica e apenas construir UI diferente para cada vez, em seguida, se elseing em todos os lugares. Titanium permite fazer aplicações de fluidos, que se sentem rápido. Você perde as habilidades de layout poderosos de cada plataforma, mas se você acha simples, as coisas podem ser feitas sob uma única língua.

Por que não um aplicativo web? Na entrada no mercado nível android telefones sua terrivelmente lenta para gerar um webview e consome uma grande quantidade de memória que você poderia estar usando para fazer lógica mais complexa.

Aqui está uma análise aprofundada mais recente e da Appcelerator e PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

E aqui está ainda mais detalhes sobre como eles diferem de programação: http://savagelook.com/blog/portfolio / phonegap-se-web-based Appcelerator-é-puro-javascript

MapKit nativa é suportada no Titanium

Fazendo HTML5 Widgets tha olhar como widgets do iPhone é uma coisa, mas fazê-los executar igualmente bem é outra questão. Desempenho de html5 animações (até Plain View Transitions), rolagem longas listas, capacidade de resposta aos gestos sentir pegajosa e jerky. usuário do iPhone Um vai notar a diferença.

Há também algumas diferenças nos tipos de gestos que são suportados por diferentes dispositivos que resulta em código específico de plataforma e questões de usabilidade também.

Vou ficar com aplicativos nativos por agora eu acho.

Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) é muito semelhante em abordagem para PhoneGap, mas é o único quadro com:

  1. um padrão Model View Controller (como a maioria dos frameworks web fornecer)
  2. um objeto relacional Gestor
  3. Suporte para todos os smartphones populares (incluindo o Windows Phone 7)
  4. um serviço de desenvolvimento hospedado (build não apenas hospedado): http://rhohub.com
  5. um depurador completo e SDK-less emulador na RhoStudio IDE
  6. suporte para dados offline sincronizados

Para qualquer um interessado em Titanium Devo dizer que eles não têm uma documentação muito boa algumas classes, propriedades, métodos estão em falta. Mas muita coisa está "documentado" em seu aplicativo de exemplo a KitchenSink por isso não é tão ruim assim.

O meu entendimento de PhoneGap é que eles fornecem APIs JavaScript para grande parte das APIs do iPhone.

Titanium parece mais fácil para um fundo desenvolvedor web. É um arquivo XML simples para criar um aplicativo TabView básico e, em seguida, tudo na área de conteúdo é controlado por HTML / JS. Sei também que Titanium prevê algum acesso javascript para alguns dos quadros (particularmente o acesso a informações de localização, o ID de telefone, etc).

UPDATE: Titanium acrescentou Maps API na versão 0.8 do seu quadro.

Você deve aprender c objectiva e programas aplicativos nativos. Não dependem dessas coisas que você acha que vai tornar a vida mais fácil. A Apple tem a certeza a maneira mais fácil é usar suas ferramentas nativas e linguagem. Para que sua 100 linhas de javascript que eu posso fazer o mesmo em 3 linhas de código ou nenhum código em tudo dependendo do elemento. Veja alguns tutoriais - se você entender javascript então Objective-C não é difícil. Soluções alternativas são miseráveis ??e maçã pode puxar a ficha sobre você a qualquer momento que eles querem.

Entre as soluções que você mencionou, nenhum deles parecem dar-lhe acesso directo ao quadro MapKit introduzido em OS 3.0.

Como os widgets do Google Maps HTML não são quase tão bom quanto MapKit (ver Google Latitude para um exemplo), você é provavelmente melhor fora de desenvolvimento de um aplicativo Cocoa Touch nativa, ou a escolha de uma solução que você pode estender para adicionar integração MapKit. PhoneGap é extensível dessa maneira (é open-source por isso é por padrão), e algumas das outras soluções podem ser tão bem.

edit: Titanium agora tem suporte para MapKit

Eu tentei corona. Foi bom até que eu descobri que não suporta mp3 streaming de áudio. Então, parei ali mesmo. Acho que se eu realmente quero ser um desenvolvedor de aplicativo para iPhone que eu deveria aprender obj c. Tudo o que eu queria fazer um aplicativo que tem uma lista de estações de rádio e você clicar sobre eles que começar a jogar.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top