Arquivo por categoria desenvolvimento

Dica aos programadores em Python

Esta dica é boa para aqueles que estão programando em Python para o N900.

Em programação existe uma ferramenta chamada profiler. Com essa ferramenta é possível analisar um programa enquanto ele está rodando. É diferente de debugar (onde você acaba executando o programa passo a passo para ver o que está acontecendo).

O profiling é extremamente útil (e muitas vezes necessário) para otimizar o código. Por exemplo: seu programa está com algum gargalo, em alguma operação, e você não consegue identificar onde é, devido à sua complexidade. Através de um profiler você talvez consiga essa informação, pois ele vai indicar quantas vezes (e por quanto tempo) um método ou função do programa foi chamado.

Em alguns casos também mostra a utilização de variáveis, e às vezes dá até para descobrir vazamentos de memória através dele (objetos que são criados, mas depois de utilizados, por algum motivo qualquer, não são destruídos).

O Python possui um esquema de profiling, porém por motivos legais (possui código proprietário), parte dele não está disponível de forma fácil (nos repositórios), o que faz com que não seja possível utilizá-lo. Parte do profiler vem na instalação padrão, mas outra parte precisa de um pacote à parte.

O pedaço que vem na instalação padrão do Python é a que gera as informações de profiling. E a que falta é justamente a parte que interpreta essas informações.

Se você mandar instalar esse outro pacote, receberá esta mensagem:

sh-2.05b# apt-get install python-profiler
Reading package lists... Done
Building dependency tree... Done
Package python-profiler is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package python-profiler has no installation candidate

A solução para isso é baixar e instalar o pacote na mão. No meu caso instalei no Scratchbox, mas no próprio N900 é igual.

Como o Maemo é baseado na família Debian, fui até o site dessa distribuição buscar o nosso pacote fujão. Neste link você verá todas as possibilidades.

Como usamos o Python versão 2.5, baixei a equivalente a essa versão, que é a 2.5.2-1 (nessa página basta selecionar de qual servidor quer baixar o arquivo). Após isso, é só mandar instalar (como root):

dpkg -i python-profiler_2.5.2-1_all.deb

E usar como manda a documentação do Python e a Wiki do Maemo.org.

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).

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:

Projeto novo: AutoUPhoto

Enquanto não termino o BlockOut, muito mais devido a bloqueios criativos que outra coisa (acha que é fácil desenhar a tela de um jogo?), estou tocando mais um programinha para uma função pra qual não há alternativa (ou pelo menos eu não conheço): subir fotos automaticamente para um serviço de compartilhamento.

Como “subir automaticamente” eu digo automaticamente MESMO! O processo de mandar fotos para algum lugar no N900 é fácil e simples, mas irritante se você tem muitas fotos. Além de ser necessária intervenção do usuário. O que eu quero é bem simples: tirei a foto, ela teve as tags de georeferência marcadas, sobe pro servidor. Sem selecionar nada, clicar nada…tudo automático e transparente.

Como eu uso o Flickr, estou inicialmente fazendo apenas para ele, mas tenho a intenção de fazer também para o Picasa.

O funcionamento do programa não é assim tão simples, pois ele é dividido em 3 partes: uma interface gráfica para configuração (que ainda está extremamente crua e conta com apenas 3 botões), um processo rodando em segundo plano para receber as notificações de novas fotos, e um outro processo que deve ser iniciado quando há alguma foto nova a ser enviada.

O processo que fica “escutando” por novas fotos está funcionando. Não do jeito que eu gostaria, mas infelizmente não encontrei outra forma. Ele vai ser avisado sobre qualquer imagem nova no aparelho…mas mais pra frente penso em colocar uma configuração para dizer quais diretórios devem ser considerados.

Esse processo, quando recebe o evento de nova imagem, chama o outro processo responsável por fazer o upload.

Isso foi pensado para diminuir a quantidade de memória necessária para o programa rodar. Enquanto ele estiver apenas esperando por uma imagem ocupará muito pouco. Além de não ter processamento envolvido (portanto, sem grandes consumos de energia).

Neste momento eu já faço a autenticação do programa com o Flickr, inicio e finalizo o serviço de escuta (ainda manualmente), e faço o upload das imagens. E também ligo o GPS para pegar as coordenadas caso a foto não as tenha.

Ainda há bastante trabalho a se fazer, principalmente na interface gráfica.

Embelezando o Blockout

Eu não sou nenhum especialista em desenho, e muito menos em fazer telas! Mas estou tentando deixar o jogo mais agradável visualmente. A primeira “vítima” dessa minha ideia é o tabuleiro.

Não é tão simples quanto parece. Como eu tenho por premissa para o jogo ele ser totalmente configurável, não dá para ter uma imagem fixa. Afinal de contas tanto a quantidade de linhas e colunas quanto a profundidade podem ser definidas pelo jogador, o que interfere diretamente na imagem.

Originalmente apenas desenhava as linhas, seguindo a sequência mostrada nestas imagens.


(clica que cresce)

Primeiro o fundo, depois as “camadas”, e por último as linhas diagonais, que juntando tudo resulta na última imagem.

Mas como colocar os blocos com uma textura e ainda manter a aparência de profundidade? Criei uma imagem, que na prática é um triângulo (na verdade um quadrado com “metade” desenhado e a outra metade transparente). Coloco essa imagem na tela, fazendo com que ele preencha metade do tabuleiro. Para a outra metade, rotaciono a imagem e aplico um filtro para deixá-la mais clara.

Para o fundo do tabuleiro tenho uma outra imagem, que simplesmente aumento seu tamanho para que preencha todo o fundo. Mas deixando apenas assim não temos a noção de profundidade tão boa, como dá pra ver nesta imagem.

A solução é desenhar linhas junto às linhas separadoras dos blocos, algumas mais claras, outras mais escuras. Assim temos um efeito melhor de 3D. Ainda não está 100%, mas pelo menos não é mais tão feio quanto antes!

Este é o resultado atual.

O próximo passo é conseguir fazer as peças que estão já fixas no fundo também ganharem uma textura, para não ficarem com a cor tão uniforme.

Uma atualização no Blockout

No primeiro texto sobre o jogo eu falei que um bom projeto sempre começa com a documentação. O motivo disso é simples: é através da documentação que você percebe diversos detalhes e, muitas vezes, evita armadilhas.

A armadilha do momento é: como fixar as peças no tabuleiro? Pode parecer simples, mas há duas situações. A primeira é quando a peça está acima de qualquer outra. Aí é fácil, pois basta ela ir “descendo” até que não possa mais. Isso estava funcionando perfeitamente.

Até o momento em que tentei fazer uma coisa: ir descendo com uma peça até ser possível encaixá-la no vão deixado entre outras duas. Isso não funciona! Pelo menos não com a lógica que estava usando. E para descobrir a lógica correta? Algumas horas quebrando a cabeça….

Como se pode ver nas figuras acima a interface progrediu um pouco. E comparando com uma imagem anterior dá pra ver que um dos controles sumiu!!

Pois é…..caiu a ficha de que não são necessários dois controles! Apenas um já resolve meu problema. Pressionando qualquer uma das setas a peça se move no sentido dela (cima, baixo, direita, esquerda). Pressionando o círculo no centro a peça “desce” um nível ou, se pressionando por um tempo mais prolongado, ela é fixada.

Para rodar a peça no sentido horário ou anti-horário basta pressionar uma das setas e mover o dedo em direção a outra! Por exemplo, para rodar uma peça no sentido horário, basta pressionar a seta para cima e deslizar o dedo para a seta para a direita. Para o sentido anti-horário, basta ir no sentido oposto: da seta pra cima para a seta para a esquerda.

E para rotacionar a peça no próprio eixo (ou girá-la), basta fazer o mesmo processo, porém usando as setas opostas. Se eu quero girar uma peça “para cima”, basta pressionar a seta para baixo e deslizar o dedo até a seta para cima.

Um controle simples, e funcional. E ainda permite que tanto destros quanto canhotos joguem sem problemas, já que basta apenas mudar o lado dele.

Já há também o placar, e mais dois botões ali embaixo: um para o som (que por enquanto está desativado pois, claro, não há som), e outro para pausar o jogo. Tocar o “tabuleiro” também o pausa.

A tela como um todo ainda está bem pobre. Mas a minha prioridade é deixar o jogo jogável, e sem bugs. Só depois melhorar a aparência.

Imagens do MeeGo no N900

Estas são algumas imagens do MeeGo rodando no N900. Até pensei em fazer um vídeo, mas vou poupar a todos de ouvir minha maravilhosa voz! 🙂



A primeira foto está ruim, mas optei por deixá-la para mostrar como é a tela “normal” dele. A segunda foto é o menu, onde se chega ao pressionar “quadrado vermelho” no rodapé central da tela. A terceira foto é a continuação do menu, movendo a tela para a esquerda. Os dois pequenos quadrados no topo central acredito que informem a quantidade de telas que há…no caso, duas.

A quarta foto é a tela de configurações. Na quinta vemos as redes wireless localizadas. E a última seriam as configurações de aparência. Dá para perceber nitidamente que o trabalho atual é fazer as coisas funcionarem, e não deixá-las utilizáveis.

Nenhum dos programas existe. Na verdade há apenas o ícone. Para os poucos ícones de programas que fazem algo é exibida apenas uma tela branca com um texto dizendo “espaço a ser utilizado pelo programa XYZ” (onde o XYZ é o nome do programa em si).

Eu consegui fazer o Multiboot iniciar o MeeGo, mas infelizmente não consegui fazer dar boot novamente no Maemo sem utilizar o Flasher (não perdi nada, tive apenas que rodar o Flasher para reinstalar o kernel). Ainda vou tentar ver se o Multiboot conseguiria se recuperar, mas sem pressa.

MeeGo no N900

A Nokia disponibilizou imagens do MeeGo para instalação no N900.

São dois arquivos, encontrados aqui:
– meego-handset-armv5tel-n900-nokia-proprietary-1.0.80.13.20100803.2-mmcblk0p.raw.bz2: o arquivo que contém a imagem em si
– meego-handset-armv5tel-n900-nokia-proprietary-1.0.80.13.20100803.2-vmlinuz-2.6.35~rc6-133.2-n900: o kernel necessário para iniciar o aparelho no MeeGo

Há um guia para instalação do sistema no cartão de memória, de forma a que o Maemo não seja tocado. Eu vou tentar fazer a instalação, no cartão de memória, porém usando o esquema de multi-boot implantado com o Android.

Mas convém salientar que o sistema ainda não é utilizável no N900! Ou seja, é provável que o Android rode mais redondo que o MeeGo neste estágio. Para o usuário comum, não vale a pena.

Mais tarde este texto será atualizado com o sucesso (ou não) da empreitada!

Atualização: não obtive muito sucesso. Instalando o kernel através do Flasher o aparelho não deu boot, e com o Multiboot também não deu certo. Talvez novamente outra hora…

Nova atualização: consegui fazer o N900 dar boot no MeeGo. Realmente foi o que imaginei: neste ponto o Android está mais avançado que o próprio MeeGo no N900. O touch está terrível…é preciso apertar consideravelmente a tela para reconhecer o toque. A navegação pelo sistema também está bem ruim e muitos ícones não está aparecendo (fica apenas um quadrado vermelho).

O wi-fi funcionou, reconhecendo minha rede doméstica (que possui criptografia WPA2), mas não consegui rodar o navegador (ou aquilo que eu acho que deveria abrir um). Tentarei tirar algumas fotos ou fazer um vídeo do aparelho rodando o MeeGo.

Realmente não recomendo, pois não há praticamente nada a ser fazer nele, a menos que você seja curioso.

Aplicativos criminosos

As lojas de aplicativos trouxeram uma grande facilidade para os usuários, e uma mina de ouro para os desenvolvedores. Já teve muita gente ganhando bastante dinheiro com eles. Obviamente com o tempo a receita vai caindo, pois a concorrência vai aumentando.

O problema das lojas é que normalmente os programas que estão nelas são fechados. Você não tem acesso ao código-fonte deles. Mas pra que isso importa para a maioria dos usuários, que sequer saberia como abrir o código? E muito menos ver o que está fazendo??

Para essa maioria, nada! Mas para uma minoria que se preocupa com segurança importa muito.

Há algum tempo o Google usou uma característica presente no Android que lhe permite apagar programas instalados no equipamento remotamente. Sim, você leu certo!! Ao pressionar um botão o Google pode apagar um programa que está instalado no SEU aparelho. Assim como a Amazon pode apagar um livro que está no seu Kindle.

Mas por que isso? Porque não se tem como saber tudo o que um programa de código fechado faz. Simples assim.

Foi descoberta na loja do Android um aplicativo que pegava as informações pessoais do usuário (IMEI, telefone, lista de contatos, etc.) e enviava para um servidor qualquer na internet. Ele estava disfarçado de protetor de tela.

E hoje surgiu a bomba de que um aplicativo da AppStore (a loja da Apple), também rouba informações do usuário.

Eu já escrevi sobre o que penso das lojas online.

Um exemplo de preocupação veio de um usuário do pySafe, pouco antes que eu publicasse o código-fonte, questionando onde ele (o código) estaria, pois ele queria ter certeza que suas informações pessoais não seriam roubadas.

Como garantir isso numa aplicação fechada? Confiar numa empresa é possível (até porque do contrário ficaremos malucos), mas e num cara que faz o programa num final de semana sentado na cama enquanto assiste televisão?

Deixar essa confiança nas mãos de quem cuida das lojas é inviável. Assim como o usuário, eles também não tem acesso ao código-fonte.

Esse é um problema para o qual dificilmente teremos uma solução. E uma nova frente se abrirá para as empresas que ganham dinheiro às custas de criminosos e usuários desatenciosos….leia-se empresas que fazem antivirus.

Procura-se designer

Estranho o título do texto, não? Mas faz todo o sentido.

Para 90% dos usuários de aparelhos celulares, ele deve ser bonito. Mas não bonito apenas estruturalmente, mas também na tela e nos seus programas. A esmagadora maioria dos usuários não está interessada em poder de processamento, apenas em velocidade de resposta. Não se importa com um programa que nada faça, contanto que seja bonito.

E na minha opinião é isso que falta para o Maemo (e provavelmente faltará para o MeeGo).

Existem programas muito bons para o N900, mas feios. Você olha o programa e ele não te chama a atenção! Você o usa porque precisa dele. E isso faz uma grande diferença para muitos usuários!

Veja o exemplo do TweeGo. Mesmo em suas versões alpha ele já chamava muito a atenção! Não pelo seu funcionamento (o Witter fazia, e ainda faz, mais coisas que ele), mas porque é bonito, é agradável, é prazeroso usá-lo.

O próprio aparelho fica muito mais bonito ao instalar um tema mais agradável que o original, com efeitos de transição e ícones novos.

A comunidade de código aberto é extremamente competente, e muitas vezes faz coisas que nem se espera dela. Mas peca na usabilidade e na apresentação. O pySafe na sua primeira versão era horrível. Hoje em dia é apenas feio.

O pessoal do TweeGo, até onde entendi, tem uma pessoa responsável pela parte visual do programa. Não é todo mundo que pode contar com uma ajuda assim.

Se você acha que não tem como colaborar com um programa por não saber nada de programação, pense que talvez possa ajudar criando um ícone, dando uma ideia para melhorar a usabilidade, fazendo uma imagem para um botão, ou um desenho para uma tela de fundo, até mesmo criando um esboço de tela!

O exemplo mais claro e nítido de que uma tela bonita é muito mais interessante é o fato de um programa gráfico ser muito mais usado do que o correspondente (e muitas vezes absurdamente mais potente) na linha de comando.