terça-feira, 29 de maio de 2012

Qual o encoding default no Android?

Vamos fazer o equivalente ao post anterior, mas agora no Android. É só deixar o main.xml assim:


E a activity assim:

E rodar e ter uma tela assim:



Só para verificarmos que o Android usa o padrão UTF-8.

Qual o encoding default?

  No post anterior mostrei a importancia de sabermos qual o encoding que um arquivo foi gravado para usarmos o mesmo para leitura.
  Na maioria das vezes, os arquivos que manipulamos em nossas aplicações são internas ao mesmo, então não nos preocupamos qual o encoding usado. Mas, quando o arquivo vai ser compartilhado entre multiplos sistemas é fundamental que o encoding seja informado.
  O código abaixo usa duas classes para fazer a gravação de um arquivo. A classe FileOutputStream é do tipo OutputStream e grava bytes no arquivo. A classe OutputStreamWriter converte character em bytes. É ela que usa o encoding para transformar o tipo char em byte. Para isso ela precisa "saber" qual o encoding. Como não informamos o encoding, ela assume o encoding default.
  Recuperamos o encoding com o método getEncoding.

  TesteEncoding.java
 

  Ao testar o código acima teremos algo assim:


 É isso!
 No próximo post vamos ver o mesmo em Android.

sábado, 26 de maio de 2012

Unicode, encodings


  Estou fazendo uma revisão nos meus estudos sobre fileio.
  Estudando uma classe após outra, acabei chegando novamente em encoding e Unicode.
  Quando se fala em processamento de texto a unidade básica é um character. É a representação de uma letra ou um sinal gráfico. Usa-se também o termo "glyph". Vem daí hieróglifo.
  Um conjunto de characters é um character set. O conjunto da lingua inglesa tem algumas dezenas de carateres, mas o conjunto da lingua chinesa alcança milhares de carateres.
  Um conjunto de characters codificado é um coded character set. Unicode é um exemplo. É a associação entre um character e um número.
  Code points - são os números que podem ser usados num coded character set.
  Character encoding scheme - mapa entre coded character set para code units
  Code units: byte, dois bytes, quatro bytes.
  Muita confusão foram feitas (e ainda são) nessa área.
  No início um byte era suficiente para guardar as informações de texto. 256 possíveis opções, e ainda sobrava. Então, na parte que sobrava, cada um usou sua imaginação e necessidade à vontade. Como tudo isso acontecia antes da globalização, cada um definiu e usou um padrão. ASCII, Cp1252, ISO-8859-1, até chegar em centenas de (falta de) padrões.
  Aí, no início dos anos 90 do século passado, surgiu o Unicode para tentar colocar uma ordem nessa verdadeira torre de Babel. O Unicode foi criado com o humilde propósito de representar qualquer character de qualquer lingua existente ou a ser inventada!
  Começou com 65.536 possibilidades, que logo se mostrou insuficiente, sendo aumentado para 1.112.064 possibilidades, atualmente. Hoje, são utilizados pouco mais de 100.000.
  O Unicode, praticamente se tornou padrão da industria de informática.
  Java usa o Unicode.
  O conceito do Unicode é simples: 1 character - 1 code point. A confusão começa, devido ao fato de que temos diversas formas de traduzir esse code point em bits.
  Na, verdade, isso só acontece devido ao fato de "esquecermos" de informar o código do encoding utilizado para gravar/ler os arquivos de textos.
  Se considerarmos que isso é uma espécie de criptografia, não aconteceria isso. Afinal, todos concordam, que se criptografarmos algo, somente teremos acesso à forma original, se fizermos o oposto. Então, se gravarmos um arquivo de texto com UTF-8, devemos ler com UTF-8. E nunca com Cp1252. É claro, que esse "esquecemos", é maneira de dizer. Afinal, na maioria das vezes isso ocorre com dados vindo de fontes que desconhecemos o formato da gravação.
E, então como proceder?

Nos próximos posts vamos fazer alguns testes com isso.

quarta-feira, 9 de maio de 2012

Estudando programação de games


Outra frente de estudos que comecei recentemente é a area de games.
Estou estudando os conceitos básicos sobre o tema.
É uma area em que temos um grande uso de CPU e de memória, em que cada milésimo de segundo faz diferença.
E foi nesta area que encontrei alguns assuntos que eu não entendia como foram parar no dia a dia da programação Android.
Uma delas é a quebra das boas práticas da programação orientada a objetos, principalmente o encapsulamento .
Em games isso é uma prática corriqueira e até compreensível, senão obrigatória, mas adotá-la e recomendá-la em desenvolvimento em outras areas é inadmissível, convenhamos.
É sabido que getters e setters são relativamente mais custosos do que acessar variáveis diretamente. Mas, os riscos de desenvolver dessa maneira beira a irresponsabilidade.
Se, por algum motivo, tiver que fazer isso, faça um favor a si mesmo: documente muito bem as práticas adotadas e os cuidados a serem tomados ao efetuar possíveis manutenções no código.
Mas, voltando ao que interessa, pretendo estudar como fazer um game com os recursos básicos e depois partir para selecionar um framework ou um gameEngine.
Sugestões serão apreciadas.