Méthodes et erreurs de l'interface

Cette section détaille les méthodes d'interface et les erreurs.

Méthodes de négligence

Les méthodes qui ne renvoient pas de résultats sont converties en méthodes Java qui : renvoient void. Par exemple, la déclaration HIDL:

doThisWith(float param);

... devient:

void doThisWith(float param);

Méthodes à résultat unique

Les méthodes qui renvoient un seul résultat sont traduites dans leur équivalents renvoyant également un seul résultat. Par exemple:

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

... devient:

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

Méthodes de résultats multiples

Pour chaque méthode qui renvoie plusieurs résultats, une classe de rappel est généré qui fournit tous les résultats dans sa méthode onValues. Ce rappel sert de paramètre supplémentaire à la méthode. Par exemple, suivantes:

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

... devient:

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

Un appelant de oneProducesTwoThings() utilise généralement un une classe interne anonyme ou un lambda pour implémenter le rappel localement:

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

Vous pouvez également définir une classe à utiliser comme rappel.

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

... et transmettez une instance de MyCallback comme troisième paramètre à oneProducesTwoThings()

Erreurs de transport et destinataires de la mort

Étant donné que les implémentations de service peuvent s'exécuter selon un processus différent, dans certains cas, le client peut rester en vie même lorsque le processus d'implémentation d'une interface s'arrête. Les appels sur un objet d'interface hébergé dans un processus mort échouent (exception d'exécution générée par la méthode appelée). Une guérison d'échec est possible en demandant une nouvelle instance du service en appelant I<InterfaceName>.getService() Cependant, cette méthode fonctionne uniquement si le processus qui a planté a redémarré et réenregistré ses services avec le servicemanager (ce qui est généralement vrai pour les implémentations HAL).

Les clients d'une interface peuvent également enregistrer un destinataire du décès pour recevoir une une notification en cas d'arrêt d'un service. Des erreurs de transport peuvent toujours se produire si un appel est faite au moment où le serveur meurt. Pour recevoir ces notifications sur une récupération IFoo, un client peut effectuer les opérations suivantes:

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

Le paramètre recipient doit être une implémentation de l'interface HwBinder.DeathRecipient fournie par HIDL. L'interface contient une seule méthode serviceDied() qui est appelée lorsque le qui héberge l'interface s'arrête.

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

Le paramètre cookie contient le cookie transmis avec l'appel à linkToDeath(). Il est également possible d'annuler l'enregistrement d'un décès destinataire après l'avoir enregistré en utilisant:

foo.unlinkToDeath(recipient);