Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML.
CRIANDO UM LANÇADOR DE APLICATIVOS
Quando temos um aplicativo funcionando em rede, alguns detalhes de instalação e manutenção nos passam desapercebidos. Em alguns casos, eles não são realmente tão importantes assim, mas quando o aplicativo está em constante atualização ou temos muitas estações funcionando em rede, cuidar desses pequenos detalhes pode significar ganhar várias horas ao final do nosso projeto.
A solução mais comumente adotada é a criação um atalho apontando para o servidor em cada uma das máquinas que estiver funcionando em rede. Esta solução é ótima na maioria das situações, mas se temos de fazer atualizações no executável, esbarramos na primeira limitação deste método, que é ter este arquivo executável bloqueado por estar em uso pelo Windows.
Creio que grande parte dos desenvolvedores que estão lendo este artigo já esbarrou nesse problema. Com isso, começa a novela: pede-se para todo mundo sair da rede, mas... Fulano está terminando um pedido, Sicrano tem de terminar uma nota porque o caminhão está esperando, Beltrano está gerando um relatório que tem de sair agora, ou ainda, o gerente de informática (seu chefe) foi tomar um café e deixou o aplicativo aberto... E por aí vai.
Pensando nestes problemas, desenvolvemos, há algum tempo, um lançador de aplicativos. Com ele, o usuário não chama diretamente o aplicativo a ser executado: é criada uma camada de controle intermediária. Muito simples e prático!
Situações que teremos de controlar
Vejamos agora algumas situações que devemos considerar para a implementação do lançador de aplicativos:
1 - O aplicativo deverá ficar temporariamente não disponível – geralmente quando temos de fazer alguma manutenção na base de dados. Nesses casos, o aplicativo em si não representa o problema, e sim o acesso à base de dados que poderá estar em manutenção, não podendo ser acessada. Para resolver esse problema, existe, dentro do arquivo INI, um parâmetro que indica se o aplicativo pode ou não ser acessado. Dessa forma, nenhum usuário “apressadinho” pode estragar o nosso trabalho.
2 - O aplicativo deverá ser atualizado – se o aplicativo estiver em desenvolvimento ou passando por uma fase de testes, é comum termos constantes atualizações de versão. Bem, como o usuário não chamou diretamente o executável – e determinamos isso em nossa camada de controle – alteramos o nome do executável, inclusive mantendo um histórico. Por exemplo, mudamos o nome de "FAT2001-05-10.exe" para a nova versão "FAT2001-05-18.exe". Localmente na maquina do usuário, isso não afeta em nada o trabalho, já que podemos definir dentro do arquivo INI que o aplicativo local pode ter um nome diferente do aplicativo remoto.
Arquivo INI
Pois bem, vamos ao que interessa. Primeiramente, os pontos a serem cuidados devem ter soluções simples. Eu gosto de manter isso em mente: a solução simples, geralmente, é a melhor solução.
A tecnologia escolhida utiliza um arquivo INI. Como é possível que queiramos migrar esse aplicativo para outras plataformas, o fato de usarmos um mecanismo simples de leitura de um arquivo TXT e a interpretação de alguns parâmetros lá escritos pode facilitar muito nossa vida no futuro.
Estes são os parâmetros armazenados dentro do arquivo INI:
...
