Saltar para conteúdo


Foto
- - - - -

Porquê que é preciso um plugin melhor que o ADT...


  • Por favor inicie sessão para responder
3 respostas a este tópico

#1 Nazgulled

Nazgulled

    Membro

  • Membros
  • PipPip
  • 216 mensagens

Mensagem publicada 27 October 2010 - 13:11

Recentemente foi anunciado que o Android Market chegou as 100k apps e eu fiz um comentário no Twitter acerca dessa afirmação, algo que despoletou alguma controvérsia e uma discussão interminável. Isto porque o Twitter não é o melhor sitio para se ter estas discussões. É complicado uma pessoa exprimir-se em 140 chars o que cria bastantes mal entendidos de ambas as partes. Que foi o caso, provocou demasiada confusão e já começava a falar de coisas diferentes.O meu comentário relativamente a essa notícia foi que essas 100k não passam de números que não significam rigorosamente nada. Como se costuma dizer por cá, são para inglês ver, são fogo-de-vista. Nem metade (e já estou a ser generoso) é boas aplicações, bem programadas ou bem desenhadas. Mas a discussão não se centra aí, mas sim, no que eu disse de seguida. Que grande parte da culpa disso está nas ferramentas de desenvolvimento para Android, nomeadamente o plugin para o Eclipse.Se não tens qualquer interesse nesta discussão, fecha agora o tópico. O que eu vou escrever vai ser longo e é mais direccionado para quem estava a ter esta discussão comigo no Twitter, mas qualquer um é bem-vindo a participar.A primeira reacção que alguém teve ao que eu disse foi uma comparação com o iPhone/Apple e quero já aqui frisar que isso pouco importa. Eu nunca fiz tal comparação e nada do que eu afirmei está relacionado com o iPhone/Apple, isso é outra discussão completamente à parte. A notícia é das 100k apps no Android Market e é somente isso que está em discussão.A minha principal crítica é ao plugin de desenvolvimento de Android para o Eclipse que é péssimo e não ajuda nenhum programador a desenvolver boas apps para o Android. Há coisas básicas e comuns que deveriam ser triviais a desenvolver, mas no Android não é assim que se passa. E só para evitar discussões paralelas, não há qualquer necessidade de discutir outro IDE qualquer porque não é isso que está em causa. Eu não estou a criticar o Eclipse, mas o plugin que a Google fez porque a grande maioria dos programadores para Android deve usa-lo, o resto não interessa. Mas é óbvio que posso desenvolver apps para o Android no bloco de notas se assim me apetecer. Mas não é isso que importa.Algo que provocou grande discussão no Twitter foi o facto de eu afirmar que não entendo como alguns programadores não conseguem ver a porcaria que é as ferramentas disponibilizadas para desenvolvimento Android. Como é que acham o editor perfeito ou suficiente e não vêem falhas no mesmo ou formas que o pudessem melhorar. Acho isto um grande defeito em quem pensa assim porque no fundo estão-se a conformar com o que existe, algo que pode ser bastante melhor, basta a Google querer e apostar fortemente nisso e não me admira nada que um dia isso venha a acontecer e depois vão-me dar razão. O plugin é muito mau e a sério que não percebo como é que se conformam com isso e não conseguem ver como é que podia ser melhorado e inovado. Um programador não pode ser assim ou não passa de mais num mercado que já começa a ficar saturado. Não se pode ser mais um, tem de se saber inovar e ter ideias para melhorar o que já existe.Hipoteticamente, se eu fosse CEO de uma empresa, nunca na vida empregava alguém assim e empresas como a Google, por exemplo, não querem pessoas assim. Eles querem pessoas que pensem “fora da caixa”. E vocês estão-se a conformar bastante dentro da caixa e nem se quer vos interessa o mundo que existe fora dela. Pelo menos é isso que os vossos comentários no Twitter (eles sabem quem são, não vale a pena apontar nomes; mas isto também não é uma ofensa lol) me fazem pensar. Porque se fosse o contrário, vocês já tinham percebido o que eu disse e eu não estava aqui a escrever isto :D Reparem numa coisa, o que seria do nosso mundo se pessoas como o Einstein, Newton, Galileu entre muitos outros, se tivessem conformado com o mundo em que viviam? Se calhar por esta altura não estávamos aqui a ter esta discussão sobre smartphones e Android, já pensaram nisso? Conclusão… O plugin é muito mau e não ajuda em nada a desenvolver apps minimamente decentes e só não vê isto quem não quer. Há tanta mas tanta coisa que podia ser melhorada e sem limitar programadores experientes e/ou mais avançados que precisam de mais flexibilidade, a sério que não percebo como não vêem isto.Num dos tweets apontei para este link:http://blog.radioactiveyak.com/2010/09/why-you-might-want-wysiwyg-layout.htmlE acho que dá para perceber que não sou o único com esta opinião e mais programadores pensam o mesmo. Apesar de que esse post no blog do Reto, é bem mais abrangente do que aquilo que eu estou aqui a discutir. Mas dá para ter uma ideia.O editor WYSIWYG do plugin para o Eclipse é simplesmente a coisa mais estúpida que alguma vez tive a infelicidade de usar. Conseguiu superar as dores de cabeça provocadas pelo Swing no Netbeans. Essa é uma das grandes razões pela qual ainda não decidi fazer uma app para Android, simplesmente não tenho tempo a perder com merdinhas triviais que deviam ser conseguidas em poucos segundos (já lá vamos a exemplos).Um outro comentário que me fizeram no Twitter foi que podia fazer o UIs no Illustrator. E quero só aqui dizer que isso não tem nada ver lol. Lá está, uma das confusões criadas nas discussões pelo Twitter foi isto. O Illustrator/Photoshop não é para aqui chamado, não se trata de desenhar UIs extravagantes cheios de gráficos e bonitinhos, não é isso que está em causa. O UI vai muito mais para além de “desenhos” numa aplicação gráfica. Eu posso muito bem desenvolver uma aplicação sem qualquer tipo de desenho extra, usando apenas os controlos nativos da plataforma e é precisamente isso de que eu me queixo no Android. Só queria tirar isso da frente da discussão porque não interessa. Não estou a falar desse tipo de UIs, óbvio, que nessas situações, é complicado existe um editor WYSIWYG, o UI pode ser de 1001 maneiras diferentes. A questão é aplicações nativas com controlos nativos.Vamos lá a um exemplo para vos provar porquê que o plugin é muito mau e não ajuda os programadores a desenvolver boas apps para Android.Um programador não é um designer. Um programador até pode ser bastante preguiçoso e não ter mesmo jeitinho nenhum para desenhar o que quer que seja. Mas daí a desenvolver um UI péssimo como este (http://i54.tinypic.com/11wadg8.png) ainda vai um passo bastante largo. Não me parece que a culpa deste UI seja apenas do programador e da sua preguicite aguda. Como é que é possível, alguém, ter uma caixa de texto com o próprio texto dentro dela completamente desalinhado? O UI desta aplicação é básico, devia ser trivial desenhar um UI em condições para uma aplicação destas, pelos vistos não é. E não se precisa de ser designer para desenhar um UI destes.Muitos de vocês são capazes de ter esta opinião sobre o editor do plugin para o Eclipse e dizerem que estão satisfeitos e que faz o seu trabalho. Mas não faz. Mais uma vez a vossa conformidade. A questão é que um dia que haja algo melhor vocês vão se perguntar a vocês mesmo, como é que algum dia se deram ao trabalho de desenvolver aplicações para Android sem esse novo sistema. É sempre assim e vocês sabem que tenho razão. O que me espanta é como é que não conseguem admitir isso, admitir que a plataforma de desenvolvimento tem problemas. Problemas que devem ser corrigidos. Problemas esses que fazem com que aplicações que poderiam ser muito boas não passem de aplicações medíocres.É por isso que o Android, como plataforma de desenvolvimento e não do Sistema Operativo, como plataforma com apps de qualidade e não de quantidade, nunca irá sair do 2º lugar. Esta comparação com a Apple é inevitável apesar de eu advertir no início para não se fazerem estas comparações. Mas isto não é propriamente uma comparação porque no caso da Apple, existem restrições e um processo de avaliação de apps antes de estas serem publicadas na App Store, mas eu sou contra esse processo (principalmente nos moldes da Apple) e sou completamente contra a um processo semelhante no Market. Um dos trunfos do Android é a liberdade que existe. Contudo, não é preciso existir um processo de avaliação de apps para o Android ter apps de qualidade como o iPhone, mas é preciso fazer-se outras coisas. Coisas que ajudem os programadores a desenvolver apps de qualidade. E na minha opinião, o primeiro passo, é um plugin decente e não a porcaria do ADT.No fundo isto resume-se a uma coisa, aplicações/controlos nativos e comuns a muitas aplicações devem ser triviais de desenvolver. Um programador não deve perder tempo quase nenhum a desenvolver algo que é comum em muitas das apps que faz, algo que é nativo ao Android e que segue os padrões de desenvolvimento de Android, por exemplo, menos de configurações ou painéis de tabs. Isso devia ser trivial de desenvolver com recurso a um editor decente e neste momento não é.O que é um editor de UI decente? O Visual Studio e os seus Windows Forms. Quem já trabalhou com isto (mas trabalhar mesmo não é instalar ver que é bonito e pronto) sabe bem do que falo. Um editor semelhante para Android e acreditem, ia-se começar a ver aplicações nativas para Android desenvolvidas sem menos de metade do tempo e em conformidade com os padrões de desenvolvimento para Android.É isso que, na minha opinião, faz grande falta ao ADT pois o actual é simplesmente péssimo. Desenvolver um simples sistema de tabs (tipo isto: http://httc.me/wp-co...snapshot_01.jpg) devia ser trivial e não dar trabalho nenhum. Mas como é que tal coisa pode ser desenvolvida em Android? Nada mais que uma quantidade enorme de input de código manual (http://developer.and...-tabwidget.html). Isto não é nada bom para qualquer programador. Os que experientes e que se desenrascam perdem tempo com o código, os principiantes perdem tempo a aprender uma coisa que não devia ser necessária (a não ser que quisessem expandir para além do básico). Como é que tal coisa é desenvolvida em Windows Forms no Visual Studio? Arrasto o controlo para o Form, com um click do botão adiciono as tabs que quiser. Facilmente mudo o nome das tabs e alterno entre elas no próprio editor como se a aplicação estivesse a correr. Isto permite-me facilmente adicionar qualquer botão, caixa de texto ou whatever a tab que quiser. Em Android? Só tenho de fazer tudo no código à pata…Mais uma vez, não me estou a referir a desenvolver aplicações como o Touiteur (por exemplo) que de nativo pouco tem (para além dos menus e da lista de definições), pois usa uma data de controlos personalizados que é precisamente o que fazem a aplicação distinguir-se de outras. Óbvio que é demasiado complicado ter-se um editor para desenvolver os mais diversos UIs e controlos tipo os usados no Touiteur. Mas desenhar UIs simples e triviais como os mencionados anteriormente, devia ser directo e ser feito em segundos sem grandes preocupações com o código.Devem estar a pensar que assim têm mais controlo sobre o código e que não é gerado lixo… Pois, os tempos de editores que geram lixo já vai longe e isso só acontecia mais em HTML. O código gerado pelo Visual Studio é limpo e bastante simples. Facilmente pode ser modificado à mão se for necessário e o editor adapta-se a essas mudanças. E como o Reto diz no seu blog, “there's no reason an Android layout editor can't produce beautiful XML” e tem toda a razão. Por isso, essa questão nem se pode colocar. Isto sou eu a antecipar-me aos vossos contra argumentos :PSerá que, finalmente percebem onde eu quero chegar e conseguem finalmente admitir que o actual editor visual do ADT é simplesmente a pior coisinha de sempre? A sério, façam uma aplicação em Windows Forms e vejam a facilidade que aquilo tem em desenvolver-se aplicações triviais e nativas ao Sistema Operativo com a possibilidade de personalizarem o que quiserem (se assim entenderem) escavando o código e alterando-o manualmente.Eu sei precisamente do que falo porque já desenvolvo em Windows Forms aos anos. E ainda mais, já desenvolvi controlos personalizados de raiz para o Windows Forms. O que significa isto? Significa que já desenvolvi um controlo onde lhe tive de dar suporte em “tempo de desenho”, ou seja, de forma que qualquer programador ao usar o meu controlo, apenas o tivesse de arrastar para o Form e configurar ali, no próprio Form e/ou na lista de propriedades, as opções e configurações mais triviais e comuns ao respectivo controlo. Acreditem, o Visual Studio é muito poderoso neste aspecto e se o Android tivesse algo semelhante, só tinha a ganhar com isso. Por exemplo, eu podia desenvolver um controlo de listagem de tweets semelhante ao Touiteur por exemplo e publica-lo. Qualquer programador iria puder usa-lo sem se preocupar como é que tal coisa foi programada e sem perder tempo a desenvolver um próprio. Isto ajudava tudo e todos. E podia ainda ser um controlo que tivesse a possibilidade de se expandir (para que todos que usem o controlo não ser igual em todas as apps porque neste exemplo, seria um controlo muito especifico, mas há controlos que se quer que sejam iguais em todas as apps, como algo que seja nativo, ie: tabs) com overrides aos métodos e tudo mais. As possibilidades são infinitas.Uma pequena nota, eu quando digo controlos, para quem não está familiarizado com esta terminologia, no Android penso que se chama widgets (não confundir com os widgets no ecrã).Conclusão… Enquanto para Android se perde imenso tempo a configurar todos os pormenores dos controlos manualmente no código, em Windows Forms, apesar de se puder fazer pelo código, temos a disposição uma lista de propriedades que facilmente permite configurar as opções mais triviais. Ou então no próprio designer, o que em certas coisas facilita bastante. Desafio-vos a sentarem-se ao meu lado e a desenhar uma simples app com tabs de raiz (sem copy/paste de código) como aquela do link que partilhei mais acima. Vocês em Android e eu em Windows Forms e vamos ver a facilidade com que cada um desenvolve uma simples app como essa. Até nem precisa de ser ao meu lado, bora fazer um vídeo e comparar? Aceitam o desafio ou será que me dão alguma razão que o ADT podia ser muito melhor que o que é? :PP.S: Espero que não tenham ficado ofendidos com nada do que eu tenha dito, está longe de ser a minha intenção.

#2 r3pek

r3pek

    Guru de Android

  • Former Staff
  • PipPipPipPipPip
  • 1560 mensagens
  • LocalizaçãoBA4 - Terceira - Açores
  • Nexus One + Motorola XOOM

Mensagem publicada 27 October 2010 - 13:29

Bem, afinal sempre era o que estava a pensar :D Compreendo a tua "insatisfação" e percebo a tua visão do visual studio. Nunca trabalhei com ele mas trabalhei com Delphi (no tempo em que era grande), e pelo que contas as coisas são muito parecidas.Mais logo posso fazer um video com o que dizes :PSó um comentário ao 1º exemplo que deste de péssima UI. concordo plenamente que aquilo é uma pessima UI, mas nota-se também que o programador não teve cuidado nenhum com o desenho da UI. Uma UI daquelas "como deve de ser" são 2 minutos a fazer no designer do ADT (no meu portatil é mais pk não tenho resolução decente nakilo :D).Anyway, quando tiver o video posto aqui para veres. Ou se alguém tiver mais tempo que eu, que o faça :P

#3 Nazgulled

Nazgulled

    Membro

  • Membros
  • PipPip
  • 216 mensagens

Mensagem publicada 27 October 2010 - 15:37

[quote name="r3pek" post=80916]Nunca trabalhei com ele mas trabalhei com Delphi (no tempo em que era grande) e pelo que contas as coisas são muito parecidas.[/quote]O Delphi ficou parado no tempo, dúvido muito que se assemelhe ao Visual Studio. E nisto não me refiro ao arrastar controlos e configurar as propriedades num painel com os mesmos. O Visual Studio vai muito mais para além disto.[quote name="r3pek" post=80916]Só um comentário ao 1º exemplo que deste de péssima UI. concordo plenamente que aquilo é uma pessima UI mas nota-se também que o programador não teve cuidado nenhum com o desenho da UI.[/quote]A questão é mesma essa... Um UI daqueles não devia precisar que o programador tenha qualquer tipo de cuidado. Aquela aplicação não precisa de ser mais que o que é, mas também não convém chegar ali e despejar os controlos e pronto.Se o ADT tivesse algo parecido com o Visual Studio, o programador podia fazer um UI igualmente simples, sem ter qualquer tipo de cuidado como o que falas (mais uma vez, não é despejar os controlos e esperar que as coisas apareçam alinhadas como é óbvio) e mesmo assim o UI ficar bem alinhado e etc...[quote name="r3pek" post=80916]Uma UI daquelas "como deve de ser" são 2 minutos a fazer no designer do ADT (no meu portatil é mais pk não tenho resolução decente nakilo :D).[/quote]Uh? Tens 640x480? Como é que não tens resolução?[quote name='"r3pek" post=80916]Anyway quando tiver o video posto aqui para veres. Ou se alguém tiver mais tempo que eu' date=' que o faça :P[/quote']Isso do vídeo não era assim sem mais nem menos nem era fazer por fazer...A questão é que se tu fizeres um sistema de tabs e adicionares coisas a todas as tabs, sem copiares qualquer código seja de onde for, fazendo tudo manualmente com as funcionalidades à tua disposição no Eclipse/ADT, vais sempre demorar mais tempo que eu num editor tipo Visual Studio/Windows Forms.Atenção que eu nunca disse que não conseguias ou que não dava, apenas estou a dizer que a facilidade com que se faz algo desse género, algo nativo e comum a muitas aplicações, no Visual Studio não tem comparação ao Android. Eu consigo fazer tudo isso sem ir ao código uma única vez e no Android não consegues isso. O facto de não ter que escrever qualquer tipo de código para algo tão trivial/comum, poupa-me imenso tempo.É somente isso que estou a dizer, há muita coisa a ser melhorada no ADT, está longe de ser perfeito. E como disse, não me admira nada que um dia a Google invista nisso se é que já não estão a investir.

#4 pedronveloso

pedronveloso

    Veloso

  • Administradores
  • 1578 mensagens
  • S8

Mensagem publicada 27 October 2010 - 16:15

Wow.. realmente colocas-te aqui um valente texto. Sendo assim vou responder por partes citando a parte que estou a responder, para conseguir que fique perceptível.

Recentemente foi anunciado que o Android Market chegou as 100k apps e eu fiz um comentário no Twitter acerca dessa afirmação, algo que despoletou alguma controvérsia e uma discussão interminável. Isto porque o Twitter não é o melhor sitio para se ter estas discussões. É complicado uma pessoa exprimir-se em 140 chars o que cria bastantes mal entendidos de ambas as partes. Que foi o caso, provocou demasiada confusão e já começava a falar de coisas diferentes.

Concordo.

O meu comentário relativamente a essa notícia foi que essas 100k não passam de números que não significam rigorosamente nada.

Exacto. Basta ver que existem dezenas (se não centenas) de apps de peidos e coisas assim :PIsto é o pessoal fanboys a tentar fazer um bocado de "OS war" com os Iphones, que também usam o mesmo argumento do nº de apps para se gabarem. O mesmo se aplica à app Store deles.--Em resposta ao resto do tópico:A percepção que tenho sobre a plugin do Eclipse é a seguinte : a nível de auxilio de código, debugging e de deployment da aplicação para um formato APK penso que está razoável e dentro do que seria espectável. Por outro lado, o editor gráfico de layouts, o que vês lá não é aquilo que obtens no dispositivo muitas das vezes.Talvez interpretes isto como conformismo com uma gralha da ferramenta da minha parte, mas eu sinto-me bem com o sistema, porque acabo por ser capaz de safar recorrendo a ferramentas externas. Talvez isto não esteja devidamente divulgado ainda, mas se deres uma olhadela nesta página : http://speckyboy.com...s-and-tools/vês que até existem bastantes recursos externos sobre os quais te podes apoiar para ter maior produtividade, e a fim de ter um editor mais agradável. Tu percebes as tuas coisas de web development, e decerto já deves ter recorrido a mais que uma ferramenta para partes diferentes da página. E apesar de nessa página que te dei não teres ainda um editor WYSIWYG consolidado, estão lá algumas das bases necessárias para algum dia termos. Eu concordo que o editor visual do plugin não é lá grande coisa, mas a Google deixou o caminho aberto para quem quiser fazer algo melhor, o que é positivo. As especificações de como a coisa funciona e recursos são dados, quem sabe alguém com a mesma visão que tu não veja aqui uma oportunidade de negócio. Uma plugin complementar assim para Android poderia ser paga, que de certeza quem a fizesse teria bastantes lucros, ainda para mais com o número de empresas de nome que estão a apostar em Android recentemente, e de certeza apostariam em ferramentas mais RAD que a actual plugin. A título de exemplo, uma plugin complementar que uso é o Sequoyah Android Localization Editor, que é uma plugin que faz aquilo que o editor de XML nativo não faz, proporciona veres o strings.xml de todas as línguas que incluíste ao mesmo tempo, e para fins de tradução é muito melhor. Essa no entanto não é paga, mas pelo preço certo de certeza que a comprava. E como essa existem mais 2 ou 3 interessantes. A seu tempo não tenho dúvidas que aparecerão mais.Se a Google é que devia ter a responsabilidade de melhorar a plugin? Sim. Se o vai fazer? Sim, mas muito lentamente, tal como têm feito, portanto eu não conto que façam assim nenhuma melhoria significante.Pensa assim. O Sense UI é mais bonito que o Android Stock (é discutível claro, susceptível à opinião de cada um, mas podemos todos concordar que é mais elaborado, e tem mais glamour). Tal como a google dá espaço para as empresas colocarem os seus dispositivos melhores, também está a dar espaço para haverem ferramentas de edição melhores. É discutível se as duas coisas são comparáveis, mas a verdade é que o intelliJ já vendeu algumas boas licenças pelo facto do seu editor de Android ser superior a vários níveis face ao Eclipse. (não tem layout editor por enquanto, mas a integração com o auto-complete no editor de layout a nível de XML está completa, e no Eclipse ainda não está)No fundo sim, dou-te razão, um editor/plugin melhor era bem vindo. Pode ser que com alguma da reestruturação estética que o Android vai sofrer no 2.3 (ou é neste, ou no seguinte), a plugin fique também um bocadinho melhor.