ASP.NET MVC - Web para grandes e pequenos: Part III - Ferramentas de Teste

Desenvolvendo aplicações PC + Mobile

• Part I - Introdução
• Part II - Suportando PCs, Celulares e Tablets
• Part III - Ferramentas de Teste

Acessando a máquina de Desenvolvimento

Nada mais útil que liberar o IIS Express da sua máquina para acesso externo. Assim, não é necessário que você publique a aplicação toda vez que queira testar diretamente nos dispositivos mobile.

Para isso basta fazer o seguinte:

1. Abra o arquivo de configuração do IIS Express que está em C:\Users\[Nome do usuário]\Documents\IISExpress\config\applicationhost.config
2. Neste arquivo procure pelo nome da aplicação e no binds adicione o ip da sua máquina . A configuração do meu está assim:

• <binding protocol="http" bindingInformation=":[porta]:[ip] />

IIS Express - Exemplo de applicationhost.config 

Agora é necessário reservar o seu endereço no windows, para isso execute o comando no CMD como administrador:

• netsh http add urlacl url=http://[ip]:[porta]/ user=everyone

Além disso, se você estiver rodando algum firewall de terceiro ou o próprio firewall do Windows é necessário liberar esta porta para acesso externo, logo siga o link abaixo da própria Microsoft, e em caso de outros firewalls procure no site do fabricante.

• Abrir uma porta no Firewall do Windows

Plugins para Browser

Esse método é o mais simples e ajuda a filtrar a maioria dos erros que podem ser encontrados em JavaScript e CSS, dado que você terá acesso à consoles poderosos como o do Chrome para avaliar seu aplicativo.

Existem uma gama de extensões para isso, eu particularmente gosto mais do Mobile/RWD Tester, que é simples e capaz de simular os dispositivos mais variados.

No Google Chrome faça o seguinte:

1. Configurações->Extensões->Obter Extenções
2. Na caixa de busca digite Mobile/RWD Tester
3. Clique no registro de mesmo nome e adicione ao Chrome

Aparecerá um ícone perto da barra de endereços, em que é possível selecionar vários dispositivos, inclusive a orientação deste:

Mobile/RWD Teste no Chrome

Basta selecionar o dispositivo que ele abrirá no tamanho compatível com este.

Iphone5 Selecionado

A mágica desta extensão está no User-Agent. Ele injeta no cabeçalho da requisição um User-Agent igual ao do Iphone 5, logo nossa aplicação vai retornar a View certa para o browser, que além disso vai apresentar a dimensão do aparelho.

Este teste não deve ser o único meio de testar, dado que apenas simulamos a tela e não temos acesso ao touch do dispositivo, por exemplo, que deve ser feito para verificar a usabilidade. 

Além disso, o browser é de um PC, isso não garante nada o funcionamento total no browser mobile.

Virtual Machines

É necessário renderizar a página nos mais variados browsers mobiles, para que seja garantido que tudo funcionará. Se você não tem todos os dispositivos a mão para testar em um por um, máquinas virtuais resolvem o problema.

Existe um serviço online chamado Browserstack. É pago, mas indispensável para garantir qualidade, que é o foco para um produto de sucesso. Há uma conta gratuita trial que permite 28 minutos de teste.

Para instalar:

1. No Visual Studio vá em Tools->Extensions and Updates
2. Selecione Online e digite Browserstack na caixa de pesquisa
3. Instale a extensão e Reinicie Visual Studio

Instalando Browserstack

Vai ficar disponível na lista que contém os browsers o Browserstack.

Browserstack no Visual Studio

Iniciando a aplicação com o Browserstack, uma lista com sistema operacional e dispositivos é exibida:

Browserstack Lista de dispositivos

O browser padrão é aberto diretamente no site do Browserstack. Suas credenciais de loging serão exigidas. Após autenticar uma máquina virtual é disponibilizada exatamente com o dispositivo que você escolheu.

Browserstack - Galaxy SIII

Outra possibilidade seria instalar várias máquinas virtuais, Android e Apple em seu pc e usá-las, mas isso foge um pouco do nosso contexto, então, "google it". (Dica: A do Windows Phone 7/8 já fica disponível quando instalamos a WIndows Phone SDK :D)

Fiddler

O Feddler é um fantástico Web Debugger feito pela Telerik e disponibilizado gratuitamente. Com ele podemos escutar as requisições HTTP e saber se algo está dando errado. É muito útil quando estamos testando nossa aplicação na máquina de desenvolvimento ou produção.

O que você deve fazer então é configurá-lo como proxy em sua máquina e então colocar o dispositivo mobile na mesma rede apontando para este proxy.

Para configurar o Feddler para ser um proxy:

1. Abra o Feddler vá em Tools->Feddler Options
2. Selecione a aba Connections
3. Coloque a porta, a padrão do Feddler é a 8888, e marque a opção Allow remote computers to connect

Feddler - Configuração como Proxy

Você deve configurar seu smartphone/tablet com o IP da máquina em que está o Feddle e a porta na conexão. Eu não vou abordar isso aqui porque cada dispositivo tem uma forma de configuração diferente, consulte a do seu.

O que você ganha com isso? Um sistema para mobile para ser eficiente terá várias chamadas Ajax. Digamos que você vai testar diretamente o aplicativo em um smartphone, por exemplo. Se algo estiver dando errado é possível ver se há requisições, quais foram as respostas e atuar para solucionar o problema.

Final

Espero que tenham gostado da série. O mundo hoje é mobile. Saber zilhões de frameworks para plataformas específicas não é o caminho. Escrever para web é HTML5, CSS3 e JavaScript, aplicação em cloud e não um aplicativo para plataforma X. Como o próprio Fernando Martin Figueira da Microsoft falou:

“Muitas vezes vejo programadores dividirem-se nos segmentos web, mobile e cloud computing, enquanto as novas plataformas de desenvolvimento se esforçam para fazer justamente o oposto, oferecendo uma experiência integrada e uma plataforma que não exija conhecimento específico. “

ASP.NET MVC - Web para grandes e pequenos: Part II - Suportando PCs, Celulares e Tablets

Desenvolvendo aplicações PC + Mobile

• Part I - Introdução
• Part II - Suportando PCs, Celulares e Tablets
• Part III - Ferramentas de Teste

BundleConfig para Mobile

Dado que aplicativo será dividido em dois mundos, nada mais justo que separar as configurações. O BundleConfig já vem como padrão no projeto ASP.NET MVC. Neste concentram-se os CSS e JavaScripts para que sejam enviados para o browser em blocos, reduzindo o número de requisições e também o tamanho. O André Paulovich, MVP em ASP.NET fez um post detalhado sobre Técnicas de Bundling em ASP.NET.

App_Start\BundleConfigMobile.cs

Perceba que os arquivos que escolhi são os ".min". Estes já são a versão minimizada, muito menos Kbytes que os originais. Ideal para mobile, menos consumo de banda.

Em verde está uma chamada importante. Por padrão o BundleCollection está configurado para ignorar esses arquivos, você tem que limpar a IgnoreList ou eles serão descartados.

DisplayModeProvider e User-Agent

Para que sua aplicação consiga identificar qual View renderizar quando é feita uma requisição é usado o User-Agent, que carrega no cabeçalho HTTP uma série de informações como OS, nome do browser, engine do browser, dentre outras informações sobre o dispositivo que está acessando o site.

Exemplo de Requisição e User-Agent

Usando User-Agent é possível criar DefaultDisplayMode, que falam qual será a View que a View Engine deve enviar de volta para o usuário.

Então, crie um DisplayModeProviderConfig na pasta App_Start que encapsulará essa lógica.

App_Start\DisplayModeProviderConfig.cs

O DefaultDisplayMode recebe como parâmetro uma string. Esta string será injetada pela View Engine no caminho dos arquivos, logo, se você acessar por smartphone o Index, ele procurará por Index.Phone.cshtml nas pastas das Views e se encontrar retornará esta para ser renderizada e enviada como resposta para o browser do usuário. 

O processo bem simplificado do ciclo está representado abaixo:

O ContextCondition aceita valor do tipo bool. A função GetDeviceType procura no User-Agent da requisição e retorna se é phone, tablet ou desktop quem está fazendo o acesso. Colocando ContextCondition = true fará com que este DefaultDisplayMode deva ser escolhido.

Existem várias listas na internet com User-Agente, veja por exemplo a string iphone, que é enviada na requisição sinalizando acesso pelo aparelho da apple. A lista é bem extensa, cobri apenas nesse exemplo os dispositivos mais usados.

Layout e Views

Agora que já empacotou o JavaScript + CSS, já sabe como identificar qual o dispositivo está acessando e o como fazer o ASP.NET escolher a View certa, faltam as próprias Views.

Estrutura com os arquivos por tipo de dispositivo

Como havia dito antes, o nome que passamos como parâmetro no DefaultDisplayMode é o complemento que você deve colocar no nome de suas Views. Logo, se você passou Phone, todos seus arquivos para Smartphone tem que ser desse padrão {Nome}.Phone.cshtml.

Outra mudança importante é no ViewStart, em que você deve adicionar condicionais para que o Layout correto seja passado, assim não é preciso incluir manualmente em cada View específica.

Views\ViewStart.cshtml

Nas Views Mobile deve ser adicionado o Bundle correto como abaixo:

Views\Layout.Phone.cshtml

Adicionando Configs ao Global.asax

Para finalizar essa parte, é necessário adicionar nossas novas configurações ao Global.asax.

Global.asax

No próximo post o foco vai ser em ferramentas para testar sua aplicação. Fiquem ligados =D.

Eu desenvolvi uma espécie de Projeto Jump Start, que ainda está incompleto, mas já contém todo isso que falei até agora. Ele está no GitHub, usem e abusem =D.

• Link do GitHub: AspMvcMobileTemplate

ASP.NET MVC - Web para grandes e pequenos: Part I - Introdução

Desenvolvendo aplicações PC + Mobile

• Part I - Introdução
• Part II - Suportando PCs, Celulares e Tablets
• Part III - Ferramentas de Teste

Introdução

Cada vez mais se faz necessário desenvolver aplicações que suportem acessos por meio de Smartphones e Tablets. Atualmente, 18% de todo o tráfego de internet é feito por meio de dispositivos móveis, segundo pesquisa realizada pelo site americano mashable.com.

Disponibilizar ferramentas gerenciais de BI e relatórios para tomada de decisões tornou-se crucial em um mercado tão competitivo. Além de serviços de e-commerce, informações, etc, para serem acessados de qualquer lugar a qualquer hora.

O ASP.NET MVC provê ferramentas de alto nível e com o que há de mais novo no mercado para criação de aplicações deste tipo.

Nesta série de três artigos, falarei como desenvolver aplicativos que extrapolem o mundo dos PCs, e que proporcionem uma usabilidade incrível para o usuário. Abordarei também técnicas e ferramentas para testar sua aplicação.

Design Responsivo x Design Específico

O Design Responsivo é feito por meio de media queries e CSS facilitam a vida quando precisamos que nossas aplicações se adaptem a diversos formatos de tela. Porém, nem tudo são flores, porque o CSS somente esconde, redimensiona e reorganiza o layout para caber na tela.

Todo o conteúdo HTML vai sempre para o cliente, o que é um problema, dado que na maioria das vezes o acesso por dispositivos móveis é feito por redes de velocidade inferior ao que temos em computadores. 

Existem também limitações de recursos de hardware e do próprio browser dos Smartphones e Tablets (compatibilidade dos browsers mobile: mobilehtml5.org/ e jquerymobile.com/gbs/).

Para gastar o mínimo de banda, dar o máximo experiência ao usuário e facilidade de desenvolvimento, o ideal é usar o Design Específico - o que vou focar nessa série de artigos. 

Neste caso, cada dispositivo terá seu próprio Layout e Views específicas que se adaptem melhor a tela do alvo, exibindo apenas informações mais prioritárias.

Mas, isso também nos traz problemas, porque temos de duplicar código, nesse caso, teremos três Views para cada recurso para o usuário, o que dificulta bastante a manutenção, 

Porém fará um cliente do outro lado da tela muito satisfeito em usar sua aplicação em qualquer lugar.

Resumindo:

Design Responsivo 

• Fácil implementar 
• Causa uso excessivo de banda
• Fácil de manter
• Experiência moderada de uso para o usuário

Design Específico

• Fácil implementar
• Reduz muito uso de banda
• Difícil de manter
• Experiência de uso com nível de excelência para o usuário

No próximo post mostrarei como identificar o dispositivo que o usuário está usando para acesso e exibir a View correta para este.

ASP.NET MVC - Validação de Datas sem complicação, JQuery Validation + JQuery.Globalize

Recentemente um amigo que começou a desenvolver em um projeto em ASP.NET MVC questionou a respeito da validação de datas. A validação sempre falha em server e client se você usar o campo do tipo DateTime e as DataAnnotations que o MVC traz. Como "paliativo" o pessoal usa um campo string e RegularExpressionAttribute, depois transfere esse valor para o campo DateTime original.

Data Válida, mas falha.

Porém, isso não é necessário, o que acontece é um problema com o localization do JQuery Val que não consegue validar o formato dd/MM/yyyy sem uma "ajuda". Neste post vou mostrar como concertar isso.

Instalando jquery.globalize

O jquery globalize é uma biblioteca de globalization e localization. Vou usá-la para parser da data que será validada.

Para instalar:

1. Clique com botão direito na Solução->Manage Nuget Packages
2. Vá em Online e digite na caixa Jquery Globalize

Agora é necessário adicionar o  jquery.globalize ao nosso BundleConfig

App_Start/BundleConfig.cs

Modificando a função de validação de datas do Jquery Val

Agora vem a parte "hardcoding". Com o jquery globalize vamos usar a função parseDate para validar nosso formato.

Views/Task/Create.cshtml

Na função acima estou alterando o método date para que a validação ocorra da forma que eu quero. Veja em Azul o formato que especifiquei. Logo, qualquer coisa diferente disso que for digitado em um campo com validação para data vai falhar.

O ideal é que você crie um arquivo de Script e coloque uma função anônima dentro para reutilizar.

Exemplo

Agora no ASP.NET é possível usar o seu campo com DateTime, sem problemas.

Models/Task.cs

View/Task/Create.cshtml

O campo pode ser criado normalmente. Quando você cria o campo como DateTime, por baixo dos panos o Html Helper já coloca que o campo é para ser validado como Data.

HTML Resultado para o Campo DateTime

Agora a validação funciona:

Espero que tenham gostado, o código fonte do exemplo pode ser baixado aqui.

ASP.NET Web API - Criação de select (DropDownList) em cascata, usando Ajax, JQuery e JSON.

Essa semana estava criando um sistema e me deparei com um problema relacionado a select list (nome da tag HTML, mas conhecido como Drop Down List no mundo Windows) encadeados. O sistema teria vários desses select em cascata.

Como um bom programador, resolvi encapsular a lógica deste em algum lugar, para futuro reuso. Então surgiu a ideia de criar uma extensão do JQuery que já fizesse o trabalho duro. É necessário Visual Studio 2010/2012 com o template do ASP.NET MVC 4 Project instalados.

• Link do Git Hub para o jquery-cascadeselect Contribua!

Criando o projeto Web Api

No Visual Studio, para um novo projeto:

1. File->New Project-> Templates->Installed Templates->Visual C#->ASP.NET MVC 4 Web Application
2. Na janela selecione Web API.

Caso já tenha um projeto MVC:

1. Adicione referência para System.Web.Http.WebHost.
2. Adicione o arquivo App_Start\WebApiConfig.cs (use como exemplo o código do post).
3. Adicione using System.Web.Http in Global.asax.cs.
4. Chame WebApiConfig.Register(GlobalConfiguration.Configuration) na função Start Global.asax.cs, antes da rota MVC, por causa de sua precedência.

A ideia

O principal objetivo era diminuir a complexidade de criar o cascateamento e também performance, dado que o resultado é em JSON, diminuindo assim, o tráfego de dados. Principalmente porque eu o usaria para mobile.

O cascateamento de componentes é recursivo por natureza. Então resolvi usar os novos padrões HTML5 data-* (chamado de "data dash attribute"), que salva as informações para que o select saiba seu comportamento. A url de origem dos dados, os parâmetros a serem passados, paramName, quem dispararia o evento para ele ser preenchido, o parentSelectId e um texto padrão que este teria vazio ou não selecionado o defatulText.

Chamada do método

A Web API

Criei um objeto SelectOption  que remete ao que é esperado pelo jquery-cascadeselect (esse o nome da extensão que crie :D).  Então nossos métodos devem preencher e retornar esse objeto.

Model/SelectOption.cs

Padrão do JSON gerado

No exemplo eu vou usar Estado, Cidade e Região. Veja que retorno em cada método de API é uma lista de SelectOption. Preste atenção também nos parâmetros. Vamos usá-los mais tarde.

Controller/SearchController.cs

Na configuração do Web API, adicionei a action na rota, porque temos mais de um método GET dentro do mesmo controller, caso contrário  o Routing não irá resolver o endereço requisitado. Além disso, JSON foi colocado como padrão de retorno.

App_Start/WebApiConfig.cs

Uso

O uso é bem simples, basta chamar como se fosse um método do JQuery, dado que é uma extensão. No exemplo abaixo estou usando com ASP.NET Web API, mas não há restrições, o endereço passado só deve garantir que seja retornado JSON no formato correto .

Cascateamento entre Regiões, Estado e Cidades

Lembra-se dos parâmetros da nossa WebAPI? Por exemplo regiaoId, o nome deve ser idêntico para que o GET seja feito corretamente.

HTML exemplo

Resultado

Abaixo está o resultado, o jquery-cascadeselect cuida da parte chata de lógica automaticamente. Ao mudarmos as seleções os select são populados segundo a configuração feita. No exemplo clássico abaixo tenho Região, Estado, e Cidade:

Regiões é o pai de todos, então já vem populado

Mudando a seleção de Região o Estado é populado

Mudando a seleção de Estado vêem as Cidades

Contribua

Eu criei uma entrada no Git Hub para jquery-cascadeselect. Não sou nenhum "expert" em JavaScript, então o código pode estar um pouco "bagunçado" e sem padrão, mas está funcionando que é uma maravilha :D! Se você tem interesse em contribuir acesse. 

Espero que tenham gostado. O exemplo que usei para testar, igual ao das imagens acima, pode ser baixado aqui.