Sabe o que é modificador internal? Sabe mesmo???

Pois é, o post começa com algo bem básico do C#, coisa do primeiro dia de aula mesmo: Modificadores de Acesso. Só pra relembrar:

• public : Sem restrição de acesso.
• protected : Acessado pela classe que o define e pelas classes derivadas dela.
• internal : Acessado apenas de dentro do mesmo assembly.
• private : Acessado somente de dentro da classe (mesmo se forem instancias diferentes).

Isso todo mundo já sabe (ou deveriam saber). O ponto em que quero chegar é que, dizer que "membros ou tipos internal só podem ser acessados dentro do mesmo assembly" não é uma completa verdade.

InternalsVisibleToAttribute

O atributo InternalsVisibleTo introduz ao assembly o conceito de Friend Assembly. Com isto os membros ou tipos marcados com o modificador de acesso internal podem ser acessados de outro assembly. Vamos ver como funciona:

Nesta solução podemos ver que existem 3 projetos, sendo 2 projetos do tipo ClassLibrary e 1 ConsoleApplication.

Adicionamos o projeto AssemblyA como referencia no projeto MyConsoleApplication. Depois o projeto AssemblyB como referencia no projeto AssemblyA e MyConsoleApplication.

Ele ficará como a imagem ao lado. Podemos ver que existem algumas classes já declaradas.

No AssemblyB temos uma classe com modificador de acesso internal e outra com o modificador de acesso public (Como dizem os nomes).

Agora vamos tentar instanciar a classe AssemblyB.MyInternalClass de dentro da classe AssemblyA.MyPublicUtilClass e compilar a aplicação para ver o que acontece.

O Visual Studio não deixa compilar a aplicação. Ele nos mostra o motivo do build failed em duas mensagens de erro:

1. O tipo AssemblyB.MyInternalClass não tem construtor definido.
2. O tipo AssemblyB.MyInternalClass não é acessível devido ao seu nível de proteção.

Como a classe está definida com o seu modificador de acesso sendo internal o Visual Studio segue a regra que descrevemos mais acima e não deixa ela ser acessada (no caso instanciada).

Esses mesmos dois erros ocorreriam se tivéssemos tentado o acesso a esta classe no assembly MyConsoleApplication.

Nesse momento entra em ação o atributo InternalsVisibleTo que faz uma alteração a nível de assembly fazendo com que AssemblyA possa instanciar a classe em questão.

Segue o trecho que pode ser colocado em qualquer arquivo de código mas que por boas práticas deve ser colocado no arquivo AssemblyInfo da pasta Properties do projeto.

Com isto compilamos novamente a aplicação e podemos ver que agora temos acesso a classe MyInternalClass de dentro do assembly AssemblyA.

Também podemos verificar que apesar do acesso a classe MyInternalClass ter sido alterado em relação ao assembly AssemblyA, o assembly MyConsoleApplication ainda continua ser ter acesso. Se fosse necessário que o assembly MyConsoleApplication pudesse acessar também a classe MyInternalClass bastaria colocar mais um atributo (permite múltiplos) no AssemblyInfo especificando isto.

Considerações Importantes

Não são muitos os casos onde é aconselhada esta prática. Ela é exigida em casos onde a organização do projeto a exige:

• Casos onde existe um projeto de teste e é necessário o acesso a membros internal para o teste.
• Quando se desenvolve um ClassLibrary que é composto por vários assemblies mas requerem acesso a membros existentes entre eles. Este é o caso do assembly System.Workflow.Activities.

O exemplo que implementei foi o de mais fácil compreensão. Existem algumas regras que devem ser seguidas para a utilização desde atributo. A regra mais importante é a respeito dos Strong Names:

• Se o assembly que se quer ter os membros internal visíveis tiver um strong name o assembly que o consumirá também deverá ter. No atributo InternalsVisibleTo deverá constar, separados por vírgula, o nome do assembly mais a public key dentro da string que é passada ao construtor.
• Se o assembly que se quer ter os membros internal visíveis não tiver um strong name o assembly que o consumirá também não deverá ter.

Enjoy

Imitando efeito 3D no Silverlight

Introduzidos na versão 3 do Silverlight os efeitos de projeção (Projection) podem passar desapercebidos como se fossem reais efeitos 3D.

Na verdade o que acontece é que o Silverlight traduz o objeto de projeção em formas matemáticas que aplicadas nas transformações de layout fazem com que elementos pareçam 3D.

Jeff Prosise mostra neste artigo da MSDN que é possível até mesmo na versão 2 do Silverlight apenas usando RenderTransform.

Mas a minha ideia hoje é mostrar do jeito mais fácil, sem todos esses cálculos e tal. Então vamos direto ao assunto.

UIElement.Projection

A propriedade Projection é onde vamos trabalhar. Nela podemos ver várias propriedades que irão afetar a renderização final de um elemento de interface.

Esta propriedade é do tipo System.Windows.Media.Projection que é uma classe abstrata. Até hoje existem duas implementações concretas no Silverlight: PlaneProjection e Matrix3DProjection.

A Matrix3DProjection permite que se escreva detalhadamente a matriz 3D que se quer desenhar, dificultando um pouco para quem não tem grandes noções do assunto.

Já a PlaneProjection permite que possamos definir um grupo de 12 propriedades de fácil entendimento. São elas:

• RotationX 
• RotationY
• RotationZ
• CenterOfRotationX
• CenterOfRotationY
• CenterOfRotationZ
• GlobalOffsetX
• GlobalOffsetY
• GlobalOffsetZ
• LocalOffsetX
• LocalOffsetY
• LocalOffsetZ

Digamos que seja 3D for newbies.

Vamos começar com um exemplo bem simples. Vamos girar um border 45 graus nos eixos x e y e z com o código abaixo (resumido):

<Border Name="border1">
  <Border.Projection>
    <PlaneProjection RotationY="45"
             RotationX="45"
             RotationZ="45" />
  </Border.Projection>
  <TextBox Text="Para Cima">
  </TextBox>
</Border>

E o resultado podemos conferir na imagem logo abaixo:

Coloquei um texto dentro só para termos um ideia de como o efeito é transmitido para os elementos filhos. Também podemos notar que o TextBox continua 100% funcional.

Mas não para por aí. A classe PlaneProjection tem várias DependencyProperties e isso quer dizer que podemos fazem Binding com elas.

Além disso também podemos aplicar animações a essas propriedades aumentado ainda mais o nível de experiência do usuário.

No exemplo abaixo Neste exemplo você pode clicar no botão para ver a animação nos controles em ação. Também pode alterar os valores dos Sliders alterando a posição da caixa vermelha.

Isso é só uma pequena demonstração do que pode ser feito. Tente em casa.

Aqui está o código fonte deste exemplo. E não, eu não me preocupei com o layout, só em passar o conhecimento. Este blog não e de Design. =D

Enjoy

Internet Explorer 9: Developer Tools

Hoje resolvi falar sobre o Developer Tools, introduzido inicialmente como uma ferramenta separada do Internet Explorer 6 mas que desde a versão 7 do browser já vem incorporada na instalação básica.

O Developer Tools pode ser encontradao no menu de opções do browser. Também pode ser acessado através da tecla de atalho F12.

A ferramenta possue opções para limpar o cache específico de um domínio, alterar definições do modo de renderização, informações sobre as imagens e cookies. Também tem ferramentas como color picker, régua, alteração da UserAgent string e muito mais.

Esta última versão apresenta 5 abas, sendo algumas delas novidades para o IE9.

 

HTML

A aba de HTML é mostrado em uma estrutura tipo árvore os elementos DOM atualmente carregados na página. Mostra o estado atual da página e não o documento recebido do servidor (que pode ter sido alterado via script).

Através do botão de seta localizado logo na parte superior esquerda da aba é possível selecionar elementos diretamente na página. Com isso se evita de ter que ficar procurando os elementos diretamente na árvore mostrada.

Na parte lateral encontramos as opções Style, Trace Styles, Layout e Attributes.

Style: Podemos ver os estilos aplicados ao elemento selecionado através de arquivo CSS ou in-line. Podemos fazer alterações dos valores diretamente nesta janela e ver como ficou na mesma hora.

Trace Styles: Semelhante ao anterior mas mostra apenas os estilos que estão sendo considerados e não os que foram sobreescritos por outro CSS ou propriedade.

Layout: Mostrar de que forma o posicionamento e tamanho do elemento está sendo afetado. Alguns desses valores podem até ser alterado ali mesmo, mas nem sempre esta opção está liberada.

Attributes: Aqui encontramos todos as propriedades do objeto DOM. Pode-se incluir, alterar, excluir e visualizar todas as suas propriedades. Também pode-se visualizar as propriedades Read-Only do mesmo.

 

CSS

Nesta aba podemos ver todos os estilos CSS aplicados a página. Eles ficam separados por arquivos e podemos desabilitar um seletor inteiro ou estilos individuais de um seletor.

 

Console

A aba console foi promovida de um pequeno espaço da aba Script do IE8.

Agora neste local é possível executar scripts diretamente e inspecionar objetos.

Ao digitar o nome de um objeto no console e pressionar Enter são apresentadas algumas de suas propriedades. Pode-se ver todos os detalhes do mesmo adicionando o objeto ao inspecionador pressionando o link watch.

 

Script

Com 5 opções diferentes de visualização a aba script é desenhada especialmente para visualização e depuração de scripts da página. Mostra os arquivos javascripts separados e podemos até pesquisar dentro deles.

Console: Tem a mesma função da aba console comentada anteriormente, inclusive os comando executados aparecem em ambas.

Breakpoints: Todos os breakpoints adicionados ao código javascript aparecerão aqui.

Locals: Objetos javascript carregados no contexto atual aparecerão neste local, podemos percorrer suas propriedades e até altera-las.

Watch: Quando você adiciona um objeto javascript ao inspecionador é aqui que ele aparecerá. Quando seu valor for alterado o mesmo aparecerá em vermelho.

Call stack: Muito importante quando se está depurando script é saber quem invocou determinado método. Com o Call Stack podemos saber os passos que o código deu até chegar até determinado ponto, seja um breakpoint ou um erro.

 

Profiler

As vezes precisamos saber a causa de um comportamento inesperado em nossa aplicação, mas não sabemos o que fez ocorrer ou quantas vezes ocorreu.

São nestes casos que podemos usar os Profilers. Neles são registrados todos os scripts que executam em um determinado momento e com isso podemos verificar a ordem de chamadas javascript feitas em um determinado período.

Você já pensou em tentar rastrear os eventos que ocorrem quando se passa o mouse por cima do mapa do Google Maps? Pois bem, com o Profiler executando podemos ver todas as execuções que ocorrem, sem falar que podemos ver não só a quantidade e tempo gasto em cada método como também a ordem de execução.

 

Network

Nova no IE9, a aba Network traz funcionalidades já presentes no Firebug e que muitos (inclusive eu) recorriam a outros programas, como o Fiddler, para capturar o tráfego de internet de determinadas páginas.

Torna-se incrivelmente útil quando precisamos verificar o tráfego de arquivos de determinada página, tamanho de chamadas Ajax, situação de cabeçalhos HTTP para averiguar headers que estão presentes ou faltando.

O recurso ainda traz dados detalhados de cada requisição, como os cabeçalhos HTTP enviados e recebidos, corpo da requisição e resposta e ainda um gráfico de onde foi gasto todo o tempo da mesma.

Bom, acho que era isso por enquanto. Este artigo foi iniciado pouco antes do PDC10 e do Plaform Preview 6 ser lançado, então ocorreram algumas melhorias na engine do Browser mas poucas diferenças nas abas (só notei a opção de identação de scripts).

Enjoy