चित्र पाठक के पहले विचार को दिखाता है जो आश्चर्यचकित करता है कि संवाद को प्रदर्शित करने जैसे सरल कार्य के बारे में क्या लिखा जा सकता है। मैनेजर इसी तरह सोचता है: "यहाँ कुछ भी जटिल नहीं है, हमारा वास 5 मिनट में करेगा।" बेशक, मैं अतिशयोक्ति करता हूं, लेकिन वास्तव में सब कुछ उतना सरल नहीं है जितना पहली नज़र में लगता है। खासकर अगर हम एंड्रॉइड के बारे में बात कर रहे हैं।

इसलिए, 2019 यार्ड में था, और हम अभी भी नहीं जानते कि कैसे संवादों को ठीक से दिखाना है ।

आइए इसे क्रम में करें और समस्या के विवरण के साथ शुरू करें:

कार्रवाई की पुष्टि करने के लिए पाठ के साथ एक सरल संवाद दिखाना आवश्यक है और बटन "पुष्टि / रद्द करें"। "पुष्टि" बटन पर क्लिक करके - "रद्द करें" बटन द्वारा एक क्रिया करें - संवाद बंद करें।

माथे का घोल

मैं इस विधि को कनिष्ठ कहूंगा, क्योंकि यह पहली बार नहीं है जब मैं गलतफहमी में आया हूं कि आप AlertDialog का उपयोग क्यों नहीं कर सकते, जैसा कि नीचे दिखाया गया है:

AlertDialog.Builder(this) .setMessage("Please, confirm the action") .setPositiveButton("Confirm") { dialog, which -> // handle click } .setNegativeButton("Cancel", null) .create() .show()

नौसिखिए डेवलपर के लिए एक काफी सामान्य तरीका, यह स्पष्ट और सहज है। लेकिन, जैसा कि एंड्रॉइड के साथ काम करते समय कई मामलों में होता है, यह तरीका पूरी तरह से गलत है। नीले रंग में से, हमें एक मेमोरी रिसाव मिलता है, बस डिवाइस को चालू करें, और आपको लॉग में निम्न त्रुटि दिखाई देगी:

स्टैकट्रेस

 E/WindowManager: android.view.WindowLeaked: Activity com.example.testdialog.MainActivity has leaked window DecorView@71b5789[MainActivity] that was originally added here at android.view.ViewRootImpl.<init>(ViewRootImpl.java:511) at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:346) at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:93) at android.app.Dialog.show(Dialog.java:329) at com.example.testdialog.MainActivity.onCreate(MainActivity.kt:27) at android.app.Activity.performCreate(Activity.java:7144) at android.app.Activity.performCreate(Activity.java:7135) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2931) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3086) at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78) at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108) at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1816) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:193) at android.app.ActivityThread.main(ActivityThread.java:6718) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

Stackoverflow पर, इस मुद्दे पर सवाल सबसे लोकप्रिय में से एक है। संक्षेप में, समस्या यह है कि हम या तो संवाद दिखाते हैं या सक्रियण पूरा होने के बाद संवाद को बंद नहीं करते हैं।

आप निश्चित रूप से ऑनपॉज़ या ऑनडेस्ट्रो गतिविधि में डायलॉग को खारिज कर सकते हैं, जैसा कि संदर्भ द्वारा उत्तर में सलाह दी गई है। लेकिन यह ठीक वैसा नहीं है जैसा हमें चाहिए। हम चाहते हैं कि डिवाइस को चालू करने के बाद संवाद ठीक हो जाए।

बाहर का रास्ता

एंड्रॉइड में टुकड़े दिखाई देने से पहले, डायलडॉग को कॉल शो के माध्यम से प्रदर्शित किया जाना चाहिए था सक्रियण विधि। इस मामले में, गतिविधि संवाद के जीवन चक्र को सही ढंग से प्रबंधित करती है और एक मोड़ के बाद इसे पुनर्स्थापित करती है। डायलॉग के निर्माण को ऑनक्रिएटडियल कॉलबैक में लागू करना पड़ा:

 public class MainActivity extends Activity { private static final int CONFIRMATION_DIALOG_ID = 1; // ... @Override protected Dialog onCreateDialog(int id, Bundle args) { if (id == CONFIRMATION_DIALOG_ID) { return new AlertDialog.Builder(this) .setMessage("Please, confirm the action") .setPositiveButton("Confirm", new DialogInterface.OnClickListener() { @Override public void onClick(DialogInterface dialog, int which) { // handle click } }) .create(); } else { return super.onCreateDialog(id, args); } } }

यह बहुत सुविधाजनक नहीं है कि आपको एक संवाद पहचानकर्ता शुरू करना है और बंडल के माध्यम से पैरामीटर पारित करना है। और हम अभी भी "लीक हुई खिड़की" समस्या प्राप्त कर सकते हैं यदि हम गतिविधि पर ऑनडस्ट्रो को कॉल करने के बाद एक संवाद प्रदर्शित करने का प्रयास करते हैं। यह संभव है, उदाहरण के लिए, जब एक अतुल्यकालिक ऑपरेशन के बाद त्रुटि दिखाने की कोशिश की जा रही है।

सामान्य तौर पर, यह समस्या एंड्रॉइड के लिए विशिष्ट होती है, जब आपको एक अतुल्यकालिक ऑपरेशन के बाद कुछ करने की आवश्यकता होती है, और उस पल में गतिविधि या टुकड़ा पहले से ही नष्ट हो जाता है। शायद यही कारण है कि एमवी * पैटर्न आईओएस डेवलपर्स के मुकाबले एंड्रॉइड समुदाय में अधिक लोकप्रिय हैं।

प्रलेखन से विधि

एंड्रॉइड हनीकॉम्ब में फ्रेगमेंट दिखाई दिए, और ऊपर वर्णित विधि को पदावनत किया गया है, और गतिविधि के प्रदर्शन के तरीके को पदावनत के रूप में चिह्नित किया गया है। नहीं, AlertDialog पुरानी नहीं है, क्योंकि कई गलत हैं। बस अब DialogFragment है , जो डायलॉग ऑब्जेक्ट को लपेटता है और अपने जीवन चक्र को नियंत्रित करता है।

28 एपीआई के बाद से मूल स्निपेट भी हटाए गए हैं। अब आपको केवल समर्थन लाइब्रेरी (AndroidX) से कार्यान्वयन का उपयोग करना चाहिए।

चलो हमारे काम को पूरा करते हैं, जैसा कि आधिकारिक दस्तावेज द्वारा निर्धारित किया गया है:

पहले आपको DialogFragment से इनहेरिट करने की जरूरत है और onCreateDialog पद्धति में एक डायलॉग के निर्माण को लागू करें।
संवाद ईवेंट इंटरफ़ेस का वर्णन करें और श्रोता को onAttach विधि में तुरंत लिखें।
एक गतिविधि या टुकड़े में एक संवाद घटना इंटरफ़ेस लागू करें।

यदि पाठक बहुत स्पष्ट नहीं है कि क्यों श्रोता को कंस्ट्रक्टर के माध्यम से पारित नहीं किया जा सकता है, तो वह इस बारे में अधिक पढ़ सकता है

संवाद टुकड़ा कोड:

 class ConfirmationDialogFragment : DialogFragment() { interface ConfirmationListener { fun confirmButtonClicked() fun cancelButtonClicked() } private lateinit var listener: ConfirmationListener override fun onAttach(context: Context?) { super.onAttach(context) try { // Instantiate the ConfirmationListener so we can send events to the host listener = activity as ConfirmationListener } catch (e: ClassCastException) { // The activity doesn't implement the interface, throw exception throw ClassCastException(activity.toString() + " must implement ConfirmationListener") } } override fun onCreateDialog(savedInstanceState: Bundle?): Dialog { return AlertDialog.Builder(context!!) .setMessage("Please, confirm the action") .setPositiveButton("Confirm") { _, _ -> listener.confirmButtonClicked() } .setNegativeButton("Cancel") { _, _ -> listener.cancelButtonClicked() } .create() } }

सक्रियण कोड:

 class MainActivity : AppCompatActivity(), ConfirmationListener { private fun showConfirmationDialog() { ConfirmationDialogFragment() .show(supportFragmentManager, "ConfirmationDialogFragmentTag") } override fun confirmButtonClicked() { // handle click } override fun cancelButtonClicked() { // handle click } }

पर्याप्त कोड निकला, है ना?

एक नियम के रूप में, परियोजना में किसी प्रकार का एमवीपी है, लेकिन मैंने फैसला किया कि इस मामले में प्रस्तुतकर्ता कॉल को छोड़ा जा सकता है। ऊपर दिए गए उदाहरण में, यह NewInstance डायलॉग बनाने और स्थैतिक तर्कों के मापदंडों को पारित करने की स्थैतिक विधि को जोड़ने के लायक है, जो सभी अपेक्षित थे।

और यह सब इतना है कि संवाद समय में छिप जाता है और सही तरीके से बहाल हो जाता है। यह आश्चर्य की बात नहीं है कि स्टैकओवरफ़्लो पर ऐसे सवाल उठते हैं: एक और दो ।

सही समाधान ढूँढना

मामलों की वर्तमान स्थिति हमारे अनुकूल नहीं थी, और हम संवादों को अधिक सहज बनाने के लिए एक रास्ता तलाशने लगे। एक भावना थी कि आप इसे आसान बना सकते हैं, लगभग पहली विधि की तरह।

निम्नलिखित विचार हैं जिन्होंने हमें निर्देशित किया है:

क्या मुझे आवेदन प्रक्रिया को मारने के बाद संवाद को बचाने और पुनर्स्थापित करने की आवश्यकता है?
ज्यादातर मामलों में, यह आवश्यक नहीं है, जैसा कि हमारे उदाहरण में, जब आपको एक सरल संदेश दिखाने या कुछ पूछने की आवश्यकता होती है। उपयोगकर्ता के ध्यान खो जाने तक ऐसा संवाद प्रासंगिक है। यदि आप आवेदन में लंबी अनुपस्थिति के बाद इसे पुनर्स्थापित करते हैं, तो उपयोगकर्ता नियोजित कार्रवाई के साथ संदर्भ खो देगा। इसलिए, आपको केवल डिवाइस के घुमावों का समर्थन करने और संवाद के जीवन चक्र को सही ढंग से संभालने की आवश्यकता है। अन्यथा, डिवाइस के अजीब आंदोलन से, उपयोगकर्ता उस संदेश को खो सकता है जो इसे पढ़ने के बिना ही खोला गया है।
DialogFragment का उपयोग करते समय, बहुत अधिक बॉयलरप्लेट कोड दिखाई देता है, सादगी खो जाती है। इसलिए, एक आवरण के रूप में टुकड़े से छुटकारा पाने और डायलॉग का सीधे उपयोग करना अच्छा होगा। ऐसा करने के लिए, आपको व्यू को फिर से बनाने के बाद उसे फिर से दिखाने के लिए डायल की स्थिति को स्टोर करना होगा और व्यू के मरने पर उसे छिपा देना होगा।
सभी को एक टीम के रूप में संवाद के प्रदर्शन को समझने के लिए उपयोग किया जाता है, खासकर यदि आप केवल एमवीपी के साथ काम करते हैं। राज्य की बाद की बहाली का कार्य FragmentManager द्वारा ग्रहण किया जाता है। लेकिन आप इस स्थिति को अलग तरह से देख सकते हैं और बातचीत को एक राज्य के रूप में देखना शुरू कर सकते हैं। पीएम या एमवीवीएम पैटर्न के साथ काम करते समय यह बहुत अधिक सुविधाजनक है।
यह देखते हुए कि अधिकांश अनुप्रयोग अब प्रतिक्रियात्मक दृष्टिकोण का उपयोग करते हैं, प्रतिक्रियाशील होने के लिए संवादों की आवश्यकता होती है। मुख्य कार्य उस श्रृंखला को तोड़ना नहीं है जो संवाद के प्रदर्शन को आरंभ करता है, और इसके परिणामस्वरूप एक परिणाम प्राप्त करने के लिए घटनाओं की प्रतिक्रियाशील धारा संलग्न करना है। जब आप कई डेटा स्ट्रीम में हेरफेर कर रहे हैं, तो PresentationModel / ViewModel पक्ष पर यह बहुत सुविधाजनक है।

हमने उपरोक्त सभी आवश्यकताओं को ध्यान में रखा और प्रतिक्रियात्मक रूप से संवाद प्रदर्शित करने के तरीके के साथ आए, जिसे हमने अपने आरएक्सपीएम पुस्तकालय में सफलतापूर्वक लागू किया (इसके बारे में एक अलग लेख है)।

समाधान के लिए खुद को एक पुस्तकालय की आवश्यकता नहीं होती है और इसे अलग से किया जा सकता है। "राज्य के रूप में संवाद" के विचार से प्रेरित होकर, आप ट्रेंडी ViewModel और LiveData के आधार पर एक समाधान बनाने की कोशिश कर सकते हैं। लेकिन मैं यह अधिकार पाठक पर छोड़ दूंगा, और फिर हम लाइब्रेरी से तैयार समाधान के बारे में बात करेंगे।

प्रतिक्रियाशील विधि

मैं दिखाऊंगा कि आरएक्सपीएम में प्रारंभिक कार्य कैसे हल किया जाता है, लेकिन पहले पुस्तकालय से प्रमुख अवधारणाओं के बारे में कुछ शब्द:

PresentationModel - एक प्रतिक्रिया स्थिति को संग्रहीत करता है, जिसमें यूआई-लॉजिक होता है, जीवित रहता है।
राज्य एक प्रतिक्रियाशील राज्य है । आप इसे BehaviorRelay पर एक आवरण के रूप में सोच सकते हैं।
एक्शन - पब्लिशरैल पर एक आवरण, घटनाओं को व्यू से प्रेजेंटेशनमॉडल में स्थानांतरित करने का कार्य करता है।
स्टेट और एक्शन में अवलोकन योग्य और उपभोक्ता हैं।

संवाद की स्थिति के लिए DialogControl वर्ग जिम्मेदार है। इसके दो मानदंड हैं: पहला उस प्रकार के डेटा के लिए जिसे संवाद में प्रदर्शित किया जाना चाहिए, दूसरा परिणाम के प्रकार के लिए। हमारे उदाहरण में, डेटा प्रकार यूनिट होगा, लेकिन यह उपयोगकर्ता या किसी अन्य प्रकार के लिए एक संदेश हो सकता है।

DialogControl के निम्नलिखित तरीके हैं:

show(data: T) - बस प्रदर्शित करने के लिए एक आदेश देता है।
showForResult(data: T): Maybe<R> - एक डायलॉग दिखाता है और परिणाम प्राप्त करने के लिए स्ट्रीम खोलता है।
sendResult(result: R) - परिणाम भेजता है, व्यू साइड से बुलाया जाता है।
dismiss() - बस संवाद छुपाता है।

DialogControl राज्य को संग्रहीत करता है - क्या स्क्रीन पर एक संवाद है या नहीं (प्रदर्शित / अनुपस्थित)। यह क्लास कोड में कैसा दिखता है:

 class DialogControl<T, R> internal constructor(pm: PresentationModel) { val displayed = pm.State<Display>(Absent) private val result = pm.Action<R>() sealed class Display { data class Displayed<T>(val data: T) : Display() object Absent : Display() } // ... }

एक सरल प्रस्तुति बनाएं:

 class SamplePresentationModel : PresentationModel() { enum class ConfirmationDialogResult { CONFIRMED, CANCELED } //        enum    val confirmationDialog = dialogControl<Unit, ConfirmationDialogResult>() val buttonClicks = Action<Unit>() override fun onCreate() { super.onCreate() buttonClicks.observable .switchMapMaybe { //           confirmationDialog.showForResult(Unit) .filter { it == ConfirmationDialogResult.CONFIRMED } } .subscribe { //   } .untilDestroy() } }

कृपया ध्यान दें कि एक ही श्रृंखला में प्रसंस्करण, पुष्टि पुष्टिकरण और कार्रवाई प्रसंस्करण पर क्लिक करें। यह आपको कोड को केंद्रित करने और कई कॉलबैक में तर्क को तितर बितर नहीं करने देता है।

अगला, हम बस डायलॉगकंट्रोल को बाइंडो एक्सटेंशन का उपयोग करके व्यू में बाँधते हैं।
हम सामान्य AlertDialog इकट्ठा करते हैं, और sendResult के माध्यम से परिणाम भेजते हैं:

 class SampleActivity : PmSupportActivity<SamplePresentationModel>() { override fun providePresentationModel() = SamplePresentationModel() //     View  PresentationModel override fun onBindPresentationModel(pm: SamplePresentationModel) { pm.confirmationDialog bindTo { data, dialogControl -> AlertDialog.Builder(this@SampleActivity) .setMessage("Please, confirm the action") .setPositiveButton("Confirm") { _, _ -> dialogControl.sendResult(CONFIRMED) } .setNegativeButton("Cancel") { _, _ -> dialogControl.sendResult(CANCELED) } .create() } button.clicks() bindTo pm.buttonClicks } }

एक विशिष्ट परिदृश्य में, हुड के नीचे ऐसा कुछ होता है:

हम बटन पर क्लिक करते हैं, एक्शन "बटन क्लिक्स" के माध्यम से घटना PresentationModel में मिलती है।
इस ईवेंट के लिए, हम कॉल के माध्यम से संवाद के प्रदर्शन को showForResult पर लॉन्च करते हैं।
परिणामस्वरूप, डायलॉगकॉन्ट्रोल में राज्य एब्सेंट से डिस्प्ले में बदल जाता है।
जब प्रदर्शित ईवेंट प्राप्त होता है, तो हम लंबो बाइंडिंग में पास हुए लंबो को कहते हैं। इसमें एक डायलॉग ऑब्जेक्ट बनाया जाता है, जिसे बाद में प्रदर्शित किया जाता है।
उपयोगकर्ता पुष्टिकरण बटन दबाता है, श्रोता आग लगाता है, और क्लिक का परिणाम SendResult को कॉल करके DialogControl को भेज दिया जाता है।
इसके बाद, परिणाम आंतरिक क्रिया "परिणाम" में गिर जाता है, और प्रदर्शित परिवर्तनों से अनुपस्थिति की स्थिति।
जब एक अनुपस्थित घटना प्राप्त होती है, तो वर्तमान संवाद बंद हो जाता है।
एक्शन "रिजल्ट" की घटना उस स्ट्रीम में आती है, जिसे कॉल के लिए शोफोर.स्कूल में खोला गया था और इसे प्रेजेंटेशनमॉडल में चेन द्वारा प्रोसेस किया गया है।

यह ध्यान देने योग्य है कि दृश्य तब भी बंद हो जाता है जब View PresentationModel से अछूता रहता है। इस स्थिति में, स्थिति प्रदर्शित रहती है। यह अगले बंधन में प्राप्त किया जाएगा और संवाद बहाल किया जाएगा।

जैसा कि आप देख सकते हैं, DialogFragment की आवश्यकता समाप्त हो गई है। जब संवाद PresentationModel से जुड़ा होता है और जब दृश्य अछूता होता है, तो संवाद दिखाया जाता है। इस तथ्य के कारण कि राज्य DialogControl में संग्रहीत किया जाता है, जो बदले में PresentationModel में संग्रहीत किया जाता है, डिवाइस को घुमाए जाने के बाद संवाद पुनर्स्थापित किया जाता है।

संवाद सही ढंग से लिखें

हमने संवाद प्रदर्शित करने के कई तरीकों की जांच की है। यदि आप अभी भी पहले तरीके से दिखा रहे हैं, तो मैं आपसे विनती करता हूं, अब ऐसा न करें। एमवीपी के प्रेमियों के लिए मानक पद्धति का उपयोग करने के अलावा कुछ नहीं बचा है, जिसे आधिकारिक दस्तावेज में वर्णित किया गया है। दुर्भाग्य से, इस पैटर्न की अपरिपक्वता की प्रवृत्ति अन्यथा करने की अनुमति नहीं देती है। खैर, मैं RxJava प्रशंसकों को प्रतिक्रियाशील विधि और हमारी RxPM लाइब्रेरी के बारे में जानने की सलाह देता हूं ।

Android में संवाद प्रदर्शित करने पर एक ताज़ा नज़र