A memória RAM do N900

No Gizmodo apareceu um interessante artigo sobre os programas chamados de task killers no Android. Eles são programas que fecham outros programas…como o Gerenciador de Tarefas do Windows, muito usado para fechar programas que não estão mais respondendo.

Qual é a utilidade de programas assim? Para um usuário consciente, apenas matar processos que, por qualquer motivo, não estejam mais respondendo. Para um usuário não muito bem informado, liberar memória RAM.

Todos que usam Linux já devem ter visto que muitas vezes a memória do computador está totalmente ocupada. E nem por isso o sistema está mais lento. No meu notebook, neste momento, estou com cerca de 500MB livres, de um total de 4GB. Mas na prática, em uso mesmo, tenho apenas 1.2GB. O que é essa diferença?

O Linux (e portanto o Maemo, MeeGo e também Android) possui um sistema extremamente eficiente de gerenciamento de memória. Ele sempre tentará usar toda a memória disponível para deixar o próprio sistema mais rápido. A “mágica” acontece ao utilizar a memória que “sobra” para buffers* e caches** e também não remover imediatamente bibliotecas que já foram utilizadas.

Então assim que você fecha um programa, nem tudo dele é removido da memória. Qual é a vantagem disso? Quando você for abrir de novo esse programa, se já houverem coisas dele na memória, o seu carregamento será mais rápido.

O sistema operacional vai liberando memória conforme a necessidade. Não há porque liberar tudo de uma vez se você pode ter um ganho com isso. Portanto memória cheia, no caso do Linux, não é sinal claro de problema!

No N900 há uma forma fácil de ver como está o uso da memória: o programa htop (ele está no repositório extras). Ao ser executado, a segunda linha mostra o uso da memória. O normal será a barra estar completamente cheia. Mas o que efetivamente está em uso é apenas a “primeira” (a verde). A barra azul e a laranja/amarela mostram os buffers e caches, respectivamente.

O Conky sempre mostrará a quantidade de memória efetivamente em uso (a barra verde do htop).

Já o comando top, que é um irmão menor do htop (e é um programa nativo da base do Linux, portanto pré-instalado no N900 também) sempre mostrará a memória total em uso (a soma das 3 barras).

Só a título de curiosidade, esses programas assassinos existem no Android porque ele foi feito de tal forma que quando o usuário fecha um programa, ele não está sendo efetivamente fechado, mas apenas suspenso e colocado em segundo plano. Quando o sistema precisar de memória, o próprio sistema sozinho efetivamente fechará o programa.

No N900, quando se fecha um programa, ele é fechado de verdade! :)

* Para explicar o que é um buffer podemos fazer uma analogia com uma impressora. Quando você manda imprimir algo em muitas folhas, você não vai até a impressora e fica colocando folha por folha no alimentador, e também não fica pegando folha impressa por folha impressa. Existe um lugar onde fica uma certa quantidade de folhas em branco, para serem usadas, e existe um lugar para onde o que foi impresso vai, esperando ser recolhido. Cada um desses lugares é um buffer. É um lugar de armazenamento temporário, ou um lugar utilizado apenas de passagem.

** Um cache é uma região onde ficam coisas que já foram usadas e, talvez, possam vir a ser usadas de novo. Um exemplo bem nítido é o navegador: quando você acessa um site ele guarda imagens, folhas de estilos, e até textos em arquivos. Ao visitar esse site novamente o seu carregamento é muito mais rápido pois muitos elementos já estão no disco localmente.

Desktop Activity Manager e Extend Contacts Search

Duas dicas úteis. Primeiro o Extend Contacts Search.

A busca de contatos no aparelho é feita apenas pelo nome, inicialmente. Instalando esse programinha a busca passa a ser feita por apelidos, telefones, emails e nome de usuário de mensagens instantâneas.

Na verdade ele não é um programa, mas um plugin que fica acoplado ao programa de Contatos. Não é necessário nada para ativá-lo nem para usá-lo….exceto instalá-lo, claro.

Já o Desktop Activity Manager ajuda a resolver um problema muito citado no fórum: a perda das configurações dos desktops (sumiço de atalhos, widgets, contatos e afins das telas).

Na verdade ele é mais poderoso que isso: permite criar perfis de uso diferentes, onde cada perfil possui suas configurações de telas. Para alternar entre uma e outra basta ir ali no menu de controle, selecionar o programa, e configurá-lo/selecionar o perfil desejado.

Você pode por exemplo ter um perfil “trabalho” onde na sua tela está sua agenda, e algumas notas, como pode ter um perfil “lazer”, tendo atalhos para alguns joguinhos, e alternando entre eles automaticamente através do Alarmed (já que o Desktop Activity Manager também pode ser usado via linha de comando).

Para usá-lo no terminal, basta dar uma lida na ajuda do programa. Vá no terminal, e como usuário comum (não faça nada como root neste caso), digite isso:

activity help

Ambos os programas estão no repositório extras.

MeeGo no cronograma

A versão 1.1 do MeeGo está programada para ser lançada em outubro. Essa versão é aquela que se espera que seja plenamente instalável em aparelhos móveis (a.k.a. celulares).

O Gizmodo deu uma notícia dizendo que há gente que já portou o sistema para um Nexus One, um HTC Desire e um tablet Dell Streak. Os 3 aparelhos rodam Android, então não é nada excepcional esperar que o MeeGo, um projeto código-aberto baseado em Linux, assim como o Android, rode neles.

Colocaram inclusive um vídeo de um aparelho da Dell (que pelo tamanho não me parece ser um tablet), dando o boot no MeeGo. Mas não é um boot completo….não aparece absolutamente nada além de 3 linhas, totalmente texto, mostrando a versão do sistema e a versão do kernel. Então fica meio difícil confiar 100% no vídeo (até porque dar boot é uma coisa, o sistema efetivamente rodar é outra).

O que eu acho “engraçado” na notícia do Gizmodo é o título. É algo como querendo dizer que o MeeGo não vai rodar nos aparelhos da Nokia, mesmo sendo ela a dona do produto (o que também não é correto).

Bem….mas o que tudo isso tem a ver com o título deste texto? Eu chego lá. Durante algum tempo os responsáveis pelo projeto soltaram versões semanais do sistema, e todos eles plenamente instaláveis no N900 (preferencialmente num cartão de memória). Há algumas semanas, para ser mais exato 3, essas versões deixaram de aparecer (a última tinha sido no dia 6 de setembro).

Pois bem…apareceu uma nova, e com uma agradável surpresa: com a parte de telefonia funcionando! Instalei o sistema, rodei, e fiz uma chamada com ele! Totalmente funcional! Mas ainda com detalhes faltando. Por exemplo, não há indicação visual de que temos sinal, e muitos menos conexão à rede de telefonia. Mas basta iniciar o programa de discagem, teclar um número, pressionar o botão “discar”, e sair falando. O programa de telefonia, claro, ainda está cru. Também é possível receber uma chamada…perfeitamente funcional. Mas ainda não utilizável!

Ele não toca, não vibra, e sequer abre qualquer coisa para se aceitar a chamada! É preciso manualmente abrir o programa de telefonia, e só então aparece uma janela para aceitar ou rejeitar. O único indicador de que há uma chamada sendo feita para o aparelho é um ícone de um telefone no canto.

Outra coisa que está funcionando é a auto-rotação da tela. Mas com um efeito um tanto quanto estranho: às vezes ela fica torta, como se eu não tivesse rotacionado o aparelho em exatos 90 graus, e portanto a tela também não o foi.

Novamente parece que a resposta à tela sensível ao toque não está totalmente implementada (ou pelo menos assim eu espero), pois em alguns casos é preciso efetivamente apertar a tela, ao contrário do Maemo no qual às vezes basta apenas encostar o dedo para o toque ser reconhecido.

Mas pelo fato da telefonia já estar funcionando, eu acredito realmente que o cronograma será cumprido e agora em outubro teremos uma versão funcional e instalável no N900.

Observação: não há imagens porque estou sem câmera. Se conseguir alguma, tirarei fotos.

Personalizando um tema

Há um programa bem interessante no repositório extras-devel: Theme Customizer. Ele permite personalizar vários componentes de um tema. Nas imagens é possível ver as opções:

Só é preciso tomar um certo cuidado ao utilizá-lo pois ele mexe em opções muito sensíveis do sistema. E já aconteceu do programa ir para o repositório com um bug que fazia com que o arquivo que ele altera ficasse corrompido. Resultado? Problemas ao utilizar o aparelho!

A versão que testei aparentemente está funcionando corretamente. Também tive um pequeno susto num dos testes que fez com que tudo nos meus desktops sumisse. A reinicialização do aparelho resolveu o problema….mas um dos desktops (que tinha atalhos para números mais discados), não voltou. Nada que 2 minutos não tenham resolvido.

Ah sim…após a instalação ele fica na sessão de configuração do aparelho! Não adianta buscá-lo no menu do aparelho que não o encontrará!

Blockout: quando pensa que está quase acabando…

Ok…eu sei que não estava quase acabando! Não o jogo inteiro, mas pelo menos toda a infra-estrutura necessária. Eis mais algumas imagens dele:

Acho que houve um significativo progresso entre a primeira versão e esta! E talvez até entre a anterior e esta.

Mas como nem tudo são flores, ontem finalmente fui testar o jogo efetivamente no N900. Pois é….até agora os meus testes eram todos no emulador. Somente algumas poucas coisas eu coloca no aparelho para testar. E claro que surgiram vários problemas!

Dois deles darão um pouco de trabalho. O primeiro é com o menu. Na imagem acima já dá pra vê-lo, mas na prática ele deveria ficar deste jeito:

Não sei porque o N900 não está desenhando a transparência corretamente. Na verdade, ele não está desenhando nada transparente no menu!

E o outro problema é na movimentação dos blocos. Existe um temporizador interno que faz com que as peças “caiam” automaticamente. Mas quando isso ocorre junto a um movimento do jogador (movendo a peça para os lados, por exemplo), o desenho na tela fica bagunçado.

O motivo disso acontecer eu sei: para evitar que o jogo consuma muita energia desnecessária, e às vezes até fique lento, eu não redesenho a tela inteira a todo instante, mas apenas o pedaço que sofreu uma alteração. Acontece que com dois movimentos acontecendo ao mesmo tempo, na hora de redesenhar um deles irá sobrepor o outro, deixando “sujeira” na tela.

A solução eu também sei qual adotar, mas pode não ser tão simples: precisa ser um sistema de “pilha”, onde os movimentos são colocados numa fila, e sempre tratados 1 a 1, nunca simultaneamente. Em algumas linguagens isso seria facilmente resolvido com métodos sincronizados (o método não pode ser executado mais de uma vez simultaneamente, sendo que o segundo que o chamou espera até que o primeiro tenha terminado). Mas o Python não possui isso.

Fora tudo isso também notei que o sistema para fazer a peça ser fixada no tabuleiro também não está muito bom. Às vezes o pressionamento mais longo do botão não é reconhecido.

Ainda falta um bocado pro jogo poder ir pros repositórios, mas resolver esses problemas já permitirá pelos menos que ele possa entrar em alpha (mais gente jogue, além de mim).

Comparativo de fotos

O N900 possui um programa para tirar fotos que não é uma maravilha. Muitas pessoas dizem que o N95 tira fotos melhores. O motivo para isso não é a lente, já que ambos os aparelhos contam com lentes de 5 megapixels Carl Zeiss. A diferença é o pós-processamento da imagem.

Neste momento o aparelho conta com 3 programas para tirar fotos mais conhecidos: o nativo, o FCamera e o BlessN900. Este último não foi feito para tirar fotos “normais”, apesar de ser possível. Com ele o ideal é apenas tirar a foto no formato RAW, e depois processá-la.

O formato RAW é um formato especial de foto: ele é como se fosse o antigo negativo. É a imagem crua da forma como foi captada pelo sensor. Para quem gosta de fotografia e sabe tratar uma imagem, ter uma foto nesse formato é o paraíso. Para meros mortais, não é lá tão útil… :)

Estas 3 imagens foram feitas com segundos de intervalos (apenas o tempo necessário para fechar um programa e abrir o outro), com as configurações padrões dos programas:

Teste estacionamento 1 Teste estacionamento 2 Teste estacionamento 3

(clique para abrir em tamanhos maiores)

A primeira imagem foi tirada usando o BlessN900. A segunda o FCamera e a terceira o programa nativo. Logo de cara dá pra perceber que a foto tirada pelo Bless não ficou boa. Ela parece estar borrada, como se tudo que está ali fosse de plástico.

A maior diferença rapidamente notada entre as outras duas é a claridade. Com o programa nativo a foto ficou mais clara. Mas há outras diferenças. Note o telhado das casas: as telhas ficaram mais nítidas no programa nativo.

Como já dito, essas fotos foram tiradas usando as configurações padrão dos programas, tudo no automático. É claro que alterando alguns parâmetros podemos melhorar consideravelmente as imagens….mas ninguém vai poder ficar ajustando configurações sempre!

O próximo comparativo será entre fotos HDR.

Navteq “Street View”

A Navteq é a empresa responsável pelos mapas que o Ovi Maps utiliza. No passado ela dividia com a Tele Atlas a supremacia desse setor, tanto que os mapas que o Google exibia no Google Maps e no Google Earth eram de uma dessas empresas. Ainda hoje se você olhar determinadas partes do globo terrestre no Google Maps verá no canto inferior o nome da Tele Atlas, junto a outras fontes das imagens.

Depois de um tempo o Google começou a ter mapas próprios, e a Navteq foi comprada pela Nokia (assim como a Tele Atlas foi pela TomTom).

Agora a Navteq fará o mesmo que o Google fez: mapeará as ruas das cidades para criar o próprio “street view”. E neste vídeo há um preview disso, usando um N900 (o carro da empresa que faz a captura também é mostrado de relance):

Quando isso estará disponível? Impossível saber! Quais os locais? Provavelmente alguns pontos da Europa e Estados Unidos primeiro. Isso, claro, se não houverem muitos processos por invasão de privacidade!

fonte: Daily Mobile

Ovi Maps com navegação por voz no N900?

Segundo um texto no The Nokia Blog, talvez.

O editor do blog, presente na Nokia World 2010, conversou com alguém da área de produtos Ovi, e questionou sobre o assunto. A resposta foi de que eles estão trabalhando para levar o Ovi Maps para o MeeGo, e que se o código resultante for facilmente transferível para o N900, então a resposta é “sim, o N900 terá uma atualização do Ovi Maps”.

Mas caso seja necessário alterar muito código, então a resposta é “não”.

O que me leva a algumas questões interessantes. A primeira delas é em relação ao próprio código. A Nokia apregoa sempre que todas as aplicações feitas para seus aparelhos devem ter como base o Qt, pois assim elas seriam facilmente portadas do Symbian pro Maemo/MeeGo e vice-versa. E eu, como programador, concordo com essa visão! Isso é factível.

Só que aí vem a questão interessante: se muito do código do Ovi Maps precisaria ser alterado para rodar no Maemo é sinal de que a Nokia não leva essa questão da “mobilidade do código” muito a sério!

Oras….o MeeGo tem como base o Linux, que também é a base do Maemo. Portanto, ambos possuem os mesmos elementos em seu interior (X-Org, Gstreamer, PulseAudio e por aí vai). Utilizando o Qt, o acesso ao hardware deixe de ser uma obrigação do programa e passa a ser da biblioteca. Então o que impediria que o programa rodasse nas duas plataformas?

Seria algo como “faça o que eu digo, não faça o que eu faço”?

O que é HDR?

Essa é uma sigla que está muito em moda agora. O High Dynamic Range é uma técnica utilizada prioritariamente em fotografias, mas também pode ser usada em filmes. A teoria é um pouco chata, então vamos explicar na prática: são tiradas algumas fotos, com exposição variada, e depois elas são unidas numa única foto (essa explicação é, digamos assim, apenas para entender, pois na prática acontecem mais coisas).

Por que variar a exposição? Porque isso permitirá pegar detalhes da foto que são escuros e também detalhes que são claros. Se a exposição for longa a ponto de pegar os detalhes escuros, os claros sairão extremamente claros (estourados). Se a exposição for curta para não estourar as partes claras, os detalhes escuros não sairão.

Ao unir todas as imagens numa só teremos os detalhes escuros das fotos com mais exposição unidos aos detalhes claros das fotos com menos exposição, resultando numa imagem onde tudo terá bons detalhes!

Aqui temos um exemplo:

20100913_002.jpg HDR_2010913_1718.jpg
(elas foram tiradas com segundos de intervalo)

A foto da esquerda foi tirada pelo programa de foto padrão do N900, com todas as configurações automáticas. Já a foto da direita foi tirada usando o HDR Capture, com uma configuração de 3 fotos (o resto tudo automático).

Algumas coisas ficaram melhor na foto “padrão”, como por exemplo os detalhes da parede verde da construção na esquina, onde se percebe o padrão da sujeira nela! Mas outras coisas ficaram absurdamente melhores na foto em HDR, como os prédios no horizonte mais próximos ao sol, à direita. Há prédios que na foto “padrão” sequer dá pra perceber que existem, enquanto que na foto em HDR estão nítidos.

Isso sem contar o próprio céu, que aparece como um borrão branco numa e com todo o degradê azul na outra.

O HDR Capture existe graças ao novo driver da câmera, comentado aqui. Na verdade são 3 programas criados como exemplos de uso da biblioteca mas que acabaram se tornando projetos reais: HDR Capture, Lowlight e FCamera, todos disponíveis no repositório extras-devel.

Acredito que tenha ficado claro que o HDR Capture pode produzir belas fotos, mas não serve para todas as ocasiões. O principal motivo para isso é que para ele funcionar corretamente é preciso tirar mais de uma foto, e caso você não esteja com o aparelho firmemente apoiado em algo, o resultado pode ser uma imagem tremida. E fotografar objetos em movimento também não é muito inteligente, caso o próprio objeto seja o foco principal.

Além do que o processamento das fotos pode demorar um pouco: a imagem acima levou cerca de 30 a 40 segundos. E isso consome CPU, e consequentemente bateria (sem considerar o fato de que enquanto está processando não dá pra tirar outra foto).

Um lugar com boas informações sobre o HDR é este site aqui.

QtWRT: ainda vai ouvir falar dele

Sobre o Qt já se falou um pouco. Quando a Nokia comprou a Trolltech o motivo era mais que evidente: criar um ambiente no qual os programas rodassem em todos os sistemas operacionais da empresa sem necessidade de alterar código-fonte. No máximo, apenas recompilando.

O Qt, ao contrário do que alguns possam imaginar, não é uma linguagem de programação. É uma biblioteca. A vantagem em usá-la é que não é preciso alterar um programa caso se queira usá-lo em outra plataforma que também rode o Qt. Como a biblioteca é padronizada, qualquer programa que a use vai rodar em qualquer lugar que rode o Qt.

E é aí que entra o tema deste texto: QtWRT significa Qt Web Runtime. Na prática nada mais é que uma biblioteca (mais uma), que permite que através de Javascript você acesse o hardware do aparelho. Javascript é a linguagem padrão utilizada em páginas da internet.

Ou seja: você pode construir uma aplicação inteira usando HTML e Javascript.

Um exemplo é o MoneyFlow. Um programa para controle de gastos, comentado pelo leitor/usuário do fórum flavio.

Acredito que as vantagens sejam evidentes: você conta com o poder do HTML unido ao Javascript, e de quebra tem acesso aos contatos, GPS, sensores, e por aí vai. E ainda rodará o programa em qualquer aparelho que entenda HTML e possa ter o QtWRT instalado.

Ainda não há uma versão final da biblioteca para o N900, mas há uma versão de preview. Ele é encontrado no extras-devel.

Os programas feitos nessa biblioteca possuem uma extensão diferente: é .wgt (não é .deb). Mas são instalados também à partir do Gerenciador de Aplicativos. Porém, eles serão reconhecidos apenas após a instalação da biblioteca!

Este vídeo demonstra a utilização do MoneyFlow (e também algumas capacidades do QtWRT):

Tags: