shouldShowRequestPermissionRationale in Android — এটি কী, প্রদর্শনের যুক্তি এবং বাস্তবায়ন

shouldShowRequestPermissionRationale কী

shouldShowRequestPermissionRationale Android-এ Activity এবং Fragment ক্লাসের একটি পদ্ধতি, যা সামঞ্জস্যের জন্য ActivityCompat-এর মাধ্যমে উপলব্ধ। এটি একটি অনুমতির নাম নেয় এবং একটি Boolean ফেরত দেয় যা নির্দেশ করে যে পুনরায় অনুরোধ করার আগে ব্যবহারকারীকে অতিরিক্ত ব্যাখ্যা দেখানো উচিত কিনা। পদ্ধতিটি Android 6.0 Marshmallow-এ রানটাইম অনুমতি মডেলের সাথে আবির্ভূত হয়েছে।

র্যাশনাল প্রক্রিয়াটি অনুমতি ডায়ালগগুলির সাথে ব্যবহারকারীর মিথস্ক্রিয়া ইতিহাস ট্র্যাক করার উপর নির্মিত। সিস্টেম মনে রাখে যে ব্যবহারকারী পূর্বে অনুরোধটি প্রত্যাখ্যান করেছিল কিনা। যদি Never Ask Again ফ্ল্যাগ সেট না করে প্রত্যাখ্যান ঘটে থাকে, তাহলে shouldShowRequestPermissionRationale true ফেরত দেয়। এটি ডেভেলপারের জন্য একটি সংকেত: ব্যবহারকারী বুঝতে পারে না কেন অনুমতিটি প্রয়োজন, এবং অতিরিক্ত ব্যাখ্যা প্রয়োজন। Google ম্যাটেরিয়াল ডিজাইন নির্দেশিকা অনুসারে, প্রথম প্রত্যাখ্যানের পরে র্যাশনাল ডায়ালগ দেখানো পুনরায় অনুমতি প্রদানের সম্ভাবনা ৩৫ শতাংশ বাড়িয়ে দেয়।

ফেরত মানগুলির অর্থ বোঝা গুরুত্বপূর্ণ: true মানে ডায়ালগ দেখানো অর্থপূর্ণ, false মানে ডায়ালগটি হয় প্রয়োজন নেই (অনুমতি ইতিমধ্যে মঞ্জুর করা হয়েছে বা কখনও অনুরোধ করা হয়নি) বা অকেজো (Never Ask Again সক্রিয়)। পদ্ধতিটি গ্যারান্টি নয় যে ডায়ালগ দেখানো হবে — এটি কেবল একটি সুপারিশ দেয়। ডেভেলপার সিদ্ধান্ত নেয় প্রতিক্রিয়ায় কোন UI দেখাতে হবে।

পদ্ধতিটি কখন চালু হয়েছিল

shouldShowRequestPermissionRationale API লেভেল ২৩-এ রানটাইম অনুমতিগুলির জন্য পদ্ধতিগুলির একটি গ্রুপের সাথে প্রবর্তিত হয়েছিল। Android 6.0-এর আগে, সমস্ত অনুমতি ইনস্টলের সময় অনুরোধ করা হত এবং কোনও ব্যাখ্যা প্রক্রিয়ার প্রয়োজন ছিল না — ব্যবহারকারী একবারে পুরো তালিকা গ্রহণ বা প্রত্যাখ্যান করতেন। রানটাইম মডেল এটি সম্ভব করেছে যে একটি ব্যবহারকারী প্রসঙ্গ না বুঝে অনুরোধ প্রত্যাখ্যান করতে পারে, এবং এই কারণেই র্যাশনাল প্রয়োজন।

shouldShowRequestPermissionRationale কীভাবে কাজ করে

পদ্ধতির যুক্তি নিম্নরূপ কাজ করে। একটি নির্দিষ্ট অনুমতির জন্য requestPermissions-এর প্রথম কলে, shouldShowRequestPermissionRationale false ফেরত দেয় — ব্যবহারকারী এখনও ডায়ালগের সম্মুখীন হননি। যদি ব্যবহারকারী অনুরোধটি প্রত্যাখ্যান করে (Deny চাপে), পদ্ধতিটি true ফেরত দিতে শুরু করে। Never Ask Again ফ্ল্যাগ সহ পুনরাবৃত্ত প্রত্যাখ্যানের পরে, পদ্ধতিটি false ফেরত দেয়।

সম্পূর্ণ অবস্থা সারণী:

shouldShowRequestPermissionRationale = false এবং checkSelfPermission = DENIED-এর সংমিশ্রণটি পরিচালনা করা সবচেয়ে কঠিন ক্ষেত্রে। এর অর্থ হয় অনুমতি কখনও অনুরোধ করা হয়নি বা Never Ask Again সেট করা আছে। ডেভেলপারকে এই দুটি অবস্থার মধ্যে পার্থক্য করতে হবে। একমাত্র উপায় হল SharedPreferences-এ বা SavedStateHandle ব্যবহার করে isFirstRequest ফ্ল্যাগ সংরক্ষণ করা। প্রথম অনুরোধে ফ্ল্যাগ সেট করুন, এবং যদি shouldShowRationale false ফেরত দেয় যখন ফ্ল্যাগ ইতিমধ্যে true — তার অর্থ Never Ask Again।

অবস্থা রিসেট

shouldShowRequestPermissionRationale রিসেট হয় যদি ব্যবহারকারী অ্যাপ আনইনস্টল এবং পুনরায় ইনস্টল করে, অ্যাপ ডেটা মুছে ফেলে, বা অনুমতি সেটিংস রিসেট করে। পুনরায় ইনস্টলেশনের পরে, পদ্ধতিটি প্রথম অনুরোধের জন্য আবার false ফেরত দেবে। সিস্টেম আপডেট এবং Android সংস্করণ পরিবর্তন ইতিহাস রিসেট করে না — এটি অ্যাপ ডেটায় সংরক্ষিত থাকে।

র্যাশনাল ডায়ালগ বাস্তবায়ন

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

private fun requestLocationWithRationale() {
    val permission = Manifest.permission.ACCESS_FINE_LOCATION

    when {
        ContextCompat.checkSelfPermission(
            this, permission
        ) == PackageManager.PERMISSION_GRANTED -> {
            startLocationTracking()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(
            this, permission
        ) -> {
            showRationaleDialog(permission)
        }
        else -> {
            requestPermissionLauncher.launch(permission)
        }
    }
}

private fun showRationaleDialog(
    permission: String
) {
    AlertDialog.Builder(this)
        .setTitle("কেন অবস্থান অ্যাক্সেস প্রয়োজন")
        .setMessage(
            "অ্যাপটি মানচিত্রে স্থান চিহ্নিত করতে অবস্থান ব্যবহার করে" +
            "। এই অনুমতি ছাড়া," +
            " ফাংশনটি কাজ করবে না।"
        )
        .setPositiveButton("অনুমতি দিন") { _, _ ->
            requestPermissionLauncher.launch(permission)
        }
        .setNegativeButton("বাতিল", null)
        .show()
}

র্যাশনালের জন্য UI প্যাটার্ন

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

র্যাশনাল স্থানীয়করণ

র্যাশনাল টেক্সট স্থানীয়করণ করা উচিত এবং নির্দিষ্ট ফাংশনের সাথে খাপ খাওয়ানো উচিত। “অ্যাপ কাজ করার জন্য এটি প্রয়োজন”-এর মতো সাধারণ বাক্যাংশ ব্যবহার করবেন না। সুনির্দিষ্টভাবে উল্লেখ করুন: “আপনার কাছে আবহাওয়া দেখানোর জন্য” বা “গ্যালারিতে ফটো সংরক্ষণের জন্য।” নির্দিষ্ট ব্যাখ্যা Google UX গবেষণা অনুসারে অনুমতি প্রদানের সম্ভাবনা ৫০ শতাংশ বাড়িয়ে দেয়।

র্যাশনাল বনাম Never Ask Again

মধ্যে পার্থক্য shouldShowRequestPermissionRationale = true (প্রথম প্রত্যাখ্যান) এবং DENIED-এর সাথে false (Never Ask Again) অনুমতি পরিচালনার একটি মূল বিষয়। প্রথম ক্ষেত্রে, ব্যবহারকারী দ্বিধাগ্রস্ত ছিলেন, এবং অতিরিক্ত ব্যাখ্যা তাকে অ্যাক্সেস মঞ্জুর করতে রাজি করাতে পারে। দ্বিতীয়টিতে, ব্যবহারকারী চূড়ান্ত সিদ্ধান্ত নিয়েছে, এবং সিস্টেম ডায়ালগ পুনরাবৃত্তি করলে কেবল বিরক্তি সৃষ্টি হবে।

প্রত্যাখ্যানের পরে পরিচালনা অ্যালগরিদম এইরকম হওয়া উচিত:

• অনুরোধ কলব্যাক থেকে DENIED ফলাফল পান
• shouldShowRequestPermissionRationale কল করুন
• যদি true — পুনরায় চেষ্টা বোতাম সহ একটি কাস্টম র্যাশনাল ডায়ালগ দেখান
• যদি false — সেটিংস খুলুন বোতাম সহ একটি ডায়ালগ দেখান

ক্রমটি বিভ্রান্ত না করা গুরুত্বপূর্ণ: প্রথমে shouldShowRequestPermissionRationale পরীক্ষা করুন, checkSelfPermission নয়। checkSelfPermission উভয় ক্ষেত্রেই DENIED ফেরত দেবে। শুধুমাত্র shouldShowRequestPermissionRationale প্রথম প্রত্যাখ্যানকে Never Ask Again থেকে আলাদা করে। “প্রথম অনুরোধ করা হয়েছিল” ফ্ল্যাগ সংরক্ষণ করতে SavedStateHandle বা SharedPreferences ব্যবহার করুন — “কখনও অনুরোধ করা হয়নি” থেকে “ব্লক করা” আলাদা করার এটাই একমাত্র নির্ভরযোগ্য উপায়।

র্যাশনাল দেখানোর সেরা অভ্যাস

র্যাশনাল দেখান শুধুমাত্র একবার। যদি ব্যবহারকারী র্যাশনাল দেখার পরে আবার অনুরোধ প্রত্যাখ্যান করে, তাহলে ব্যাখ্যা আবার দেখাবেন না। সরাসরি সেটিংস খোলার প্রস্তাবে যান। বারবার র্যাশনাল দেখানো বিরক্তিকর হিসাবে বিবেচিত হয় এবং অ্যাপ রেটিং কমিয়ে দেয়। সর্বোত্তম দৃশ্যকল্প: অনুরোধ — প্রত্যাখ্যান — র্যাশনাল — পুনরায় অনুরোধ — প্রত্যাখ্যান — সেটিংস।

প্রথম অনুরোধের আগে র্যাশনাল দেখাবেন না। কিছু ডেভেলপার ভুল করে প্রথম ডায়ালগের আগে ব্যাখ্যা দেখান, এই যুক্তিতে যে “ব্যবহারকারীকে বুঝতে হবে।” এটি UX খারাপ করে: ব্যবহারকারী একটির পরিবর্তে পরপর দুটি ডায়ালগ দেখে। Google সুপারিশ করে অবিলম্বে সিস্টেম ডায়ালগ দেখানো, এবং র্যাশনাল শুধুমাত্র প্রত্যাখ্যানের পরে।

প্রাসঙ্গিক র্যাশনাল ব্যবহার করুন যা ফাংশনটি প্রকৃতপক্ষে প্রয়োজন তখনই আবদ্ধ। অ্যাপ স্টার্টআপে সমস্ত অনুমতি অনুরোধ করবেন না — এটির অনুমোদনের হার সবচেয়ে কম। ক্যামেরা অনুরোধ করুন যখন ব্যবহারকারী “ফটো তুলুন” বোতাম টিপে এবং অবস্থান অনুরোধ করুন যখন সে মানচিত্র খোলে। প্রাসঙ্গিক অনুরোধ র্যাশনালের সাথে মিলে স্টার্টআপে অনুরোধ করলে ৩০ শতাংশের তুলনায় অনুমোদন ৮০ শতাংশ পর্যন্ত বাড়িয়ে দেয়।

র্যাশনাল দৃশ্যকল্প পরীক্ষা

shouldShowRequestPermissionRationale পরীক্ষা সারণীর চারটি অবস্থা পরীক্ষা করা প্রয়োজন: অনুরোধ করা হয়নি, মঞ্জুর করা হয়েছে, প্রত্যাখ্যাত, Never Ask Again। ইউনিট পরীক্ষায়, কনফিগারযোগ্য shouldShowRationale আচরণ সহ FakePermissionHandler ব্যবহার করুন। ইন্সট্রুমেন্টেশন পরীক্ষায়, ডায়ালগ প্রতিক্রিয়া অনুকরণ সহ UiAutomator বা Espresso ব্যবহার করুন।

class RationaleViewModelTest {

    private val handler = FakePermissionHandler()
    private val viewModel = PermissionsViewModel(handler)

    fun testFirstDenial_shouldShowRationale() {
        handler.shouldShowRationale = true
        handler.cameraResult =
            PermissionResult.DENIED(true)

        viewModel.onCameraRequested()

        assertEquals(
            PermissionUiState.Denied(true),
            viewModel.uiState.value
        )
    }

    fun testNeverAskAgain_redirectToSettings() {
        handler.shouldShowRationale = false
        handler.cameraResult =
            PermissionResult.DENIED(false)

        viewModel.onCameraRequested()

        assertEquals(
            PermissionUiState.RedirectToSettings,
            viewModel.uiState.value
        )
    }
}

ইন্সট্রুমেন্টেশন পরীক্ষার জন্য মূল দৃশ্যকল্প হল যাচাই করা যে প্রথম প্রত্যাখ্যানের পরে র্যাশনাল ডায়ালগ প্রকৃতপক্ষে প্রদর্শিত হয়। সিস্টেম ডায়ালগের জন্য অপেক্ষা করতে idling resources সহ Espresso ব্যবহার করুন, তারপর Deny টিপুন, কাস্টম ব্যাখ্যা ডায়ালগের উপস্থিতি পরীক্ষা করুন এবং Allow টিপুন — মঞ্জুর যাচাই করুন। UIAutomator বোতাম টেক্সট দ্বারা সিস্টেম ডায়ালগের সাথে যোগাযোগের অনুমতি দেয়, যা পরীক্ষাটিকে আরও স্থিতিশীল করে।

এছাড়াও র্যাশনাল ডায়ালগের ভিতরে প্রত্যাখ্যান দৃশ্যকল্প পরীক্ষা করা উচিত। যদি ব্যবহারকারী কাস্টম ব্যাখ্যায় Deny টিপে, তাহলে shouldShowRequestPermissionRationale আবার true ফেরত দেওয়া উচিত, কারণ Never Ask Again এখনও সক্রিয় হয়নি। সেরা অভ্যাস হল পরপর দুইটি প্রত্যাখ্যানের পরে সেটিংস-এ পুনঃনির্দেশ করা যাতে ব্যবহারকারীকে বারবার ব্যাখ্যা দিয়ে বিরক্ত না করা এবং অ্যাপ রেটিং কমানো না হয়।