Metodi ed errori dell'interfaccia

Questa sezione descrive i metodi e gli errori dell'interfaccia.

Metodi non validi

I metodi che non restituiscono risultati vengono tradotti in metodi Java che restituisce void. Ad esempio, la dichiarazione HIDL:

doThisWith(float param);

... diventa:

void doThisWith(float param);

Metodi con risultato singolo

I metodi che restituiscono un singolo risultato vengono tradotti in Java. equivalenti che restituiscono anche un singolo risultato. Ad esempio:

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

... diventa:

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

Metodi con risultati multipli

Per ogni metodo che restituisce più di un risultato, viene applicata una classe di callback generato che fornisce tutti i risultati nel suo metodo onValues. Questo callback funge da parametro aggiuntivo al metodo. Ad esempio, seguenti:

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

... diventa:

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

Un chiamante di oneProducesTwoThings() in genere usa un classe interna anonima o lambda per implementare il callback localmente:

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

oppure:

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

Puoi anche definire una classe da utilizzare come callback...

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

... e passa un'istanza di MyCallback come terzo parametro a oneProducesTwoThings().

Errori di trasporto e destinatari dei decesso

Poiché le implementazioni dei servizi possono essere eseguite in un processo diverso, in alcuni casi il client può rimanere attivo anche quando il processo di implementazione di un'interfaccia si interrompe. Le chiamate a un oggetto dell'interfaccia ospitato in un processo inattivo non riescono con un trasporto (un'eccezione di runtime generata dal metodo chiamato). Il ripristino da un è possibile richiedere una nuova istanza del servizio chiamando I<InterfaceName>.getService(). Tuttavia, questo metodo funziona solo se il processo che si è arrestato in modo anomalo è stato riavviato e ha registrato nuovamente i suoi servizi con servicemanager (vale a dire in genere per le implementazioni HAL).

I client di un'interfaccia possono anche registrare un ricevitore del decesso per ottenere una notifica quando un servizio smette di funzionare. Gli errori di trasporto possono comunque verificarsi se una chiamata viene è stato creato esattamente come muore il server. Per ricevere queste notifiche dopo aver recuperato IFoo, un client può effettuare le seguenti operazioni:

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

Il parametro recipient deve essere un'implementazione del metodo l'interfaccia HwBinder.DeathRecipient fornita da HIDL. L'interfaccia contiene un singolo metodo serviceDied() che viene chiamato quando il processo che ospita l'interfaccia muore.

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

Il parametro cookie contiene il cookie che è stato trasmesso con la chiamata a linkToDeath(). È anche possibile annullare la registrazione di un decesso destinatario dopo averlo registrato utilizzando:

foo.unlinkToDeath(recipient);