Metody i błędy interfejsu

Ta sekcja zawiera szczegółowe informacje o metodach i błędach interfejsu.

Nieważne metody

Metody, które nie zwracają wyników, są przekładane na metody Java, które zwróć void. Na przykład deklaracja HIDL:

doThisWith(float param);

... staje się:

void doThisWith(float param);

Metody oparte na pojedynczym wyniku

Metody zwracające pojedynczy wynik są przekładane na ich język Java zwracają też pojedynczy wynik. Na przykład:

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

... staje się:

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

Metody z wieloma wynikami

W przypadku każdej metody, która zwraca więcej niż 1 wynik, klasa wywołania zwrotnego ma postać , który dostarcza wszystkie wyniki w swojej metodzie onValues. To wywołanie zwrotne jest dodatkowym parametrem metody. Na przykład parametr :

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

... staje się:

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

Osoba dzwoniąca pod numerem oneProducesTwoThings() zwykle użyje anonimowej klasy wewnętrznej lub 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ę, która zostanie użyta jako wywołanie zwrotne...

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

...i przekazać wystąpienie MyCallback jako trzeciego parametru do oneProducesTwoThings()

Błędy transportowe i odbiorcy śmierci

W niektórych przypadkach implementacje usług mogą działać w innym procesie, klient może przetrwać, nawet jeśli proces wdrażania interfejsu się kończy. Wywołania obiektu interfejsu hostowanego w martwym procesie kończą się niepowodzeniem z użyciem transportu (wyjątek środowiska wykonawczego zgłoszony przez wywoływaną metodę). Działania naprawcze po może wystąpić błąd przez żądanie nowej instancji usługi przez wywołanie metody I<InterfaceName>.getService() Metoda ta działa jednak tylko wtedy, gdy proces, który uległ awarii, został ponownie uruchomiony i ponownie zarejestrował usługi z menedżerem usługi (co zazwyczaj odnosi się do implementacji HAL).

Klienci interfejsu mogą także zarejestrować odbiorcę śmierci, aby otrzymać powiadomienia o śmierci usługi. Błędy transportu mogą nadal występować, jeśli połączenie w chwili, gdy serwer umiera. Aby zarejestrować takie powiadomienia po pobraniu IFoo, klient może wykonać te czynności:

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

Parametr recipient musi być implementacją funkcji HwBinder.DeathRecipient interfejsu HIDL. Interfejs zawiera jedną metodę serviceDied(), która jest wywoływana, gdy gdy proces hostowania interfejsu się kończy.

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

Parametr cookie zawiera plik cookie, który został przekazany z połączenie z numerem linkToDeath(). Możesz też wyrejestrować zgon odbiorcy po zarejestrowaniu go za pomocą:

foo.unlinkToDeath(recipient);