Desenvolvendo aplicativo móvel multiplataforma [fechado]


109

Mais e mais plataformas móveis estão sendo lançadas e os SDKs estão disponíveis para desenvolvedores. Existem várias plataformas móveis disponíveis: Android, iOS, Moblin, Windows mobile 7, RIM, symbian, bada, maemo etc.

E a criação de aplicativos multiplataforma é uma dor de cabeça para os desenvolvedores. Estou procurando coisas comuns entre as plataformas que ajudarão os desenvolvedores que desejam portar aplicativos para todas as plataformas. Como quais são as diferentes resoluções de tela, métodos de entrada, suporte a gl aberto, etc., compartilhe detalhes que você conhece para qualquer plataforma.

Ou existem possibilidades, escrevendo o código em html (tipo de widget) e carregando-o no aplicativo nativo. Eu sei sobre o Android, no qual podemos adicionar a visualização da web ao aplicativo chamandosetContentView(view)

Compartilhe os detalhes da aula onde podemos adicionar a visualização html no aplicativo nativo de diferentes tipos de plataformas que você conhece.

O objetivo deste tópico é compartilhar detalhes comuns entre os desenvolvedores. marcando como wiki da comunidade.

Ferramentas e biblioteca multiplataforma


1
Embora eu tenha encontrado um tópico interessante relacionado a este, stackoverflow.com/questions/3326110/…
sohilv

outra boa postagem sobre desenvolvimento de plataforma cruzada: stackoverflow.com/questions/51988/…
sohilv

1
Votado para fechar isto como uma duplicata. Isso é muito importante para ser dividido em duas questões. stackoverflow.com/questions/51988/…
ripper234

Respostas:


97

Minha resposta aqui cobre algumas das limitações técnicas das ferramentas de plataforma cruzada, mas deixe-me expandir um pouco:

Acho que as ferramentas de plataforma cruzada sempre foram historicamente perdidas porque essas ferramentas têm o foco filosófico errado.

Todos os argumentos de venda para ferramentas de plataforma cruzada são os benefícios que trazem aos desenvolvedores . Eles estão convencidos de que permitem aos desenvolvedores escrever uma vez, executar em qualquer lugar. Eles estão convencidos de que permitem aos desenvolvedores expandir seu mercado sem aprender novas APIs. Eles estão convencidos de que permitem aos desenvolvedores reduzir custos e tempo de lançamento no mercado.

A ferramenta de plataforma cruzada que NÃO se vende é o benefício que trazem aos usuários finais .

O benefício para o usuário final não é um argumento de venda porque o desenvolvimento de plataforma cruzada raramente é um benefício para o usuário final. O usuário final não se importa com o quão duro o desenvolvedor teve que trabalhar para levar o produto ao mercado. Eles também não se importam em quantas plataformas o aplicativo pode ser executado quando eles não usam apenas uma plataforma. Eles apenas se preocupam se o aplicativo faz o que eles precisam no hardware em que precisam para executá-lo. A menos que eles tenham uma necessidade específica de executar o aplicativo em muitas plataformas diferentes, o fato de que isso não traz nenhum valor.

Por outro lado, os compromissos inevitáveis ​​de fazer uma API de plataforma cruzada significam que todos os aplicativos criados pela API terão a melhor classificação B em todas as plataformas. Eles nunca serão a melhor ferramenta para usar em cada plataforma.

Tudo isso significa que, na maioria dos casos de uso, as ferramentas de plataforma cruzada fornecem ao usuário final um produto inferior em comparação com aqueles feitos com APIs específicas da plataforma. O usuário final sempre terá uma escolha melhor.

Você ganha dinheiro a longo prazo, dando aos usuários finais as ferramentas mais úteis. Se você não se concentrar filosoficamente em tornar a vida do usuário final mais fácil e produtiva, você estará condenado desde o início. Os usuários finais têm muitas opções e se sua ferramenta não for uma das melhores, você não vai fazer isso no mercado.

Você só deve usar ferramentas de plataforma cruzada se achar que "os usuários realmente se beneficiarão ao executar este aplicativo em muitas plataformas diferentes". Se você começar a olhar para as ferramentas de plataforma cruzada apenas porque elas facilitarão a sua vida (dos desenvolvedores), então você as escolheu pelo motivo errado e elas irão prejudicá-lo mais do que ajudar.


52
Bem menos trabalho (desnecessário) para os desenvolvedores significa ciclos de atualização mais rápidos, novos recursos mais rápidos, correções de bugs mais rápidas e assim por diante. Com a mesma mão de obra, mais pode ser alcançado. Considero isso um benefício para o usuário final.
schoetbi 01 de

10
Em teoria, o desenvolvimento mais rápido pode ser melhor para o usuário final, mas esse não é o fundamento filosófico da maioria das APIs de plataforma cruzada. Tenho visto muitas tentativas de usar essas ferramentas em vários ambientes e o foco está sempre em facilitar a vida do desenvolvedor em detrimento da qualidade do produto final. Além disso, a promessa de mais rápido e mais barato raramente se concretiza. Sempre parece haver um empecilho em algum lugar que consome a maior parte do tempo.
TechZen

5
Para esclarecer meu ponto de vista, considere o seguinte: APIs de plataforma cruzada existem para muitas classes diferentes de hardware e sistema operacional. Quantos aplicativos multiplataforma você usa regularmente? Quantos aplicativos de plataforma cruzada você já usou e pensou bem? As pessoas têm promovido APIs de plataforma cruzada desde que existem mais de uma plataforma, mas nunca tiveram sucesso em lugar nenhum. Eles não têm sucesso porque não produzem os aplicativos mais úteis para os usuários finais.
TechZen

4
@TechZen - Estou usando o StackOverflow agora no meu navegador da web e não vejo nenhuma razão para procurar um cliente nativo. Eu acho que você generalizou suas afirmações.
Youval Bronicki

4
Estou bastante chateado porque esse tipo de debate filosófico subjetivo recebe a nota correta em um site técnico. O que é pior, a tese deste post é inválida para a maioria dos principais softwares que usamos hoje: navegadores da Web são multiplataforma; Photoshop, MS Office, Dropbox e outros produtos são multiplataforma; apenas abra o menu Iniciar ou Finder e liste os caras específicos da plataforma - as chances são de encontrar pequenos utilitários. Seu argumento seria válido se você acredita que os telefones celulares são radicalmente diferentes (uma suposição altamente válida), mas parece não haver argumentos para construir essa base.
kizzx2

14

Existem várias abordagens para o desenvolvimento de plataforma cruzada em dispositivos móveis. Claro que todos eles têm limitações. Nenhuma solução consegue aproveitar todas as funcionalidades do aparelho como um aplicativo nativo.

Reutilizar código

Embora todos os sistemas operacionais móveis não usem a mesma linguagem de desenvolvimento e API, às vezes você pode compartilhar algumas classes ou código de camada lógica.

C ++, por exemplo, provavelmente pode ser reutilizado para um aplicativo iOS , para um aplicativo Android usando o NDK , para um aplicativo Symbian, uma vez que são desenvolvidos em C ++, etc.

Algumas soluções também oferecem a possibilidade de escrever o aplicativo em um idioma diferente do normalmente usado pelo dispositivo. Os mais famosos (na verdade, os únicos que conheço) são comerciais e baseados no projeto Mono (desenvolvimento C #):

Mas não tenho certeza se podemos realmente chamar isso de desenvolvimento de plataforma cruzada, uma vez que a reutilização do código é limitada dependendo do dispositivo:

  • O Windows Phone 7 não permitirá o desenvolvimento de código nativo (talvez em novas atualizações)
  • O projeto do tipo mono AFAIK não existe para todas as plataformas (ainda?) Bada, webOS, maemo, etc.

E a parte da IU também permanece específica para cada dispositivo.

desenvolvimento web

Uma resposta regular ao perguntar sobre o desenvolvimento de plataforma cruzada para celulares é o desenvolvimento para web. Precisamos então de um wrapper, que usará o navegador móvel, para fazer com que pareça e se comporte como um aplicativo nativo. É assim que parte da estrutura de plataforma cruzada que veremos mais adiante funciona.

O surgimento do HTML5 traz para o desenvolvimento web funcionalidades que só poderiam ser feitas com um aplicativo nativo como geolocalização, aplicativo off-line e armazenamento local.

Podemos encontrar cada vez mais estruturas para desenvolver aplicativos da web para dispositivos móveis com uma aparência nativa, aproveitando os mais recentes padrões da web HTML5, CSS3, Js:

Mas o HTML5 ainda é muito jovem e a implementação pode variar de um navegador para outro. A maioria dos navegadores móveis padrão usa o motor WebKit (a principal exceção é o Windows mobile / telefone usando o Internet Explorer) e mesmo assim eles não suportam necessariamente as mesmas funcionalidades . O banco de dados local ainda é difícil de trabalhar e não podemos ter certeza de como ele será implementado pelos diferentes navegadores. Além disso, mesmo com HTML5, o desenvolvimento web ainda é muito limitado em comparação com um aplicativo nativo. Você não pode acessar contatos, câmera, acelerômetro, etc.

Edit: No início deste mês, o W3C emitiu alguns avisos sobre a evolução do HTML5: Artigo da ZDNet

Portanto, ele só se adequará a uma categoria limitada de aplicativos.

Estruturas multiplataforma

E então temos as estruturas de aplicativos móveis de plataforma cruzada. Com o qual você pode provavelmente desenvolver uma vez e implantar em diferentes plataformas. Essas soluções geralmente se concentram em iOS e Android e contam com o mecanismo WebKit. Eles oferecem mais interação com as funcionalidades do telefone durante o desenvolvimento com tecnologias web. Os mais conhecidos são Nitobi PhoneGap, RhoMobile Rhodes, Appcelerator Titanium. Mas muitos outros estão por aí e nem todos usam a mesma técnica como MoSync, que traduz seu código para sua própria linguagem intermediária antes de compilá-lo para a plataforma desejada.

[1] Lembre-se de que a Apple tem uma política especial sobre aplicativos escritos para sua plataforma. Eles não parecem estar bloqueando esses aplicativos no momento, mas é uma informação que deve ser levada em consideração. Editar: a Apple mudou essa política desde 9 de setembro.


6

Você obtém alguns pontos em comum ao implantar como um webapp (html5 como mencionado acima), mas para aplicativos nativos ricos, as APIs são completamente diferentes para os vários smartphones.

O HTML5 pode melhorar um pouco as coisas, mas para fazer coisas interessantes você precisa se tornar nativo.

Existem frameworks para smartphones de 'plataforma cruzada', como Phonegap, mas ouvi muitas coisas ruins sobre como usá-lo para um trabalho "real". (muita sobrecarga, etc)


5

Sim, o html5 está recebendo alguma atenção. Você também deve olhar para este consórcio e plataforma que virá no quarto trimestre. Não tenho certeza sobre o sucesso desse projeto, pois parece um grande desafio, mas aqui estão os detalhes:

Site: http://www.wholesaleappcommunity.com/default.aspx

Notícias: http://news.google.de/news/search?aq=f&pz=1&cf=all&ned=us&hl=en&q=%22Wholesale+Applications+Community%22

O WAC pretende publicar sua especificação inicial e componentes de seu SDK para desenvolvedores em novembro. Esta especificação será baseada nos padrões W3C e criará uma plataforma forte para o desenvolvimento de aplicativos da web móveis ricos. O WAC também fornecerá compatibilidade com versões anteriores para dispositivos com base nas especificações JIL e BONDI atuais. ( http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=31021 )

.

É uma coalizão internacional de cerca de 25 empresas de telecomunicações que tem como objetivo criar uma plataforma aberta a todos os desenvolvedores e vendendo para todos os usuários de telefones celulares. ( http://www.downloadsquad.com/2010/02/15/atandt-wholesale-applications-community-is-a-platform-not-an-app/ )


1

Pelo que eu sei, a maioria desses dispositivos é capaz de executar isso:

Java ME - a plataforma de aplicativos mais onipresente para dispositivos móveis

Acho que isso pode servir como bom e mau exemplo.


Na verdade, não há java no iPhone e, pelo que eu sei, java me não roda no Android
Alaa Nassef

O desenvolvimento do Android é maciçamente Java. developer.android.com/reference/java/net/package-summary.html
Nick Garvey

Não sei os detalhes, mas o Avian JVM permite que o java seja executado em dispositivos iOS.
Quazi Irfan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.