পাঠ ৩৯ · ৫৭-এর মধ্যে · মডিউল ৯
Home / Courses / Mobile App Development / ব্যাকগ্রাউন্ড সিঙ্ক

ব্যাকগ্রাউন্ড সিঙ্ক ও ফেচ

Background sync and fetch
৯ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • ব্যাকগ্রাউন্ড সিঙ্ক/ফেচ কী এবং কেন OS এটি শর্তসাপেক্ষে চালায়
  • একটি সত্যিকারের should_run_background_sync() পলিসি ফাংশন — নেটওয়ার্ক, ব্যাটারি ও চার্জিং অবস্থার সমন্বয়ে সিদ্ধান্ত নেওয়া
  • একাধিক কনক্রিট শর্ত-সমন্বয়ের বিপরীতে পলিসিটি হাতে-কলমে যাচাই করা

১ · ব্যাকগ্রাউন্ড সিঙ্ক কী এবং কেন শর্তসাপেক্ষ

একটি অ্যাপ যদি প্রতি সেকেন্ডে ব্যাকগ্রাউন্ডে সার্ভারের সাথে যোগাযোগ করতে থাকে, তাহলে ব্যাটারি ও মোবাইল ডেটা দ্রুত শেষ হয়ে যাবে। তাই iOS ও Android উভয়ই ব্যাকগ্রাউন্ড সিঙ্ক/ফেচ একটি OS-নিয়ন্ত্রিত, পর্যায়ক্রমিক সুযোগ হিসেবে দেয় — অ্যাপ নিজে ঠিক কখন চালু হবে তা নির্ধারণ করে না, বরং OS সিস্টেম-ব্যাপী অবস্থা (ব্যাটারি, নেটওয়ার্ক, ব্যবহারকারীর অভ্যাস) বিবেচনা করে সিদ্ধান্ত নেয়।

Wi-Fi
সাধারণত সীমাহীন ও দ্রুত ধরে নেওয়া হয় — Wi-Fi-তে সিঙ্ক চালানো প্রায় সবসময় নিরাপদ।
ব্যাটারি শতাংশ
সেলুলার ডেটায় থাকলে ব্যাটারি কম হলে ব্যাকগ্রাউন্ড কাজ স্থগিত রাখাই ভালো।
চার্জিং অবস্থা
ডিভাইস চার্জ হচ্ছে মানে ব্যাটারি নিয়ে দুশ্চিন্তার প্রয়োজন নেই — সিঙ্ক নির্দ্বিধায় চালানো যায়।

২ · পলিসি ফাংশন

নিচের কোডে একটি কনক্রিট পলিসি বাস্তবায়ন করা হয়েছে: Wi-Fi থাকলে সবসময় চালাও; নয়তো সেলুলার-এ থাকলে শুধু ব্যাটারি ২০%-এর বেশি থাকলে চালাও; নয়তো ডিভাইস চার্জ হচ্ছে কিনা দেখো — হলে চালাও, অন্যথায় সিঙ্ক স্থগিত রাখো।

Python
# should_run_background_sync -- একটি সত্যিকারের, একাধিক শর্তের পলিসি ফাংশন
# পলিসি: Wi-Fi -> সবসময় চালাও
#         সেলুলার -> ব্যাটারি 20%-এর বেশি হলে চালাও
#         charging -> ব্যাটারি নির্বিশেষে চালাও
#         অন্য সব ক্ষেত্রে -> স্থগিত রাখো

def should_run_background_sync(network_type, battery_pct, is_charging):
    if network_type == "wifi":
        return True
    if network_type == "cellular" and battery_pct > 20:
        return True
    if is_charging:
        return True
    return False


test_cases = [
    ("wifi",     5,   False),   # Wi-Fi -- ব্যাটারি কম হলেও চলবে
    ("wifi",     100, False),   # Wi-Fi -- ব্যাটারি পূর্ণ
    ("cellular", 50,  False),   # সেলুলার -- ব্যাটারি যথেষ্ট (>20)
    ("cellular", 15,  False),   # সেলুলার -- ব্যাটারি কম (<=20), চার্জ হচ্ছে না
    ("cellular", 20,  False),   # সেলুলার -- ব্যাটারি ঠিক 20% (সীমারেখায়, > নয়)
    ("cellular", 21,  False),   # সেলুলার -- ব্যাটারি সীমারেখার ঠিক ওপরে
    ("none",     10,  True),    # নেটওয়ার্ক নেই কিন্তু চার্জ হচ্ছে
    ("none",     10,  False),   # নেটওয়ার্ক নেই, চার্জও হচ্ছে না
]

print(f"{'network':10s} {'battery':8s} {'charging':9s} -> sync চলবে")
print("-" * 45)
for network_type, battery_pct, is_charging in test_cases:
    decision = should_run_background_sync(network_type, battery_pct, is_charging)
    print(f"{network_type:10s} {battery_pct:6d}%  {str(is_charging):9s} -> {decision}")

    
লক্ষ্য করুন ("cellular", 20, False) কেসে ফলাফল False কিন্তু ("cellular", 21, False) কেসে True — কারণ শর্তটি battery_pct > 20 (কঠোরভাবে বেশি), >= নয়। এই সীমারেখা (boundary) পরীক্ষাটিই প্রমাণ করে পলিসি ফাংশনটি ঠিক যেভাবে লেখা হয়েছে সেভাবেই আচরণ করছে — "প্রায় ২০%" আর "ঠিক ২০%"-এর মধ্যে পার্থক্য গুরুত্বপূর্ণ।
মূল কথা · Key takeaway

ব্যাকগ্রাউন্ড সিঙ্কের সিদ্ধান্ত কখনোই "সবসময় চালাও" হওয়া উচিত নয় — এটি একটি ব্যবহারকারীর রিসোর্স (ব্যাটারি, ডেটা) খরচ করে যা ব্যবহারকারী সরাসরি দেখছেন না। একটি স্পষ্ট, পরীক্ষাযোগ্য পলিসি ফাংশন এই সিদ্ধান্তকে অস্পষ্ট প্রোজ থেকে সরিয়ে সুনির্দিষ্ট, যাচাইযোগ্য কোডে পরিণত করে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন OS নিজেই ব্যাকগ্রাউন্ড সিঙ্কের ঠিক সময় নির্ধারণ করে, অ্যাপকে নিজে থেকে টাইমার সেট করতে দেয় না?

যদি প্রতিটি অ্যাপ নিজের ইচ্ছামতো টাইমার সেট করত, তাহলে ডিভাইসের প্রসেসর বারবার ভিন্ন ভিন্ন সময়ে জেগে উঠত, যা ব্যাটারির জন্য অত্যন্ত অদক্ষ। OS সব অ্যাপের ব্যাকগ্রাউন্ড কাজ একসাথে "ব্যাচ" করে একটি নির্দিষ্ট উইন্ডোতে চালায় (একবার জেগে উঠে সব কাজ সেরে আবার ঘুমিয়ে পড়ে) — এটি সামগ্রিকভাবে অনেক বেশি ব্যাটারি-সাশ্রয়ী।

প্র ০২ উপরের পলিসিতে "Wi-Fi + ব্যাটারি ৫%" কেস True রিটার্ন করে — এটি কি ঝুঁকিপূর্ণ নয়?

এই সরলীকৃত পলিসিতে Wi-Fi থাকলে ব্যাটারি না দেখেই চালানো হয়, কারণ Wi-Fi রেডিও সেলুলারের চেয়ে কম শক্তি খরচ করে ধরে নেওয়া হয়েছে। বাস্তব সিস্টেমে এটি আরও রক্ষণশীল হতে পারে — যেমন ব্যাটারি একটি অতি-নিম্ন সীমার (যেমন ৫%) নিচে থাকলে নেটওয়ার্ক টাইপ নির্বিশেষে সব ব্যাকগ্রাউন্ড কাজ স্থগিত রাখা। এটি দেখায় পলিসি ফাংশন লেখা মানে শুধু কোড লেখা নয়, সঠিক থ্রেশহোল্ড ঠিক করাও একটি ডিজাইন সিদ্ধান্ত।

প্র ০৩ এই পাঠের পলিসি ফাংশনটি L38-এর রিট্রাই/ব্যাকঅফ লজিকের সাথে বাস্তবে কীভাবে একসাথে ব্যবহৃত হতে পারে?

ব্যাকগ্রাউন্ড সিঙ্ক শুরু করার আগে should_run_background_sync() চেক করা হয় — অনুমতি পেলে সিঙ্ক শুরু হয়, এবং সিঙ্কের নেটওয়ার্ক কল নিজেই যদি ফ্লেকি হয়, তখন L38-এর এক্সপোনেনশিয়াল ব্যাকঅফ রিট্রাই লজিক প্রয়োগ হয়। দুটি সিদ্ধান্তই স্বাধীন কিন্তু ক্রমান্বয়ে কাজ করে — প্রথমে "চালানো উচিত কি না", তারপর "চালানোর পর ব্যর্থ হলে কী করা উচিত"।

অনুশীলন

  1. চিন্তা করুন: "লো পাওয়ার মোড" (Low Power Mode/Battery Saver) চালু থাকা অবস্থায় ব্যাকগ্রাউন্ড সিঙ্ক পলিসি কীভাবে বদলানো উচিত বলে আপনার মনে হয়?

    লো পাওয়ার মোডে সাধারণত ব্যাকগ্রাউন্ড রিফ্রেশ সম্পূর্ণ বন্ধ বা আরও কড়াকড়িভাবে সীমিত করা হয় — ব্যাটারি শতাংশের থ্রেশহোল্ড নির্বিশেষে। বাস্তব বাস্তবায়নে should_run_background_sync() ফাংশনে একটি অতিরিক্ত is_low_power_mode প্যারামিটার যোগ করে সবচেয়ে আগে চেক করা যেত — সত্য হলে সরাসরি False রিটার্ন করে বাকি সব শর্ত এড়িয়ে যাওয়া যায়।

  2. পরীক্ষা করুন: উপরের কোড সেলে test_cases তালিকায় ("cellular", 20, True) যোগ করুন (সেলুলার, ব্যাটারি ঠিক ২০%, কিন্তু চার্জ হচ্ছে), তারপর কোডটি আবার চালিয়ে দেখুন ফলাফল True নাকি False হয়, এবং কেন।

    ফলাফল True হবে। প্রথম শর্ত (network_type == "wifi") মেলে না, দ্বিতীয় শর্তও মেলে না (battery_pct > 20 মিথ্যা যেহেতু ঠিক ২০%), কিন্তু তৃতীয় শর্ত (is_charging) সত্য — তাই ফাংশন True রিটার্ন করবে। এটি দেখায় চার্জিং শর্তটি ব্যাটারি শতাংশ শর্তকে "ওভাররাইড" করতে পারে, কারণ এগুলো ফাংশনে or-এর ধাঁচে স্বাধীন শর্ত হিসেবে চেক হচ্ছে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
ফ্লেকি মোবাইল নেটওয়ার্ক হ্যান্ডলিং — রিট্রাই ও টাইমআউট