Revista MSDN Magazine Edição 15 - Pocket PC - Otimize sua Aplicação com o .NET Compact Framework

Clique aqui para ler todos os artigos desta edição

Pocket PC – Otimize sua Aplicação com o .NET Compact Framework

por Dave Edson e John Socha-Leialoha

Os programadores precisam lidar com muitas dificuldades hoje em dia. No caso do .NET, existe pelo menos uma estrutura que permite o desenvolvimento realmente fácil de aplicativos. A memória é gerenciada com tão pouco esforço por parte do desenvolvedor que podemos abusar com facilidade. Todos os controles bem apresentados, formulários, sistemas de janelas e recursos de GDI+ facilitam bastante. Fácil, quer dizer, até que você tenha que escrever para o Pocket PC, uma plataforma de 200MHz com imagens lentas de doer (leia-se: sem aceleração), sem disco rígido e somente 32 MB de RAM, dos quais você pode usar de verdade somente 2 ou 3 MB. Acrescente às limitações do hardware o sentimento terrível que se tem ao mergulhar no .NET Compact Framework e descobrir que alguns dos seus recursos favoritos não foram implementados. De repente seu sonho de criar aquele aplicativo perfeito e de “arrebentar” em C# se transforma em pesadelo.

Não se desespere. O .NET Compact Framework pode ser usado para criar ótimos códigos e excelentes aplicativos. Desde que você leve algumas coisas em consideração, e esteja disposto a contornar uma ou outra regras, poderá conseguir o que quer. Escrevemos muitos aplicativos em C# para o Pocket PC, resultando em aplicativos bem acabados e elegantes que ficaram pequenos e velozes.

Este artigo divide-se em duas seções principais: recursos e otimização. Na parte dos recursos, vamos ver alguns truques interessantes que facilitam nossas vidas de programadores, usando o .NET Compact Framework. Na seção sobre otimização, vamos discutir as técnicas para aumentar o desempenho, reduzir o tempo de carga e reduzir o espaço ocupado na memória. Será apresentado exemplos de código para lhe ajudar a transformar seu aplicativo em algo pequeno e rápido.

Recursos essenciais e nossa bancada de testes

Ao carregar o Visual Studio® .NET para criar nosso aplicativo inicial, você terá adicionar essas linhas de código no construtor do formulário principal, logo após a chamada a InitializeComponent:

#if DEBUG

    MinimizeBox = false;

#else

    MinimizeBox = true;

#endif

Isto permite que você feche o aplicativo, em vez de apenas minimiza-lo, o que pode ser algo muito prático ao executar testes fora do depurador. A próxima tarefa importante é desenterrar todo o poder do dispositivo para o qual você estiver programando.

O .NET Compact Framework certamente faz juz ao seu nome e é realmente compacto. Felizmente, os serviços interop estão presentes, e assim você pode chamar qualquer API CE do Win32® no dispositivo. Como muitas dessas APIs precisam de um handle de janela, você precisa conseguir uma. Até a versão 2.0 do .NET Compact Framework ser lançada (que ressuscita a propriedade Handle), use estas linha de código para obter o hWnd:

control.Capture = true;

IntPtr hwnd = Win32.GetCapture();

control.Capture = false;

Agora que a API do Win32 está novamente ao seu alcance, há uma outra utilização muito prática daquele hWnd. Você pode transformar em subclasse a sua própria janela com uma DLL do Win32 escrita com eMbedded Visual C++® 4.0 e jogar pesado. Mas há algo que não se deve esquecer: os serviços interop não mantêm uma DLL carregada na memória. Bem no âmago do P/Invoke há um par LoadLibrary/FreeLibrary. Se você quiser que sua DLL transforme em subclasse o seu aplicativo (ou, me desculpe, qualquer aplicativo do sistema), essa DLL deverá permanecer carregada na memória até que você esteja pronto para liberá-la. Há uma solução para este problema: basta chamar LoadLibrary na DLL ao iniciar, depois chamar FreeLibrary na DLL quando você terminar. A contagem de referência causará um impacto e o par LoadLibrary/FreeLibrary de P/Invoke se tornará benigno.

Figura 1 Test Bench da MSDN

Este artigo abordará diversos assuntos. Criamos o programa Test Bench (mostrado na Figura 1), que integra muitos dos conceitos abordados.

Caixas de diálogo malvadas

Usuários e desenvolvedores que desconhecem o comportamento das caixas de diálogo no .NET Compact Framework, podem acabar na terra do nunca quando abrirem uma caixa de diálogo modal. As caixas de diálogo do .NET Compact Framework não são realmente caixas de diálogo, no sentido normal. Em vez disso, são apenas novos formulários que aparecem sobre outros formulários já existentes, mas não devolvem o controle ao caller até que você as feche. Se você usar um código como este para exibir sua caixa de diálogo

  BadDialog test = new BadDialog();

   test.ShowDialog();

ela aparecerá como um formulário de nível mais alto. Quando o usuário comutar para fora do seu programa, terá início a diversão. Eles acabarão querendo voltar para o seu programa, e irão até a página System | Settings | Memory | Running Programs, onde verão seu aplicativo principal e a caixa de diálogo relacionados. Se o usuário clicar no aplicativo de nível mais alto, em vez de clicar na caixa de diálogo, será exibida a janela do aplicativo principal, mas ficará inativa, já que estará esperando que a caixa de diálogo seja fechada.

Para ver isso acontecer, clique no botão Bad Dialog no aplicativo Test Bench. Agora vá até a lista de programas em execução, a partir da tela Settings, e ative o aplicativo Test Bench (Figura 2). Se você pressionar qualquer um dos botões, todos eles apenas emitirão um bip, já que essa janela está desativada. Você não poderá nem mesmo fechá-la. Então o usuário responderá da única maneira que conhece: Uma correção com clique (na verdade, uma correção com toque no dispositivo móvel). A saída é voltar à lista de programas em execução e ativar o item Bad Dialog. Para apimentar mais um pouco, depois que você fechar a caixa de diálogo, outro aplicativo poderá surgir, já que a ordem z das janelas pode ter sido alterada enquanto quando você alternava de um programa para outro.

Figura 2  Informações confusas

Para resolver esses problemas, assim como alguns outros relacionados com a existência de vários formulários, criamos uma classe Dialogs com um membro estático chamado ShowDialog. Veja o que ele faz: ...