Metody i błędy interfejsu

W tej sekcji znajdziesz szczegółowe informacje o metodach i błędach interfejsu.

Metody anulowania

Metody, które nie zwracają wyników, są tłumaczone na metody Javy zwracające void. Na przykład deklaracja HIDL:

doThisWith(float param);

… zmienia się w:

void doThisWith(float param);

Metody z jednym wynikiem

Metody zwracające pojedynczy wynik są tłumaczone na ich odpowiedniki w języku Java, które również zwracają pojedynczy wynik. Na przykład:

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

… zmienia się w:

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

Metody z wieloma wynikami

W przypadku każdej metody zwracającej więcej niż 1 wynik generowana jest klasa wywołania zwrotnego, która dostarcza wszystkie wyniki w swojej metodzie onValues. To wywołanie zwrotne działa jako dodatkowy parametr metody. Na przykład:

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

… zmienia się w:

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

Wywołujący oneProducesTwoThings() zwykle używa anonimowej wewnętrznej klasy lub funkcji lambda, aby zaimplementować wywołanie zwrotne lokalnie:

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

lub:

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

Możesz też zdefiniować klasę do użycia jako wywołania zwrotnego… 

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

… i jako 3 parametry funkcji oneProducesTwoThings() przekazać instancję funkcji MyCallback.

Błędy transportu i odbiorcy zmarłego

Implementacje usług mogą działać w ramach innego procesu, więc w niektórych przypadkach klient może pozostać aktywny nawet wtedy, gdy proces implementujący interfejs przestanie działać. Wywołania obiektu interfejsu hostowanego w martwym procesie kończą się błędem transportowym (wyjątek zgłoszony przez wywołaną metodę). Odzyskiwanie po takim błędzie jest możliwe przez zażądanie nowej instancji usługi przez wywołanie funkcjiI<InterfaceName>.getService(). Ta metoda działa jednak tylko wtedy, gdy uruchomiony ponownie proces, który uległ awarii, ponownie zarejestrował swoje usługi w servicemanagerze (co jest ogólnie prawdziwe w przypadku implementacji HAL).

Klienci interfejsu mogą też zarejestrować adresata powiadomień o śmierci, aby otrzymywać powiadomienia o śmierci usługi. Błędy transportu mogą nadal występować, jeśli wywołanie zostanie wysłane w momencie, gdy serwer przestaje działać. Aby zarejestrować się w celu otrzymywania takich powiadomień w wyświetlonym interfejsie IFoo, klient może wykonać te czynności:

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

Parametr recipient musi być implementacją interfejsu HwBinder.DeathRecipient udostępnionego przez HIDL. Interfejs zawiera jedną metodę serviceDied(), która jest wywoływana, gdy proces hostujący interfejs przestaje działać.

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

Parametr cookie zawiera plik cookie przekazany w wywołaniu funkcji linkToDeath(). Możesz też wyrejestrować odbiorcę powiadomienia o śmierci, korzystając z:

foo.unlinkToDeath(recipient);