Para quem está acompanhando a trilha Android do Google I/O, viu a pouco entrevistas com diversos devs de apps famosas (como o Pocket), dando conselhos e falando sobre suas lições aprendidas. O que mais foi falado foi sobre criar apps nativas: um deles disse sobre usar os componentes visuais do sistema, para que sua aplicação possa evoluir seu visual junto com o sistema, e outro falou sobre respeitar as convenções de cada plataforma.
Quem não pôde ver, terá oportunidade depois do evento. O vídeo é o "What is new In Android?".
Para evitar flamewars, não estou condenando quaisquer soluções apresentadas nesta thread. O que eles falaram é o ideal e nem sempre é possível fazer o ideal. Mas é importante ter consciência dos riscos de cada abordagem.
Abraço!
--
Rodrigo
http://www.rodrigocarvalho.blog.br
--
Rodrigo
http://www.rodrigocarvalho.blog.br
2012/6/27 Pedro E. Cunha Brigatto <pedrobrigatto@gmail.com>
Só para dar um encorpar um pouco mais o tópico, olha a notícia que saiu no NY Times.É iOS e não Android, mas adivinha o foco: hybrid vs. native.Muitas empresas vem migrando (vulgo "remendando a cagada que fizeram") suas apps híbridas para nativas, mas ainda assim, dada a inundação de fontes que existe (e que confundem muito o end user), empresas na condição de cliente já chegam impondo tecnologia, e em alguns casos realmente não há o que fazer. Uma pena. Mas ... c'est la vie.[]s,PedroEm 26 de junho de 2012 22:41, Artur Gonçalves <marturgsilva@gmail.com> escreveu:
Olá, pessoal.Minha humilde opinião baseada em experiência pessoal com PhoneGap em um projeto apenas: O fator experiência da equipe foi muito relevante, no nosso caso o cliente escolheu (leia-se impôs) o uso do PhoneGap por ter perfis predominantemente web na equipe dele, e o desenvolvimento nativo mostrou-se muito intimidador para os desenvolvedores web de lá e do nosso time, também. A app era um jogo bastante simples e a experiência do usuário não estava vinculada ao look-and-feel nativo do Android, portanto não houve grande impacto nesse ponto, mas em geral é um fator de peso. Embora a app fosse simples nossa equipe ficou insatisfeita com o desempenho final, e além disso tivemos problemas de adaptação de uma plataforma para a outra (um deles cheguei a postar aqui, com um evento que disparava no iOS mas não no Android). No fim das contas, acho que o único fator incontestável de ganho foi a velocidade para atender as duas plataformas, e acho que se a sua equipe já é experiente em Javascript, eles vão sofrer bem menos para gerar resultado rápido. Tem ainda a subjetividade de codificar em Javascript ou Java... gosto pessoal, como os colegas já disseram. Mas descendo do muro: Pessoalmente eu prefiro desenvolvimento nativo. :) Um abraço.ArturEm 26 de junho de 2012 21:30, Andreus Timm <andreus.timm@gmail.com> escreveu:
Obrigado Pedro, era isso que eu queria ouvir a experiência de quem já trabalhou com ambos os lados. Já fiz protótipos com Sencha e Phonegap, mas trabalhar bastante com Sencha Touch ainda não, teria que estudar bastante como ele trabalha com o MVC e as outras lib. Já o jQuery Mobile é bem simples, ainda mais quem já usou ele na web.Não sou evangelista de framework, mas temos que saber dosar as coisas.Obrigado a todos que ajudaram na discussão, se alguém tiver mais experiências para compartilhar sempre são bem vindas, abraços.
Em 26 de junho de 2012 19:34, Pedro E. Cunha Brigatto <pedrobrigatto@gmail.com> escreveu:Andreus,Na minha opinião e com base no que eu já vi em projetos, a curva de aprendizado em Secha foi bem maior, demora-se muito tempo para fazer coisas simples, que usando a API do Android diretamente você faria com os pés nas costas, suportando todas as resoluções numa boa. O framework é bem menos amigável que o Titanium e o Phonegap, e por isso é que eu te digo, HOJE, que JQuery Mobile acabaria sendo a opção mais viável, através por exemplo do próprio Phonegap. Tem uma plataforma da SAP também, que utiliza JQuery mobile como padrão para UI na sua abordagem híbrida (suporta tanto app híbrido quanto nativo).Opinião particular: vá sempre para nativo quando a decisão é exclusivamente sua. E não precisa usar lib disso, lib daquilo, lib daquele outro, framework prá cá e prá lá, prá todo lado, só pela agilidade. Arregace as mangas e traduza, na mão, camadas de domínio, acesso a BD, serviços e etc, de uma linguagem para outra. Não é difícil e não é mais que sua obrigação como desenvolvedor. E fica ainda menos complicado quando você usa OO decentemente. Então, se você quer suportar iOS, aprenda Objective-C. Se quer suportar BlackBerry, aprenda a trabalhar com a API da RIM, e daí por diante. É o que eu penso, e é o que eu faço.Entretanto, é importante analisarmos que, atualmente, o mercado está bem confuso e contaminado com tanta informação, e não é raro empresas chegarem com uma ideia e a proposta de tecnologia (hoje mesmo aconteceu isso conosco), muitas vezes sem interesse em ouvir o que você, desenvolvedor, tem a dizer. Ele tem a grana, você a mão de obra, e ele sabe exatamente o que quer e como, sabendo inclusive dos riscos!!!! Vai vendo ... hahaha curioso prá caramba! Aí, nesses casos, não tem muito o que fazer, e pagar de evangelista não vai te adiantar de nada.Ajudei, Andreus?[]s,PedroEm 26 de junho de 2012 17:22, Erick Couto <erickcouto79@gmail.com> escreveu:
Acredito que especificamente para mobile, onde os recursos geralmente são limitados, toda otimização e utilização de recursos nativos vá apresentar uma experiência mais fluida.
Existem diferenças significativas entre a UI do Android e do iOS, não dá para tratar tudo como uma coisa só.
Não vejo tanto futuro na criação de aplicações em HTML5 para mobile. (minha opinião)Em 26 de junho de 2012 17:16, luciofm <luciofm@gmail.com> escreveu:
Na verdade existem versões de 399 (ok, ainda é caro...)
Bom, ja dei minha opiniao, se a qualidade de UI/UX não é importante, vá em frente com esses frameworks... Se isso é uma premissa, vá de desenvolvimento nativo.
Lúcio Maciel
luciofm@gmail.com
2012/6/26 Rodrigo Carvalho Silva <rcsilva83@gmail.com>Lúcio, dependendo da aplicação e do tamanho da lentidão, ás vezes é "só" mesmo e não vale a pena pagar US$1k para resolver... Como o Neto falou, se a aplicação fizer tratamento de imagens, pode esquecer. Se for um CRUD, porque não?Abraço!
--
Rodrigo
http://www.rodrigocarvalho.blog.br
2012/6/26 luciofm <luciofm@gmail.com>Se performance é um "só", ok...BTW (estou falando um achismo puro, mas baseado em muita leitura), acho que o suporte android do Mono for Android é bem mais completo que o Titanium.
Lúcio Maciel
luciofm@gmail.com
2012/6/26 Rodrigo Carvalho Silva <rcsilva83@gmail.com>Lúcio,Ao meu ver, o Mono só teria a vantagem do desempenho em relação ao Titanium. De resto, é uma plataforma paga (e cara, US$999), o que pode não compensar no final...
--
Rodrigo
http://www.rodrigocarvalho.blog.br
2012/6/26 luciofm <luciofm@gmail.com>Nesse caso eu recomendaria trabalhar com o MonoTouch para iOS e Mono for Android no Android...É possivel compartilhar a parte de negócio entre os dois (se bem compartimentada, claro), e ter um aplicativo em cada plataforma.
Lúcio Maciel
luciofm@gmail.com
2012/6/26 Rodrigo Carvalho Silva <rcsilva83@gmail.com>É verdade, Neto. Me expressei mal.O que você falou é o trade-off: Quanto mais você reaproveita de código, menos a aplicação ficará com experiência nativa. Talvez valha a pena reescrever apenas a interface e reaproveitar a lógica de negócio, pois já é um ganho em relação à aplicação 100% nativa.--
Rodrigo
http://www.rodrigocarvalho.blog.br
2012/6/26 Antonio Marin Neto <netomarin@gmail.com>Só um detalhe sobre Titanium, ele NÃO gera app nativa. A interface gráfica gerada é realmente uma "tradução" pra nativa, mas o resto continua sendo JavaScript.
Inclusive, se vc baixar um IPA ou APK e descompilar o pacote vc vai achar um arquivo texto com todo o código de todos os arquivos JavaScript do seu projeto.
Digo isso por experiência própria em um grande cliente q ficou mto insatisfeito por essa questão. E assim sendo, se vc precisa de algo de mais performance, como por exemplo processamento de imagem, grandes pacotes de dados, etc, ficará um pouco frustrado.
Além disso, mesmo com Titanium não há reaproveitamento total do código. Vc precisará reescrever todo o código de interface gráfica. Claro q já é um ganho, mas eu acho q o crime não compensa.
Meus 2 centavos...
Abraços
Neto
Enviado pelo meu Windows Phone
De: Rodrigo Carvalho Silva
Enviada em: 26/06/2012 16:08
Para: androidbrasil-dev@googlegroups.com
Assunto: Re: [androidbrasil-dev] Re: SenchaTouch2 vs jQueryMobile
Estes são todos os clientes da Sencha - não necessariamente todos eles utilizaram o Sencha Touch e certamente a minoria (se é que tem algum) que utilizou o Sencha Touch embutido para imitar um app nativo.Nunca utilizei nada disso, mas, se fosse utilizar, iria de Titanium Appcelerator, porque gera uma aplicação nativa e não um webapp dentro de um WebView.
--
Rodrigo
http://www.rodrigocarvalho.blog.br
2012/6/26 Andreus Timm <andreus.timm@gmail.com>Será que as aplicações desses clientes sejam tão ruins assim? http://www.sencha.com/company/customers Tem muita empresa grande aí no meio.Acredito que vai da capacidade da equipe. Não estou descordando que talvez seja melhor desenvolver nativamente para ambas tecnologias, mas a curto prazo consigo disponibilizar uma maior acessibilidade para qualquer pessoa, fazendo poucos ajustes em um único projeto. Capitando público, web, iOS, Android, BlackBarry, etc...E infelizmente hoje tempo é $$$$.Em 26 de junho de 2012 15:28, Jonas Alves <jonasfa@gmail.com> escreveu:Assino embaixo.E minha linguagem preferida também não é Java, é Ruby. Apesar disso, não uso Ruby em Android porque não existe uma ferramenta pra isso que tenha resultados tão bons quanto o "nativo" Java tem.On Tuesday, June 26, 2012 at 3:08 PM, luciofm wrote:
Ops, enviei antes de terminar...Não é uma questão de gosto pessoal por linguagens, até porque nunca fui o maior fã de Java e só fui programar profissionalmente em Java quando comecei a desenvolver para Android, é uma questão de preocupação com a qualidade final do produto no qual estou trabalhando.Eu já fiz essa pergunta a todos defensores desses frameworks, e até agora não recebi uma resposta satisfatória.Se esses frameworks são tão bons, porque não temos nenhum aplicativo com qualidade comparavel aos melhores aplicativos nativos?Meus 2 centavos.
Lúcio Maciel
luciofm@gmail.com
2012/6/26 luciofm <luciofm@gmail.com>EU programo em Java para Android porque ela é a linguagem nativa do sistema, simplesmente por isso.. Se fosse C, C++, Objctive-C, C# programaria nessas linguagens..
Eu programo em Java no Android porque acredito que nenhum framework multi-plataforma me da a qualidade que espero em meus projetos.
E acredito que continuará assim bom um bom tempo, ainda mais que a grande maioria destes frameworks é focado em iOS, portando o iOS para o Android)
Lúcio Maciel
luciofm@gmail.com
2012/6/26 Andreus Timm <andreus.timm@gmail.com>Acho que a maioria que programa em JAVA, prefere o JAVA. Opinião pessoal de cada um.Essa foi a opinião do Lucio, Jonas e Pedro, não descordo da preferência de vocês, eu tenho minha linguagem preferida também, mas programo em java quando preciso.Jonas já desenvolvi uma app TTS (Text-to-Speech), com phonegap e utilizei uma lib externa e atendeu bem a necessidade, o PhoneGap tem essa camada JS que faz a abstração, achei isso fantastico, pois é possível transportar recursos nativos para comunicar com a "Web".Mas voltando no foco do tópico SenchaTouch2 vs jQueryMobile, os que utilizam e gostam, qual a opinião de vocês ?
Também não sei se este tópico seria OFF ou não.Em 26 de junho de 2012 14:51, Jonas Alves <jonasfa@gmail.com> escreveu:Nem sempre. PhoneGap e outras ferramentas semelhantes têm só um subset dos frameworks "nativos", pois tudo que eles oferecem precisa funcionar igual em todas as plataformas que suportam.Eventualmente você vai precisar implementar os próprios componentes "nativos" pra suprir alguma necessidade que o PhoneGap não atende.Sobre profissionais baratos: a qualidade da equipe vai impactar diretamente no resultado. Isso serve pra qualquer área técnica.On Tuesday, June 26, 2012 at 2:33 PM, Andreus Timm wrote:
Sim, claro. Nesta parte concordo contigo, mas para recursos nativos temos nosso bom amigo PhoneGap, que faz essa ponte. Posso utilizar de recursos nativos via JS.E pensando como empreendedor, hoje é mais fácil e mais barato conseguir e pagar mão de obra para Web (html, js e css) do que um programador Server Side. Basta ter um Senior na equipe para coordenar, concordas ?
Andreus Timm - Analista de Sistemas
Empresa: www.zorbit.net
Blog: www.andreustimm.com.br
Em 26 de junho de 2012 14:07, Jonas Alves <jonasfa@gmail.com> escreveu:Também não sou fã da parte técnica, mas isso já é muito particular de cada projeto.Por exemplo: eventualmente você vai precisar usar recursos do framework "nativo" da plataforma, e você precisará desenvolver componentes "nativos" e código "glue" pra fazer o "nativo" conversar com a WebView. Isso aumentará a complexidade do software e dificultará sua manutenção.Mas, como eu disse, a questão técnica é bastante particular de cada projeto.Sobre performance: com a capacidade de processamento que smartphones e tablets têm atualmente, a diferença de performance entre essas opções normalmente não é perceptível. Mas cada caso é um caso: se você pretender fazer algo CPU-bound, como manipulação de imagens em lote, a performance passa a fazer diferença.On Tuesday, June 26, 2012 at 12:17 PM, Andreus Timm wrote:
Boa tarde Jonas!
Então você só é contra na questão da usabilidade? Referente a técnologia, performance e etc...Vocês está de acordo?
Andreus Timm - Analista de Sistemas
Empresa: www.zorbit.net
Blog: www.andreustimm.com.br
Em 26 de junho de 2012 11:50, Jonas Alves <jonasfa@gmail.com> escreveu:Eu não recomendo HTML e cia em mobile por causa da experiência de usuário.Quando o usuário abre um webapp ou site no browser, ele entende que a experiência será de browser.Mas quando o usuário abre um aplicativo, mesmo sem entender detalhes técnicos, ele espera que o app e sua interface se comporte como "nativo" e que se integre muito bem na plataforma em que ele está sendo executado.Basicamente, a experiência de uso de um app "WebView" é pior do que o esperado e deixa os usuários frustados.On Tuesday, June 26, 2012 at 10:16 AM, Andreus Timm wrote:
Queria um app híbrido, (iOS, Android, etc...) comecei os testes com webview, funciona, mas acho que não vai ficar legal.Então estou pensando em reescrever as Views do projeto apenas para mobile, desenvolvendo com sencha e comunicando via json com o server.Pedro, porque você não recomenda HTML, CSS e JS no desenvolvimento para Android? Performance?
Andreus Timm - Analista de Sistemas
Empresa: www.zorbit.net
Blog: www.andreustimm.com.br
Em 26 de junho de 2012 00:58, Pedro E. Cunha Brigatto <pedrobrigatto@gmail.com> escreveu:O que você quer fazer? Um app híbrido? Web app? É app ou site? Se for app, eu recomendo a API do Android, nada além. Não recomendo nada que envolva CSS, HTML e Javascript para desenvolvimento de aplicativos móveis para devices Android,[]s,PedroEm 25 de junho de 2012 19:21, Andreus Timm <andreus.timm@gmail.com> escreveu:Ninguém?Em 25 de junho de 2012 13:10, Andreus Timm <andreus.timm@gmail.com> escreveu:Boa tarde, este é meu primeiro post no GRUPO, minhas experiencias vocês podem verificar em meu blog, não vou me alongar nos detalhes.Eu achei o SenchaTouch mais completo, pois possui uma SDK para rodar comandos via Shell.Gostaria de saber a opinião de vocês sobre esses 2 frameworks, prós, contras, features, etc... ?-------------------------------------------------------
Pedro E. Cunha BrigattoTwitter: @pedrobrigatto, GoogleTalk: pedrobrigatto@gmail.com
-----------------------------------------------------
--
-----------------------------------------------------------------
Erick Couto
Tavindo - Feriados Brasileiros
-------------------------------------------------------
Pedro E. Cunha BrigattoTwitter: @pedrobrigatto, GoogleTalk: pedrobrigatto@gmail.com
-----------------------------------------------------
--
Artur Gonçalves
Recife - Pernambuco - Brasil
"Ser autêntico é parecer-se mais e mais com o que você sonhou ser."
-------------------------------------------------------
Pedro E. Cunha BrigattoTwitter: @pedrobrigatto, GoogleTalk: pedrobrigatto@gmail.com
-----------------------------------------------------
0 comentários:
Postar um comentário