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);