Métodos y errores de la interfaz

En esta sección, se detallan los métodos y errores de la interfaz.

Métodos nulos

Los métodos que no devuelven resultados se traducen en métodos de Java que Se muestra void. Por ejemplo, la declaración HIDL tiene las siguientes características:

doThisWith(float param);

... se convierte en:

void doThisWith(float param);

Métodos de resultado único

Los métodos que devuelven un solo resultado se traducen a su Java equivalentes que también muestran un solo resultado. Por ejemplo:

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

... se convierte en:

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

Métodos de resultados múltiples

Para cada método que devuelve más de un resultado, se aplica una clase de devolución de llamada generado que proporciona todos los resultados en su método onValues. Esa devolución de llamada actúa como un parámetro adicional para el método. Por ejemplo, el lo siguiente:

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

... se convierte en:

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

Un llamador de oneProducesTwoThings() normalmente usaría un lambda o clase interna anónima para implementar la devolución de llamada localmente:

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

O bien:

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

También puedes definir una clase para usar como devolución de llamada...

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

... y pasar una instancia de MyCallback como tercer parámetro a oneProducesTwoThings()

Errores de transporte y destinatarios de fallecimiento

Debido a que las implementaciones de servicios pueden ejecutarse en un proceso diferente, en algunos casos el cliente puede seguir con actividad incluso cuando deja de funcionar el proceso que implementa una interfaz. Las llamadas en un objeto de interfaz alojado en un proceso muerto fallan con un transporte. (una excepción de tiempo de ejecución que arroja el método llamado). La recuperación de un una falla es posible solicitando una nueva instancia del servicio llamando I<InterfaceName>.getService() Sin embargo, este método funciona solo si el proceso que falló se reinició y volvió a registrar sus servicios con el servicemanager (lo que suele suceder en las implementaciones de HAL).

Los clientes de una interfaz también pueden registrar un destinatario de la muerte para obtener un cuando un servicio deja de funcionar. Aun así, pueden ocurrir errores de transporte si se realiza se hace justo cuando el servidor deja de funcionar. A fin de registrarse para este tipo de notificaciones en un IFoo, un cliente puede hacer lo siguiente:

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

El parámetro recipient debe ser una implementación del interfaz HwBinder.DeathRecipient proporcionada por HIDL. La interfaz contiene un único método serviceDied() al que se llama cuando se proceso que aloja la interfaz deja de funcionar.

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

El parámetro cookie contiene la cookie que se pasó con la llamada a linkToDeath(). También es posible cancelar el registro de una muerte destinatario después de registrarlo con:

foo.unlinkToDeath(recipient);