Device Token: এটি কীভাবে কাজ করে, APNS টোকেন প্রাপ্তি এবং আপডেট

Device Token কী

Device Token (ডিভাইস টোকেন) হল একটি হেক্স স্ট্রিং-এর আকারে অনন্য শনাক্তকারী যা APNS (Apple Push Notification Service) প্রতিটি iOS ডিভাইসে প্রতিটি অ্যাপের জন্য জেনারেট করে। টোকেনটি হল সেই চাবি যার মাধ্যমে সার্ভার একটি নির্দিষ্ট ডিভাইসে পুশ নোটিফিকেশন পাঠায়। বৈধ Device Token ছাড়া, সার্ভার পুশ নোটিফিকেশন ডেলিভার করতে পারে না — APNS 400 BadRequest ত্রুটি সহ অনুরোধ প্রত্যাখ্যান করে।

টোকেন কীভাবে গঠিত হয়

Device Token iOS সিস্টেম দ্বারা তৈরি হয় যখন অ্যাপ ইনস্টলের পর প্রথমবার APNS-এর সাথে যোগাযোগ করে। জেনারেশন প্রক্রিয়া অ্যাপের bundle ID এবং ডিভাইসের অনন্য শনাক্তকারীর (UID) সাথে ক্রিপ্টোগ্রাফিক বাইন্ডিং অন্তর্ভুক্ত করে, তারপর APNS অ্যাপকে হেক্স ফরম্যাটে (64 অক্ষর) একটি 32-বাইট টোকেন ফেরত দেয়। টোকেন স্থায়ী নয় — সিস্টেম নির্দিষ্ট শর্তে একটি নতুন টোকেন জেনারেট করতে পারে।

পুশ নোটিফিকেশন ডেলিভারিতে টোকেনের ভূমিকা

যখন সার্ভার একটি পুশ নোটিফিকেশন পাঠায়, এটি APNS-কে HTTP/2 অনুরোধে Device Token অন্তর্ভুক্ত করে। APNS টোকেন যাচাই করে: যদি টোকেনটি ভিন্ন পরিবেশের (production-এর পরিবর্তে sandbox) হয়, মেয়াদোত্তীর্ণ হয় বা প্রত্যাহার করা হয়, Apple সার্ভার 410 Gone বা 400 BadRequest ত্রুটি ফেরত দেয়। শুধুমাত্র সফল টোকেন যাচাইয়ের পর APNS ডিভাইসে নোটিফিকেশন ডেলিভার করা শুরু করে।

Device Token এবং অন্যান্য শনাক্তকারীর মধ্যে পার্থক্য

Device Token-কে IDFA (Identifier for Advertisers), IDFV (Identifier for Vendor) বা UID (Unique Device Identifier) এর সাথে গুলিয়ে ফেলা উচিত নয়। IDFA এবং IDFV বিজ্ঞাপন এবং বিশ্লেষণের জন্য ব্যবহৃত হয়, UID একটি হার্ডওয়্যার সিরিয়াল নম্বর। Device Token শুধুমাত্র পুশ নোটিফিকেশনের জন্য বিদ্যমান এবং APNS-এর বাইরে ব্যবহারকারী বা ডিভাইস সম্পর্কে তথ্য প্রকাশ করে না।

ডিভাইস কীভাবে টোকেন পায় এবং রেজিস্টার করে

Device Token পাওয়ার প্রক্রিয়াটি বেশ কয়েকটি বাধ্যতামূলক ধাপ নিয়ে গঠিত, ব্যবহারকারীর কাছ থেকে অনুমতি চাওয়া থেকে শুরু করে সার্ভারে টোকেন পাঠানো পর্যন্ত। প্রতিটি ধাপ গুরুত্বপূর্ণ — এগুলোর যেকোনো একটি এড়িয়ে গেলে ডিভাইসে পুশ নোটিফিকেশন পাঠানো অসম্ভব হয়ে পড়ে।

নোটিফিকেশন অনুমতি অনুরোধ

প্রথম ধাপ হল অ্যাপ UNUserNotificationCenter.current().requestAuthorization-এর মাধ্যমে ব্যবহারকারীর কাছ থেকে নোটিফিকেশন পাঠানোর অনুমতি চাওয়া। ব্যবহারকারী সম্মতি দিতে পারেন, অস্বীকার করতে পারেন বা ঐচ্ছিক অপশন (alert, badge, sound) নির্বাচন করতে পারেন। স্পষ্ট ব্যবহারকারী সম্মতি ছাড়া, সিস্টেম Device Token জারি করবে না, এমনকি যদি অ্যাপ registerForRemoteNotifications কল করে। অনুমতি পাওয়ার পর, অ্যাপ UIApplication.shared.registerForRemoteNotifications() কল করে, যা APNS-এ রেজিস্ট্রেশন প্রক্রিয়া শুরু করে।

APNS থেকে টোকেন পাওয়া

রেজিস্ট্রেশনের পর, APNS AppDelegate-এর মাধ্যমে টোকেন ফেরত দেয়: application(_:didRegisterForRemoteNotificationsWithDeviceToken:)। সফল কল টোকেন সহ একটি Data অবজেক্ট ধারণ করে, যা সার্ভারে প্রেরণের জন্য হেক্স স্ট্রিং-এ রূপান্তর করা আবশ্যক। ত্রুটির ক্ষেত্রে, সিস্টেম সমস্যার বিবরণ সহ application(_:didFailToRegisterForRemoteNotificationsWithError:) কল করে: ভুল সার্টিফিকেট কনফিগারেশন, নেটওয়ার্কের অনুপলব্ধতা, বা ভুল প্রকল্প কনফিগারেশন।

আপনার সার্ভারে টোকেন পাঠানো

টোকেন পাওয়ার পর, অ্যাপটিকে তা ডেটাবেসে সংরক্ষণের জন্য তাৎক্ষণিকভাবে তার সার্ভারে পাঠানো উচিত। API অনুরোধ টোকেন, ডিভাইস শনাক্তকারী (ম্যাপিংয়ের জন্য), পরিবেশ (sandbox/production), এবং ঐচ্ছিকভাবে অতিরিক্ত ডেটা: OS সংস্করণ, ডিভাইস মডেল, ভাষা অন্তর্ভুক্ত করে। প্রতিটি অ্যাপ লঞ্চে টোকেন পুনরায় পাঠানোর সুপারিশ করা হয় যাতে সার্ভারের কাছে সর্বদা আপ-টু-ডেট টোকেন থাকে।

// অনুমতি অনুরোধ এবং APNS-এ রেজিস্ট্রেশন
func registerForPushNotifications() {
    UNUserNotificationCenter.current()
        .requestAuthorization(options: [.alert, .sound, .badge]) {
        [weak self] granted, error in
        guard granted else {
            print("অনুমতি দেওয়া হয়নি")
            return
        }
        DispatchQueue.main.async {
            UIApplication.shared
                .registerForRemoteNotifications()
        }
    }
}

// APNS থেকে Device Token পাওয়া
func application(
    _ application: UIApplication,
    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
    let tokenString = deviceToken
        .map { String(format: "%02.2hhx", $0) }
        .joined()
    print("Device Token: \(tokenString)")

    // সার্ভারে টোকেন পাঠানো
    PushTokenService.shared
        .sendTokenToServer(tokenString) { success in
        if success {
            UserDefaults.standard.set(tokenString,
                forKey: "lastDeviceToken")
        }
    }
}

সার্ভার সাইড টোকেন ব্যবস্থাপনা

পুশ সিস্টেমের সার্ভার সাইড Device Token ডেটাবেসে সংরক্ষণ করা উচিত, ব্যবহারকারী এবং পরিবেশের সাথে সংযুক্ত। নোটিফিকেশন পাঠানোর সময়, সার্ভার APNS-এ একটি অনুরোধ তৈরি করে, URL-এ টোকেন এবং প্রমাণীকরণের জন্য JWT টোকেন (বা সার্টিফিকেট) অন্তর্ভুক্ত করে। সঠিক টোকেন ব্যবস্থাপনা পুশ নোটিফিকেশন ডেলিভারি হারকে গুরুত্বপূর্ণভাবে প্রভাবিত করে।

টোকেন ডেটাবেস কাঠামো

সার্ভারে টোকেন টেবিলে কমপক্ষে থাকা উচিত: Device Token (অনন্য), ব্যবহারকারী ID, পরিবেশ (sandbox/production), শেষ আপডেটের তারিখ, এবং অবস্থা (সক্রিয়/নিষ্ক্রিয়)। পাঠানোর সময় দ্রুত অনুসন্ধানের জন্য টোকেনে এবং একজন ব্যবহারকারীর সমস্ত ডিভাইসের তালিকা পেতে ব্যবহারকারীর উপর ইনডেক্স যোগ করার সুপারিশ করা হয়। অনেক অ্যাপ একজন ব্যবহারকারীকে একাধিক ডিভাইস রাখতে অনুমতি দেয় — প্রতিটির নিজস্ব টোকেন।

APNS অনুরোধের অনুমোদন

পুশ নোটিফিকেশন পাঠানোর জন্য, সার্ভারকে দুটি উপায়ে APNS-এ অনুরোধ অনুমোদন করতে হবে। সার্টিফিকেট-ভিত্তিক Apple Developer Console-এ জেনারেট করা SSL সার্টিফিকেট ব্যবহার করে। টোকেন-ভিত্তিক .p8 কী সহ JWT (JSON Web Token) ব্যবহার করে যা সার্টিফিকেট নবায়ন না করেই 30 দিন পর্যন্ত বৈধ থাকে। টোকেন-ভিত্তিক অনুমোদন আরও আধুনিক বলে বিবেচিত এবং নতুন প্রকল্পের জন্য Apple দ্বারা সুপারিশকৃত।

HTTP/2 APNS অনুরোধ তৈরি

APNS-এ অনুরোধে HTTP/2 POST পদ্ধতি, পাথ /3/device/{device_token} সহ URL, অনুমোদন হেডার, এবং পেলোড সহ JSON বডি অন্তর্ভুক্ত। apns-topic হেডার অবশ্যই অ্যাপের bundle ID ধারণ করবে। apns-priority ডেলিভারি অগ্রাধিকার নির্দেশ করে (5 — অবিলম্বে, 10 — ব্যাটারি সাশ্রয়ের সাথে)। apns-expiration সেই সময় সেকেন্ডে নির্ধারণ করে যতক্ষণ APNS নোটিফিকেশন ডেলিভার করার চেষ্টা করবে।

// APNS HTTP/2-এর মাধ্যমে Node.js-এ push পাঠানোর উদাহরণ
const http2 = require('http2');
const client = http2.connect('https://api.push.apple.com');

const deviceToken = 'abcdef0123456789...';
const payload = JSON.stringify({
    "aps": { "alert": "Hello!", "sound": "default" }
});

const req = client.request({
    ':method': 'POST',
    ':path': `/3/device/${deviceToken}`,
    'apns-topic': 'com.example.app',
    'apns-priority': '10',
    'apns-expiration': '0',
    'authorization': `bearer ${jwtToken}`
});
req.write(payload);
req.end();
req.on('response', (headers) => {
    if (headers[':status'] === '200') {
        console.log('Push সফলভাবে পাঠানো হয়েছে');
    }
});

ব্যাচ পাঠানো এবং থ্রটলিং

বিপুল সংখ্যক ডিভাইসে পুশ নোটিফিকেশন পাঠানোর সময়, গতি নিয়ন্ত্রণের সাথে ব্যাচ পাঠানো ব্যবহার করুন। APNS সুপারিশ করে প্রতি সংযোগে প্রতি সেকেন্ডে 1500 অনুরোধের বেশি না করতে। সীমা অতিক্রম করলে, Apple সার্ভার 429 Too Many Requests ত্রুটি ফেরত দেয়। বৃহৎ পরিসরের ক্যাম্পেইনের জন্য, একাধিক সংযোগ ব্যবহার করুন এবং ডিভাইস জুড়ে লোড সমানভাবে বিতরণ করুন।

টোকেন আপডেট এবং ইনভ্যালিডেশন

Device Token স্থায়ী নয় এবং বেশ কয়েকটি পরিস্থিতিতে পরিবর্তিত হতে পারে, যার জন্য সার্ভারে একটি আপডেট ব্যবস্থা প্রয়োজন। যদি সার্ভার পুরোনো টোকেনে পুশ পাঠাতে থাকে, APNS 410 Gone ত্রুটি ফেরত দেয়, যা নির্দেশ করে প্রদত্ত পরিবেশের জন্য টোকেনটি আর বৈধ নয়।

কখন টোকেন পরিবর্তিত হয়

Apple এমন বেশ কয়েকটি পরিস্থিতি নথিভুক্ত করে যেখানে Device Token পরিবর্তিত হয়: ব্যবহারকারী অ্যাপ পুনরায় ইনস্টল করে, iCloud ব্যাকআপ থেকে ডিভাইস পুনরুদ্ধার করে, iOS-এর নতুন সংস্করণ ইনস্টল করে, বা নেটওয়ার্ক বা গোপনীয়তা সেটিংস রিসেট করে। প্রতিটি ক্ষেত্রে, অ্যাপ তার পরবর্তী লঞ্চে APNS থেকে একটি নতুন টোকেন পাবে। সার্ভারকে ডেটাবেসে টোকেন আপডেট করা উচিত, পুরোনোটি সরিয়ে নতুনটি সংরক্ষণ করে।

APNS থেকে 410 Gone ত্রুটি পরিচালনা

যখন সার্ভার পুরোনো টোকেনে পুশ পাঠায়, APNS apns-unless-timestamp হেডার সহ HTTP 410 ফেরত দেয়। এই হেডার সেই সময় নির্দেশ করে যার পরে টোকেনটি অবৈধ হয়ে গেছে। সার্ভারকে ডেটাবেসে এই টোকেনটি তাৎক্ষণিকভাবে মুছে ফেলা বা নিষ্ক্রিয় করা উচিত যাতে এতে পুনরায় পাঠানো না হয়। 410 ত্রুটি উপেক্ষা করলে সম্পদ নষ্ট হয় এবং ডেলিভারেবিলিটি হার কমে যায়।

নিষ্ক্রিয় টোকেনের পর্যায়ক্রমিক পরিষ্কার

টোকেন ডেটাবেস আপ-টু-ডেট রাখতে, পর্যায়ক্রমিক পরিষ্কার চালানোর সুপারিশ করা হয়। পরিষ্কার স্ক্রিপ্ট শেষ N দিনের APNS লগ বিশ্লেষণ করে, সমস্ত টোকেন খুঁজে পায় যেগুলো 410 ত্রুটি পেয়েছে, এবং ডেটাবেসে সেগুলো নিষ্ক্রিয় করে। অতিরিক্তভাবে, 90 দিনের বেশি ব্যবহারকারী কার্যকলাপ নেই এমন টোকেন সরানো যেতে পারে — এগুলি অকেজো রেকর্ড যা শুধুমাত্র ডেটাবেসের আকার বাড়ায়।

গণ পাঠানোর আগে টোকেন যাচাইকরণ

পুশ নোটিফিকেশন (নিউজলেটার, প্রোমো ক্যাম্পেইন) গণ পাঠানোর আগে, টোকেনগুলি পূর্ব-যাচাই করার সুপারিশ করা হয়। APNS ব্যাচ টোকেন যাচাইকরণের জন্য সরাসরি API প্রদান করে না, তাই কম অগ্রাধিকার সহ পরীক্ষামূলক পুশ পাঠানো এবং ত্রুটি বিশ্লেষণের কৌশল ব্যবহৃত হয়। 410 ত্রুটি ফেরত দেয় এমন টোকেন মূল পাঠানো থেকে বাদ দেওয়া হয়।

Device Token পাওয়ার জন্য কোড উদাহরণ

আসুন Swift-এ Device Token পাওয়ার সম্পূর্ণ চক্রটি দেখি, ত্রুটি পরিচালনা এবং সার্ভারে পাঠানো সহ। কোড কভার করে অনুমতি অনুরোধ, APNS-এ রেজিস্ট্রেশন, Data-কে হেক্স স্ট্রিং-এ রূপান্তর, ত্রুটি পরিচালনা, এবং ব্যর্থতায় পুনরায় চেষ্টা সহ আপনার নিজের সার্ভারে টোকেন পাঠানো।

import UIKit
import UserNotifications

final class PushNotificationManager: NSObject {

    static let shared = PushNotificationManager()
    private let apiClient = APIClient()
    private var currentToken: String?

    func register() {
        UNUserNotificationCenter.current()
            .requestAuthorization(
                options: [.alert, .badge, .sound]) {
            [weak self] granted, error in
            guard granted else {
                Analytics.log(
                    "Push permission denied")
                return
            }
            DispatchQueue.main.async {
                UIApplication.shared
                    .registerForRemoteNotifications()
            }
        }
    }

    func handleDeviceToken(_ tokenData: Data) {
        let token = tokenData
            .map { String(format: "%02.2hhx", $0) }
            .joined()

        guard token != currentToken else { return }
        currentToken = token
        sendTokenToServer(token)
    }

    func handleRegistrationError(_ error: Error) {
        Analytics.log(
            "Push registration failed: \(error)")

        // নেটওয়ার্ক ত্রুটিতে বিলম্বের পর পুনরায় চেষ্টা
        if let urlError = error as? URLError,
            urlError.code == .notConnectedToInternet {
            DispatchQueue.main.asyncAfter(
                deadline: .now() + 10) { [weak self] in
                self?.register()
            }
        }
    }

    private func sendTokenToServer(_ token: String) {
        let body = PushTokenRequest(
            token: token,
            environment: Environment.current == .debug
                ? "sandbox" : "production",
            osVersion: UIDevice.current.systemVersion,
            locale: Locale.current.identifier
        )
        apiClient.sendToken(body) { [weak self] result in
            if case .success = result {
                self?.currentToken = token
            }
        }
    }
}

রেজিস্ট্রেশনের সময় ত্রুটি পরিচালনা

APNS রেজিস্ট্রেশনের সময় ত্রুটিগুলি বিভিন্ন কারণে ঘটতে পারে। সবচেয়ে সাধারণ মধ্যে নেটওয়ার্কের অনুপলব্ধতা, Xcode-এ ভুল সার্টিফিকেট কনফিগারেশন (যেমন, Push Notifications ক্ষমতা নিষ্ক্রিয়), সিমুলেটর ব্যবহার (যা পুশ সমর্থন করে না), বা ভুল provisioning profile অন্তর্ভুক্ত। প্রোডাকশনে, ত্রুটিগুলি লগ করা এবং সম্ভব হলে, পরবর্তী অ্যাপ লঞ্চে রেজিস্ট্রেশন পুনরায় চেষ্টা করা গুরুত্বপূর্ণ।

সিমুলেটরে Device Token পরীক্ষা

iOS সিমুলেটর বাস্তব Device Token পাওয়া সমর্থন করে না। সিমুলেটরে রেজিস্ট্রেশন পরীক্ষার জন্য, i386 আর্কিটেকচার চেক ব্যবহার করুন: ডিবাগ বিল্ডে, টোকেন প্রাপ্তি সিমুলেট করা যেতে পারে বা মক অবজেক্ট সহ UI পরীক্ষা ব্যবহার করা যেতে পারে। বাস্তব পুশ নোটিফিকেশন পরীক্ষা সবসময় Xcode-এর সাথে সংযুক্ত একটি শারীরিক ডিভাইসে করা হয়।