Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Todos os dispositivos POS têm a capacidade de gerar eventos ou alterar o estado independentemente do aplicativo. Por exemplo, se um operador desconecta um dispositivo PinPad , o aplicativo não tem nenhuma maneira direta de detetar essa alteração, pois não é uma alteração de estado solicitada pelo aplicativo. Um objeto de serviço deve ter alguma maneira de alertar o aplicativo para 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, outra solução é necessária. Normalmente, a solução é criar um thread em segundo plano para monitorar o dispositivo.
Como outros exemplos demonstraram, a criação de um segmento de leitura é sempre necessária para dispositivos de entrada, como scanners ou leitores de banda magnética. Para dispositivos de saída, como monitores de linha e impressoras, no entanto, um segundo thread geralmente é necessário para observar as alterações de estado, como perda de energia ou ficar offline e, em seguida, para enviar um evento StatusUpdateEvent para o aplicativo.
Dessa forma, o objeto de serviço pode responder a solicitações do aplicativo enquanto monitora o hardware de forma assíncrona.
Definição de eventos
Os eventos são o mecanismo pelo qual o objeto de serviço notifica a aplicação de uma alteração de estado no dispositivo ou a chegada de novos dados.
Em termos gerais, um evento é uma notificação entre um thread ou processo e outro de que algo ocorreu. Mais especificamente, o Microsoft Point of Service para .NET (POS para .NET) usa o recurso de delegados do .NET para entregar ao aplicativo.
A especificação Unified Point Of Service (UnifiedPOS) define um conjunto de cinco eventos: DataEvent, DirectIOEvent, ErrorEvent, OutputCompleteEvent e StatusUpdateEvent. Cada Objeto de Serviço pode ter permissão para suportar apenas um subconjunto destes. O conteúdo exato dos dados também depende do tipo de objeto de serviço.
Filas de eventos
Quando você cria uma classe de objeto de serviço derivada de uma das classes POS para .NET Base , 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 despacha eventos somente quando é apropriado fazê-lo. O objeto de serviço não precisa estar ciente da fila ou dos requisitos que devem ser atendidos antes que um evento possa ser acionado. Isso alivia muito a carga sobre o desenvolvedor do Service Object.
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.
Adicionando eventos à fila
As classes POS para .NET Base 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 o enfileiramento de certos 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 é 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 simplesmente definindo a propriedade Properties.PowerState no Objeto de Serviço.
Finalmente, se necessário, um objeto de serviço pode enfileirar especificamente um evento usando qualquer uma das substituições de QueueEvent . Isso pode ser usado com mais frequência para enviar um DirectIOEvent. Como os 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 maioria das entradas de dispositivo seja lida de forma assíncrona pelo Objeto de Serviço e, em seguida, despachada 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 um tempo limite tenha sido atingido. Para obter mais informações sobre a entrada orientada a eventos, consulte Gerenciamento de eventos.