A sigla JSON significa “Javascript Object Notation”, ou “Notação de Objetos do Javascript”. Trata-se de um formato de serialização de dados, tal qual YAML ou até XML. Seu principal diferencial é que, ao invés de alternativas mais complexas como XML, ele é fácil de ser lido por humanos (tendo a mesma sintaxe do Javascript, basicamente) e também é simples de ser lido por programas de computador (tendo a mesma sintaxe do Javascript, basicamente).
Um formato de serialização é o que permite você transmitir um objeto mais ou menos complexo (como um dicionário cheio de valores ou, meramente, um número inteiro) por um transporte simples e não-tipado (um socket, um pipe ou até um simples arquivo).
A sintaxe do JSON (conforme consta no site http://json.org ) é bem simples:
Motivação
Não adianta tentar negar: se você quer uma aplicação que rode direito no Android, você, programador-não-Java, precisa sujar as mãos e enfrentar o velho Androidão de frente, meter a mão na massa e se embrenhar pelo mundo assombroso do Java do Android (argh!), das bibliotecas, da IDE, das licenças e, enfim, de todo o ferramental necessário para se escrever aplicações nativas.
Eu atualmente tenho dois projetos cuja base de funcionamento são aplicações que rodem em celulares de gente normal. Um deles envolve extrair dados de praticamente todos os sensores presentes no aparelho, enquanto o outro baseia-se mais em notificações personalizadas por usuário.
Sobre este último, eu cheguei a considerar criar Progressive Web Apps. Cheguei a pesquisar sobre Push Notifications. Mas, sinceramente, não senti que as alternativas eram boas o bastante e, no fim das contas, tenho percebido que dificilmente eu escapo de ter que pelo menos conseguir escrever aplicações nativas para Android.
Até para o meu trabalho atual é interessante eu possuir essa habilidade…
Neste artigo apresento como escrever aplicações nativas Android usando Python e as ferramentas do projeto PyBee.
Não pretendo tratar diretamente da sintaxe da linguagem, já que você pode aprendê-la facilmente na documentação disponível no site oficial. O que considero muito mais útil é apresentar exemplos de coisas que fazemos comumente no nosso dia-a-dia.
Nesse exemplo mostrarei o início de um projeto pessoal que funciona assim: o programa lê constantemente da entrada padrão ( stdin ) e a GUI (“graphical user interface”) reage de acordo com essa entrada.
Antes de começar a falar da linguagem em si, acho interessante falar sobre como acabei descobrindo-a e, especialmente, como resolvi encarar esse trabalho de pastar feito um jumento que é aprender uma nova linguagem de programação.
Pastar
Sim, pastar. Sofrer e ficar de saco cheio.
Porque o futuro é distribuído — e legal!
Não faz muito tempo eu comecei uma pesquisa sobre IPFS, o Sistema de Arquivos InterPlanetário. E eu realmente aprecio que haja um esforço honesto para que um protocolo seja criado para lidar com “questões distribuídas”. Mas há pessoas que gostam de partir rapidamente para as questões mais práticas e acabam conseguindo construir algumas coisas bem interessantes.
É o caso do projeto ZeroNet.
A internet invisível
tl;dr
– I2P é uma rede própria (uma darknet);
– É muito fácil de instalar e rodar;
1- O que é o I2P
“I2P” é a sigla de “The Invisible Internet Project” ou “O Projeto da Internet Invisível”. Trata-se de uma darknet, ou seja, é uma rede per si, isolada da clearnet (a internet que as “pessoas normais” usam).
1.1- Anonimato
O objetivo principal do I2P é o anonimato: se usado da maneira correta é muito difícil que você seja (a) identificado e (b) tenha seu tráfego monitorado. Entretanto, ao contrário do Tor (The Onion Router), cujo objetivo é “anonimato para acessar o Facebook”, por exemplo, o I2P simplesmente não serve para acessar nada da clearnet: I2P é uma rede em si mesmo, isolada de outras redes.
HTTP é um protocolo baseado em streams de texto. Muito resumidamente, o cliente abre um socket para falar com o servidor e, nesse socket, envia requisições (requests), as quais o servidor responderá com respostas (responses).
O texto da requisição HTTP tem, basicamente, três partes: request line, headers e body. Esse texto é lido linha a linha, sendo que cada linha é separada por CR+LF (carriage return + line feed). (line feed = newline = ‘\n’).
O formato geral é o seguinte:
O sistema de arquivos interplanetário
O que é o IPFS
É um sistema de arquivos.
Caso você já tenha começado a pesquisar sobre IPFS, pode acabar ficando confuso com a maneira como esse protocolo é abordado. Geralmente os artigos começam com uma seção “IPFS versus HTTP” ou “HTTP é quebrado”, o que eu acho não somente desnecessário, como também que gera uma tendência grande de desentendimento a respeito da coisa toda.
IPFS é a sigla para “InterPlanetary File System”. Logo, além de ser um sistema de arquivos, parece que a ideia é que ele seja ubíquo, onipresente.
Ou: como não escrever APIs que fedem
Your API stinks!
— Me
O “I” de “API” é de “Interface”, e me parece que “o mal do século” no mundo da programação é a falta de boas interfaces. Nós temos bom hardware, boas linguagens de programação, boa velocidade de rede para comunicar processos inter-máquinas (inter-continentalmente, inclusive) e temos bons protocolos à nossa disposição. Mas o desenho de interfaces parece avançar como “a lesma subindo o poço” dos problemas de Física do Ensino Médio: sobe um metro e meio, desce um metro, sobre um metro e meio, desce um metro…
Enquanto os protocolos cumprem o papel de linguagem (e uma espécie de meio, especialmente nos níveis “físicos” dos protocolos de rede, por exemplo), definindo como um componente deve “falar” com o outro (desculpa, São Dijkstra, eu antropomor… fi… zo… descaradamente, mesmo), as interfaces definem o que um componente deve dizer ao outro e o que esperar como resposta.