Entrada e eventos do dispositivo (documentação do SDK do POS para .NET v1.14)

Todos os dispositivos POS têm a capacidade de gerar eventos ou alterar o estado, independentemente do aplicativo. Por exemplo, se um operador desligar um dispositivo PinPad, o aplicativo não terá uma maneira direta de detectar essa alteração por não se tratar de uma alteração de estado solicitada pelo aplicativo. Um Objeto de Serviço deve ter alguma maneira de alertar o aplicativo sobre essas alterações de estado.

Multithreading

Como fazer com que o aplicativo sonde continuamente o Objeto de Serviço para seu estado atual seria muito caro, é preciso haver outra solução. Normalmente, a solução é criar um thread em segundo plano para monitorar o dispositivo.

Como outros exemplos demonstraram, é sempre preciso criar um thread de leitor para dispositivos de entrada, como scanners ou leitores de faixa magnética. Para dispositivos de saída, como telas de linha e impressoras, no entanto, geralmente é preciso ter um segundo thread para observar as alterações de estado, como perder energia ou ficar offline e, em seguida, enviar um evento StatusUpdateEvent para o aplicativo.

Dessa forma, o Objeto de Serviço pode responder às solicitações do aplicativo enquanto monitora o hardware de forma assíncrona.

Definir eventos

Os eventos são o mecanismo pelo qual o Objeto de Serviço notifica a aplicação quanto a uma alteração de estado no dispositivo ou à chegada de novos dados.

Em termos gerais, um evento é uma notificação de que algo ocorreu entre um thread ou um processo e outro. Mais especificamente, o POS para .NET (Ponto de Serviço para .NET) da Microsoft usa o recurso de delegados do .NET para entregar ao aplicativo.

A especificação UnifiedPOS (Unified Point Of Service) define um conjunto de cinco eventos: DataEvent, DirectIOEvent, ErrorEvent, OutputCompleteEvent e StatusUpdateEvent. Cada Objeto de Serviço pode ter permissão para dar suporte a apenas um desses subconjuntos. O conteúdo exato dos dados também depende do tipo do Objeto de Serviço.

Filas de eventos

Ao criar uma classe de Objeto de Serviço derivada de classes Base dos POS para .NET, os eventos não são enviados diretamente do Objeto de Serviço para o aplicativo. Em vez disso, os eventos são colocados em uma fila gerenciada pela classe Base. Como há condições que devem ser atendidas antes que os eventos possam ser entregues a um aplicativo, o código na classe Base só enviará eventos quando for apropriado. O Objeto de Serviço não precisa estar ciente da fila ou dos requisitos que devem ser atendidos antes do acionamento de um evento. Isso ajuda muito o desenvolvedor do Objeto de Serviço.

A fila de eventos opera de forma assíncrona usando seu próprio thread. Isso significa que o Objeto de Serviço não espera pela entrega real do evento.

Adicionar eventos à fila

As classes Base do POS para .NET fornecem várias maneiras de adicionar um evento à fila, dependendo do Objeto de Serviço e do tipo de evento.

Muitas classes Base têm métodos auxiliares para simplificar a fila de determinados eventos; mais comumente, eventos DataEvent. Por exemplo, o método MsrBase.GoodRead pode ser usado para enfileirar um evento DataEvent após uma leitura bem-sucedida do cartão. Da mesma forma, PosKeyboard.KeyDown enfileira um DataEvent, indicando que uma tecla foi pressionada.

Os eventos também podem ser enfileirados automaticamente pela classe Base quando um determinado estado for alterado. Por exemplo, se um Objeto de Serviço tiver definido sua propriedade Properties.CapPowerReporting, um StatusUpdateEvent indicando uma alteração de energia poderá ser enviado ao simplesmente definir-se a propriedade Properties.PowerState no Objeto de Serviço.

Por fim, se necessário, um Objeto de Serviço poderá enfileirar especificamente um evento usando qualquer uma das substituições QueueEvent. Isso pode ser usado com mais frequência para enviar um DirectIOEvent. Como eventos DirectIOEvent são específicos do fornecedor e do dispositivo, nenhum mecanismo genérico pode ser usado para enfileirá-los.

Entrada síncrona

Embora a maior parte da entrada do dispositivo seja lida de forma assíncrona pelo Objeto de Serviço e, em seguida, enviada para o aplicativo na forma de eventos, há instâncias, no entanto, em que o aplicativo pode solicitar dados do Objeto de Serviço e não retornar até que os dados estejam prontos ou que um tempo limite tenha sido atingido. Para obter mais informações sobre a entrada controlada por eventos, confira Gerenciamento de Eventos.

Consulte Também

Tarefas

• Exemplo de manipulador de eventos

Conceitos

• Gerenciamento de eventos

Outros recursos

• Desenvolvendo Objetos de Serviço usando Classes Base