Procurando por isso, acabei achando esse teste muito legal:
São testes com alguns smartphones do mercado. Assista o vídeo e tire suas conclusões.
domingo, 12 de abril de 2009
Teclado Virtual ou Teclado Tradicional
Sempre foi minha curiosidade medir o desempenho de teclados virtuais em relação a teclados tradicionais nos smartphones.
sexta-feira, 20 de março de 2009
ASP.NET MVC RTW 1.0!!!
Olá Pessoal,
Hoje foi lançado o MVC RTW (Release to Web) 1.0!
Em breve imagino que venha o aguardado post do scott'gu apresentando os últimos ajustes em relação ao RC2.
Enquanto isso, como aperitivo temos o breve post do Phil Hack sobre o release.
Não cheguei a pegar a versão RTW ainda para fazer um review, mas da versão RC1 para a RTW, pelo que venho acompanhando, poucas coisas mudaram no motor do MVC, as mudanças mais significativas ficaram no processo de instalação e na distribuição dos assemblyes.
Assemblyes System.Web.Abstractions.dll e System.Web.Routing.dll são embarcados no .net 3.5 SP1, portanto, foi criada uma dependência do MVC para o SP1 e de agora em diante esses dois assemblyes não acompanham mais o assembly principal System.Web.Mvc.dll
Mesmo assim ainda é possível utilizar nos servidores o .net 3.5 com os assemblyes embarcados na pasta Bin, já que não há nenhuma outra dependência do Asp.net MVC no .net 3.5 Sp1.
Uma coisa que eu percebi entre o projeto ASP.net MVC e os outros projetos da Microsoft que eu acompanhei é que a aproximação da equipe de desenvolvimento com a comunidade foi muito maior, e o resultado é uma versão 1.0 bastante estável e robusta, que mudou muito pouco. Já tive a experiência de ver projetos 1.0 da Microsoft bastante atropelados, o que levou a updates e fixes poucas semanas depois. O Asp.net MVC não é o caso.
Que venha o MVC Futures!
quarta-feira, 4 de fevereiro de 2009
Snippets
Olá Pessoal, desculpem ter passado janeiro em branco, mas os trabalhos aqui tem ficado cada vez mais pesados. :-)
Semana passada saíu no blog do scott'gu o seu tão esperado post sobre o release candidate do MVC. Como eu esperava, houveram alguns breaking changes, mas a estrutura quase não foi alterada. Essa versão trouxe integrado com o visual studio uma maneira muito legal de basear a construção de views em templates que são usadas com certa frequência. Pra ficar melhor, ainda podemos criar nossas próprias views.
É lógico que algumas ferramentas como o codesmith há tempos faziam o mesmo trabalho. Mas a integração dessas ferramentas com o visual studio nunca foi lá grande coisa.
Mas com base nessa tecnologia, fiz um comentário no blog do scott'gu sobre a possibilidade de fazer visual studio snippets atenderem a esse mesmo padrão. Pois isso é uma porta se abrindo para termos snippets que suportam parâmetros de entrada e até snippets genéricas integradas com o visual studio.
Exemplo:
Imaginem a classe produto:
class Produto{
[IdKey] //estou chutando aqui um atributo relevante para o snippet
public int Id { get; set; }
public string Nome { get; set; }
public decimal Preco { get; set; }
}
e você está escrevendo um model no MVC e decide elaborar as rotinas de validação.
Então você digita dentro da classe:
ModelValidation (e bate duas vezes no tab. Than!)
Poderia resultar numa validação padrão baseada num template, como a classe abaixo:
public class ProdutoModelValidation{
public class ValidateInput(Produto p){
//em funcao do key ID, a validacao aqui é desse jeito
if ( p.Id > 0 && p.Id != null ) ...
//o snippet sabe o que fazer quando trata tipos padrão string, como num template
if ( p.Nome != null) ...
//o snippet tem ciência dos tipos que ele está tratando, pois ele está acessando a
// classe produto através de reflection
if ( p.Preco != 0 ) ...
}
}
Bom, fica registrada aqui a idéia :-) vou encaminhar alguma coisa pro time do VS2010
Semana passada saíu no blog do scott'gu o seu tão esperado post sobre o release candidate do MVC. Como eu esperava, houveram alguns breaking changes, mas a estrutura quase não foi alterada. Essa versão trouxe integrado com o visual studio uma maneira muito legal de basear a construção de views em templates que são usadas com certa frequência. Pra ficar melhor, ainda podemos criar nossas próprias views.
É lógico que algumas ferramentas como o codesmith há tempos faziam o mesmo trabalho. Mas a integração dessas ferramentas com o visual studio nunca foi lá grande coisa.
Mas com base nessa tecnologia, fiz um comentário no blog do scott'gu sobre a possibilidade de fazer visual studio snippets atenderem a esse mesmo padrão. Pois isso é uma porta se abrindo para termos snippets que suportam parâmetros de entrada e até snippets genéricas integradas com o visual studio.
Exemplo:
Imaginem a classe produto:
class Produto{
[IdKey] //estou chutando aqui um atributo relevante para o snippet
public int Id { get; set; }
public string Nome { get; set; }
public decimal Preco { get; set; }
}
e você está escrevendo um model no MVC e decide elaborar as rotinas de validação.
Então você digita dentro da classe:
ModelValidation
Poderia resultar numa validação padrão baseada num template, como a classe abaixo:
public class ProdutoModelValidation{
public class ValidateInput(Produto p){
//em funcao do key ID, a validacao aqui é desse jeito
if ( p.Id > 0 && p.Id != null ) ...
//o snippet sabe o que fazer quando trata tipos padrão string, como num template
if ( p.Nome != null) ...
//o snippet tem ciência dos tipos que ele está tratando, pois ele está acessando a
// classe produto através de reflection
if ( p.Preco != 0 ) ...
}
}
Bom, fica registrada aqui a idéia :-) vou encaminhar alguma coisa pro time do VS2010
quinta-feira, 25 de dezembro de 2008
domingo, 14 de dezembro de 2008
Recomendações de Leitura
Olá pessoal,
Depois das minhas pequenas férias no Rio, estou de volta com duas recomendações de livros que encontrei ao visitar a Siciliano no Shopping .
Esse eu ainda vou comprar pra ler, mas pelo que eu já li é indispensável para gerentes e líderes de equipes que desejam implantar o desenvolvimento ágil dentro do seu modelo de desenvolvimento de software.
O outro, é a história "do negócio de mídia e tecnologia de maior sucesso dos nossos tempos", o google, que mostra a trajetória de Larry Page e Sergey Brin, dois dos mais fantásticos personagens desta década. A Internet não seria a mesma sem eles.
...esse eu comprei, e já estou terminando. Excelente! :-)
terça-feira, 18 de novembro de 2008
Dica: Renderizando páginas HTML no ASP.NET MVC
Olá pessoal,
Nessas últimas semanas tenho feito um mergulho profundo no ASP.net MVC Beta, e confesso que estou muito entusiasmado com o resultado. Sei que cada um tem o seu gosto por paradigmas e eu não sou diferente, e nessa semana percebi que me encontrei no MVC, e posso dizer um adeus sem remorso para os WebForms.
Acho até que foi uma escolha meio tardia, tardia em função da escolha de acompanhar especificamente o MVC da Microsoft, pois talvez se tivesse experimentado o Monorail, esse adeus teria acontecido alguns meses atrás.
Por fim, recomendo este artigo do Samir Mamude . A "história" que ele conta pode representar bem o estado de espírito de uma transição.
Bom, mas vamos pra nossa dica!
Para desenvolver controllers, quase sempre você está enviando Dados e Submetendo Views, mas existem casos onde o que você quer enviar seja simples markup, HTML. Será que necessito mesmo enviar para uma ViewPage para ser processada? Hum, Não!
Até enviei um e-mail pra equipe do MVC, vamos ver o que eles respondem. Mas o que eu gostaria de colocar é que existe uma maneira talvez um pouco mais "eficiente" de exibir esses dados casos eles sejam apenas text.
Nos controllers, um dos possíveis retornos (ActionResult's) são através da propriedade Content.
public ActionResult Home()
{
return Content("Olá Mundo");
}
Até aí, tudo bem, mas você pode enviar um arquivo HTML inteiro por ele se preferir, mas seu código poderia ficar um pouco sujo, além de enfrentar problemas na separação de competências.
Então, uma alternativa interessante (O Eder achou POG :-P) , seria de criar um resource file e inserir nele todos os arquivos HTML que não necessitam de nenhum tratamento ou manipulação, ou seja, são renderizados "as is".
Dessa forma:
public ActionResult Home()
{
return Content(ContentPages.Home);
}
...e uma página HTML inteira é renderizada através de um Controller MVC. Obviamente o conceito é o mesmo para partes de uma página HTML. Talvez isso saia mais rápido do que fazer a ViewEngine processar o conteúdo de uma View, que, pelo que percebi, não difere muito de uma classe Page do WebForms em alguns aspectos.
Nessas últimas semanas tenho feito um mergulho profundo no ASP.net MVC Beta, e confesso que estou muito entusiasmado com o resultado. Sei que cada um tem o seu gosto por paradigmas e eu não sou diferente, e nessa semana percebi que me encontrei no MVC, e posso dizer um adeus sem remorso para os WebForms.
Acho até que foi uma escolha meio tardia, tardia em função da escolha de acompanhar especificamente o MVC da Microsoft, pois talvez se tivesse experimentado o Monorail, esse adeus teria acontecido alguns meses atrás.
Por fim, recomendo este artigo do Samir Mamude . A "história" que ele conta pode representar bem o estado de espírito de uma transição.
Bom, mas vamos pra nossa dica!
Para desenvolver controllers, quase sempre você está enviando Dados e Submetendo Views, mas existem casos onde o que você quer enviar seja simples markup, HTML. Será que necessito mesmo enviar para uma ViewPage para ser processada? Hum, Não!
Até enviei um e-mail pra equipe do MVC, vamos ver o que eles respondem. Mas o que eu gostaria de colocar é que existe uma maneira talvez um pouco mais "eficiente" de exibir esses dados casos eles sejam apenas text.
Nos controllers, um dos possíveis retornos (ActionResult's) são através da propriedade Content.
public ActionResult Home()
{
return Content("Olá Mundo");
}
Até aí, tudo bem, mas você pode enviar um arquivo HTML inteiro por ele se preferir, mas seu código poderia ficar um pouco sujo, além de enfrentar problemas na separação de competências.
Então, uma alternativa interessante (O Eder achou POG :-P) , seria de criar um resource file e inserir nele todos os arquivos HTML que não necessitam de nenhum tratamento ou manipulação, ou seja, são renderizados "as is".
Dessa forma:
public ActionResult Home()
{
return Content(ContentPages.Home);
}
...e uma página HTML inteira é renderizada através de um Controller MVC. Obviamente o conceito é o mesmo para partes de uma página HTML. Talvez isso saia mais rápido do que fazer a ViewEngine processar o conteúdo de uma View, que, pelo que percebi, não difere muito de uma classe Page do WebForms em alguns aspectos.
sábado, 18 de outubro de 2008
Interfaces e Extension Methods: Uma Combinação poderosa (parte 2)
Olá Pessoal,
Finalmente consegui terminar! Essa parte do post demorou um pouco porque o trabalho apertou. Espero que curtam.
Agora que vocês estão familiarizados com Extension Methods, então vale a pena mostrar do que ele é capaz na prática no sentido de facilitar e viabilizar desenhos arquiteturais antes de difícil implementação.
No nosso exemplo, a idéia é mostrar como se cria uma biblioteca de controles herdada da biblioteca padrão System.Web.UI.WebControls e adicionar aos controles uma propriedade chamada DataBinder do tipo IDataBinder.
public interface IDataBinder
{
}
public class MeuTextBoxHerdado : System.Web.UI.WebControls.TextBox
{
public IDataBinder DataBinder{ get; set; }
}
A classe que implementará a propriedade nesse cenário é o que menos irá importar. O importante é que DataBinder será um ponto onde nós poderemos pendurar Extension Methods. A idéia lembra um pouco as "Interfaces de Marcação", que são utilizada em algumas situações no ASP.NET para indicar que uma classe deve receber alguma implementação especial que será controlada por outra classe (procure saber sobre INamingContainer), só que sem a necessidade do uso de reflection.
A diferença é que o ponto de marcação não é uma classe atributo, mas sim uma propriedade, e a partir dela poderemos implementar uma gama de recursos, que poderão ser facilmente portados para outros controles. Para isso, basta que os mesmos possuam uma propriedade qualquer que seja daquele tipo.
Assim, podemos começar a construir nossa biblioteca de extension Methods.
public static BibliotecaDataBinder{
public static void BindText(this IDataBinder control, object dataSource)
{
}
public static object Read(this IDataBinder control)
{
}
...
}
Para usar, basta referenciar o namespace, e finalmente:
MeuTextBoxHerdado h = new MeuTextBoxHerdado();
h.DataBinder.BindText("Olá");
Assim, você pode usar vários métodos úteis através da propriedade. Cabe a você como arquiteto decidir quais os métodos e propriedades que a interface deve mandar implementar para ter o trabalho feito.
Nesse aspecto, dependendo do caso, sería até uma estratégia interessante manter a própria classe como implementadora da interface IDataBinder, assim, os membros da classe vão poder ser acessados diretamente pela nossa biblioteca.
Reconheço que essa parte é um pouco complicada de abstrair, mas a flexibilidade do modelo faz ele valer a pena. Com essa arquitetura, recentemente migramos do modelo WebForms para MVC com uma simples adição de uma propriedade.
Finalmente consegui terminar! Essa parte do post demorou um pouco porque o trabalho apertou. Espero que curtam.
Agora que vocês estão familiarizados com Extension Methods, então vale a pena mostrar do que ele é capaz na prática no sentido de facilitar e viabilizar desenhos arquiteturais antes de difícil implementação.
No nosso exemplo, a idéia é mostrar como se cria uma biblioteca de controles herdada da biblioteca padrão System.Web.UI.WebControls e adicionar aos controles uma propriedade chamada DataBinder do tipo IDataBinder.
public interface IDataBinder
{
}
public class MeuTextBoxHerdado : System.Web.UI.WebControls.TextBox
{
public IDataBinder DataBinder{ get; set; }
}
A classe que implementará a propriedade nesse cenário é o que menos irá importar. O importante é que DataBinder será um ponto onde nós poderemos pendurar Extension Methods. A idéia lembra um pouco as "Interfaces de Marcação", que são utilizada em algumas situações no ASP.NET para indicar que uma classe deve receber alguma implementação especial que será controlada por outra classe (procure saber sobre INamingContainer), só que sem a necessidade do uso de reflection.
A diferença é que o ponto de marcação não é uma classe atributo, mas sim uma propriedade, e a partir dela poderemos implementar uma gama de recursos, que poderão ser facilmente portados para outros controles. Para isso, basta que os mesmos possuam uma propriedade qualquer que seja daquele tipo.
Assim, podemos começar a construir nossa biblioteca de extension Methods.
public static BibliotecaDataBinder{
public static void BindText
{
}
public static object Read(this IDataBinder control)
{
}
...
}
Para usar, basta referenciar o namespace, e finalmente:
MeuTextBoxHerdado h = new MeuTextBoxHerdado();
h.DataBinder.BindText
Assim, você pode usar vários métodos úteis através da propriedade. Cabe a você como arquiteto decidir quais os métodos e propriedades que a interface deve mandar implementar para ter o trabalho feito.
Nesse aspecto, dependendo do caso, sería até uma estratégia interessante manter a própria classe como implementadora da interface IDataBinder, assim, os membros da classe vão poder ser acessados diretamente pela nossa biblioteca.
Reconheço que essa parte é um pouco complicada de abstrair, mas a flexibilidade do modelo faz ele valer a pena. Com essa arquitetura, recentemente migramos do modelo WebForms para MVC com uma simples adição de uma propriedade.
Assinar:
Postagens (Atom)