uniPaaS 2.0 – Detalhes que fazem a diferença

Manoel Frederico da Silva / Product Manager & MAGIC Evangelist / Magic Software Brasil

A integração do uniPaaS 2.0 com o MS.NET abre sem dúvida um leque muito grande em termos de funcionalidades e recursos para as nossas soluções.

Mas como sempre, com o poder vem a responsabilidade. Algumas coisas precisam ser observadas.

Por exemplo: criar uma variável/tipo .NET é exatamente igual ao procedimento de se criar variáveis nativas do uniPaaS. Mas apesar disso, elas só parecem ser a mesma coisa. De fato, não são.

Uma variável/campo uniPaaS definida nas tarefas/programas representa um tipo “valor”. Sua vida útil vai desde a instanciação da tarefa (antes do Task Prefix), até a sua finalização (após o Task Suffix). E sua área de memória é criada automaticamente pelo runTime uniPaaS durante a instanciação da tarefa, a mantida durante a vida útil desta tarefa.

Já uma variável/campo .NET representa (*em geral) um tipo “objeto”. O objeto é uma variável que irá conter a referência a uma instância de uma classe. A variável do tipo “objeto” não contém nada (é nula) até que a instância da classe seja criada e sua referência seja colocada ali dentro. E quando se utiliza uma variável “objeto” que ainda não possui uma referência de instância válida, o resultado é uma exceção do tipo NullPointerException.

Esse conceito é básico para os desenvolvedores MS.NET, mas pode ser uma novidade para o mundo uniPaaS, já que nunca houve necessidade de se lidar com alocação explícita de memória (tá vendo pq o uniPaaS sempre foi top? 🙂).

Quando criamos uma variável .NET no uniPaaS que é relacionada a um controle .NET que será colocado na tela (formulário), a instanciação da classe é feita automaticamente pelo runTime no momento da criação da janela (antes do Task Prefix).

Mas e quando formos utilizar uma classe que não é um controle?

Nestes casos, precisamos instanciar a classe (através de seu construtor) e colocar a referência dentro da variável. Isso deve ser feito apenas uma vez, já que cada execução do construtor cria uma nova instância (e normalmente não é o que se deseja).

Vejamos este exemplo: Supondo que queremos usar a classe MS.NETContextMenuStrip”, para criar um menu de contexto que poderá depois ser associado a algum controle .NET existente.

ContextMenuStrip” é definido no assembly “System.Windows.Forms”, que iremos referenciar como componente do projeto:

NOTA: Usaremos a alias “SWF” apenas para diminuir o esforço de digitação. Isto é um passo “opcional” (mas muito legal 🙂).

Criamos o nosso programa (RIA, On-Line ou Batch), e nele definimos uma variável deste tipo:

Agora temos um objeto “ContextMenuStrip” na tarefa, que representa um menu de contexto vazio. Os itens deste menu devem ser criados através do método “Add” da coleção “Items”, ex:

<var>.Items.Add( “Opção 1”)

<var>.Items.Add( “Opção 2”)

<var>.Items.Add( “Opção 3”)

O uso completo do “ContextMenuStrip” não é o foco neste post. O fato é que ao executar a tarefa, a variável .NET estará nula e a execução das instruções acima resultará em nada.

NOTA: a função uniPaaS “DNExceptionOccurred()” deverá retornar ‘TRUE’LOG, e “DNException()” retornará o objeto “Exception” descritivo da exceção.

Por isso, antes de qualquer uso desta variável deveremos instanciar a sua classe e guardar a referência dentro dela. Como queremos fazer isto uma única vez (nesta tarefa), o local mais apropriado parece ser o Task Prefix:

NOTA #1: “construtores” de classes MS.NET são métodos que possuem o mesmo nome da classe. As classes podem ter mais de um construtor, variando os argumentos, e você seleciona aquele que desejar.

NOTA #2: “DotNet” é uma palavra especial que pode ser usada nas expressões uniPaaS para acessar métodos .NET (ex: construtores e estáticos), não obrigatoriamente associados a uma variável .NET.

Agora sim. Após esta instrução, a variável “v. ContextMenuStrip” contém uma referência a uma instância da classe “ContextMenuStrip”, e poderá ser utilizada normalmente no restante da tarefa/programa.

E quando a memória associada a este objeto será liberada?

Esta decisão pertence ao GC (Garbage Collector) do framework MS.NET, que irá determinar quando aquela instância não é mais necessária e liberar a sua memória associada. Normalmente é após a tarefa/programa uniPaaS finalizar.

(*) O MS.NET também possui os tipos “valor”.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *