নেটিভ মোবাইল অ্যাপের জন্য ডিপ লিঙ্ক: রুট, টোকেন, এবং ‘অ্যাপে খুলুন’

ডিপ লিংককে সাধারণ ভাষায় কী করা উচিত\n\nকেউ যখন তাদের ফোনে একটি লিংকে ট্যাপ করে, তারা একই ফলাফল আশা করে: লিংক তাদের সঠিক গন্তব্যে অবিলম্বে নিয়ে যায়। কাছাকাছি কিছু নয়। হোম স্ক্রীন নয়। এমনকি একটা লগইন স্ক্রীন নয় যা তাদের আসার কারণ ভুলে যায়।\n\nএকটি ভালো ডিপ লিংক অভিজ্ঞতা এইরকম দেখতে হবে:\n\n- অ্যাপ ইন্সটল থাকলে, লিংকটি যে স্ক্রীন নির্দেশ করে তাতে খোলে।\n- অ্যাপ ইন্সটল না থাকলে, ট্যাপটি তবুও সাহায্য করে (উদাহরণস্বরূপ, একটি ওয়েব ফলব্যাক বা অ্যাপ স্টোর পেজ খুলে এবং ইনস্টল পর৷ একই গন্তব্যে ফিরিয়ে দেওয়ার পথ রাখতে পারে)।\n- যদি ব্যবহারকারীকে লগইন করতে হয়, তারা একবার লগইন করে উদ্দেশ্যীয় স্ক্রীনে landet, অ্যাপের ডিফল্ট শুরুতে নয়।\n- লিংকে যদি কোনো ক্রিয়া থাকে (ইনভাইট গ্রহণ, অর্ডার দেখা, ইমেল কনফার্ম), তাহলে সেই ক্রিয়াটি স্পষ্ট ও নিরাপদ হওয়া উচিত।\n\nঅধিকাংশ বিরক্তি আসে এমন লিংক থেকে যা “প্রায় কাজ করে” কিন্তু ফ্লো ভেঙে ফেলে। মানুষ ভুল স্ক্রীন দেখেন, তারা যা করছিলো তা হারান, বা লুপে আটকে যান: লিংকে ট্যাপ, লগইন, ড্যাশবোর্ডে landen, আবার লিংকে ট্যাপ, আবার লগইন। এমন এক ধাপেরও অতিরিক্ততা ব্যবহারকারীকে ছেড়ে দেয়ার কারণ হয়ে দাঁড়াতে পারে, বিশেষত একবারের কাজের ক্ষেত্রে যেমন ইনভাইট বা পাসওয়ার্ড রিসেট।\n\nআপনি Kotlin বা SwiftUI কোড লেখার আগে ঠিক করুন লিংকগুলোর মানে কী। বাইরের থেকে কোন কোন স্ক্রীন খোলা যাবে? অ্যাপ বন্ধ থাকলে বনাম চালু থাকলে কি বদলাবে? ব্যবহারকারী লগআউট অবস্থায় থাকলে কী হওয়া উচিত?\n\nএই পরিকল্পনাই পরে অধিকাংশ অসুবিধা রোধ করে: পরিষ্কার রুট, পূর্বানুমেয় “অ্যাপে খুলুন” আচরণ, এবং একবার ব্যবহারযোগ্য কোড হস্তান্তরের নিরাপদ উপায় যা URL-এ গোপনীয়তা রাখে না।\n\n## ডিপ লিংকের ধরন এবং "অ্যাপে খুলুন" কোথায় ভেঙে যায়\n\n“অ্যাপ খুলে দেওয়া” মানে একরকম সবসময় নয়। এগুলো বিনিমেয় মনে করলে ক্লাসিক ব্যর্থতার সম্মুখীন হবেন: লিংকটি ভুল জায়গায় খোলে, ব্রাউজার খুলে দেয় অ্যাপের পরিবর্তে, বা কেবল এক প্ল্যাটফর্মে কাজ করে।\n\nপ্রধান তিনটি ধরণ:\n\n- কাস্টম স্কিম (উদাহরণস্বরূপ, myapp: মত অ্যাপ-নির্দিষ্ট স্কিম)। সেটআপ সহজ, কিন্তু অনেক অ্যাপ ও ব্রাউজার এগুলোকে সাবধানে হ্যান্ডল করে।\n- Universal Links (iOS) ও App Links (Android). এগুলো সাধারণ ওয়েব লিংক ব্যবহার করে এবং অ্যাপ ইন্সটল থাকলে অ্যাপ খুলতে পারে, না থাকলে ওয়েবসাইটে ফলব্যাক দেয়।\n- ইন-অ্যাপ ব্রাউজার লিংক। ইমেল অ্যাপ বা মেসেঞ্জারের বিল্ট-ইন ব্রাউজারে খোলা লিংকগুলো প্রায়ই Safari বা Chrome-র থেকে ভিন্নভাবে আচরণ করে।\n\n"অ্যাপে খুলুন" কোথায় ট্যাপ হচ্ছে তার উপর ভিন্ন অর্থ দিতে পারে। Safari-তে ট্যাপ করা লিংক সরাসরি অ্যাপ-এ লাফিয়ে যেতে পারে। একই লিংক যদি ইমেল বা মেসেঞ্জারের ভিতরের ব্রাউজারে ট্যাপ করা হয়, তবে প্রায়ই এম্বেডেড ওয়েব ভিউতে প্রথমে খুলে এবং ব্যবহারকারীকে অতিরিক্ত “অপেন” বাটন টিপতে হতে পারে (বা তারা কখনোই সেটা না দেখতে পারে)। Android-এ Chrome App Links-কে সম্মান করতে পারে কিন্তু সোশ্যাল অ্যাপের ইন-অ্যাপ ব্রাউজার তা উপেক্ষা করতে পারে।\n\nকল্ড স্টার্ট বনাম অ্যাপ ইতিমধ্যেই চালু থাকা পরের ফাঁদ।\n\n- কল্ড স্টার্ট: OS আপনার অ্যাপ লঞ্চ করে, অ্যাপ ইনিশিয়ালাইজ করে, এবং তারপরই আপনি ডিপ লিংকটি পান। যদি আপনার স্টার্টআপ ফ্লো স্প্ল্যাশ দেখায়, অথ চেক করে বা রিমোট কনফিগ লোড করে, লিংকটি হারিয়ে যেতে পারে যদি আপনি সেটি স্টোর না করেন এবং অ্যাপে প্রস্তুতি হলে পরে রিপ্লে না করেন।\n- ইতিমধ্যেই চালু: আপনি লিংকটি সেশন মাঝেই পান। ন্যাভিগেশন স্ট্যাক থাকে, তাই একই গন্তব্যের জন্য ভিন্ন হ্যান্ডলিং দরকার হতে পারে (স্ক্রীন পুশ করা বনাম স্ট্যাক রিসেট করা)।\n\nএকটি সাধারণ উদাহরণ: Telegram-এ থেকে ট্যাপ করা এক ইনভাইট লিংক প্রায়ই প্রথমে ইন-অ্যাপ ব্রাউজারে খুলে। যদি আপনার অ্যাপ ধরে নেয় যে OS সর্বদা সরাসরি হ্যান্ডঅফ করবে, ব্যবহারকারী একটি ওয়েব পেজ দেখে লিংক ভাঙা ভেবে ফেলবে। এই পরিবেশগুলোর জন্য আগেই পরিকল্পনা করলে পরে কম প্ল্যাটফর্ম-নির্দিষ্ট গ্লু কোড লিখতে হবে।\n\n## কিছুই ইমপ্লিমেন্ট করার আগে আপনার রুটগুলো পরিকল্পনা করুন\n\nঅধিকাংশ ডিপ লিংক বাগ Kotlin বা SwiftUI সমস্যা নয়—এগুলো পরিকল্পনার সমস্যা। লিংকটি পরিষ্কারভাবে একটি স্ক্রীনে মানচিত্রায়িত নয়, বা এটি অনেকগুলো “হয়তো” অপশন বহন করে।\n\nএকটি ধারাবাহিক রুট প্যাটার্ন দিয়ে শুরু করুন যা মানুষের আপনার অ্যাপ সম্পর্কে মনে করে এমন নিয়ম অনুসরণ করে: লিস্ট, ডিটেইল, সেটিংস, চেকআউট, ইনভাইট। এটি পাঠযোগ্য ও স্থিতিশীল রাখুন, কারণ আপনি ইমেইল, QR কোড এবং ওয়েব পেজে এটিকে পুনরায় ব্যবহার করবেন।\n\nএকটি সহজ রুট সেটে থাকতে পারে:\n\n- Home\n- Orders list এবং Order details (orderId)\n- Account settings\n- Invite acceptance (inviteId)\n- Search (query, tab)\n\nতারপর আপনার প্যারামিটারগুলো নির্ধারণ করুন:\n\n- একক অবজেক্টের জন্য IDs ব্যবহার করুন (orderId)।\n- UI স্টেটের জন্য অপশনাল প্যারামিটার ব্যবহার করুন (tab, filter)।\n- ডিফল্ট গুলো ঠিক করুন যাতে প্রতিটি লিংকের একটি শ্রেষ্ঠ গন্তব্য থাকে।\n\nএছাড়াও ঠিক করুন লিংক ভুল হলে কী হবে: ডেটা নেই, অবৈধ ID, বা এমন কন্টেন্ট যা ব্যবহারকারী অ্যাক্সেস করতে পারে না। সবচেয়ে নিরাপদ ডিফল্ট হল নিকটতম স্থিতিশীল স্ক্রীন খুলে একটি ছোট বার্তা দেখানো (যেমন লিস্ট)। ব্যবহারকারীকে খালি স্ক্রীনে বা প্রসঙ্গহীন লগইন স্ক্রীনে ফেলে দেবেন না।\n\nঅবশেষে, উৎস অনুযায়ী পরিকল্পনা করুন। QR কোড সাধারণত একটি সংক্ষিপ্ত রুট প্রয়োজন যা দ্রুত খোলে এবং খারাপ কানেক্টিভিটি সহ্য করে। ইমেল লিংক দীর্ঘ হতে পারে ও অতিরিক্ত প্রসঙ্গ রাখতে পারে। ওয়েব পেজ লিংক gracefully degrade করা উচিত: যদি অ্যাপ ইন্সটল না থাকে, ব্যবহারকারী এমন একটি পেজে যায় যা পরবর্তী করণীয় বোঝায়।\n\nআপনি যদি ব্যাকএন্ড-চালিত পদ্ধতি ব্যবহার করেন (উদাহরণস্বরূপ, API এন্ডপয়েন্ট ও স্ক্রীন জেনারেট করা প্ল্যাটফর্ম হিসেবে AppMaster ব্যবহার করে), এই রুট পরিকল্পনা একটি শেয়ার করা চুক্তিতে পরিণত হয়: অ্যাপ জানে কোথায় যেতে হবে, এবং ব্যাকএন্ড জানে কোন IDs ও স্টেটগুলো বৈধ।\n\n## URL-এ গোপনীয়তা না রেখে নিরাপদ টোকেন হ্যান্ডঅফ\n\nএকটি ডিপ লিংক প্রায়শই নিরাপদ খামে মতো আচরণ করা হয়। কিন্তু তা নয়। URL-এ থাকা যেকোনো কিছু ব্রাউজার ইতিহাস, স্ক্রিনশট, শেয়ারড প্রিভিউ, অ্যানালিটিক্স লগ বা কপি হয়ে চ্যাট-এ পড়ে যেতে পারে।\n\nগোপনীয়তা URL-এ রাখবেন না। এর মধ্যে পড়ে দীর্ঘস্থায়ী অ্যাকসেস টোকেন, রিফ্রেশ টোকেন, পাসওয়ার্ড, ব্যক্তিগত ডেটা বা এমন কিছু যা কাউকে ব্যবহারকারীর মতো কার্যকর হতে দেবে যদি লিংক ফরওয়ার্ড হয়ে যায়।\n\nনিরাপদ পদ্ধতি হল স্বল্প-সময়ের, এক-বার ব্যবহারযোগ্য কোড। লিংকে শুধুমাত্র সেই কোড থাকে, এবং অ্যাপ খোলার পরে এটি প্রতিস্থাপন করে আসল সেশন পান। যদি কেউ লিংক চুরি করে, কোডটি এক মিনিট বা দুই মিনিট পরে বা প্রথম সফল ব্যবহারের পরে অকার্যকর হওয়া উচিত।\n\nএকটি সাধারণ হ্যান্ডঅফ ফ্লো:\n\n- লিংকে একটি এক-বার ব্যবহারযোগ্য কোড থাকে, সেশন টোকেন নয়।\n- অ্যাপ খোলে এবং ব্যাকএন্ডকে কোড রিডিম করার জন্য কল করে।\n- ব্যাকএন্ড মেয়াদ, পূর্বে ব্যবহৃত না হওয়া ইত্যাদি যাচাই করে, তারপর এটিকে ব্যবহার হিসেবে মার্ক করে।\n- ব্যাকএন্ড সাধারণ অথেনটিকেটেড সেশন রিটার্ন করে।\n- অ্যাপ রিডিম করার পরে কোডটি মেমরি থেকে মুছে দেয়।\n\nরিডিম সফল হওয়ার পরও, অ্যাপের ভিতরে কোনো সংবেদনশীল কাজ করার আগে পরিচয় নিশ্চিত করুন। লিংক যদি পেমেন্ট অনুমোদন, ইমেইল পরিবর্তন বা ডেটা এক্সপোর্টের মতো কিছু করে থাকে, তাহলে বায়োমেট্রিক্স বা নতুন লগইন মতো দ্রুত রি-চেক চাইলে নিরাপদ।\n\nপ্রাপ্ত সেশন সুরক্ষিতভাবে সংরক্ষণ করুন। iOS-এ সাধারণত Keychain ব্যবহার করুন। Android-এ Keystore-ব্যাকড স্টোরেজ ব্যবহার করুন। প্রয়োজনীয় তথ্যই রাখুন, লোগআউট, অ্যাকাউন্ট রিমুভ করা বা সন্দেহজনক পুনর্ব্যবহার ধরা পড়লে তা ক্লিয়ার করুন।\n\nএকটি বাস্তবিক উদাহরণ: আপনি কারো কাছে একটি ইনভাইট লিংক পাঠান। লিংকে ১০ মিনিট মেয়াদী এক-বার ব্যবহারযোগ্য কোড থাকে। অ্যাপ সেটি রিডিম করে, তারপর একটি স্ক্রীন দেখায় যা স্পষ্টভাবে বলে কি হবে (কোন ওয়ার্কস্পেসে যোগ দিতে যাচ্ছেন)। ব্যবহারকারী নিশ্চিত করলে যোগ সম্পন্ন হয়।\n\nAppMaster দিয়ে বানালে, এটি একটি এন্ডপয়েন্টে সুন্দরভাবে মানচিত্রিত হয় যা কোড রিডিম করে ও সেশন রিটার্ন করে, এবং আপনার মোবাইল UI নিশ্চিতকরণ ধাপটি হ্যান্ডল করে উচ্চ-প্রভাব অ্যাকশনের আগে।\n\n## অথেনটিকেশন এবং “আপনি যেখানে ছিলেন সেখানে চালিয়ে যাওয়া”\n\nডিপ লিংক প্রায়ই এমন স্ক্রীনে যায় যেখানে ব্যক্তিগত ডেটা থাকে। প্রথমে ঠিক করুন কোনগুলো পাবলিক এবং কোনগুলো প্রোটেকটেড। এই এক সিদ্ধান্ত বেশিরভাগ “টেস্টে কাজ করছিল” ধরণের অপ্রত্যাশা প্রতিহত করে।\n\nএকটি সহজ বিধি: প্রথমে নিরাপদ ল্যান্ডিং স্টেট দেখান, তারপর ব্যবহারকারী অথেনটিকেটেড কি না নিশ্চিত করে প্রোটেকটেড স্ক্রীনে নেভিগেট করুন।\n\n### কী পাবলিক বনাম প্রোটেকটেড সিদ্ধান্ত নেবেন\n\nডিপ লিংককে এমন ধরে নিন যে তা ভুল ব্যক্তির কাছে ফরওয়ার্ড হয়ে যেতে পারে।\n\n- পাবলিক: মার্কেটিং পেজ, হেল্প আর্টিকেল, পাসওয়ার্ড রিসেট শুরু, ইনভাইট অ্যাকসেপ্ট্যান্স শুরু (এখানে কোনো ডেটা দেখাবেন না)\n- প্রোটেকটেড: অর্ডার ডিটেইল, মেসেজ, অ্যাকাউন্ট সেটিংস, অ্যাডমিন স্ক্রীন\n- মিক্সড: একটি প্রিভিউ স্ক্রীন চলবে, কিন্তু লগইন পর্যন্ত শুধু সংবেদনশীল নয় এমন প্লেসহোল্ডার দেখান\n\n### লগইনের পরে ফিরে আসা যাতে সঠিক জায়গায় ফেরে\n\nনির্ভরযোগ্য পদ্ধতি হল: লিংক পার্স করুন, উদ্দেশ্যীয় গন্তব্য সংরক্ষণ করুন, তারপর অথ স্টেট অনুযায়ী রুট করুন।\n\nউদাহরণ: ব্যবহারকারী একটি সাপোর্ট টিকেটের লিংকে ট্যাপ করে যখন লগআউট অবস্থায়। অ্যাপটি একটি নিরপেক্ষ স্ক্রীনে খুলে, তাদের সাইন ইন করতে বলবে, এবং সাইন ইন শেষে সেই টিকিটে স্বয়ংক্রিয়ভাবে নিয়ে যাবে।\n\nনির্ভরযোগ্য রাখতে, একটি ছোট "রিটার্ন টার্গেট" লোকালি স্টোর করুন (রুট নাম ও টিকিট ID) এবং সল্প মেয়াদি এক্সপায়ারেশন রাখুন। লগইন সম্পন্ন হলে একবার পড়ে নেভিগেট করে মুছে ফেলুন। যদি লগইন ব্যর্থ হয় বা টার্গেট মেয়াদোত্তীর্ণ হয়, নিরাপদ হোমে fallback করুন।\n\nকেসগুলো সম্মান করে হ্যান্ডল করুন:\n\n- মেয়াদোত্তীর্ণ সেশন: সংক্ষিপ্ত বার্তা দেখান, পুনরায় অথেনটিকেট করুন, তারপর চালিয়ে নিন।\n- অ্যাক্সেস প্রত্যাহার: গন্তব্যের শেল খুলুন, তারপর “আপনার আর অ্যাক্সেস নেই” দেখান এবং একটি নিরাপদ পরবর্তী ধাপ অফার করুন।\n\nলক স্ক্রীন প্রিভিউ, অ্যাপ সুইচার স্ক্রিনশট বা নোটিফিকেশন প্রিভিউতে ব্যক্তিগত ডেটা দেখাবেন না। ডেটা লোড ও সেশন যাচাই হওয়া পর্যন্ত সংবেদনশীল স্ক্রীনগুলো ফাঁকা রাখুন।\n\n## কাস্টম নেভিগেশন জটলা এড়ানোর জন্য একটি রাউটিং পদ্ধতি\n\nপ্রতিটি স্ক্রীন আলাদা করে URL পার্স করলে ডিপ লিংক জটিল হয়। এতে ছোট সিদ্ধান্তগুলো (কি অপশনাল, কি প্রয়োজনীয়, কি বৈধ) পুরো অ্যাপে ছড়িয়ে পড়ে এবং নিরাপদভাবে পরিবর্তন করা কঠিন হয়ে যায়।\n\nরাউটিংকে শেয়ার করা প্লাম্বিং হিসেবে দেখুন। একটি রুট টেবিল এবং এক পার্সার রাখুন, এবং UI-কে পরিষ্কার ইনপুট দিন।\n\n### একটি শেয়ার করা রুট টেবিল ব্যবহার করুন\n\niOS ও Android-কে একটি মানব-পাঠযোগ্য রুট তালিকায় একমত করান। এটিকে একটি চুক্তি মনে করুন।\n\nপ্রতিটি রুট ম্যাপ করে:\n\n1) একটি স্ক্রীন, এবং\n2) একটি ছোট ইনপুট মডেল।\n\nউদাহরণ: “Order details” একটি Order স্ক্রীনে ম্যাপ করে যার ইনপুট হতে পারে OrderRouteInput(id)। যদি রুটে অতিরিক্ত মান দরকার (যেমন ref source), সেগুলো ইনপুট মডেলে থাকা উচিত, না ভিউ কোডে ছড়িয়ে।\n\n### পার্সিং ও ভ্যালিডেশন কেন্দ্রীভূত করুন\n\nপার্সিং, ডিকোডিং ও ভ্যালিডেশন এক জায়গায় রাখুন। UI-কে জিজ্ঞেস করা উচিত নয় “এই টোকেন আছে কি?” বা “এই ID বৈধ?”—একে একটি বৈধ রুট ইনপুট বা একটি স্পষ্ট এরর স্টেট দিন।\n\nএকটি বাস্তবিক ফ্লো:\n\n- URL গ্রহণ করুন (ট্যাপ, স্ক্যান, শেয়ার শিট)\n- এটিকে একটি পরিচিত রুটে পার্স করুন\n- প্রয়োজনীয় ফিল্ড ও ফরম্যাট ভ্যালিডেট করুন\n- একটি স্ক্রীন টার্গেট ও ইনপুট মডেল তৈরি করুন\n- একটি একক এন্ট্রি পয়েন্ট দিয়ে নেভিগেট করুন\n\nএকটি “অজানা লিংক” ফালব্যাক স্ক্রীন যোগ করুন। সেটি ডেড এন্ড নয়—দেখান কী খোলা যায়নি, সাধারণ ভাষায় বলুন কেন, এবং পরবর্তী কার্যকরী অপশন দিন যেমন Home, সার্চ বা সাইন ইন।\n\n## স্টেপ বাই স্টেপ: ডিপ লিংক ও "অ্যাপে খুলুন" আচরণ ডিজাইন করা\n\nভালো ডিপ লিংকটি বিরক্তিকরভাবে সাধারণ মনে হয়—মানুষ ট্যাপ করে সঠিক স্ক্রীনে landen, অ্যাপ ইন্সটল থাকুক বা না থাকুক।\n\n### স্টেপ 1: গুরুত্বপূর্ণ এন্ট্রি পয়েন্ট নির্বাচন করুন\n\nশুরুতে টেনটি লিংক টাইপ লিস্ট করুন যা মানুষ বাস্তবেই ব্যবহার করে: ইনভাইট, পাসওয়ার্ড রিসেট, অর্ডার রসিদ, “টিকিট দেখুন” লিংক, প্রচার লিংক। ইচ্ছাকৃতভাবে সংখ্যা কম রাখুন।\n\n### স্টেপ 2: প্যাটার্নগুলো একটি চুক্তির মতো লিখুন\n\nপ্রতিটি এন্ট্রি পয়েন্টের জন্য একটি ক্যানোনিক্যাল প্যাটার্ন ও খোলার জন্য ন্যূনতম ডেটা নির্ধারণ করুন। স্থিতিশীল IDs-কে নামের উপরে অগ্রাধিকার দিন। নির্ধারণ করুন কি বাধ্যতামূলক এবং কি অপশনাল।\n\nসহজ নিয়ম:\n\n- প্রতি রুটে একটি উদ্দেশ্য।\n- বাধ্যতামূলক প্যারামিটার সবসময় উপস্থিত থাকে; অপশনালগুলো নিরাপদ ডিফল্ট রাখে।\n- iOS (SwiftUI) ও Android (Kotlin)-এ একই প্যাটার্ন ব্যবহার করুন।\n- যদি পরিবর্তনের আশা থাকে, সহজ ভার্সন প্রিফিক্স (যেমন v1) সংরক্ষণ করুন।\n- প্যারামিটার মিসিং হলে কি হবে তা সংজ্ঞায়িত করুন (এরর স্ক্রীন দেখান, ব্ল্যাঙ্ক না)।\n\n### স্টেপ 3: লগইন আচরণ ও পোস্ট-লগইন টার্গেট নির্ধারণ করুন\n\nপ্রতিটি লিংক টাইপ অনুযায়ী লিখে রাখুন লগইন দরকার কি না। যদি দরকার হয়, টার্গেট মনে রাখুন এবং লগইন পরে চালিয়ে যান।\n\nউদাহরণ: একটি রসিদ লিংক লগইন ছাড়া প্রিভিউ দেখাতে পারে, কিন্তু “ডাউনলোড ইনভয়েস” করলে লগইন দরকার এবং ব্যবহারকারীকে ঠিক ঐ রসিদে ফেরত পাঠাতে হবে।\n\n### স্টেপ 4: টোকেন হ্যান্ডঅফ নিয়ম নির্ধারণ করুন (গোপনীয়তা URL-এ রাখবেন না)\n\nলিংক যদি এক-বার ব্যবহারযোগ্য টোকেন প্রয়োজন করে, নির্ধারণ করুন তার মেয়াদ ও কীভাবে এটি ব্যবহার করা যাবে।\n\nবাস্তবিক পদ্ধতি: URL-এ স্বল্প-সময়ের, একবার-ব্যবহারযোগ্য কোড রাখুন, এবং অ্যাপ সেটি ব্যাকএন্ডে এক্সচেঞ্জ করে বাস্তব সেশন পায়।\n\n### স্টেপ 5: তিনটি বাস্তব-দুনিয়ার স্টেট টেস্ট করুন\n\nডিপ লিংক প্রান্তে ভেঙে যায়। প্রতিটি লিংক টাইপ নিচের তিন কন্ডিশনে টেস্ট করুন:\n\n- কল্ড স্টার্ট (অ্যাপ বন্ধ)\n- ওয়ার্ম স্টার্ট (অ্যাপ মেমরিতে)\n- অ্যাপ ইন্সটল নেই (লিংক তবুও অর্থপূর্ণ জায়গায় যায়)\n\nরুট, অথ চেক ও টোকেন এক্সচেঞ্জ নিয়মগুলো এক জায়গায় রাখলে Kotlin ও SwiftUI স্ক্রীন জুড়ে কাস্টম লজিক ছড়িয়ে পড়বে না।\n\n## ডিপ লিঙ্ক ভাঙিয়ে দেয় এমন সাধারণ ভুলসমূহ (এবং কিভাবে এড়াবেন)\n\nডিপ লিংক সাধারণত বিরক্তিকর কারণে ব্যর্থ হয়: একটি ছোট অনুমান, একটি রিনেম করা স্ক্রীন, বা একটি “অস্থায়ী” টোকেন যা সব জায়গায় ছড়িয়ে পড়ে।\n\n### মাঠে দেখা ব্যর্থতা ও তাদের সমাধান\n\n- URL-এ অ্যাকসেস টোকেন রাখা (এবং তাদের লগ হওয়া)। কুয়েরি স্ট্রিং কপি, শেয়ার, ব্রাউজার ইতিহাস এবং ক্র্যাশ লগে পড়ে যায়। সমাধান: লিংকে কেবল স্বল্পকালীন, একবার ব্যবহারযোগ্য কোড রাখুন, অ্যাপের ভিতরে রিডিম করুন, এবং দ্রুত অবৈধ করে দিন।\n\n- অ্যাসাম করা যে অ্যাপ ইন্সটল আছে (ফলব্যাক নেই)। লিংক কোনো ত্রুটি পেজে যায় অথবা কিছুই করে না—ব্যবহারকারী ছেড়ে দেয়। সমাধান: একটি ফলব্যাক ওয়েব পেজ দিন যা কি হবে বলে এবং ইনস্টল পাথ অফার করে। একটি সাধারণ “অ্যাপ খুলে চালিয়ে যান” পেজও নীরবতার থেকে ভালো।\n\n- একই ডিভাইসে একাধিক অ্যাকাউন্ট না হ্যান্ডল করা। ভুল ব্যবহারকারীর জন্য সঠিক স্ক্রীন খুলে দেওয়া ভাঙা লিংকের থেকেও খারাপ। সমাধান: লিংক পাওয়া গেলে চেক করুন কোন অ্যাকাউন্ট একটিভ, ব্যবহারকারীকে কনফার্ম বা অ্যাকাউন্ট সুইচের অপশন দিন, তারপর চালিয়ে যান। যদি অ্যাকশন নির্দিষ্ট ওয়ার্কস্পেস চায়, ওয়ার্কস্পেস শনাক্তকরণ (সিক্রেট নয়) যোগ করুন ও ভ্যালিডেট করুন।\n\n- স্ক্রীন বা রুট বদলালে লিংক ব্রোক হয়ে যায়। যদি রুট UI নামের সাথে জড়িত থাকে, ট্যাবের নাম পাল্টালে পুরনো লিংক কাজ বন্ধ করে দেয়। সমাধান: স্থিতিশীল, উদ্দেশ্যভিত্তিক রুট ডিজাইন করুন (invite, ticket, order) এবং পুরনো ভার্সনগুলোও কাজ করে রাখুন।\n\n- কিছু ভুল হলে ট্রেসযোগ্যতা নেই। পুনরায় প্লে করার উপায় না থাকলে সাপোর্ট অনুমান ছাড়া কাজ করে। সমাধান: লিংকে অ-সংবেদনশীল রিকোয়েস্ট আইডি রাখুন, সার্ভার ও অ্যাপে লগ করুন, এবং ত্রুটির বার্তায় সেই আইডি দেখান।\n\nএকটি বাস্তবতা পরীক্ষা: একটি ইনভাইট লিংক গ্রুপ চ্যাটে পাঠানো হয়েছে। কেউ এটি একটি ওয়ার্ক ফোনে খুলে যার দুটি অ্যাকাউন্ট আছে, তাদের ট্যাবলেটে অ্যাপ নেই, এবং লিংকটি একজন সহকর্মীর কাছে ফরওয়ার্ড করা হয়। যদি লিংকে কেবল ইনভাইট কোড থাকে, ফলব্যাক আচরণ সহ থাকে, সঠিক অ্যাকাউন্ট চাওয়া হয়, এবং একটি রিকোয়েস্ট আইডি লগ করা হয়—তাহলে এমন একক লিংক সব পরিস্থিতিতেই সফল হতে পারে গোপনীয়তা ছাড়াই।\n\n## উদাহরণ: এমন একটি ইনভাইট লিংক যা প্রতিবার সঠিক স্ক্রীন খুলে\n\nইনভাইটগুলি ডিপ লিংকের ক্লাসিক উদাহরণ: কেউ একজন টিমমেটকে মেসেঞ্জারে লিংক পাঠায়, প্রাপক এক ট্যাপে আশা করে ইনভাইট স্ক্রীনে পৌছবে, না একটি জেনেরিক হোমে।\n\nপরিবেশ: একটি ম্যানেজার “Support Team” ওয়ার্কস্পেসে নতুন সাপোর্ট এজেন্টকে আমন্ত্রণ জানায়। এজেন্ট Telegram-এ ইনভাইট ট্যাপ করে।\n\nঅ্যাপ ইন্সটল থাকলে, সিস্টেম অ্যাপ খুলে ইনভাইট ডিটেইলস পাঠানো উচিত। অ্যাপ না থাকলে, ব্যবহারকারী একটি সাদামাটা ওয়েব পেজে যায় যা ইনভাইটের উদ্দেশ্য বোঝায় এবং ইনস্টল পাথ দেয়। ইনস্টল ও প্রথম লঞ্চের পরও অ্যাপ ইনভাইট ফ্লো শেষ করতে সক্ষম হওয়া উচিত যাতে ব্যবহারকারী লিংক খুঁজে বেড়াতে না হয়।\n\nঅ্যাপের ভিতরে Kotlin ও SwiftUI-এ ফ্লো একই:\n\n- ইনকামিং লিংক থেকে ইনভাইট কোড পড়ুন।\n- ব্যবহারকারী লগ ইন আছে কি না চেক করুন।\n- ব্যাকএন্ডে ইনভাইট ভেরিফাই করুন, তারপর সঠিক স্ক্রীনে রুট করুন।\n\nভেরিফিকেশনই মূল। লিংকে দীর্ঘস্থায়ী সেশন টোকেন রাখা ঠিক না। বরং এটি এমন একটি স্বল্প-সময়ের কোড বহন করবে যা সার্ভার ভেরিফাই করার পরে কাজে লাগে।\n\nব্যবহারকারীর অভিজ্ঞতা_predictable হওয়া উচিত:\n\n- লগইন না করা: তারা একটি লগইন স্ক্রীন দেখবে, তারপর লগইন শেষে ইনভাইট অ্যাকসেপ্ট্যান্সে ফিরে আসবে।\n- লগইন করা: তারা একটি “Join workspace” কনফার্মেশন দেখবে, তারপর সঠিক ওয়ার্কস্পেসে landen।\n\nইনভাইট মেয়াদোত্তীর্ণ বা ব্যবহার済 হলে ব্যবহারকারীকে খালি এরর পেজে ফেলে দেবেন না। স্পষ্ট বার্তা ও পরবর্তী বিকল্প দেখান: নতুন ইনভাইট অনুরোধ করুন, অ্যাকাউント পরিবর্তন করুন বা অ্যাডমিনের সাথে যোগাযোগ করুন। “This invite was already accepted” টেক্সটটি “Invalid token” এর চেয়ে ব্যবহারকারীর জন্য ভালো।\n\n## দ্রুত চেকলিস্ট ও পরবর্তী পদক্ষেপ\n\nডিপ লিংক তখনই “সম্পন্ন” মনে হয় যখন সেগুলো সব জায়গায় একইভাবে আচরণ করে: কল্ড স্টার্ট, ওয়ার্ম স্টার্ট, এবং যখন ব্যবহারকারী ইতিমধ্যেই সাইন ইন করেছে।\n\n### দ্রুত চেকলিস্ট\n\nশিপ করার আগে প্রতিটি আইটেম রিয়েল ডিভাইসে ও OS ভার্শনে টেস্ট করুন:\n\n- লিংক কল্ড স্টার্ট ও ওয়ার্ম স্টার্টে সঠিক স্ক্রীন খোলে।\n- URL-এ কিছুই সংবেদনশীল নেই। যদি টোকেন বাধ্যতামূলক হয়, সেটি স্বল্প-মেয়াদি ও একবার-ব্যবহারযোগ্য রাখুন।\n- অজ্ঞাত, মেয়াদোত্তীর্ণ বা ব্যবহার-হওয়া লিংকগুলো পরিষ্কার স্ক্রীনে ফallback করে এবং সহায়ক পরবর্তী পদক্ষেপ দেয়।\n- এটি ইমেল অ্যাপ, ব্রাউজার, QR স্ক্যানার ও মেসেঞ্জার প্রিভিউ থেকে কাজ করে (কিছু আগে থেকেই লিংক ওপেন করে)।\n- লগিং জানায় কি ঘটেছে (লিংক পাওয়া গেছে, রুট পার্স করা হয়েছে, অথ প্রয়োজন, সাফল্য বা ব্যর্থতার কারণ)।\n\nএকটি সহজ ভেরিফিকেশন পদ্ধতি হল কয়েকটি অবশ্যই-চলবে এমন লিংক নির্বাচন করা (ইনভাইট, পাসওয়ার্ড রিসেট, অর্ডার ডিটেইল, সাপোর্ট টিকেট, প্রচার) এবং সেগুলো একই টেস্ট ফ্লো দিয়ে চালানো: ইমেল থেকে ট্যাপ, চ্যাট থেকে ট্যাপ, QR স্ক্যান, পুনরায় ইনস্টল করার পরে ওপেন।\n\n### পরবর্তী পদক্ষেপ (রক্ষণাবেক্ষণযোগ্য রাখুন)\n\nডিপ লিংক স্ক্রিন জুড়ে ছড়াতে শুরু করলে রাউটিং ও অথকে শেয়ার করা প্লাম্বিং হিসেবে দেখুন, প্রতিটি-স্ক্রীন কোড নয়। রুট পার্সিংকে কেন্দ্রীভূত করুন এবং প্রতিটি গন্তব্যে ক্লিন প্যারামিটার পাঠান (কাঁচা URL নয়)। অথের জন্যও একই জিনিস: একটি গেট যা সিদ্ধান্ত নেয় “এখন চালিয়ে যাক” বনাম “প্রথমে সাইন ইন করুন, তারপর চালিয়ে যান”।\n\nকাস্টম গ্লু কোড কমাতে ব্যাকএন্ড, অথ এবং মোবাইল একসাথে বানানো সাহায্য করে। AppMaster (appmaster.io) একটি নো-কোড প্ল্যাটফর্ম যা প্রোডাকশন-রেডি ব্যাকএন্ড ও নেটিভ মোবাইল অ্যাপ জেনারেট করতে পারে, যা রুট নাম ও এক-বার কোড রিডেম্পশন এন্ডপয়েন্টগুলো পরিবর্তনের সাথে সামঞ্জস্য রাখা সহজ করে।\n\nপরের সপ্তাহে যদি একটি কাজ করতে চান, এটি করুন: আপনার ক্যানোনিক্যাল রুটগুলো লিখে রাখুন এবং প্রতিটি ব্যর্থতার ক্ষেত্রে এক্সপ্লিসিট ফলব্যাক আচরণ সংজ্ঞায়িত করুন, তারপর সেই নিয়মগুলো একটি একক রাউটিং লেয়ারে ইমপ্লিমেন্ট করুন।