terça-feira, 9 de outubro de 2012

Salvar "Print Screen" - Java

import java.awt.Rectangle;
import java.awt.Robot;
import java.awt.Toolkit;
import java.awt.image.BufferedImage;
import java.io.File;
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.imageio.ImageIO;
import javax.swing.JOptionPane;

public class Main {
    public static void main(String[] args) {
        try{
            BufferedImage imagem = new Robot().createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()));
   
            SimpleDateFormat dateFormat = new SimpleDateFormat("ddMMyyyyhhmm");
            String data = dateFormat.format(new Date());
           
            File file = new File("D:\\imagem" + data + ".jpg");
   
            ImageIO.write(imagem, "jpg", file);
           
        }catch(Exception e){
            JOptionPane.showMessageDialog(null, "Erro: " + e);
        }
    }
}

sexta-feira, 28 de setembro de 2012

Como tocar MP3 - Java

Esses dias tive a curiosidade de saber como tocar MP3 em java, e com alguns minutos descobri o quanto isso pode ser simples, graças as centenas de bibliotecas opensource que a comunidade JAVA já está acostumada. Darei um breve exemplo usando a biblioteca JLayer.
Para começar, faça o donwload em http://www.javazoom.net/javalayer/javalayer.html. É um arquivo bem pequeno que já vem com a documentação e o único jar necessário.
Adicione o arquivo jl1.0.jar ao CLASS_PATH da sua aplicação e análise o exemplo a seguir:
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import javazoom.jl.decoder.JavaLayerException;
import javazoom.jl.player.Player;

public class Tocador {
public static void main (String args[]){
 FileInputStream in;
 try {
  //Inicializa o FileInputStream com o endereço do arquivo para tocar
  in = new FileInputStream("D:/Hey Jude.mp3");

  //Cria uma instancia da classe player passando para ele o InpuStream do arquivo
  Player p = new Player(in);

  //executa o som
  p.play();
 } catch (FileNotFoundException e) {
  e.printStackTrace();
 } catch (JavaLayerException e) {
  e.printStackTrace();
 }
}
}


Retirado em 28/09/2012 do site : http://falandoemtecnologia.wordpress.com/2009/09/22/como-tocar-mp3-em-java/

quarta-feira, 29 de agosto de 2012

Inverter número inteiro com 3 algarismos - JAVA

    public void inverterNumero(){
       int x, a, b, c;
       x= 123;
       a= x / 100;
       b= (x % 100) / 10;
       c= (x % 100) % 10;
       System.out.println(c + b + a);
    }

terça-feira, 17 de julho de 2012

Obter o nome do mês a partir de uma data - Java

public static void main(String[] args) throws ParseException {
       Date data = null;
        try {
            data = new SimpleDateFormat("yyyy-MM-dd").parse("2012-07-17");
       
            String dataFormatada = new SimpleDateFormat("MM").format(data); 
          
            System.out.println(dataFormatada);
           
            SimpleDateFormat sdf = new SimpleDateFormat("MM"); 
           Date mesDate = sdf.parse(dataFormatada); 
           sdf.applyPattern("MMMM"); 
           System.out.println(sdf.format(mesDate));
       
        }
        catch (ParseException e) {
            e.printStackTrace();
        } 
    }

segunda-feira, 18 de junho de 2012

Subversion e Ant - Capturando o número da última revisão - Ant

O número da revisão será exibido no console e será salvo no arquivo "build.txt"

Estrutura do Projeto
 build.xml

quarta-feira, 30 de maio de 2012

Remover acentuação - JAVA

Uma solução fácil e simples.


String input = "áéíóú-ÁÉÍÓÚ";  
input = Normalizer.normalize(input, Normalizer.Form.NFD);  
input = input.replaceAll("[^\\p{ASCII}]", "");  
System.out.println(input);
  
Solução retirada do: http://javafree.uol.com.br/topic-871337-Remover-acentuacao.html

segunda-feira, 30 de abril de 2012

Como colocar bordas arredondadas em um Bitmap?

private static Bitmap getRoundedCornerBitmap(Bitmap bitmapOld, int roundPixel) {
   Bitmap output = Bitmap.createBitmap(bitmapOld.getWidth(), bitmapOld.getHeight(),    Config.ARGB_8888);
   Canvas canvas = new Canvas(output);
   final Paint paint = new Paint();
   final Rect rect = new Rect(0, 0, bitmapOld.getWidth(), bitmapOld.getHeight());
   final RectF rectF = new RectF(rect);
   final float roundPx = roundPixelSize;
   paint.setAntiAlias(true);      
   canvas.drawRoundRect(rectF, roundPx, roundPx, paint);
   paint.setXfermode(new PorterDuffXfermode(Mode.SRC_IN));
   canvas.drawBitmap(bitmapOld, rect, rect, paint);

   return output;
}



Fonte: http://debugcodigos.blogspot.com.br/2012/02/para-nunca-mais-esquecer-3-android.html

quarta-feira, 28 de março de 2012

Entendendo o serialVersionUID - JAVA

O serialVersionUID é uma dúvida constante entre muitos desenvolvedores. Afinal, quando e para que exatamente usá-lo? Devo gerar um número aleatório bem grande, ou um número qualquer? Essas perguntas são comuns, e ao desenvolvedor experiente é necessário conhecer a fundo esse detalhe do processo de serialização do Java.
Quando um objeto é serializado no Java, essa sequência de bytes, além de conter seus atributos de instância não transientes, carrega consigo um número que indentifica a “versão” da classe que foi usada durante o processo. Esse é o chamado serialVersionUID, ou seja, o indentificador de versão de serialização de uma classe. Esse número é utilizado para saber se o objeto que estamos recuperando é de uma versão “compatível” com a versão da classe que foi utilizada quando serializamos o objeto: em outras palavras, os arquivos .class não precisam ser necessariamente os mesmos para que o processo de serialização ocorra com sucesso.
Por exemplo, considere a seguinte classe Usuario:
package br.com.caelum;
 
public class Usuario implements Serializable {
  private String login;
}
Essa classe possui o serialVersionUID igual a 2806421523585360625L. Esse número não é aleatório! Ele é um hash (SHA) calculado em cima dos nomes dos seus atributos, e assinaturas dos métodos em uma ordem bem definida pela especificação do processo de serialização. E como eu sei esse número? O JDK vem com a ferramenta serialver, que implementa esse mesmo hash:
serialver br.com.caelum.Usuario
Se o serialVersionUID utilizado durante a serialização não bater exatamente com oserialVersionUID da classe que está sendo usada para recuperar essa informação, uma exception é lançada: java.io.InvalidClassException.
Por exemplo, se adicionarmos um novo atributo na nossa classe Usuario:
public class Usuario implements Serializable {
  private String login;
  private String senha;
}
Agora teremos o serialVersionUID valendo 416295346730660862L. Caso você serialize umUsuario com a primeira classe aqui definida, e tentar recuperar essa informação usando essa nova versão de classe, receberemos a conhecida java.io.InvalidClassException. Esse é o comportamente que em muitos casos queremos, mas algumas vezes fazemos pequenas modificações na classe as quais percebemos que não impactarão no processo de serialização, e precisamos manter compatibilidade com a versão antiga daquela classe. Para isso, basta definirmos explicitamente qual é o nosso serialVersionUID, e no caso de querer manter compatibilidade com a classe Usuario anterior, vamos utilizar o valor de serialVersionUID que seria gerado pela JVM: 2806421523585360625L. O código ficaria:
public class Usuario implements Serializable {
  private static final long serialVersionUID = 2806421523585360625L;
  private String login;
  private String senha;
}
Às vezes recebemos um warning do Eclipse, e ele pede para que seja definido oserialVersionUID da classe em questão. Isso ocorre porque você implementa Serializable ou uma de suas mães a implementa. O Eclipse então te abre três opções: utilizar o@SurpressWarnings para você assumir o risco, usar um valor default, ou usar o valor gerado. O gerador de UIDs do Eclipse é exatamente o mesmo gerador utilizado pelo Java SE para criar os UIDs padrão! Reforçando, esse número não é um número aleatório!
Quando alguém esquece de manter o mesmo serialVersionUID para duas versões compatíveis de uma classe, podemos ter problemas em usar diferentes versões do software que são teoricamente compatíveis. Isso muitas vezes acontece em servidores de aplicação, e se seu cliente esta desatualizado em relação a versão dos jars necessários pelo servidor, podemos ter algunsInvalidClassExceptions que poderiam ser facilmente evitados se o serialVersionUID tivesse sido corretamente aplicado. Claro que algumas outras vezes as versões realmente não são compatíveis e a exception procede.
Esse grave problema pode acontecer mesmo usando classes do Java SE entre diferentes versões, como é o caso da classe java.text.AttributedCharacterIterator.Attribute (utilizada pelajava.awt.Font). Do Java 1.3 para o Java 1.4 essa classe foi levemente alterada, e oserialVersionUID gerado pelo algoritmo da JVM desta classe mudou de-1514471214376796190L para -9142742483513960612L. Quando alguém serializava umajava.awt.Font em uma versão não podia desserializa-la em outra, sendo que as versões tecnicamente são compatíveis: a não definição explícita do serialVersionUID gerou um bug no Java SE. Como isto foi resolvido? Definiram o serialVersionUID como -1514471214376796190L, que é o valor que seria gerado pela JVM na versão anterior da classe.
Como então devemos proceder para escolher um serialVersionUID apropriado? É muito simples: se essa classe está nascendo neste momento, você pode se dar ao luxo de utilizar umserialVersionUID, como por exemplo:
public class Usuario implements Serializable {
  private static final long serialVersionUID = 1L;
  private String login;
}
Porém se você está definindo o serialVersionUID de uma classe já em produção, e sabe que a mudança que está fazendo é compatível com a versão anterior, você deve utilizar oserialVersionUID que seria gerado pela JVM na primeira versão, como foi o caso aqui quando adicionamos o atributo senha na classe Usuario, e também foi o caso da correção do bug da classe java.text.AttributedCharacterIterator.Attribute. Quando você fizer uma alteração onde percebe que o cliente precisará de atualização das classes envolvidas, basta definir um serialVersionUID diferente dos anteriormente utilizados.
Para completar, implementar uma interface que não define métodos (Serializable) e ser forçado a escrever um atributo sem um contrato mais burocrático é um tanto estranho em uma linguagem como o Java. Sem dúvida, se esse mecanismo todo tivesse sido inventado já com a existência de anotações, Serializable seria uma anotação e version um atributo dela, talvez obrigatório, criando algo como @Serializable(version=12345L). Boas serializações e invocações remotas!