Build 2015 – Build Tour São Paulo

Build 2015 - São Paulo

A conferência Build é o meu evento técnico preferido, desde que a Microsoft extinguiu o MIX em 2011, mas infelizmente eu não irei para o Build em São Francisco esse ano. Por um lado essa é até uma boa notícia, com a cotação do dollar do jeito que está, mas não tem preço a oportunidade de interagir diretamente com o pessoal da Microsoft e outros profissionais, além de rever velhos amigos, conhecidos e MVPs do mundo todo com quem normalmente interajo apenas por redes sociais e e-mails.

[continuar lendo]

Navegacao localhost com Project Spartan no Windows 10

Se você está usando o Preview do Windows 10 então provavelmente estava tão ansioso quanto eu para poder testar logo o Spartan, novo navegador de internet da Microsoft. Ontem (30/03/2015) foi liberado para o grupo FAST o update 10049, contendo a primeira versão pública do Spartan.

Como era de esperar de um desenvolvedor web, a primeira coisa que fui testar foi um site que está hospedado no IIS do meu computador. Para a minha surpresa, a página nao carregou de forma alguma, mesmo estando funcionando normalmente nos outros navegadores instalados no mesmo computador.

Como todo bom beta tester, a primeira coisa que fiz foi relatar este problema para a Microsoft, usando o aplicativo Windows Feedback do Windows 10, detalhando o que eu tentei fazer e inclusive adicionando prints de tela. Como no meu computador de trabalho eu não coloquei o Windows 10 ainda (achei melhor ter pelo menos 1 computador com Windows 8.1, "just in case..."), não tive como continuar testando e só pude voltar a "brincar" quando cheguei em casa.

Após fuçar um pouco eu me dei conta de uma coisa: O Spartan é um aplicativo Metro/Modern/Universal/Windows. Sendo assim ele está sujeito às mesmas restrições de qualquer aplicativo que façamos para a loja. Uma dessas limitações é que esses aplicativos, por padrão não têm permissão para fazer requesições web de loopback, ou seja, requisições para a própria máquina. Isso inclui localhost, "nome-do-computador", entradas no arquivo de hosts local, etc... Este recurso se chama AppContainer e é um mecanismo de segurança dos aplicativos da loja.

Como sou desenvolvedor web, uma ferramenta que uso bastante é o Fiddler, para monitorar e depurar tráfego http de projetos em que trabalho. Acontece que o Fiddler tem uma configuração que nos permite criar excessões de loopback para que aplicativos da loja possam realizar requisições locais.
Para realizar essa configuração basta acessar o menu Tools > Win8 Loopback Exemptions ou clicar na opção WinConfig da barra de ferramentas.

opção WinConfig na barra de ferramentas do Fiddler

Após isso será exibida a tela abaixo, contendo a lista de aplicativos da loja, onde você poderá informar quais estão isentos da restrição de loopback. Agora basta escolher o Project Spartan, salvar a configuração e usar o novo navegador com seu sites locais normalmente. Espero que nos proximos builds do Windows 10, ou pelo menos antes da versão final o Spartan já venha com essa exceção configurada por padrão.

PS.: Uma segunda opção para editar as regras de exceção é o aplicativo open source Windows 8 Loopback Exempltion Manager disponível no Codeplex: http://loopback.codeplex.com/. Se você quiser entender como funciona essa lista de exceção, dê uma olhada no código fonte desse aplicativo.

Resolvendo mudanca automática de layout de teclado no Windows 8

Desde quando instalei o Windows 8 no meu computador, ainda durante o beta, eu notei um comportamento estranho e que me incomodava muito: O layout do meu teclado mudava “sozinho”.

selecao de teclado e lingua

No início eu achava que era a sincronização de configurações que estava fazendo isso, mudando o layout do meu computador do trabalho para o layout de casa e vice-versa. Para a maioria das pessoas isso não seria um problema, pois normalmente teriam todos os teclados com o mesmo layout (ABNT2 para o teclados nacionais). Mas para mim isso é um problema pois tenho 3 computadores:

[continuar lendo]

Webcast sobre Novidades no WPF 4.5 - MVP Showcast 2014

MVP ShowCast 2014

Entre 15 de setembro e 09 de outubro deste ano acontecerá a quarta edição do MVP ShowCast, um evento virtual gratuito sobre tecnologias Microsoft, composto por webcasts transmitidos ao vivo por MVPs e outros profissionais conhecidos da comunidade técnica brasileira. O evento é organizado por MVPs com o apoio da Microsoft e será composto por 64 sessões, sendo 32 de TI e 32 desenvolvimento de software.

Este ano eu apresentarei uma sessão no dia 08/10 as 20:00 sobre as Novidades no WPF 4.5. Se você tiver interesse nesta ou em outras sessões do evento, basta se inscrever nelas pelo site e esperar pelo dia da apresentação. Não percam essa oportunidade.

Integrando o botão voltar do Windows Phone com o controle WebBrowser

Recentemente trabalhei em um projeto para Windows Phone onde a aplicação continha um mix de telas xaml e webviews (páginas web hospedadas nos servidores da empresa). O uso de webviews era um requisito da empresa pois as funcionalidades existentes nessas páginas não estavam disponíveis por meio de apis e tais apis não serão disponibilizadas no futuro próximo.

Para dar uma boa experiência para os usuários da aplicação, queríamos que o botão voltar do aparelho também afetasse a navegação do webview, fazendo com que o usuário não perceba que estã em uma webview e a aplicação inteira tenha um comportamento consistente. Já vi várias aplicações no Windows Phone que usam webviews sem fazer isso e a experiência é péssima pois você está no webview, usa o voltar do aparelho para tentar ir para a página anterior e acaba saindo da navegação do webview por completo e indo para a tela anterior ao webview (o aplicativo Audible é um exemplo desse comportamento ruim).

Para fazer essa integração com o botão voltar não basta assinar o evento do voltar do telefone e chamar o voltar do webbrowser pois é necessário saber se o webbrowser ainda tem para onde voltar e temos que tomar cuidado para não entrar em um looping de backstack (navegando entre páginas que foram chamadas usando o back, fazendo com que a pilha nunca acabe).

Para realizar isso de forma correta, precisamos controlar a navegação do webview. Esse controle consiste em criar e manter uma lista contendo as urls navegadas e um método que decide se o webview ainda pode voltar. A única limitação da solução proposta neste post é que ela só funciona corretamente para casos onde a navegação entre as páginas em modo webview passa parametros via url (querystring) e não via post. Se alguma página for navegada via post, o back pode não vai voltar para ela como o usuário espera. No caso da aplicação que eu estava trabalhando isso não seria um problema, mas se fosse seria necessária uma solução bem mais complexa que envolveria injeção de javascript nas páginas do webview.

O controle da navegação é feito assinando o evento “Navigated” do controle WebBrowser. Abaixo segue o código comentado usado nesse event handler.

int GoingBack = 0; //contador indicando se está voltando
Uri CurrentPage = null;
Stack<Uri> NavigationStack = new Stack<Uri>(); //pilha de navegação

///


/// conta quantas páginas foram navegadas para saber se pode voltar.
/// ignora a contagem quando a navegação foi feita usando back
///

void webview_Navigated(object sender, NavigationEventArgs e) {
    lock (this) {
        if (GoingBack > 0) {
            GoingBack--;
        } else {
            if (CurrentPage != null) {
                NavigationStack.Push(CurrentPage);//acrescenta a página de onde está saindo na pilha de navegação
            }
        }
        CurrentPage = e.Uri;
    }
}

O NavigationEventArgs do evento acima tem uma propriedade chamada NavigationMode que teoricamente indicaria se a navegação é do tipo New, Back, Forward ou Refresh, mas não está sendo usada pois ela não indicou os valores corretos nos meus testes, mesmo quando eu estava usando “history.back();” ou “history.go(-1);” via javascript injection no webview. Por isso foi necessário controlar se está sendo feita navegação de back e quais páginas estão na pilha.

O segundo método usado para esse processo é o responsável por tentar efetuar a navegação do webview para a página anterior e informar se conseguiu.

///


/// Tenta navegar o browser para a página anterior. Se conseguir retorna true, se não houver página anterior ou der erro, retorna false.
///

bool TryGoBack() {
    lock (this) {
        if (NavigationStack.Count > 0) {
            try {
                GoingBack++;
//incrementa o contador de navegação voltando
                webview.Navigate(NavigationStack.Pop()); //remove a última página navegada da pilha e navega para ela
                return true;
            } catch { }
        }
    }
    return false;
}

A última parte do processo todo é assinar o evento do botão back do telefone usando o código abaixo:

protected override void OnBackKeyPress(System.ComponentModel.CancelEventArgs e) {
    e.Cancel = TryGoBack();
    if (!e.Cancel) base.OnBackKeyPress(e);
}

Se sua aplicação tiver mais de um lugar que utilize webviews, você pode criar um controle para encapsular o webbrowser e os 2 primeiros métodos, mas o evento do botão voltar deverá ser assinado em cada página que usar esse controle, pois não é possível assinar o evento do voltar a partir de controle. Não esqueça de fazer o método TryGoBack ser public se encapsular o controle, para poder chamar a partir da página.

DISCLAIMER: Este código é disponibilizado “as is”, e atende às necessidades descritas acima, mas deve ser bem testado para garantir que funcionará da forma desejada em outras aplicações. Este código funciona tanto para Windows Phone 7 como 8.