দুই দশক ধরে Google Play অ্যাপকে Jetpack Compose-এ মাইগ্রেট করা

সবাইকে স্বাগত!

আমার নাম জন।

আমি Google Play Store টিম থেকে আপনার সাথে যোগাযোগ করছি।

ইনি আমার সহকর্মী কিরিল।

ভিউ ও ফ্র্যাগমেন্ট সিস্টেম থেকে কম্পোজে আমরা কীভাবে অনেক কোড সরিয়ে নিয়ে এসেছি, সেই বিষয়ে আজ আমরা কথা বলব।

আসুন শুরু করা যাক।

তাহলে, সেই অ্যাডপশন কীভাবে হয়েছিল এবং তার স্কেল কেমন ছিল?

তাই, আমাদের অ্যাপ কোডবেসের জন্য, এটি ২০০৭ সাল থেকে সত্যিই অর্গানিকভাবে বৃদ্ধি পেয়েছে।

আমাদের কাছে কয়েক মিলিয়ন প্রোডাকশন কোড, ২০০টি স্ক্রিন এবং ৫০০টি অনন্য UI কম্পোনেন্ট আছে যা বিভিন্ন স্ক্রিনে ব্যবহার করা হয়।

২০২০ সালে আমরা সিদ্ধান্ত নিয়েছিলাম যে, ডেভেলপার ভেলোসিটি, নির্ভরযোগ্যতা এবং পারফর্ম্যান্স আমাদের কাঙ্খিত লক্ষ্যে পৌঁছাতে পারছে না।

তাই আমরা একটি আধুনিক UI টেক স্ট্যাক গ্রহণ করার সিদ্ধান্ত নিয়েছি।

আমরা বিভিন্ন লাইব্রেরি মূল্যায়ন করেছি।

AndroidX-এর কিছু বন্ধুও সেই সময় আমাদের সাথে Compose সম্পর্কে কথা বলছিলেন এবং আমরা Compose গ্রহণ করার সিদ্ধান্ত নিই এবং Compose-এর প্রথম প্রধান পার্টনার হয়ে উঠি।

সবকিছু কেমন হল?

ছয় বছর পরে, এখন Play Store অ্যাপে ব্যবহারকারীর ইম্প্রেশনের ৯৭% শুধুমাত্র Compose-এর মাধ্যমে তৈরি করা স্ক্রিনে হয়।

সব, দুঃখিত, ২০২০ সাল থেকে সমস্ত ফোন এবং বড় স্ক্রিনের ডেভেলপমেন্ট শুধুমাত্র কম্পোজে স্থানান্তরিত হয়েছে।

এমনকি আমাদের এক্সটেন্ডেড ফর্ম ফ্যাক্টর, XR, TV, Auto, Wear, ২০২৫ সাল থেকে Compose-এ চলে গেছে।

And Compose has been a really strong proponent of that success and why we've continued to adopt more and more.

তাদের কাছে একটি খুব শক্তিশালী, ব্যাপক টেস্ট স্যুট ছিল যা আমাদের সপ্তাহে দুবার Compose-এর নতুন ভার্সন গ্রহণ করতে সাহায্য করেছে।

তাদের আলফা বিল্ড এবং নতুন API-এর সুবিধা নিয়ে, এটি আমাদের নতুন ত্রুটি সমাধান, নতুন পারফর্ম্যান্সের উন্নতি এবং সত্যিই সেই নতুন API-এর কিছু এক্সপ্লোর করতে এবং নতুন ব্যবহারকারীর অভিজ্ঞতা প্রদান করতে সাহায্য করে।

বিশেষ করে পারফর্ম্যান্সের কথা বলতে গেলে, Compose আমাদের অ্যাপের সমস্ত প্রধান স্ক্রিন জুড়ে ক্রমাগত জ্যাঙ্ক পারফর্ম্যান্স প্রদান করেছে।

এটি হল সার্চ ফলাফল পৃষ্ঠা, হোম পৃষ্ঠা, বিবরণ পৃষ্ঠা।

আমাদের ব্যবসা এবং ব্যবহারকারীর অভিজ্ঞতার জন্য পারফর্ম্যান্স, জ্যাঙ্ক এবং লোড লেটেন্সি খুবই গুরুত্বপূর্ণ মেট্রিক।

তাই আমরা গত ১৪ মাসে ৩০% উন্নতি দেখেছি।

কিন্তু আমরা এখানে এলাম কীভাবে?

আমরা আসলে এই বিষয়েই কথা বলতে চাই।

তাহলে, মাইগ্রেশন প্ল্যান সম্পর্কে আলোচনা করা যাক।

তাই, Play একাধিক ধাপের পদ্ধতি গ্রহণ করেছে।

আমরা সব কিছু একবারে করতে চাইনি, তাই সব ডিম এক ঝুড়িতে রাখিনি।

আমরা ঝুঁকিগুলি বুঝতে, আমাদের ব্যবসায় এটি কীভাবে প্রভাব ফেলে তা জানতে এবং সম্পূর্ণভাবে শুরু করার আগে আত্মবিশ্বাস তৈরি করতে কয়েকটি পদক্ষেপ নিয়েছি।

তাই, আমি সেগুলির নাম দেব: হামাগুড়ি দেওয়া, হাঁটা, জগিং করা এবং দৌড়ানো।

তাই আমাদের জন্য ক্রলিং ছিল Compose-এর সাথে পরিচিতি গড়ে তোলা।

আমরা কম ট্রাফিক আছে এমন পৃষ্ঠা দিয়ে শুরু করেছি।

এটি সেটিংস পৃষ্ঠা, থার্ড-পার্টি লাইসেন্স, এই ধরনের কিছু হতে পারে।

Compose লাইব্রেরির সাথে পরিচিতি গড়ে তোলাই আপনার মূল লক্ষ্য।

তাই, সারি, কলাম, টেক্সট, ছবি, এই ধরনের সব কিছুতে অভ্যস্ত হতে এটি সাহায্য করতে পারে।

তারপর আপনাকে অ্যাপের সব ইনফ্রাস্ট্রাকচার নিয়ে আসতে হবে এবং বুঝতে হবে যে Compose-এর মাধ্যমে এটি কীভাবে কাজ করে।

তাই এটি ইম্প্রেশন লগিং, ক্লিক লগিং, থিমিং হতে পারে, আমরা একই সাথে ডেটা লোডিং রিভ্যাম্প করছিলাম।

তাই এই সব জিনিসই।

এবং একটি নির্দিষ্ট জিনিস যা আমরা সহায়ক বলে মনে করেছি তা হল আমাদের সমস্ত স্ক্রিন যাতে একই রকম দেখায় তা নিশ্চিত করা, আমরা কিছু ইউনিট টেস্ট এবং ফাংশনাল টেস্ট তৈরি করেছি যাতে Compose-এ আমাদের থিমিং অবজেক্টগুলি সরাসরি XML স্টাইল, টাইপোগ্রাফি, রঙ, এই সমস্ত কিছুর সাথে ম্যাপ করা হয়েছে কিনা তা চেক করা যায়।

তাই আমরা একবার পরিচিত হয়ে গেলে এবং স্বাচ্ছন্দ্য বোধ করলে, আমরা হাঁটার সিদ্ধান্ত নিয়েছিলাম।

আমাদের জন্য এটি ছিল খুব বেশি ট্রাফিক থাকা স্ক্রিনে একটি ছোট কম্পোনেন্ট নেওয়া এবং সেই ধরনের মাইগ্রেশন কেমন দেখায় তা মূল্যায়ন করা।

আমরা RecyclerView-এ থাকা কোনও আইটেম নেওয়ার সাজেশন দেব, যাতে আপনি View ও Compose সিস্টেমের মধ্যে মানানসই হওয়ার ব্যাপারে কোনও সমস্যা থাকলে তা বুঝতে পারেন এবং সেইসাথে পারফর্ম্যান্স ও জ্যাঙ্ক পরিমাপ করতে পারেন।

কম্পোনেন্টটি খুব জটিল হতে হবে না, তবে আপনি এমন কিছু চান যা লেআউট, টেক্সট, ছবি এবং এই ধরনের জিনিসগুলি ব্যবহার করে, যা আপনি সাধারণত দেখেন তার থেকে কিছুটা আলাদা।

একটি জিনিস যা আপনার লক্ষ্য করা উচিত এবং সম্ভবত এই ক্ষেত্রে আশা করা উচিত তা হল জ্যাঙ্ক এবং লেটেন্সি কিছুটা বৃদ্ধি, এটি সামান্য হবে, তবে এটি কারণ আপনি এখন দুটি স্ট্যাক চালাচ্ছেন।

আপনার কাছে একটি রেন্ডারিং স্ট্যাক আছে যা Compose-এ এবং আরেকটি Views-এ আছে।

তাই কিছু মেমরি থ্র্যাশিং, কিছু অতিরিক্ত ক্লাস লোডিং, এই সব জিনিস হতে চলেছে।

তবে, আপনি যত বেশি Compose ব্যবহার করবেন, তত বেশি এই সমস্যা দূর হবে।

আর এর মধ্যে যদি আপনার সত্যিই এটির প্রয়োজন হয়, তাহলে আপনি সেই স্ক্রিনটি কিছুটা প্রি-ওয়ার্ম করতে পারেন যাতে এটি লাইনে আনতে এবং স্বল্প মেয়াদে সেই খরচ কমাতে সাহায্য করে।

তাই হাঁটার পরে, আমরা জগিংয়ে চলে যাই।

তাই, আমরা যখন খুব, খুব স্বাচ্ছন্দ্য বোধ করি, তখন এটি করি।

কোনও একটি বেশি ট্রাফিক থাকা পৃষ্ঠার একটি কম্পোনেন্ট পরীক্ষা করার পরিবর্তে, পুরো পৃষ্ঠাটিই পরীক্ষা করুন।

তাই আমরা যা করেছি তা হল, আমরা এখনও নেভিগেশন লাইব্রেরি এবং ফ্র্যাগমেন্ট ব্যবহার করেছি, কিন্তু প্রতিটি পৃথক স্ক্রিনের জন্য, এটি সম্পূর্ণরূপে Compose-এ প্রয়োগ করা হয়েছে।

আমরা শুধু Fragment-কে ComposeView ফিরিয়ে দিতে বলেছি।

তাই, আপনি উন্নত লেটেন্সি ও জ্যাঙ্ক আশা করতে পারেন।

আমি যে মেমরি থ্র্যাশিং এবং ক্লাস লোডিংয়ের কথা বলছিলাম, আপনার ক্ষেত্রে তা ততটা হচ্ছে না।

এবং Compose নিজেই ComposeView লেভেলে কিছু লেভেলের ক্যাশিং করে।

তাই, আপনার কাছে যদি এমন একটি RecyclerView থাকে যাতে অনেকগুলি কার্ড আছে এবং সেগুলি দেখতে একই রকম এবং সেগুলিতে একই আইকন থাকতে পারে, তাহলে সেই সমস্ত আইকন পার্সিং এবং রিসোর্স ব্যবহার ComposeView-এর সবকিছুর মধ্যে শেয়ার করা হয়।

তাই, এর পরে আমরা দৌড়ানো শুরু করি।

তাই, এই সময় আপনি সত্যিই সব ধরনের কন্টেন্ট উপভোগ করেন।

Compose-এ আপনার অ্যাপ থেকে বেশিরভাগ ট্রাফিক পাওয়ার পরে, আমরা এক লেভেল উপরে উঠেছি।

তাই উপরের স্ক্রিনে, আমাদের কাছে অ্যাক্টিভিটি আছে।

তাই ComposeView-কে অ্যাক্টিভিটি রুটে সরান।

এবং আপনার অনেক কোড তুলনামূলকভাবে একই রকম দেখাবে।

আপনি এখনও নেভিগেশন সংক্রান্ত নির্দেশ দেওয়ার চেষ্টা করছেন যেখানে আপনি বলতে চান, এক স্ক্রিন থেকে অন্য স্ক্রিনে যান।

কিন্তু ফ্র্যাগমেন্ট ট্রানজ্যাকশন করার পরিবর্তে, আপনি একটি কম্পোজেবল ফাংশন কল করছেন।

আপনি Nav2 লাইব্রেরি বা Nav3 লাইব্রেরির মধ্যে যেটি বেছে নেবেন, তার উপরেই এটি করতে পারবেন।

আমাদের ক্ষেত্রে, আমরা সব স্ক্রিন মাইগ্রেট করিনি।

আমি তো বলেইছিলাম যে আমাদের কাছে অনেক আছে।

তাই আমরা ফ্র্যাগমেন্ট কম্প্যাটিবিলিটি তৈরি করেছি যেখানে আপনি ফ্র্যাগমেন্ট-ভিত্তিক স্ক্রিন পেতে পারেন এবং এটি করার জন্য Compose-এর AndroidFragment র‍্যাপার ব্যবহার করতে পারেন।

আপনি আবার কী আশা করতে পারেন, আবার, জ্যাঙ্ক এবং লেটেন্সি আমাদের ব্যবসার জন্য গুরুত্বপূর্ণ, তাই আমরা শুধু সেই খামটি পুশ করতে থাকি এবং আপনি এটি উন্নত করতে দেখতে থাকেন কারণ এখন আমাদের স্ক্রিন জুড়ে ক্যাশিং আছে এবং এই মেমরি থ্র্যাশিং সমস্যা অনেক কম।

তবে আপনি নতুন নতুন সুবিধাও পাবেন।

এই GIF-এর ডানদিকে আমরা এর একটি উদাহরণ দিয়েছি যেখানে আপনি স্ক্রিনের মধ্যে শেয়ার করা এলিমেন্ট ট্রানজিশন করতে পারবেন।

তাই আমাদের কাছে একটি ছবি আছে যা আপনি এক স্ক্রিন থেকে অন্য স্ক্রিনে যাওয়ার সময় আমরা বড় করে দেখাই এবং এটি সেই ধারাবাহিকতা প্রদান করে।

এছাড়াও, আপনি পুরো ট্রানজিশন করার সময় Compose-এর সমস্ত অ্যানিমেশন নমনীয়তার সুবিধা নিতে পারেন।

আর এর সাথে, আমি কিরিলকে আরও কিছু ক্ষমতা সম্পর্কে কথা বলার জন্য এটি হস্তান্তর করব।

ধন্যবাদ, জন।

আমি এমন একটি বিষয় নিয়ে একটু কথা বলতে চাই যা আমার হৃদয়ের খুব কাছাকাছি এবং প্রিয়, যা হল Android অ্যাপের থিমিং এবং স্টাইলিং, এমন কিছু যা আমি এখন কিছু সময়ের জন্য করছি।

ভিউ ওয়ার্ল্ডে, জাভা কোড এবং একটু পরে কোটলিন কোড ছিল এবং তারপরে X-- XML রিসোর্স, যেমন রঙ, স্ট্রিং, ডাইমেনশন, লেআউট এবং থিম ও স্টাইল ছিল।

এবং এটি যেভাবে কাজ করেছিল তা হল এই সমস্ত XML রিসোর্স একটি রিসোর্স টেবিলে কম্পাইল করা হয়েছিল যা APK-তে অন্তর্ভুক্ত ছিল এবং এটি অনেকটাই স্ট্যাটিক ছিল।

একটি API Resources.Theme.applyStyle আছে যা আপনি রানটাইমে ডাইনামিকভাবে ব্যবহার করে UI হায়ারার্কির উপরে কাস্টম স্টাইলিং প্রয়োগ করতে পারেন।

সবচেয়ে বড় সীমাবদ্ধতা ছিল বা আছে যে আপনার কন্টেন্ট ইনফ্লেট করার আগে আপনাকে এটি করতে হবে, যার অর্থ হল আপনি যদি কোনও বিদ্যমান UI-তে ডাইনামিকভাবে সেই স্টাইলিং প্রয়োগ করতে চান, তাহলে আপনাকে পুরো অ্যাক্টিভিটিটি ভেঙে ফেলতে হবে এবং আবার তৈরি করতে হবে, যা ব্যবহারকারীর অভিজ্ঞতার জন্য ভালো ছিল না।

এছাড়াও, যেহেতু এটি এই প্রি-কম্পাইল করা XML ব্লকগুলি প্রয়োগ করছিল, তাই আপনার এক্সপেরিমেন্ট ফ্ল্যাগ বা অন্য কোনও ব্যবসায়িক প্রয়োজনের উপর ভিত্তি করে একে অপরের উপরে একাধিক শর্তসাপেক্ষ ডাইনামিক ওভারলে একত্রিত করা কঠিন হয়ে উঠছিল।

XML-এর দুনিয়ায় স্টাইল হায়ারার্কির সঠিক মেন্টাল মডেল তৈরি করা কিছুটা কঠিন ছিল।

এবং অবশেষে, Android Studio বা অন্য কোনও ডেভেলপমেন্ট টুলে এমন কোনও একক ইউনিফায়েড ভিউ ছিল না যা আপনাকে Java, কোড এবং XML-এর মধ্যে ব্যবধান কমাতে সাহায্য করে।

আর, আমার স্টাইল কেন প্রয়োগ করা হচ্ছে না, কেন আমি ভুল রঙ পাচ্ছি এবং এই ধরনের আরও অনেক কিছু নিয়ে সঠিক মানসিক মডেল তৈরি করা এবং ডিবাগ করা কঠিন ছিল।

নতুন বিশ্বে, কম্পোজের বিশ্বে, বিশেষ করে মেটেরিয়াল ডিজাইন সিস্টেম এবং কম্পোজ মেটেরিয়াল লাইব্রেরির জন্য, তবে অন্যান্য ডিজাইন সিস্টেমের জন্যও, মেটেরিয়াল ডিজাইন সিস্টেমের জন্য আমাদের কাছে যা আছে, তা হল একটি MaterialTheme কম্পোজেবল যা আপনি আপনার স্ক্রিনে আপনার UI হায়ারার্কির একেবারে শীর্ষে প্রয়োগ করেন এবং আপনি এই MaterialTheme-কে আপনার UI-এর যেকোনো ছোট অংশে ওভারলে হিসেবেও প্রয়োগ করতে পারেন।

আপনি যদি ডানদিকে স্ক্রিনে দেখেন, তাহলে উপরে এই Play Points গোল্ড দেখতে পাবেন, যা এখানে প্রগ্রেস ইন্ডিকেটর এবং কিছু টেক্সট সহ একটি ছোট কার্ড।

আমরা এই মেটিরিয়াল থিম ওভারলে, মেটিরিয়াল কালার ইউটিলিটি লাইব্রেরি দ্বারা তৈরি কাস্টম রঙের স্কিমের সাথে প্রয়োগ করি, যা আপনার ব্যবহারের জন্য GitHub-এ উপলভ্য।

আমরা এই বাদামী, হলুদ, সোনালী রঙের মতো বীজ পাস করি এবং এটি মেটেরিয়াল কালার টোকেনের সম্পূর্ণ স্পেকট্রাম তৈরি করে, প্রাইমারিতে প্রাইমারি, সেকেন্ডারিতে সেকেন্ডারি, যা আমরা এই কার্ডের ইমপ্লিমেন্টেশনের মধ্যে ব্যবহার করি।

এবং এটি Android ডেভেলপারদের হাতে সম্পূর্ণ ডায়নামিক থিমিংয়ের ক্ষমতা এনে দেয়।

এটি সম্পূর্ণভাবে কোডে করা হয়, এটি সম্পূর্ণভাবে Kotlin-এ করা হয়, যার অর্থ হল এটি কীভাবে কাজ করে তার সঠিক মেন্টাল মডেল তৈরি করা অনেক সহজ এবং এটি ডিবাগ করা অনেক সহজ।

এবং ইন্টার্নালি, এই ওভারলেগুলি আপনার হায়ারার্কিতে নির্দিষ্ট UI নোডে কম্পোজিশন লোকাল হিসেবে অ্যাটাচ করা হয়, যেখানে আপনি সেগুলি প্রয়োগ করতে চান।

পারফর্ম্যান্স সংক্রান্ত বিবেচনা: Material Color Utilities লাইব্রেরির মাধ্যমে সম্পূর্ণ কালার স্কিম তৈরি করা ফ্রি নয়।

এটি নির্দিষ্ট ওভারহেডের সাথে আসে।

তাই, আপনার কাছে যদি এমন জটিল কিছু থাকে যার জন্য একাধিক Bento বক্স বা অন্য কিছু প্রয়োজন হয়, আপনার প্রোডাক্টের প্রয়োজনীয়তার উপর নির্ভর করে এবং আপনার কাছে একাধিক রঙের স্কিম থাকে যা আপনি রানটাইমে জেনারেট করেন, তাহলে তা যোগ হতে শুরু করে, যা লেটেন্সি এবং জ্যাঙ্ক যোগ করতে শুরু করে।

তাই, প্রথমত, আপনি এটি আপনার পারফর্ম্যান্সকে কীভাবে প্রভাবিত করে তা পরিমাপ করা শুরু করতে চান এবং দ্বিতীয়ত, আপনি রানটাইম থেকে বিল্ড টাইমে এই ওভারহেডের কিছু অফলোড করতে পারেন।

আপনার ব্র্যান্ডিং বা প্রোডাক্টের প্রয়োজনীয়তার উপর ভিত্তি করে সেইসব রঙের স্কিম আগে থেকে তৈরি করতে, আপনি বিল্ড টাইমে একই মেটিরিয়াল কালার ইউটিলিটি লাইব্রেরি ব্যবহার করতে পারেন এবং বিল্ড টাইমে এই ওভারহেড অফলোড করতে পারেন।

আমি যে কম্পোজিশন লোকালগুলির কথা উল্লেখ করেছি, যেগুলি UI হায়ারার্কি ট্রিতে ওভারলেগুলি ঠিক কোথায় আছে তা ট্র্যাক করে, সেগুলি অনেক সস্তা, কিন্তু এখনও ফ্রি নয়।

তাই, আপনি কতগুলি ব্যবহার করছেন তার উপর নির্ভর করে, ডজন, শত শত, এটি যোগ হতে শুরু করে।

এবং কোনও এক সময়, আপনি এই সমস্ত কম্পোজিশন লোকালের সম্মিলিত খরচ দেখতে চাইবেন।

এবং এটি হল আমি যা উল্লেখ করছিলাম তার একটি উদাহরণ, যেমন Compose-এর সত্যিকারের ডায়নামিক রানটাইম থিমিং ক্ষমতা।

এখানে আমাদের চারটি কোয়াড্রেন্ট আছে, একই ভিজ্যুয়াল, একই, আসুন এটিকে একটি ইভেন্ট কার্ড বলি।

আমাদের কাছে এই অনেক বড় ছবি আছে যা পুরো কার্ড জুড়ে থাকে এবং তারপরে আমাদের কাছে উপরে বাঁদিকে একটি লেবেল, নিচে ডানদিকে একটি বোতাম এবং কয়েকটি টেক্সট আছে।

এবং প্রতিটি কোয়াড্রেন্টের ডানদিকে, আপনি কালার টোকেনের কল আউট দেখতে পাবেন যা প্রতিটি এলিমেন্টের জন্য ডিজাইন স্পেক হিসেবে ব্যবহার করা হয়।

এই চারটির ক্ষেত্রেই কার্ডের প্রয়োগ একই রকম।

একমাত্র পার্থক্য হল, কার্ডটি যে মেটিরিয়াল থিম ওভারলে দিয়ে র‍্যাপ করা থাকে, সেটি ছবির প্রধান রঙের উপর ভিত্তি করে ডায়নামিকভাবে তৈরি করা কালার স্কিম দিয়ে জেনারেট বা কনফিগার করা হয়: নীল, বেগুনি, হলুদ ও লাল।

বাকি সবকিছু একই থাকবে।

আপনাকে অ্যাক্টিভিটি বন্ধ করে আবার তৈরি করতে হবে না।

আপনার এক্সপেরিমেন্ট ফ্ল্যাগ বা অন্য কোনও ব্যবসায়িক প্রয়োজনের ভিত্তিতে আপনি এটি শর্তসাপেক্ষে প্রয়োগ করতে পারবেন।

এবং এটি অনেক বেশি ডায়নামিক, যেমন আমি আগেই বলেছি, এটি অনেক বেশি ডায়নামিক, আপনার অ্যাপে কালার কাস্টমাইজেশন প্রয়োগ করার জন্য সত্যিই ডায়নামিক বিশ্ব।

এবার পরবর্তী বিভাগের জন্য জন আবার ফিরে এসেছেন।

হ্যাঁ।

তাহলে, কিরিল যে নমনীয়তার কথা বলছিলেন, এটি তার আরও একটি উদাহরণ।

আসুন, নির্ভরযোগ্যতা ও বেগ নিয়ে আলোচনা করা যাক।

তাই, সব ডেভেলপার ও ব্যবসা খুব ভালো কোয়ালিটির কোড দ্রুত তৈরি করার উপায় খুঁজছে।

তাহলে, Compose কীভাবে Play-কে এটি করতে সাহায্য করেছে তা দেখা যাক।

তাই, প্রথম এবং সর্বাগ্রে, আমি জানি বড় ডায়াগ্রাম, প্রথম এবং সর্বাগ্রে আর্কিটেকচারের সরলতা সমস্ত কোড লেখক এবং রক্ষণাবেক্ষণকারী, মানুষ এবং এজেন্টদের জন্য বিশাল সুবিধা রয়েছে।

আমি এই বিষয়ে খুব বেশি গভীরে যাব না, তবে Compose যে মানসিক মডেলের জিনিসগুলি তুলে ধরার চেষ্টা করে তার মধ্যে একটি হল ইউনিডাইরেকশনাল ডেটা ফ্লো এবং এটি আমাদের টিমের উপর সত্যিই একটি বড় প্রভাব ফেলেছে।

এটি কীভাবে কাজ করে সেই সম্পর্কে যারা জানেন না, তাদের জন্য বেসিক হল আপনার কাছে একটি ডেটা সোর্স আছে।

ডেটা সোর্স ডেটা প্রদান করে।

সেই ডেটা নির্দিষ্ট UI-তে রূপান্তরিত করা হতে পারে, যা আমরা UI মডেল হিসেবে আউটপুট করি।

এবং তারপর Compose সহজেই সেই স্টেটে একটি ভ্যালু প্রপার্টি কল করে তা পর্যবেক্ষণ করতে পারে।

এটি এই ডায়াগ্রামের উপরের দিকে থাকা তীরচিহ্নের মতো।

এবং তারপর ইভেন্টগুলি বিপরীত দিকে প্রবাহিত হয়।

তাই, কোনও ব্যবহারকারী বোতামে ক্লিক করলে, এটি UI ট্রান্সফর্মারে ফিরে যাবে, ডেটা সোর্স আপডেট করবে, নতুন ভ্যালু এমিট করবে, ট্রান্সফর্ম রান করবে এবং আপনি এই লুপ পাবেন।

তাই সবকিছুই এই তুলনামূলকভাবে সহজ লুপের মাধ্যমে চলে।

আমরা এর থেকে যে সুবিধাগুলি সত্যিই দেখেছি তা হল এটি র‍্যাম্প-আপ টাইম কমাতে সাহায্য করে।

এইসব কল মূল থ্রেডে নাকি অন্য থ্রেডে হচ্ছে তা নিয়ে আর কোনও বিভ্রান্তি নেই।

এটি একটি সাধারণ লুপ অনুসরণ করে।

Compose-এর মাধ্যমে ডেটা পর্যবেক্ষণ করা অত্যন্ত সহজ এবং আর্কিটেকচারাল লেয়ার জুড়ে ডেটার ধারাবাহিকতা বজায় রাখার ব্যাপারে শক্তিশালী গ্যারান্টি দেয়।

মেন্টাল মডেল আমাদের টিমের মধ্যে সত্যের উৎস সম্পর্কে অনেক কথোপকথন কমিয়েছে এবং সম্পূর্ণরূপে বিভিন্ন ধরনের রেস কন্ডিশন সরিয়ে দিয়েছে।

আমাদের জন্য আরেকটি বিশাল সুবিধা হল, আমাদের আগের মডেল-ভিউ-কন্ট্রোলার আর্কিটেকচারের তুলনায়, ডেটা সোর্স এবং UI ট্রান্সফর্মের সমান্তরাল এক্সিকিউশন করা খুব, খুব সহজ হয়ে গেছে।

তাই, এটি স্টোরের মধ্যে আমাদের লোড লেটেন্সি সত্যিই উন্নত করেছে, আপনি জানেন, ডজন ৫০ মিলি সেকেন্ড বা এই ধরনের কিছু।

এটি আমাদের কাছে বেশ চিত্তাকর্ষক ছিল।

ইউনিডিরেকশনাল ডেটা ফ্লোর সাথে পেয়ার করা, Compose-এর অন্য বিশাল প্রবক্তা ডিক্লেরেটিভ UI-এর কাছাকাছি।

কিরিল এই বিষয়ে একটু বলেছেন।

তাই, Play ডেভেলপাররাও এটি সত্যিই উপভোগ করেছেন।

UI কন্ট্রোল ফ্লো এখন একটি ফাইলে রয়েছে।

ডানদিকে একটি উদাহরণ দেওয়া আছে যা খুবই সহজ।

@Composable
fun PurchaseRow(onClick: () -> Unit, modifier: Modifier) {
  Row(modifier) {
    Text("20% off sale")
    if (LocalExpts.current.useButtonV2) {
      ButtonV2("Buy", onClick = onClick)
    } else {
      ButtonV1("Buy", onClick = onClick)
    }
  }
}

আমরা এক্সপেরিমেন্ট ফ্ল্যাগের উপর ভিত্তি করে দুটি বোতাম প্রয়োগের মধ্যে পরিবর্তন করছি।

একাধিক ভিউ ফাইল বা ফ্র্যাগমেন্ট ফাইল এবং XML ফাইল পড়ার পরিবর্তে, আপনি এটি উপর থেকে নিচ পর্যন্ত পড়তে পারেন এবং এটি অনেক সহজ করে তোলে।

নেস্টিং কম্পোজেবলের খরচও নেস্টেড ভিউ হায়ারার্কির চেয়ে অনেক অনেক কম এবং এটি আমাদের কোডকে আরও সহজে পড়ার যোগ্য করে তুলতে স্বাভাবিকভাবে সাজানোর অনুমতি দেয়, যাতে পারফর্ম্যান্সের জন্য প্রতিটি ছোটখাটো বিষয় নিয়ে চিন্তা করতে না হয়।

অন্যান্য সুবিধা যা আমরা দেখেছি তা হল লাইফ-সাইকেল কলব্যাকগুলি অনেক বেশি সহজ হয়েছে এবং আপনাকে কতগুলি নিয়ে চিন্তা করতে হবে তা কমে গেছে।

তাই, ভিউ লাইফ-সাইকেল, ফ্র্যাগমেন্ট লাইফ-সাইকেল, অ্যাক্টিভিটি লাইফ-সাইকেল থাকার পরিবর্তে, আপনি ডিসপোজেবল এফেক্ট, সাইড এফেক্ট পান এবং আপনি এটি যেখানেই রাখুন না কেন, এটি খুব সামঞ্জস্যপূর্ণ উপায়ে কাজ করে।

তাই, এটি আমাদের জন্য একটি বিশাল সুবিধা।

তাই, আমার মতে, আর্কিটেকচারে এই দুটি পরিবর্তন LLM-এর জন্য সত্যিই মঞ্চ তৈরি করেছে এবং এটিকে খুব ভালো কোয়ালিটির কোড তৈরি করতে সক্ষম করেছে।

আর আমি নিশ্চিত যে আপনাদের মধ্যে অনেকেই হয়ত এটি চেষ্টা করেছেন বা আপনার প্রিয় LLM-এর সাথে এটি করেছেন।

আপনি হয়তো এমন একটি স্ক্রিনশট নিতে পারেন যা রঙ এবং টাইপোগ্রাফি দিয়ে অ্যানোটেট করা হয়েছে এবং এটি ফিড করে দেখতে পারেন, আপনি জানেন, এটি সারি এবং কলাম এবং টেক্সট এবং বোতাম তৈরি করতে পারে এবং এটি একটি যুক্তিসঙ্গত কাজ করে।

তবে, এর কিছু সীমাবদ্ধতা আছে।

আর Play আসলে যা দেখেছে তা হল এটি আপনার কোডবেস বুঝতে পারে না, তাই তো?

আপনি আগে থেকে কোন কম্পোনেন্ট তৈরি করেছেন যা এটি আবার ব্যবহার করতে পারে, তা এটি জানে না, ডিজাইন টোকেনের নামও জানে না।

এটি আপনাকে শুধু হার্ড-কোডেড রঙ ও স্ট্রিং দেয়।

ডিভাইস থেকে কোন কন্টেন্ট দেখানো উচিত, সার্ভার থেকে কোন কন্টেন্ট আসা উচিত অথবা শুধু একটি বিশাল কলাম তৈরি না করে LazyList ব্যবহার করার সময় এটি যাতে ভালভাবে কাজ করে তা কীভাবে নিশ্চিত করব?

তাই, এর মধ্যে কিছু সমস্যার সমাধান করতে আমরা যা করেছি তা হল, আরও কিছুটা মেটাডেটা সহ সেইসব স্ক্রিনশট অ্যানোটেট করা।

তাই, UI-এর নাম, বাউন্ডিং বক্স যাতে আমরা জানতে পারি কম্পোনেন্ট কোথায় শুরু ও শেষ হচ্ছে, রঙ ও টাইপোগ্রাফির সিম্যান্টিক নামের জন্য ডিজাইন টোকেন, স্কিল এবং এটি কোথায় প্লেস করা হবে সেই সম্পর্কে কিছু প্রম্পট যাতে এটি সেই পারফর্ম্যান্স সংক্রান্ত বিষয়গুলি বিবেচনা করতে পারে।

এবং তারপরে খুব হাই-লেভেল ফাংশন সিগনেচার, যাতে আপনি বলতে পারেন কোন কন্টেন্ট ডায়নামিক এবং কোনটি স্ট্যাটিক।

সুতরাং, আপনি এমন কিছু দিয়ে শেষ করেন যা আমাদের আগে ছিল, পরে চলে যায়।

আমার কাছে এখানে বাউন্ডিং বক্স নেই কারণ এটি ডায়াগ্রামে অনেক নয়েজ যোগ করবে।

তবে আপনি দেখতে পাবেন যে সেই হার্ড-কোডেড রঙ এবং টাইপোগ্রাফির নামগুলি বড় শিরোনাম এবং সারফেসে পরিবর্তন করা হচ্ছে।

আমরা কার্ড হেডার এবং আইকন ব্যাজের মতো কম্পোনেন্টের নাম স্পষ্টভাবে চিহ্নিত করেছি।

তাই, এইভাবে, সেগুলি আপনার কোডবেসে খুঁজে পাওয়া যেতে পারে।

এবং আমাদের জন্য, আমাদের কাছে আছে, আপনি জানেন, এর মধ্যে অনেকগুলি সাধারণ ডিজাইন লাইব্রেরি থেকেও আসছে, যা কিরিল এক মিনিটের মধ্যে কথা বলবে।

তাই, আপনি সবসময় এগুলির সবকটিতে কাস্টম লেবেল যোগ করছেন না।

আপনি সেটিকে নিচে দেখানো মেথড সিগনেচারের সাথে পেয়ার করেন, OfferCard, এবং তারপরে এটি বুঝতে পারে যে, আপনি জানেন, শীর্ষক, endDate, ছবি সবই ডায়নামিক।

আমাদের সেগুলি হার্ড-কোড করা উচিত নয়।

এবং সেইসব সিম্যান্টিক নামের সাথে, আমরা এখন সেইসব বিভিন্ন রঙের অ্যাপ্লিকেশন সোয়াপ করতে পারি যেগুলির ব্যাপারে কিরিল বলছিলেন।

আর এর সাথে, আমরা আরও অনেক কোড জেনারেট করছি।

আমরা কীভাবে কোয়ালিটি বজায় রাখছি সেই বিষয়ে কথা বলার জন্য আমি কিরিলকে হ্যান্ডওভার করছি।

ডানে।

ধন্যবাদ, জন।

তাই, LLM এবং এজেন্টিক-অ্যাসিস্টেড ডেভেলপমেন্টের এই বিষয় নিয়ে আলোচনা চালিয়ে যেতে, আমরা প্রথমে UX ডিজাইন দিয়ে শুরু করি।

আপনি যা করতে চান তা হল, আপনার পছন্দের ডিজাইন টুল যাই হোক না কেন, Figma বা অন্য কিছু, আপনি একটি শেয়ার করা টেমপ্লেট পেতে চান যা সমস্ত ডিজাইনাররা ব্যবহার করেন যাতে আপনার পছন্দের ডিজাইন সিস্টেম থেকে কালার টোকেন, টাইপোগ্রাফি টোকেন, শেপ টোকেন থাকে।

হয়ত এটি মেটেরিয়াল।

হয়ত এটি আপনার কাস্টম ডিজাইনার সিস্টেম।

এবং আপনি বিশেষভাবে কালার টোকেনের জন্য চান, আপনি চান যে সেই টেমপ্লেটগুলিতে লাইট এবং ডার্ক মোডের মধ্যে পরিবর্তন করার জন্য এবং সাধারণ, মাঝারি এবং উচ্চ কনট্রাস্ট মোডের মধ্যে পরিবর্তন করার জন্য বিল্ট-ইন সাপোর্ট থাকুক যা কয়েক বছর আগে Android লেভেলে চালু করা হয়েছিল।

যাতে ডিজাইনাররা দ্রুত এই বিভিন্ন কম্বিনেশনের মধ্যে পরিবর্তন করে দেখতে পারেন যে তাদের ডিজাইন স্পেসিফিকেশন কীভাবে প্রতিক্রিয়া জানায়।

তারপর, এটি চূড়ান্ত করার পরে এবং বাস্তবায়নের জন্য হস্তান্তর করার পরে, সেই এক্সপোর্ট পাইপলাইনে, আপনি প্রতিটি রঙ, প্রতিটি টাইপোগ্রাফি এলিমেন্ট, প্রতিটি আকৃতি হার্ডকোড করা RGB ভ্যালু বা হার্ডকোড করা ফন্ট ফ্যামিলি বা ফন্টের সাইজের পরিবর্তে একটি ম্যাচিং টোকেন ব্যবহার করছে কিনা তা ট্র্যাক করার জন্য কোনও ধরনের ক্ষমতা পেতে চান।

এবং সবশেষে, Google Play-এর স্কেলে আমরা যা খুব উপযোগী বলে মনে করেছি, তা হল আমাদের কাছে ডজন নয়, কয়েকশো কম্পোনেন্ট, ক্লাস্টার, কার্ড, কন্টেনার আছে যা আমাদের বিভিন্ন স্ক্রিনে ব্যবহার করা হয়।

আমরা দেখেছি যে, এই সবকিছুর ট্র্যাক এক জায়গায় রাখলে সুবিধা হয়, যাকে আমরা কম্পোনেন্ট ক্যাটালগ বলি এবং তারপর সেই কম্পোনেন্ট ক্যাটালগের উপর একটি কাস্টম এজেন্টকে ট্রেনিং দিই।

এবং এটি যেখানে কাজে আসে তা হল যখন আপনি একটি নতুন স্ক্রিন শুরু করেন, হতে পারে একটি নতুন ব্যবহারকারীর অভিজ্ঞতা, হতে পারে একটি নতুন প্রোডাক্ট এরিয়া এবং সেই প্রাথমিক ডিজাইন এক্সপ্লোরেশন থেকে, হতে পারে স্লাইড, হতে পারে Figma স্পেক, আপনি সেই এজেন্টে তা ফিড করতে পারেন এবং এজেন্ট দ্রুত শনাক্ত করতে সাহায্য করে যে কোন কম্পোনেন্টগুলি আগে থেকেই আছে যাতে সেগুলি আবার ডিজাইন এবং আবার স্পেক করার প্রয়োজন না হয়, যাতে সেগুলি স্ক্র্যাচ থেকে আবার প্রয়োগ করার প্রয়োজন না হয়।

এবং এটি ডিজাইন এবং বাস্তবায়নের খরচ উল্লেখযোগ্যভাবে কমিয়ে দেয়।

প্রয়োগের ক্ষেত্রে, আমরা কোর ও কাস্টম Lint নিয়মের উপর খুব বেশি নির্ভর করি।

আমি দুটি মূল Lint নিয়মের কথা উল্লেখ করতে চাই, একটি হল FrequentlyChangingValueDetector যা অপ্রয়োজনীয় রিকম্পোজিশনের সোর্স শনাক্ত করতে সাহায্য করে, যার ফলে লেটেন্সি ও জ্যাঙ্ক হতে পারে এবং অন্যটি হল ScaffoldPaddingDetector যা এমন কেস ফ্ল্যাগ করে যেখানে আমরা Material Compose Scaffold কম্পোজেবল ব্যবহার করি, কিন্তু ইনকামিং প্যাডিং উপেক্ষা করি।

এটি লেটেন্সি এবং জ্যাঙ্কের সোর্স নয়, তবে কিছু ক্ষেত্রে, এটি ডিবাগ করা খুব কঠিন হতে পারে, যেমন, কিছু ক্ষেত্রে লেআউট মিসঅ্যালাইনমেন্ট, যেমন, এটি এজ-টু-এজ, বা ফোল্ডিং, আনফোল্ডিং।

এবং, অবশেষে, BoxWithConstraints, এটি নির্দিষ্ট পারফর্ম্যান্স বিবেচনার সাথে আসে।

সবকিছু সঠিকভাবে সাজাতে দুটি ফ্রেম লাগতে পারে।

আমরা এটি সরাসরি ব্লক করি না, তবে আমরা এটিকে একটি লিন্ট সতর্কতা হিসাবে ফ্ল্যাগ করি যাতে সেই নির্দিষ্ট স্ক্রিনে কাজ করা ডেভেলপার জানতে পারেন যে তারা BoxWithConstraints ব্যবহার করার জন্য একটি নির্দিষ্ট পছন্দ করছেন, অথবা তারা সেই নির্দিষ্ট লেআউটের জন্য অন্য কিছু ব্যবহার করতে পারেন।

থিম অটোমেশনের জন্য, আবার, কালার টোকেন, টাইপোগ্রাফি টোকেন, শেপ টোকেন।

আমাদের একটি লিন্ট রুল আছে যা হার্ডকোড করা রঙ এবং হার্ডকোড করা টাইপোগ্রাফির ব্যবহার ব্লক করে।

আমাদের একটি লিন্ট রুল আছে যা মেটেরিয়াল ২ কম্পোনেন্টের ব্যবহার ফ্ল্যাগ করে।

আমরা শুধু Material 3 ব্যবহার করতে চাই, যা লেটেস্ট ও সবচেয়ে ভালো, এর মধ্যে গত বছর ও এই বছর রিলিজ হওয়া নতুন এক্সপ্রেসিভ কম্পোনেন্টও অন্তর্ভুক্ত।

আমরা চাই আমাদের একটি কাস্টম লিন্ট নিয়ম আছে যা লোকেদের রঙ পড়তে বাধা দেয়, ধরা যাক, লিগ্যাসি XML ফাইল।

আমরা নতুন স্ক্রিনের জন্য Compose-ফার্স্ট এবং Compose-অনলি হতে চাই।

এবং, টেক্সট কম্পোজেবল, বিশেষ করে মেটেরিয়াল ডিজাইন সিস্টেমে, স্টাইল এবং রঙের জন্য ফলব্যাক থাকে।

তারা এটি লোকাল কন্টেন্টের রঙ এবং লোকাল টাইপোগ্রাফি থেকে পড়ে, কিন্তু আমরা তার উপর নির্ভর করতে চাই না।

আমরা চাই প্রতিটি টেক্সট যেন ইচ্ছাকৃতভাবে নির্দিষ্ট স্টাইল, টাইপোগ্রাফি স্টাইল এবং ডিজাইন স্পেক থেকে নির্দিষ্ট রঙ ব্যবহার করে।

তাই, এটি আমাদের একটি লিন্ট নিয়ম।

এবং শেষটি, ScaffoldPaddingDetector-এর মতো, আমাদের একটি কাস্টম লিন্ট নিয়ম রয়েছে যা আমাদের প্রতিটি কম্পোজেবল ফাংশন যাতে তার ইনপুট মডিফায়ার ব্যবহার করে তা এনফোর্স করে।

আবার, যেমন, আপনি জানেন, নতুন ব্যবহার যাতে ভুলভাবে না করা হয় বা ইনকামিং ব্যাকগ্রাউন্ডকে সম্মান না করা হয় বা এই ধরনের কিছু যাতে না হয়, তা আটকানোর জন্য।

এই প্রেজেন্টেশন থেকে আমরা চাই যে আপনি এই তিনটি প্রধান পয়েন্ট মনে রাখুন।

প্রথমত, ২০২৬ সালের শেষে, আমাদের মতে, Compose হল একটি পরিপক্ক UI টুলকিট, যা স্কেলে প্রমাণিত।

Android নিজেই কম্পোজ-ফার্স্ট।

এই বছরের শুরুতে Google I/O-তে আমরা ঘোষণা করেছি যে সব UI লাইব্রেরি এবং সব এজেন্টিক ফ্লো Compose-ফার্স্ট।

এবং, জন প্রেজেন্টেশনে আগেই যেমন উল্লেখ করেছেন, ক্রল, ওয়াক, জগ এবং রান, আমরা সাজেস্ট করি যে আপনি ইনক্রিমেন্টাল পদ্ধতিতে মাইগ্রেট করুন, বিশেষ করে বড় কোডবেস, যাতে ডেভেলপার ফ্লো এবং এজেন্টিক ফ্লোর জন্য আপনার গতি বাড়ানো যায়।

এবং, এর সাথে, আজ আমাদের সাথে আপনার সময় ভাগ করে নেওয়ার জন্য আমরা আপনাকে ধন্যবাদ জানাই এবং কয়েক মিনিটের মধ্যে, আপনার যেকোনও প্রশ্নের উত্তর দেওয়ার জন্য আমি এবং জন বাইরে থাকব।

এবং, সময় দেওয়ার জন্য আপনাকে আবারও ধন্যবাদ।