Métodos de interface e erros

Esta seção detalha os métodos e erros da interface.

Métodos nulos

Métodos que não retornam resultados são convertidos em métodos Java que retorne void. Por exemplo, a declaração HIDL:

doThisWith(float param);

... passa a ser:

void doThisWith(float param);

Métodos de resultado único

Os métodos que retornam um único resultado são convertidos em equivalentes também retornam um único resultado. Por exemplo, o seguinte:

doQuiteABit(int32_t a, int64_t b,
            float c, double d) generates (double something);

... passa a ser:

double doQuiteABit(int a, long b, float c, double d);

Métodos com vários resultados

Para cada método que retorna mais de um resultado, uma classe de callback é gerado que fornece todos os resultados no método onValues. Esse callback atua como um parâmetro adicional do método. Por exemplo, o seguinte:

oneProducesTwoThings(SomeEnum x) generates (double a, double b);

... passa a ser:

public interface oneProducesTwoThingsCallback {
    public void onValues(double a, double b);
}
void oneProducesTwoThings(byte x, oneProducesTwoThingsCallback cb);

O autor da chamada de oneProducesTwoThings() normalmente usaria uma classe interna anônima ou lambda para implementar o callback localmente:

someInstanceOfFoo.oneProducesTwoThings(
         5 /* x */,
         new IFoo.oneProducesTwoThingsCallback() {
          @Override
          void onValues(double a, double b) {
             // do something interesting with a and b.
             ...
          }});

ou:

someInstanceOfFoo.oneProducesTwoThings(5 /* x */,
    (a, b) -> a > 3.0 ? f(a, b) : g(a, b)));

Também é possível definir uma classe para usar como callback...

class MyCallback implements oneProducesTwoThingsCallback {
  public void onValues(double a, double b) {
    // do something interesting with a and b.
  }
}

... e transmitir uma instância de MyCallback como o terceiro parâmetro para oneProducesTwoThings().

Erros de transporte e destinatários de morte

Como as implementações de serviço podem ser executadas em um processo diferente, em alguns casos o cliente pode permanecer ativo mesmo quando o processo de implementação de uma interface falha. As chamadas em um objeto de interface hospedado em um processo inativo falham com um transporte (uma exceção de tempo de execução gerada pelo método chamado). A recuperação de um falha é possível ao solicitar uma nova instância do serviço chamando I<InterfaceName>.getService(): No entanto, esse método funciona somente se o processo que falhou tiver reiniciado e registrado novamente seus serviços com o servicemanager (o que geralmente é verdadeiro para implementações da HAL).

Os clientes de uma interface também podem registrar um destinatário da morte para receber uma quando um serviço é encerrado. Erros de transporte ainda podem ocorrer se uma chamada for feita assim que o servidor falha. Para se registrar para receber essas notificações em um IFoo, um cliente poderá fazer o seguinte:

foo.linkToDeath(recipient, 1481 /* cookie */);

O parâmetro recipient precisa ser uma implementação do interface HwBinder.DeathRecipient fornecida pelo HIDL. Interface contém um único método serviceDied() que é chamado quando a que hospeda os dados da interface.

final class DeathRecipient implements HwBinder.DeathRecipient {
    @Override
    public void serviceDied(long cookie) {
        // Deal with service going away
    }
}

O parâmetro cookie contém o cookie que foi transmitido com a chamada para linkToDeath(). Também é possível cancelar o registro de uma morte destinatário após o registro usando:

foo.unlinkToDeath(recipient);