ইন্টারফেস পদ্ধতি এবং ত্রুটি

এই বিভাগে ইন্টারফেস পদ্ধতি এবং ত্রুটি বিশদ বিবরণ.

অকার্যকর পদ্ধতি

যে পদ্ধতিগুলি ফলাফল ফেরত দেয় না সেগুলি জাভা পদ্ধতিতে অনুবাদ করা হয় যা void ফেরত দেয়। উদাহরণস্বরূপ, HIDL ঘোষণা:

doThisWith(float param);

… হয়ে যায়:

void doThisWith(float param);

একক ফলাফল পদ্ধতি

যে পদ্ধতিগুলি একটি একক ফলাফল প্রদান করে তাদের জাভা সমতুল্যগুলিতে অনুবাদ করা হয় এবং একটি একক ফলাফল প্রদান করে। উদাহরণস্বরূপ, নিম্নলিখিত:

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

… হয়ে যায়:

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

একাধিক ফলাফল পদ্ধতি

প্রতিটি পদ্ধতির জন্য যা একাধিক ফলাফল প্রদান করে, একটি কলব্যাক ক্লাস তৈরি করা হয় যা তার onValues ​​পদ্ধতিতে সমস্ত ফলাফল সরবরাহ করে। সেই কলব্যাক পদ্ধতিতে একটি অতিরিক্ত পরামিতি হিসাবে কাজ করে। উদাহরণস্বরূপ, নিম্নলিখিত:

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

… হয়ে যায়:

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

oneProducesTwoThings() এর একজন কলার সাধারণত স্থানীয়ভাবে কলব্যাক বাস্তবায়নের জন্য একটি বেনামী অভ্যন্তরীণ শ্রেণী বা ল্যাম্বডা ব্যবহার করবে:

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

বা:

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

আপনি কলব্যাক হিসাবে ব্যবহার করার জন্য একটি ক্লাস সংজ্ঞায়িত করতে পারেন …

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

… এবং oneProducesTwoThings() এ তৃতীয় প্যারামিটার হিসাবে MyCallback এর একটি উদাহরণ পাস করুন।

পরিবহন ত্রুটি এবং মৃত্যু প্রাপক

যেহেতু পরিষেবা বাস্তবায়ন একটি ভিন্ন প্রক্রিয়ায় চলতে পারে, কিছু ক্ষেত্রে ক্লায়েন্ট জীবিত থাকতে পারে এমনকি যখন একটি ইন্টারফেস বাস্তবায়ন প্রক্রিয়াটি মারা যায়। একটি ডেড প্রসেসে হোস্ট করা একটি ইন্টারফেস অবজেক্টের কলগুলি একটি পরিবহন ত্রুটির সাথে ব্যর্থ হয় (কথিত পদ্ধতি দ্বারা ছুঁড়ে দেওয়া একটি রানটাইম ব্যতিক্রম)। I<InterfaceName>.getService() কল করে পরিষেবার একটি নতুন উদাহরণের অনুরোধ করে এই ধরনের ব্যর্থতা থেকে পুনরুদ্ধার করা সম্ভব। যাইহোক, এই পদ্ধতিটি তখনই কাজ করে যখন ক্র্যাশ হওয়া প্রক্রিয়াটি পুনরায় চালু হয় এবং সার্ভিস ম্যানেজার (যা সাধারণত HAL বাস্তবায়নের ক্ষেত্রে সত্য) এর সাথে তার পরিষেবাগুলি পুনরায় নিবন্ধিত করে।

একটি ইন্টারফেসের ক্লায়েন্টরা একটি পরিষেবা মারা গেলে একটি বিজ্ঞপ্তি পেতে একটি মৃত্যু প্রাপককে নিবন্ধন করতে পারে। ট্রান্সপোর্ট ত্রুটি এখনও ঘটতে পারে যদি একটি কল করা হয় ঠিক যেমন সার্ভার মারা যায়। একটি পুনরুদ্ধার করা IFoo ইন্টারফেসে এই ধরনের বিজ্ঞপ্তিগুলির জন্য নিবন্ধন করতে, একজন ক্লায়েন্ট নিম্নলিখিতগুলি করতে পারেন:

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

recipient পরামিতি অবশ্যই HIDL দ্বারা প্রদত্ত ইন্টারফেসের HwBinder.DeathRecipient এর বাস্তবায়ন হতে হবে। ইন্টারফেসটিতে একটি একক পদ্ধতি রয়েছে serviceDied() যা ইন্টারফেস হোস্টিং প্রক্রিয়াটি মারা গেলে বলা হয়।

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

cookie প্যারামিটারে সেই কুকি রয়েছে যা linkToDeath() এ কল করার সাথে পাস করা হয়েছিল। এটি ব্যবহার করে নিবন্ধন করার পরে একজন মৃত্যু প্রাপককে নিবন্ধনমুক্ত করাও সম্ভব:

foo.unlinkToDeath(recipient);