GameInput seja projetado principalmente em torno de um modelo de sondagem, existem casos em que é melhor notificar os aplicativos de forma assíncrona. Para dar suporte a isso, a interface IGameInput expõe alguns métodos para registrar funções de retorno de chamada que são invocadas quando determinados eventos de interesse ocorrem.
Internamente, o GameInput serializa o despacho de retornos de chamada para que apenas um retorno de chamada seja executado por vez. O GameInput garante que os retornos de chamada sejam despachados em ordem cronológica. Essas garantias simplificam o código que um aplicativo precisa escrever em suas funções de retorno de chamada.
O GameInput permite que no máximo 64 retornos de chamada, independentemente do tipo, sejam registrados a qualquer momento. Os retornos de chamada são despachados a partir de um thread de trabalho interno no GameInput. Para obter mais informações sobre como isso funciona, juntamente com opções para agendar esse trabalho manualmente, confira Filas de trabalho do GameInput.
Retornos de chamada de dispositivo
Os retornos de chamada de dispositivo fornecem uma maneira para os aplicativos saberem quando o status dos dispositivos de entrada muda, conforme mostrado na sintaxe a seguir. Mais comumente, isso é usado para detectar quando dispositivos se conectam e desconectam, mas outras alterações de status também podem ser de interesse.enumerationKind recebe um valor da enumeração GameInputEnumerationKind, indicando se a enumeração deve ser executada como parte do registro do retorno de chamada e, em caso afirmativo, se a enumeração deve ser executada de forma bloqueante ou assíncrona. Combinar a enumeração de dispositivos com as alterações de status subsequentes em uma única operação atômica evita condições de corrida das quais muitos aplicativos sofrem involuntariamente em seu código de entrada.
Retornos de chamada de leitura
Por meio de retornos de chamada de leitura, os aplicativos podem ser notificados sempre que novas leituras chegam ao fluxo de entrada, conforme mostrado na sintaxe a seguir. Embora muitos aplicativos considerem que a sondagem de entrada é melhor, existem situações em que a entrada orientada por eventos pode ser preferível. Por exemplo, a interface do usuário do menu principal de um jogo pode ser mais adequada para entrada baseada em eventos. Outro exemplo é uma interface do usuário de mapeamento de entrada que precisa aguardar a entrada depois de solicitar a seleção do usuário.Cancelar o registro de retornos de chamada
Depois que um retorno de chamada é registrado com êxito, o aplicativo deve garantir que todos os recursos necessários para executar o retorno de chamada permaneçam válidos. Isso inclui tanto os recursos consumidos pelo código do retorno de chamada quanto a própria função de retorno de chamada, por exemplo, se a função de retorno de chamada estiver hospedada em uma DLL que o aplicativo carrega e descarrega sob demanda. Para recuperar esses recursos com segurança, um aplicativo deve primeiro cancelar o registro do retorno de chamada passando o token recebido do métodoRegister*Callback para o método UnregisterCallback. Se o retorno de chamada estiver sendo executado quando esse método for chamado, ele será bloqueado até que o retorno de chamada termine de ser executado. Como resultado, um retorno de chamada não pode cancelar o próprio registro de dentro de sua própria função de retorno de chamada.
Os retornos de chamada também podem ser interrompidos chamando o método StopCallback. Isso não cancela o registro do retorno de chamada, mas garante que ele não seja chamado novamente. Como o registro do retorno de chamada não é cancelado, é seguro chamar esse método de dentro da própria função de retorno de chamada. Ele termina de executar o retorno de chamada atual, mas não o chama novamente. O registro dos retornos de chamada deve ser cancelado em algum momento, pois apenas 64 retornos de chamada são permitidos a qualquer momento.