Telas com alta densidade de pixels, chamadas pela Apple de "telas Retina", já são uma realidade. Temos smartphones, tablets e notebooks com essa incrível resolução.
Se considerarmos a porcentagem de visitantes utilizando essas telas, pode parecer pouco, mas esse é um número que só vai crescer a cada dia. Como diz o Marco Arment, esses visitantes representam o futuro. Não é como a porcentagem de pessoas utilizando o Internet Explorer 6, que só tende a diminuir, nesse caso o número só vai aumentar.
Agora, como adequar seu site para essas telas? Como primeiro passo, siga esse guia. A biblioteca Retina.js pode lhe ajudar a prover imagens de alta resolução apenas em dispositivos compatíveis, economizando largura de banda para os outros dispositivos.
Alterar as imagens do site é apenas o primeiro passo. Com isso feito, cabe a você identificar as áreas que não estão com boa aparência. Talvez trocar a fonte utilizada, ajustar outros elementos do site... mas isso só vendo o site em uma tela Retina pra poder dizer.
Mostrando postagens com marcador Internet. Mostrar todas as postagens
Mostrando postagens com marcador Internet. Mostrar todas as postagens
sábado, 14 de julho de 2012
quinta-feira, 28 de junho de 2012
Google Chrome para iPhone e iPad
O Google acaba de lançar o Chrome para iPhone e iPad.
O Chrome utiliza a mesma engine de renderização do Safari, pois a Apple proibe que aplicativos usem outra engine. Dessa forma, o Google não pode utilizar por exemplo sua engine de javascript V8 e nem mesmo fazer outras otimizações no WebKit.
Só resta ao Google se dedicar a criar uma interface muito boa, e foi justamente isso que fizeram. A interface é claramente inspirada no WebOS, não é a toa que recentemente contrataram vários funcionários que trabalharam no desenvolvimento do finado sistema da Palm/HP.
Para alterar entre as guias, as telas são apresentadas como um baralho de cartas. Para eliminar uma guia, basta arrastá-la para "fora do baralho". As imagens abaixo mostram o funcionamento das guias (clique para ampliar).
Outro recurso interessante é a troca rápida de abas (também inspirado no WebOS). Pode-se arrastar a tela na direção da borda para o centro para mudar entre as abas. É necessário iniciar o movimento bem no canto da tela, vindo de fora da tela para dentro.
Além do visual interessante, ele também conta com recursos como sincronização de abas, sincronização de favoritos, e o famoso modo anônimo. A velocidade dele me parece ser semelhante ao Safari, mas preciso testar mais para afirmar com certeza.
O único ponto negativo é a limitação imposta pela Apple, não permitindo que navegadores de terceiros sejam definidos como o navegador padrão. Já passou da hora dela remover essa limitação!
Veja abaixo o vídeo de divulgação do Google:
O download do Chrome para iOS (iPhone e iPad) pode ser feito pela App Store.
O Chrome utiliza a mesma engine de renderização do Safari, pois a Apple proibe que aplicativos usem outra engine. Dessa forma, o Google não pode utilizar por exemplo sua engine de javascript V8 e nem mesmo fazer outras otimizações no WebKit.
Só resta ao Google se dedicar a criar uma interface muito boa, e foi justamente isso que fizeram. A interface é claramente inspirada no WebOS, não é a toa que recentemente contrataram vários funcionários que trabalharam no desenvolvimento do finado sistema da Palm/HP.
Para alterar entre as guias, as telas são apresentadas como um baralho de cartas. Para eliminar uma guia, basta arrastá-la para "fora do baralho". As imagens abaixo mostram o funcionamento das guias (clique para ampliar).
Outro recurso interessante é a troca rápida de abas (também inspirado no WebOS). Pode-se arrastar a tela na direção da borda para o centro para mudar entre as abas. É necessário iniciar o movimento bem no canto da tela, vindo de fora da tela para dentro.
Além do visual interessante, ele também conta com recursos como sincronização de abas, sincronização de favoritos, e o famoso modo anônimo. A velocidade dele me parece ser semelhante ao Safari, mas preciso testar mais para afirmar com certeza.
O único ponto negativo é a limitação imposta pela Apple, não permitindo que navegadores de terceiros sejam definidos como o navegador padrão. Já passou da hora dela remover essa limitação!
Veja abaixo o vídeo de divulgação do Google:
O download do Chrome para iOS (iPhone e iPad) pode ser feito pela App Store.
segunda-feira, 13 de setembro de 2010
Como funciona a autenticação OAuth
Nos últimos anos, com a tão aclamada Web 2.0 muitos sites passaram a fornecer APIs que podem ser usadas por terceiros para agregar valor ao sistema. Sites como Twitter e Facebook devem grande parte de seu sucesso pelo fato de ter essa possibilidade de extensão.
Nesses sites normalmente a API é acessada "em nome" de um usuário. Ou seja, é necessário ter um usuário autenticado para obter os dados. Vou tomar como exemplo o Twitter, que é bem conhecido de todos. Para que uma aplicação possa enviar um tweet em nome do usuário, ela precisa do login e senha dele.
Agora vem a questão, quem gosta de compartilhar sua senha com os outros? Mesmo que o outro seja uma aplicação. E, ao alterar sua senha, você deseja ir em cada aplicativo e reconfigurá-lo?
Para resolver esse problema surgiu o protocolo de autenticação OAuth.
Basicamente, a aplicação pede permissão de acesso para aquele usuário e o usuário concede ou não a permissão, sem que para isso tenha que informar a senha. Essa permissão independe da senha. Mesmo que a senha seja alterada a permissão continuará válida. Além disso, a permissão dada à aplicação cliente pode ser revogada a qualquer momento.
Eu tentei explicar o funcionamento em um nível bem alto, sem entrar em detalhes técnicos. Para uma explicação mais aprofundada recomendo a leitura deste link e deste. Deixei de lado aspectos como criptografia e HTTPS, focando basicamente no fluxo da autenticação. Então vamos lá...
A autenticação por meio do OAuth consiste de três passos:
Nesse momento a aplicação cliente solicita à aplicação servidora uma chave de autenticação. A aplicação servidora devolve duas chaves, uma pública e uma privada. Repare que essas chaves não dão permissão de acesso, elas são usadas apenas durante o processo de autenticação.
A seguir, a aplicação cliente redireciona o usuário para a aplicação servidora usando a chave pública (no caso do TwitPic, por exemplo, o usuário vai para o site do Twitter).
Assim que o usuário efetuou a autorização, ele é redirecionado de volta à aplicação cliente.
Repare que, para se comunicar com a aplicação servidora é utilizada a chave privada, desse modo, apenas a aplicação cliente consegue obter a chave de acesso.
A chave de acesso obtida é utilizada pelo cliente para acessar a API do servidor “em nome” do usuário.
O usuário deve ter cuidado ao autorizar qualquer aplicação cliente. Ele deve dar autorização apenas às aplicações que ele confia, pois com essa autorização, uma aplicação mal intencionada pode fazer tantos estragos quanto faria se o usuário passasse sua senha.
Um detalhe importante é revogar a autorização de aplicações que não são mais utilizadas ou de origem duvidosa. No Twitter, por exemplo, pode-se acessar esta página para remover a permissão de acesso.
Aproveite que você está lendo isso e olhe sua lista de aplicativos com acesso permitido ao Twitter, provavelmente alguns deles você nem lembra mais que existem.
Nesses sites normalmente a API é acessada "em nome" de um usuário. Ou seja, é necessário ter um usuário autenticado para obter os dados. Vou tomar como exemplo o Twitter, que é bem conhecido de todos. Para que uma aplicação possa enviar um tweet em nome do usuário, ela precisa do login e senha dele.
Agora vem a questão, quem gosta de compartilhar sua senha com os outros? Mesmo que o outro seja uma aplicação. E, ao alterar sua senha, você deseja ir em cada aplicativo e reconfigurá-lo?
Para resolver esse problema surgiu o protocolo de autenticação OAuth.
Objetivo
O principal objetivo do OAuth é permitir que uma aplicação se autentique em outra "em nome de um usuário", sem precisar ter acesso a senha dele.Basicamente, a aplicação pede permissão de acesso para aquele usuário e o usuário concede ou não a permissão, sem que para isso tenha que informar a senha. Essa permissão independe da senha. Mesmo que a senha seja alterada a permissão continuará válida. Além disso, a permissão dada à aplicação cliente pode ser revogada a qualquer momento.
Funcionamento da autenticação OAuth
Pesquisei na internet a respeito do funcionamento dessa autenticação e, na maioria das vezes, a explicação é bem técnica. Geralmente é explicado apenas como usar determinadas bibliotecas.Eu tentei explicar o funcionamento em um nível bem alto, sem entrar em detalhes técnicos. Para uma explicação mais aprofundada recomendo a leitura deste link e deste. Deixei de lado aspectos como criptografia e HTTPS, focando basicamente no fluxo da autenticação. Então vamos lá...
A autenticação por meio do OAuth consiste de três passos:
- Aplicação cliente obtém chave de autenticação;
- Usuário autoriza aplicação cliente na aplicação servidora;
- Aplicação cliente troca a chave de autenticação pela chave de acesso;
1 - Aplicação cliente obtendo chave de autenticação
No primeiro passo o usuário inicia o processo de autenticação. Por exemplo, no site TwitPic ele clicaria no botão “Login or Create an Account”.Nesse momento a aplicação cliente solicita à aplicação servidora uma chave de autenticação. A aplicação servidora devolve duas chaves, uma pública e uma privada. Repare que essas chaves não dão permissão de acesso, elas são usadas apenas durante o processo de autenticação.
A seguir, a aplicação cliente redireciona o usuário para a aplicação servidora usando a chave pública (no caso do TwitPic, por exemplo, o usuário vai para o site do Twitter).
2 - Usuário autorizando o acesso
Depois que o usuário foi redirecionado para a aplicação servidora, ele autoriza o acesso da aplicação cliente. No Twitter isso ocorre ao clicar em “Allow”.Assim que o usuário efetuou a autorização, ele é redirecionado de volta à aplicação cliente.
3 - Aplicação cliente trocando a chave de autenticação pela chave de acesso
Nesse momento, a aplicação cliente troca a chave de autenticação pela chave de acesso. A chave de acesso só é concedida se o usuário autorizar o acesso.Repare que, para se comunicar com a aplicação servidora é utilizada a chave privada, desse modo, apenas a aplicação cliente consegue obter a chave de acesso.
A chave de acesso obtida é utilizada pelo cliente para acessar a API do servidor “em nome” do usuário.
Cuidados e perigos
Um dos perigos desse protocolo é uma questão cultural. Como o usuário não fornece a senha ele se sente seguro. Ele muitas vezes não se dá conta que está dando acesso a aplicação cliente, mesmo sem informar a senha.O usuário deve ter cuidado ao autorizar qualquer aplicação cliente. Ele deve dar autorização apenas às aplicações que ele confia, pois com essa autorização, uma aplicação mal intencionada pode fazer tantos estragos quanto faria se o usuário passasse sua senha.
Um detalhe importante é revogar a autorização de aplicações que não são mais utilizadas ou de origem duvidosa. No Twitter, por exemplo, pode-se acessar esta página para remover a permissão de acesso.
Aproveite que você está lendo isso e olhe sua lista de aplicativos com acesso permitido ao Twitter, provavelmente alguns deles você nem lembra mais que existem.
sábado, 26 de junho de 2010
Que preguiça de pesquisar!!!
É incrível o número de perguntas repetidas que encontro ao fazer uma pesquisa por algum assunto técnico. Todo fórum tem a mesma pergunta repetida inúmeras vezes.
Eu fico me perguntando, será que as pessoas não conhecem o Google ou será que é tão mais fácil postar uma dúvida do que fazer uma simples pesquisa?
Acho que todo site onde o usuário pode postar dúvidas deveria ter uma caixa de pesquisa como a abaixo, que deve ser preenchida obrigatoriamente antes do usuário postar qualquer dúvida. Teste e veja por quê (Se você está lendo pelo Feed, o formulário abaixo não irá aparecer. Clique aqui para acessar o site).
Além disso, o FAQ de diversos sites poderia ser substituído por links como os abaixo. Certamente seriam muito mais relevantes:
Eu fico me perguntando, será que as pessoas não conhecem o Google ou será que é tão mais fácil postar uma dúvida do que fazer uma simples pesquisa?
Acho que todo site onde o usuário pode postar dúvidas deveria ter uma caixa de pesquisa como a abaixo, que deve ser preenchida obrigatoriamente antes do usuário postar qualquer dúvida. Teste e veja por quê (Se você está lendo pelo Feed, o formulário abaixo não irá aparecer. Clique aqui para acessar o site).
Além disso, o FAQ de diversos sites poderia ser substituído por links como os abaixo. Certamente seriam muito mais relevantes:
Assinar:
Postagens (Atom)