| Autor |
Mensagem |
|
|
Pra falar a verdade não testei, mas acho que deve ajudar:
http://www.guj.com.br/java/165368-ireport-mostrar-imagens
http://ireport-tutorial.blogspot.com/2008/11/show-blob-image-in-ireport.html
|
 |
|
|
|
A intenção é botar uma vez só e o objeto ficar la pra "sempre", daí você sempre vai usar o mesmo objeto.
|
|
|
|
|
Sim, isso mesmo, ele só entra no if uma vez. Por que? Porque a lista só é nula uma vez, na segunda vez ao invés de ela ser nula, ela vem preenchida com o objeto que você colocou na sessão anteriormente.
|
|
|
|
É assim:
Esse código tenta pegar a lista na sessão. Se tiver, ele pega e bota na variável lista, se não tiver, ele bota null na lista.
Daí você verificando isso, consegue criar uma nova lista se ela não existir, já colocando-a na sessão. Na próxima vez que você verificar a sessão em busca dessa lista, ela vai estar lá até rolar um session.invalidate() ou ela expirar por tempo (ela tem um tempo de vida - ou inatividade, que é configuravel). Esses conceitos você consegue ver ali nos links que eu te passei, mas pense na sessão como uma área reservada na memória pra você guardar objetos e elas são acessíveis apenas pelo cliente (usuário) que botou o objeto lá nesse espaço. No submarino.com.br por exemplo, quando você coloca um item no carrinho de compras, coloca na verdade na sessão do seu usuário.
|
|
|
|
Cara, desculpa, agora vi que faltava coisa:
Lê o código com calma que você vai entender.
|
|
|
|
É, essa linha aqui tem que ser substituida por um código igual ao que eu coloquei ali:
Isso faz criar toda vez que você ve a página, mas você só pode criar quando ele for nulo na sessão.
|
|
|
|
Olá!
Nesse caso você pode usar o objeto session (HttpSession):
Essa lista está disponível para qualquer página (e qualquer servlet), durante uma sessão aberta por esse cliente.
Algo em português aqui e em inglês aqui.
Abraços
|
|
|
|
Olá!
Existem várias maneiras de fazer essa comunicação:
- Um ServerSocket, ao qual você definiria na mão um protocolo de comunicação entre os nós de rede (o que dispensaria o JSF/JSP) e deixaria teu servidor independente de cliente (qualquer coisa que consiga se conectar via TCP e entenda seu protocolo poderá utilizar seu servidor)
Vantagens: O cliente precisa apenas utilizar TCP, o que faz com que qualquer tipo de dispositivo embarcado que saiba como se comunicar via TCP consiga se comunicar com seu servidor
Desvantagens: Seu protocolo deverá ser implementado na mão e a troca de textos deverá ser parseada em ambos os nós, algo tipo (repare que você terá que fazer tudo na mão):
Cliente envia: "acao='salvarPedido';"
Cliente envia: "pedido=[cliente='Fulano de Tal',dataCompra='17/02/2000',produtos=['Camisa Branca','Camisa Azul','Calça Vermelha']];"
Servidor recebe, parseia, salva e devolve: "resposta='sucesso';"
- O teu cliente android poderia usar páginas HTML (HTTP simples), onde ele chamaria uma URL passando os parametros via GET ou POST, como uma web application normal
Vantagens: Qualquer cliente com um browser (ou qualquer coisa que implemente HTTP) conseguiria acessar teu servidor
Desvantagens: Ainda sim, seu protocolo deverá ser desenvolvido na mão, algo do tipo (no exemplo está um GET, mas podia ser muito bem um POST):
Cliente requisita; http://www.suawebapplication.com/?acao=salvarPedido&pedido=[cliente='Fulano...
Servidor recebe, parseia, salva e devolve uma página HTML: <html><body>Sucesso!</body></html>
- Teu servidor pode disponibilizar seus serviços por meio de Web Services (REST ou SOAP) e fazer tua aplicação Android consumi-los, ví algo por cima aqui e aqui.
Vantagens: Como agora tanto REST quanto SOAP são specs, você tem além de um material muito rico na net, várias ferramentas para automatizar a construção da sua solução. Do lado do cliente android eu já não conheço muita coisa, mas acredito que o bind entre a comunicação entre os nós e os objetos deve ser feita de maneira transparente por alguma ferramenta. Do lado do servidor, nenhuma novidade.
Desvantagens (que na verdade não é nenhuma desvantagem): Você vai ter que estudar REST ou SOAP e achar um cliente que consuma isso no android
Abraços
|
|
|
|
esmiralha wrote:
Alguém aqui já trabalhou em algum sistema Java onde um bug poderia causar a morte de diversas pessoas ou a perda de milhões de reais?
Opa, eu também (e acredito que mais um monte de gente aqui também).
O Brasil é phoda. Ô povo que reclama! O pessoal usa, reclama, usa, reclama... Estou estudando muito Rails e vejo que apesar de conhecer muito rubista fanboy chato, os caras na comunidade deles produzem muito (vide o RubyOnBr). Vamos começar a produzir mais antes de ficar especulando coisas que não vamos mudar. Digo isso porque a área de software em sí possibilita uma oportunidade muito legal para nós desenvolvedores: se não gosta dessa JVM da SUN (Oracle), você pode fazer uma melhor e disponibilizar pra todo mundo. A JVM em sí vai continuar existindo da mesma forma. Esse argumento de implementação de referência tem que ser o melhor é totalmente sem fundamento, pois qual é a implementação de referência do JEE? Ele é o melhor application server no mercado?
Btw, eu estava dando uma olhada no VRaptor e puxa, não havia visto como ele é uma ferramenta coesa e possui recursos bem interessantes. Parabéns ao pessoal da Caelum por cada vez mais desenvolver material de qualidade.
Engraçado que eu não vejo esse mesmo pessoal (que produz material interessante e útil) reclamando.
|
|
|
|
|
Quer dizer, alguns pequenos erros, mas nada pra começar a chorar e reclamar pra mãe.
|
|
|
|
|
Eu li metade em ingles e to lendo o resto (ou melhor re-lendo) em português. Pagina 200 e até agora normal.
|
|
|
|
Então cara, sobre o livro:
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Sensacional! Mostra realmente boas práticas (no nível do código) que fazem toda a diferença. Ele pega alguns códigos reais de projetos open source e mostra alguns pontos que podem melhorar e tal. Na ultima parte do livro tem uma série de estudos de caso práticos de como melhorar a qualidade do código. Muito interessante mesmo.
Depois dele é legal ler o Effective Java do Joshua Bloch e depois dar uma olhada no P of EAA do Fowler. Meio que é uma subida gradual no nível de abstração do desenvolvimento de softwares.
Abraços
|
|
|
|
|
To terminando o Clean Code do Tio Bob aqui e com certeza evolui infinitamente lendo esse livro! Um fórum disso seria uma ótima idéia!
|
|
|
|
No meio ai desse monte de opiniões, uma do kicolobo aê é justamente o que eu penso:
kicolobo wrote:Já uso o "Java 7" há um bom tempo. Se chama Groovy.
A tal "decadência do Java (linguagem)" pelo que posso ver, é muito mais relacionada a hype do que a fatos concretos. O que vejo é o surgimento de algumas linguagens com features bem bacanas, como Groovy, Scala, Clojure, JRuby comparadas com a linguagem Java.
O que eu pergunto é: será que eu realmente quero todos estes recursos na linguagem Java? Será que é REALMENTE uma boa entupir a linguagem de features só pra satisfazer o desejo (na minha opinião infantil) de "também tenho"? Afinal de contas, você pode mesclar linguagens em um projeto. Eu por exemplo tenho mesclado muito Clojure com Java em algo no qual venho trabalhado recenemente, aproveitando assim o melhor de dois mundos.
Sinceramente não vejo necessidade de mais recursos no Java (linguagem) após a versão 5. Se for pra pedir novas possibilidades, que estas sejam incluidas na JVM, pois assim satisfaz uma gama BEM MAIOR de desenvolvedores.
Mas no frigir dos ovos, Java é como o C do século XXI. Seu valor é inegável - você tem de ser muito ingênuo para ignorar - e você não é obrigado a trabalhar com ela. Mas que o bom conhecimento vai te fornecer um fundamento muito melhor sobre a plataforma, ah, isto vai.
(aliás, se for pra de fato satisfazer o desejo de ter mais e mais features na linguagem, a única alternativa é ir pro Lisp e seus derivados, aonde o programador inclui o que deseja na linguagem, sem precisar ficar dependendo do implementador padrão)
Java tá bom do jeito que tá. Se ficar enxendo de coisa na linguagem só vai é ficar atrasando e o povo ficando puto. É muito tenso manter compatibilidade e adicionar recursos. Ou faz uma versão alternativa ou o pessoal continua a usar outras linguagens. Melhorar a JVM e implementar novas features em linguagens que realmente estão PREPARADAS para suportá-las é muito mais interessante que demorar 5 anos pra implementar uma gambiarra que não vai implementar um conceito em sua plenitude (vide Generics). Chega uma hora que não dá mais, algo como C/C++ fizeram. Apareceram com o tal de OO e queriam porque queriam botar de qualquer jeito no C, dai fizeram o C++. Alguns aqui podem me xingar, mas com certeza fazer uma linguagem do zero que tenha o conceito em sua essência é bem mais interessante do que "acoplar" conceitos que não foram propostos e arquitetados anteriormente. Certeza que vão ficar reclamando das closures do java 7 (ou  e comparando com as de Ruby ou de Groovy. E esses que estarão reclamando serão os mesmos que ficaram choramingando pra adicionarem as closures em java.
|
|
|
|
Fala Camilo, beleza?
Eu trabalho aqui em sampa (tava na granja julieta e agora to no centro) há um tempo (quase 3 anos), e moro na praia (vou e volto de fretado), mas conheço muita gente que mora aqui (eu inclusive venho pra cá de vez depois que acabar minhas DPs na facool =/) e te digo, nessa região de Jardins da pra encontrar algo tipo 1500 com água inclusa (com sorte condomínio também, mas ja acho mais difícil). O esquema é morar perto de algum metro da linha azul, tipo Saude, Conceição, porque perto da Paulista é meio tenso de caro. E outra: a sacada é dividir com alguém mano. Sai mais barato, dois quartos e panz, cada um na sua, além de ter um brother pra poder dar roles e enxer a cara de vez em quando. Morar SÓ é legal mas muito SÓ eu acho meio solitário demais hehe. Eu por exemplo vou subir com uns brothers pra ficar um teminho (tipo 1, 2 anos) pra daí poder comprar um apê ou algo do tipo. Eu ja cansei de dormir aqui na casa de brotheres e te digo que se não tiver uma cervejinha na quarta vendo o jogo do Timão em galera você endoida de tanto trabalhar, fora que em mais de um da pra rachar empregada, tv, internet, etc..
E sobre trampo, aqui com 3 anos de experi (e uma competência legal, claro) da pra arrumar algo pra ganhar 5,6k facil.
Abraços e boa sorte!
|
|
|
|
|
|