ইন্টারফেস পদ্ধতি ও সমস্যা

এই বিভাগে ইন্টারফেস পদ্ধতি ও সমস্যা সম্পর্কে বিস্তারিত তথ্য দেওয়া আছে।

void পদ্ধতি

যেসব মেথড ফলাফল রিটার্ন করে না, সেগুলি জাভা মেথডে অনুবাদ করা হয়, যা void রিটার্ন করে। যেমন, HIDL ডিক্লারেশন:

doThisWith(float param);

… হয়ে যায়:

void doThisWith(float param);

সিঙ্গেল-রেজাল্ট পদ্ধতি

যেসব পদ্ধতি একটি ফলাফল প্রদান করে, সেগুলিকে Java-এর সমতুল্য পদ্ধতিতে অনুবাদ করা হয় এবং সেগুলিও একটি ফলাফল প্রদান করে। যেমন, নিচে উল্লেখ করা বিষয়গুলি:

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.
  }
}

… এবং MyCallback-এর একটি ইনস্ট্যান্সকে oneProducesTwoThings()-এর থার্ড প্যারামিটার হিসেবে পাস করুন।

ট্রান্সপোর্ট সংক্রান্ত সমস্যা ও মৃত প্রাপক

কারণ, পরিষেবার ইমপ্লিমেন্টেশন আলাদা প্রসেসে চলতে পারে, কিছু ক্ষেত্রে ইন্টারফেস ইমপ্লিমেন্ট করার প্রসেস বন্ধ হয়ে গেলেও ক্লায়েন্ট চালু থাকতে পারে। ডেড প্রসেসে হোস্ট করা ইন্টারফেস অবজেক্টে কল করলে ট্রান্সপোর্ট এরর (কল করা মেথডের মাধ্যমে নিক্ষিপ্ত রানটাইম ব্যতিক্রম) সহ ব্যর্থ হয়। 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);