Ainda em JavaFx, minha segunda aplicação esta se saindo bem, estou gostando do resultado.
Este texto não é só propaganda(mas também é :), vou analisar a criação, negativos e positivos. Mas primeiro, a apresentação:
O TwitterFlow é um cliente para twitter que conta com alguns dos principais recursos que deve-se ter já funcionando:
- Ele tem múltiplas contas
- Escreve em qualquer uma das contas (doh)
- Atualiza automaticamente (ou não, claro)
- Faz buscas
- Retweet, Reply, links...
Para oferecer algo um pouco além do "basicão", que os clients legais costumam ter:
- Envia fotos
- Encurtar URLs
- Salva buscas
- Busca por menções(ret e rep) de qualquer usuário
- Segue usuários sem precisar "follow" de verdade (não lembro mais por que)
- Atualiza qualquer coisa automaticamente
- Manter mais de uma janela, cada uma aconpanhando um fluxo
- Paginação
- Se "esconde" na bandeja do sistema
- Exibe alertas na bandeja quando há novos tweets
Acho que é só isso por enquanto...
A tarefa de construção de UIs no JavaFx é muito boa, e mesmo um "nada-designer-e-preguiçoso" como eu consegui fazer algo razoável.
Os principais dificuldades foram as já esperadas: Quando fora da UI, não consegui bons resultados com as classes fornecidas pelo SDK.
Fiz o controle de threads e temporização na mão, e em Java. Foi uma cascata nessa parte na verdade, primeiro usei as classes mais "abstratas" do JavaFx, a RssTask. Depois Passei a usar o HttpRequest mesmo junto com Timer e TimerTask. Depois usei o Timer e TimerTask com URLConnection (estas já são do Java), e como já estava aqui larguei o Timer e usei Threads e Runnables mesmo.
O resultado esta com Threads bem legais até, sem dores de cabeça e boa performance, sem overhead.
Na parte de UI apenas algumas ressalvas, escrevi um campo de password baseado no campo de texto, e um Spinner do zero. Ainda faltam matar os Swings do TextArea e (mais complicado) FileChooser, mas acho que o FileChoose já tem pronto por ai.
Quanto às chamadas de serviço, a API do Twitter é uma maravilha. Mesmo. A do twitpic abstraí através do twitipic4j. E os encurtadores de URLs também não podiam ser mais simples. Para cuidar do JSon usei a fornecida no próprio json.org , que sempre me ajuda. Já que estou nos créditos, todas as imagens (exceto os avatares, óbvio) são do Iconset do Oxygen. (Links no final)
Mas um pouco na API , tem uma complicação na verdade. Depois de todo o mimimi de segurança e todos os problemas em digitar sua senha em aplicativos, o twitter esta introduzindo autenticação por OAuth (parecido com grandes sites fazem), e com novas apps só tem seus nomes aparecendo no tweet se usarem OAuth (antigas continuam ok). Então aparece apenas API por hora.
Uma parte que rendeu uma boa Gambiarra foi para fazer os links no tweet. Bom, como não é simples HTML e não posso simplesmente usar <a>, nem inserir eventos em partes especificas de uma string. A primeira POG foi dividir o conteúdo nos espaços e ver se são possíveis links (http, @ ou #). Se for uso um elemento devido, senão uso o Text padrão. E fazer uma sequence com isso.
O primeiro problema dessa abordagem foram parenteses e pontuação, por exemplo o conteúdo "bla bla (http://g.com)" sairia errado. Isso já rendeu bons IFs. O segundo é que cada palavra era na verdade um elemento de UI, o "tweet" em sí era um "float" desses elementos. Imagine a confusão!
A solução atual é diferente, eu busco pelos links no conteúdo os guardo em uma sequencia, depois ele são inseridos numa área especifica da UI. Salvei bastante memória assim, até melhorou o layout, mas perdi um pouco em design já que não tenho "cores" no tweet (apenas na área dos links).
Falando em memória, essa sempre foi uma preocupação. Chances para Leaks , o fato da tecnologia ainda ser nova e fama de Java como devorador de memória me deixavam bastante preocupado.
De fato é muito fácil "torrar" memória na construção UI, principalmente por que estou sempre lidando com sequencias e binds, mas tenho feito um esforço bom para mante-la sobre controle e tem ficado tudo bem. Reduzi a passagem de objetos entre diferentes camadas da aplicação, para evitar de esquecer referencias, e reutilizei os objetos que consegui.
O modelo de threads ajudou bastante a controlar a memória, um "pool" para as imagens também reduziu bastante. A lista de tweets é mantida somente em um lugar, e quem a recebe sempre se livra da referência. A gambiarra dos links quando desfeita também liberou bastante coisa.
Mas é um trabalho eterno, ainda pode melhorar muito.
Não gosto de fazer comparações, pois sei que são muito diferentes e todo um blá blá blá(...), mas sempre achei que os clientes twitter consumissem bem pouco. Estava enganado. Tirando os pertencentes aos browsers (twitterfox, Opera Twitter widget, etc), a maioria consome muita memória. Talvez eu só tenha escolhido os maiores consumidores para testar.
Nos clients em Adobe AIR, ( Twhirl, Spaz e TweetDeck que eu vi) é fácil começarem nos 70, 80, subir para 90 e 100MBs (e até continuar), o TweetDeck, um client completíssimo, é assustador nisso. Não posso falar que é culpa do AIR (provavelmente não é), já que o DestroyTwitter (que eu usaria fácil, gostei muito) usa bem menos(visual mais simples, talvez), entre 55~65Mbs.
Nos feitos em JavaFx, como o TwitterFx e o TweetBox, o consumo também é muito alto, tanto ou maior que os em AIR. O TwitterFlow (o meu) também não está ideal ainda, mas fica parecido com o DestroyTwitter, durante o uso normal ao longo do dia fica entre uns 60~70Mbs, mas se for abrindo mais janelas e mais fluxos, passa fácil para 70~80MBs.
Não testei nenhuma aplicação nativa, nem para Windows, nem Linux e nem Mac (informações são bem vindas!), mas imagino que esses se saiam bem melhor (por favor!).
Voltando para a aplicação, usei melhor os recursos de binds, triggers e sequences do JavaFx, facilitando manter a conformidade , normalização e sincronismo dos dados. Salvo as configurações usando a API de Storage local, que é encriptada e "sandboxada" para cada app.
A parte de integração com o Desktop (lançar navegador e bandeja) ainda esta na gambiarra, ambas usam a classe de Desktop do Java. O lançar navegador usa o BareBonesBrowserLauncher.
Ainda quero implementar pelo menos OAuth, manutenção de cada usuário e , claro, memória e performance. E o que mais der na telha!
Enfim, o aplicativo, links e código em http://kenai.com/projects/twitterflow. Opiniões são bem vindas, para mal ou bem :)
- Comments
