O que o fim do Windows XP significa para nós desenvolvedores?

Hoje é o dia de despedida do notável Windows XP. Depois de 12 anos por aí a Microsoft finalmente encerrou as atualizações e explica em O que significa o fim do suporte ao Windows XP? o que os usuários do sistema devem fazer neste momento.

Windows XP

Neste breve texto vou abordar o que acho interessante com o término do suporte ao XP. São coisas muito boas, pelo menos para nós desenvolvedores.

O que significa para os desenvolvedores de apps Windows?

Com a manutenção do Windows XP a maioria das empresas deixaram de migrar seus setores de desenvolvimento. Eu mesmo, por exemplo, trabalhei em um grande projeto de software ERP que era usado em massa por empresas que possuíam a versão XP. De acordo com o gráfico da StatCounter é possível ver que há ainda uma parcela considerável de Windows XP no Brasil.

Uso de Sistemas Operacionais no Brasil

Resultado: grande parte do desenvolvimento e dos desenvolvedores ficou parado no Framework .NET 4.0, devido a falta de suporte, como pode ser visto aqui: .NET Framework System Requirements. 

A maioria nem mesmo usa o WPF ou tira proveito dos avanços feitos com a implementação de MVVM. Estão no Windows Forms, executando queries em plain SQL com ADO.NET e fazendo bind de campos diretamente para DataSets.

Com a atualização para as versões mais novas do sistema operacional a empresa pode migrar seu toolbox de desenvolvimento também, colocando seus desenvolvedores de volta na década certa!

O que significa para os desenvolvedores de apps Web?

Para quem desenvolve para Web o fim do Windows XP é mais feliz ainda. Com ele morre a versão do Internet Explorer 8 e os workarounds de JavaScript para entregar um projeto. Até o ano passado era possível encontrar várias empresas que necessitavam suportar o IE 8, devido ao legado do XP - "pain, pain, pain" =(!

Da mesma forma que para os aplicativos Windows, a empresa agora pode ficar mais a vontade para migrar para novas tecnologias Microsoft que ofereçam o MVC, SignalR e felicidade para seus colaboradores que vão poder voltar aos trilhos da tecnologia.

Convençam seus gestores a migrarem seus softwares! Será um custo recuperado facilmente com a produtividade oferecida pelas novas tecnologias Microsoft presentes no Visual Studio.

Boa semana para todos! Nunca vou me esquecer daquele papel de parede com céu azul Adeus Windows Xp!

ASP.NET MVC - Dicas para não falhar com ASP.NET MVC + Angular JS

O Angular JS é o pop dos Frameworks para desenvolvimento de aplicações SPA (Single Page Application), aparecendo na lista como uma das Most Excited Techology of 2013 na StackOverflow Survey 2013. Este foi criado e, é mantido por Engenheiros da Google e traz um toolbox completo para desenvolver aplicativos fantásticos, criando uma organização natural no projeto e possibilitando extensibilidade por meio de criação de componentes. Outro diferencial é o suporte oferecido pela comunidade, que é bem grande no GoogleDocs e StackOverflow.

Abaixo estão algumas dicas que recolhi por experiência desenvolvendo uma Aplicação complexa a nível Enterprise com ASP.NET MVC e Angular JS.

Não abandone a sua ViewEngine

Passar a responsabilidade de tudo na sua View para o Angular JS é complicado. Você perderá toda flexibilidade e controle que a ViewEngine te proporciona. Deixando esta de lado seu código JavaScript crescerá de maneira assustadora, sendo difícil de rastrear problemas. Além disso, a segurança pode ficar comprometida se você retornar diretamente uma View em HTML estática.

Use os Controllers do MVC e seus filtros para ajudarem nessa parte de segurança e a ViewEngine para popular com alguma informação ou bloquear e sumir conteúdos que necessitam de perfis específicos. A reusabilidade de conteúdo também depende da sua ViewEngine, use ViewBag/ViewData e PartialViews sempre quando necessário. Faça o Angular JS atuar onde ele é bom e não comprometerá sua produtividade.

Não crie directives que herdem $scope

Como um bom iniciante, procure entender o comportamento do $scope dentro de uma Directive. Existem três tipos.

1. Parent scope você pode fazer iteração entre diretivas.
2. Child scope herda completamente o scope atual, no caso do controller mais acima, logo é possível setar valores de variáveis do Controller de dentro da diretiva.
3. Isolated scope, em que a diretiva tem seu próprio $scope e não interage com outro.

Entender esses conceitos é importante. Quando comecei a desenvolver directives não entendia direito e várias das quais criei tiveram que ser refeitas. Não sabia que criando diretivas de Child scope causariam problemas em meus componentes, porque estavam todas ligadas ao mesmo Controller e várias dessas dentro da mesma View causariam concorrência e erros "bizarros" - aprendi da pior forma, "leson learned" :D.

O site do Angular JS não explica bem o conceito, como a maioria dos outros, mas esse post do SackOerflow te dará uma aula completa:

• When writing a directive, how do I decide if a need no new scope, a new child scope, or a new isolate scope?

Não use JQuery

O Angular JS vem com uma versão do JQuery embutida, chamada JQLite que disponibiliza as funções básicas da versão full que são mais utilizadas. Existe uma variedade de diretivas que fazem o trabalho do JQuery de maneira muito mais elegante como ng-class, ng-hide, ng-show, ng-selected, ng-disabled, dentre outras.

Mas na hora de construir as suas próprias diretivas será necessário acessar o DOM para interagir com o elementos da View. É aí que entra o JQLite:

Então, nada de scripts JQuery soltos na View ou mesmo dentro do Controller.

• Angular's jqLite

Não lute contra o padrão, aprenda MVVM

O MVVM foi criado pelo prodígio do Design Patterns Martin Fowler e o Angular JS foi construído com base nele. De uma maneira geral Angular JS te obriga a seguir um certo padrão para desenvolver a sua aplicação.

Dentro desse padrão está o Controller e $scope que representam sua ViewModel, seu HTML e directives que compõem a View. Não use lógicas absurdas dentro da View usando variáveis do $scope, pois a manutenção vai ficar muito mais difícil. Faça toda a lógica dentro do Controller, e reforçando mais uma vez, sem JQuery.

• Model View ViewModel

Aprenda a usar $watch e os interceptadores $http

O $watch possibilita que você observe uma variável qualquer do $scope e execute algum evento caso o seu valor mude. Esse recurso é muito poderoso e pode te economizar centenas de linhas de código para, por exemplo, caso o valor da variável assistida mude esconda, apague ou crie campos dinamicamente na tela.

Do mesmo modo que o $watch, os interceptadores $http podem salvar tempo, possibilitam centralizar validações de erros, habilitar e desabilitar cache, alterar e ler cabeçalhos HTTP e muito mais.

Se você quer mostrar para o usuário uma mensagem de erro amigável toda vez que o seu servidor lançar uma exceção ou uma mensagem específica caso uma validação de campo falhe, os interceptadores são o melhor caminho e você fará uma vez só para ser usada por toda aplicação - Don't repeat yourself.

Herança de controllers existe

Quando seu projeto apresenta muitos padrões, com telas parecidas que executam coisas iguais, a primeira coisa que se pensa é fazer algo reutilizável. Imagine uma tela de inserção que é utilizada em vários cenários, que possuem os mesmos campos e acessam os mesmo dados.

Você pode fazer herança de controllers do Angular JS para facilitar a sua vida. A maneira mais fácil é colocar o controller pai declarado mais externo na View e o controller filho dentro deste. O $scope do pai estará acessível para o filho, sendo possível utilizar de todos os métodos e variáveis. Eu ainda inventei uma maneira de se fazer override dos métodos do controller pai - não sei se isso é legal, se é bonito ou feio, mas salvou minha vida.

//Copio o método original do Controller Pai

$scope.salvarBase = angular.copy($scope.salvar);

//Modifico o método e chamo o base

$scope.salvar = function () {

  //Faço coisas específicas para o Controller Filho]

  $scope.salvarBase();

}

No trecho de código acima eu copio o método original do Controller mais externo, logo depois altero seu comportamento. Por mais feio que seja, funciona e me salvou horas de trabalho.

• AngularJS–Part 3, Inheritance

Não deixe clientes e analistas criarem Fluxos esdrúxulos

Esta é uma parte crítica e bem abstrata do problema, porque dependendo da forma que seu cliente ou analista escreve o Angular JS pode ser um passo para o fracasso. A quantidade de JavaScript que será necessária para escrever seu sistema vai ser absurda - tenho controllers com mais de 2200 linhas de JavaScript devido a pedidos esdrúxulos do cliente.

Não deixe que seu analista crie telas com abas por todos os lados ou fluxos que envolvam chamadas em cascatas de modais que são exibidos a partir de determinados resultados de chamadas assíncronas ao ASP.NET. Irão aparecer erros quase impossíveis de rastrear e o código ficará poluído.

Não deixe a validação por conta do AngularJS

Infelizmente a validação de campos ainda não funciona muito bem, principalmente no IE8/9/10, total fracasso. Deixe tudo que puder no server e use os interceptadores $http que falei anteriormente para exibir os erros para o usuário em um modal, por exemplo.

É possível combinar interceptadores e directive para exibir aquelas famosas validações inline ou em um sumário parecido com o do ASP.NET MVC puro.

Se achar que é muito trabalhoso fazer a sua diretiva, use o clássico jquery-validation para fazer o trabalho duro para você – já aviso que vai perder toda a diversão fazendo sua própria directive =D.

Diga não a versões anteriores ao IE10

O IE7/8/9 como sempre nos acompanha em nossa jornada – desculpe MS, mas é dureza suportá-lo, principalmente com muito JavaScript =(. Se for realmente necessário usar o IE7/8/9, seu cliente for teimoso na verdade, já aviso que terá uma dura jornada.

Cada Controller Angular JS, pode ter certeza, vai ter uma série de trechos de código que só serão executados caso o Browser usado seja IE. No caso das directives, algumas específicas que desenvolvi, foram feitas praticamente duas versões por causa de incompatibilidades.

Um grande problema que enfrentei também foi o cache. Em alguns casos o IE não atualiza a tela de maneira alguma, então existe um cache killer, em que é desabilitado cache de JSON para IE7/8/9 e no interceptador. Chamadas get recebem um timestamp para evitar problemas.

Se você será um sofredor como eu fui, segue abaixo uma série de links que resolverão alguns problemas:

• Data not updating on ie 9/10 in application developed using angularjs
• Disable browser cache for entire ASP.Net website
• AngularJS on IE7 not working: how to fix it.
• Is JSON.stringify() supported by IE 8?

Conclusão

O Angular JS é fantástico, sua aplicação fica com outro nível. Se você tem medo de JavaScript mude de profissão, porque o futuro da Web é Single Page Application.

Abaixo seguem alguns tutoriais de como iniciar em Angular JS + ASP.NET MVC:

• Video Tutorial: AngularJS Fundamentals in 60-ish Minutes
• Angular App Structuring Guidelines
• Iniciando com AngularJS – Guia Muito bom feito pelo MVP Andre Baltieri

Espero que tenham gostado do Artigo. Qualquer dúvida sobre Angular JS e ASP.NET MVC estou a disposição. Meu contato está no blog, me procure.

Boa semana para todos!

Windows Phone 8 - Usando HttpClient em um App WP8

O Windows Phone 8 está fenomenal, com cada vez mais recursos e aplicativos. Eu sou um usuário hardcore e considero este o sistema operacional mais estável para mobile. Um app mobile precisa acessar o mundo externo de alguma forma, seja para consultar dados em um serviço ou mesmo enviar informações que serão persistidas em algum lugar. Pensando nisso, foi criado o HttpClient, que facilita a vida de quem precisa acessar Http, como Windows Azure Mobile Services ou consumir Restful services feitos em Web API, por exemplo.

Instalando o HttpClient

O HttpClient está localizado no assembly System.Net.Http.dll e pode ser instalado via Nuget:

1. Acesse o Nuget Package Manager para instalar um novo pacote.
2. Procure pelo pacote Microsoft.Net.Http, ele aparecerá como a primeira opção.
3. Dê dois cliques para instalar o pacote.

Package HttpClient

Com este pacote já é possível usar a classe em sua aplicação, mas com um porém, os métodos dessa classe no WP8 não tem acesso a 100% dos recursos async, o que nos leva a outro passo :).

Instalando o Microsoft Async

Para que os projetos WP8 façam uso de async/await é necessário instalar um pacote Nuget que adiciona métodos extendidos para os tipos que acessam recursos de rede, como por exemplo, o HttpClient.

Para instalar o Microsoft Async:

1. Acesse o Nuget Package Manager para instalar um novo pacote.
2. Procure pelo pacote Microsoft Async, ele aparecerá como a primeira opção.
3. Dê dois cliques para instalar o pacote.

Package com extension method para networking types

Com esse pacote instalado é possível usar o HttpClient com todos os recursos modernos fornecidos pelo .NET.

Exemplo simples de uso do HttpClient

Para usar o HttpClient adicione a referência em sua classe para System.Net.Http. No exemplo abaixo, existe um simples botão, que faz uma chamada Http e coloca o body da request em um textbox.

private async void Button_Click(object sender, RoutedEventArgs e)
{
 HttpClient client = new HttpClient();

 try
 {
  HttpResponseMessage response = await client.GetAsync("http://www.google.com/");
  response.EnsureSuccessStatusCode();
  string responseBody = await response.Content.ReadAsStringAsync();

  this.txtResponse.Text = responseBody;
 }
 catch (HttpRequestException ex)
 {
  throw ex;
 }
}

Veja o uso de async/await sem maiores problemas.

App usando HttpClient

Ao clicar no botão, é chamado o evento Button_Click, perceba que a requisição retorna status 200.

Código do evento do botão

Como a requisição é para www.google.com, a resposta será o HTML da página, como pode ser visto no textbox:

Textbox é preenchido com o resultado da requisição

Finalizando

O HttpClient está estável e muito fácil de usar. Um problema que tive durante os testes foi a falta de conexão com a internet no emulador do Windows Phone 8 que resolvi usando este post do stackoverflow:

• Windows Phone 8 emulator can't connect to the internet

Para maiores referências de como usar o HttpClient nas sua aplicações, um bom lugar para começar é o link abaixo:

• Início rápido: conectando-se usando System.Net.Http.HttpClient (aplicativos da Windows Store que usam C#/VB e XAML)

Espero que tenham gostado da dica. Bom final de semana para todos!

ASP.NET MVC - Novidades do ASP.NET MVC 5

São muitas as novidades que virão com o ASP.NET MVC 5 no Visual Studio 2013. Houve uma mudança visual com novo CSS e templates de Scaffold, incorporação do Claims Security, além  da nova camada middleware OWIN. No Visual Studio 2013, a tela para criação do projeto ficou mais inflada, com várias opções de escolha para autenticação e algumas outras perfumarias.

Novo wizard para criar Web App

A tela para criação de projetos ficou um pouco diferente. Agora é possível selecionar WebForms, MVC e Web API, o que adicionará suporte ao que for selecionado. Parece que a Microsoft finalmente resolveu deixar claro que WebForms pode conviver na mesma aplicação que o MVC.

Novo Wizard para criação de Web Apps

Foi adicionado também um novo botão, em que é possível selecionar o tipo de autenticação que a aplicação irá usar.

Dentre as formas de Autenticação estão: Nenhuma, Individual, Windows e para Organizações. Esta última está diretamente ligada a outra novidade que foi adicionada, o Claim Security, que falarei mais tarde.

Novo wizard Scaffold e Bootstrap

Foi criado uma entrada de menu Scaffold para criação de Views/Controllers. Eu particularmente achei que este deviria ficar no menu principal, mas adicionaram como sub item do menu Add.

Menu Scaffold

O processo foi centralizado em um único local, parecido com um wizard de criação de projetos e soluções. Na primeira tela você seleciona o item que deseja, Controller, View, Web API.

Wizard para seleção de item de Scaffold

A próxima tela é bem parecida com as antigas, em que adiciona-se nome do arquivo, modelo, etc, sendo mais um rearranjo de layout, como por exemplo a tela de Views da figura seguinte.

Wizard criação de View

O CSS padrão agora é o Bootstrap. Uma coisa que achei estranha é que a versão do Bootstrap que vem com o template ser a 2.3.1, sendo que a de mercado já é a 3.0.0. Dado que estamos em RC, acho provável que a nova  seja adicionada ao MVC 5 Final- pelo menos espero que sim :).

CSS padrão agora é Bootstrap

Outra coisa importante é que os templates para Scaffold de View criam essas com layout todo baseado no Bootstrap, ficou muito bom!

Segurança com Claims

A segurança para o seu aplicativo agora pode ser ampliada usando Claims. Com isso é possível criar várias formas de autenticação, como os próprios profissionais do ASP.NET Team comentam, ".. é possível criar um Framework de autorização dirigido a qualquer coisa que você saiba que está associado a identidade de uma requisição que estiver sendo efetuada...".

A maior mudança está no arquivo AccountController.cs, como por exemplo, o método de login abaixo, que agora busca IdentityResult, em vez de usuários diretamente como no MVC 4:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task Login(LoginViewModel model, string returnUrl)
{
    if (ModelState.IsValid)
    {
        // Validate the password
        IdentityResult result = await IdentityManager.Authentication.CheckPasswordAndSignInAsync(AuthenticationManager, model.UserName, model.Password, model.RememberMe);
        if (result.Success)
        {
            return RedirectToLocal(returnUrl);
        }
        else
        {
            AddErrors(result);
        }
    }

    // If we got this far, something failed, redisplay form
    return View(model);
}

Para saber mais sobre essa novidade sugiro os artigos abaixo:

• Leveraging Claims-Based Security in ASP.NET 4.5

• Going Beyond Usernames and Roles with Claims-Based Security in .NET 

OWIN

O OWIN Open Web Interface for .NET (OWIN) é uma camada intermediária que separa a sua aplicação do Web Server. Com isto é possível migrar facilmente um aplicativo do IIS para um serviço Windows, por exemplo.

Você notará dois novos arquivos na soluçao, ambos com o prefixo Startup. Estes são os arquivos de configuração do OWIN.

Arquivos de configuração do OWIN

Para saber mais sobre o OWIN:

• Getting Started with OWIN and Katana

Entity Framework 6

O Entity Framework vem em uma nova versão com várias novidades, principalmente melhoria de performace e novos recursos na parte de Migrations - acho excelente esse recurso. No projeto em si a única mudança visível é adição de uma classe IdentityModels.cs.

O Entity traz agora um contexto próprio para tratar as classes personalizadas de usuário que serão usadas com o Claims Security:

public class ApplicationUser : User
{  
}

public class ApplicationDbContext : IdentityDbContextWithCustomUser
{
}

Para saber mais sobre o Entity Framework 6:

• Entity Framework 6 RC

No próximo post vou cobrir mais a fundo as novidades para Web API 2. Espero que tenham gostado! Boa semana para todos!

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.