गतिविधि और सेवा की सहभागिता की वास्तुकला का संगठन

नमस्ते!

आज मैंने आपको Android एप्लिकेशन में गतिविधि-सेवा सहभागिता को व्यवस्थित करने का मेरा तरीका बताया। विषय इस तथ्य से प्रेरित है कि अक्सर आप उन अनुप्रयोगों को पा सकते हैं जिनमें, कहते हैं, AsyncTask में गतिविधि के अंदर सर्वर की यात्रा आयोजित की जाती है। इसी समय, अक्सर एक सही विचार है कि यह सेवाओं में किया जाना चाहिए, लेकिन कार्यालय में कहीं नहीं। दस्तावेज़ीकरण उनके बीच दो-तरफ़ा बातचीत की सही वास्तुकला के संगठन के बारे में एक शब्द नहीं है।

इसलिए, परीक्षण और त्रुटि से मैं एक वास्तुकला में आया जो व्यक्तिगत रूप से मेरे लिए सभी आवश्यक मुद्दों को शामिल करता है।

मैं इस विधि के बारे में बाद में बात करूंगा।

हवाई दृश्य

आइए सबसे पहले प्रस्तावित वास्तुकला के एक उच्च-स्तरीय चित्र को देखें।

बाद में लेख में मैं दो शब्दों का उपयोग करूंगा - प्रबंधित और अप्रबंधित प्रतिक्रिया। ये अनौपचारिक शर्तें हैं, लेकिन मैं उनका उपयोग करूंगा, क्योंकि मैं उन्हें पसंद करता हूं। प्रबंधित - ये हमारे लिए Android प्लेटफ़ॉर्म (ContentProvider + ContentObserver system) द्वारा प्रदान की गई सूचनाएं हैं। UI को प्रबंधित सूचनाएं प्राप्त करने के लिए, हमें एक सही ढंग से कार्यान्वित प्रदाता के अलावा किसी चीज की आवश्यकता नहीं है।

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

तो, यह वास्तुकला प्रणाली के चार मुख्य घटकों की उपस्थिति का अर्थ है:

• एक मानक इंटरफ़ेस मानचित्रण भूमिका के रूप में कार्य करने वाली गतिविधि
• सेवा - एक सेवा जो पृष्ठभूमि के धागे में भारी काम करती है
• ServiceHelper - हमारा घटक जो हमारी गतिविधि और सेवा को एक साथ रखेगा और अनियंत्रित सूचनाएं प्रदान करेगा
• ContentProvider एक वैकल्पिक घटक है, जो आपके UI पर निर्भर करता है, जो प्रबंधित सूचनाओं को लागू करने में मदद करेगा।

सेवा

हमारी सेवा कमांड प्रोसेसर के रूप में कार्य करती है।

प्रत्येक आने वाले इरादे एक्स्ट्रा में वहन करती है:

• किए जाने की क्रिया
• आदेश द्वारा परिभाषित तर्क
• ResultReceiver

सेवा पारित कार्रवाई को देखती है, उसे उस कमांड पर मैप करती है जिसे निष्पादित करने की आवश्यकता होती है, और कमांड के तर्कों और ResultReceiver को पास करता है।

सेवा को लागू करने का सबसे आसान विकल्प:

protected void onHandleIntent(Intent intent) { String action = intent.getAction(); if (!TextUtils.isEmpty(action)) { final ResultReceiver receiver = intent.getParcelableExtra(EXTRA_STATUS_RECEIVER); if (AwesomeHandler.ACTION_AWESOME_ACTION.equals(action)) { new AwesomeHandler().execute(intent, getApplicationContext(), receiver); } // ..... } } 

यहां, बड़े में अगर ब्लॉक, वांछित कमांड बस खोज की जाती है। बेशक, यहां आप ड्राइव कर सकते हैं जैसा कि आप इफ्ता से बचने के लिए कर सकते हैं: मैप एक्शन-हैंडलर पकड़ो, एक कारखाना बनाओ, आईओसी का उपयोग करें, आदि, लेकिन यह लेख के दायरे से परे है।

हैंडलर

हैंडलर निष्पादन प्रक्रिया को अपने भीतर समाहित कर लेते हैं। मेरे लिए, वे एक निश्चित पदानुक्रम बनाते हैं, जहाँ आधार वर्ग दिखता है:

 public abstract class BaseIntentHandler { public static final int SUCCESS_RESPONSE = 0; public static final int FAILURE_RESPONSE = 1; public final void execute(Intent intent, Context context, ResultReceiver callback) { this.callback = callback; doExecute(intent, context, callback); } public abstract void doExecute(Intent intent, Context context, ResultReceiver callback); private ResultReceiver callback; private int result; public int getResult() { return result; } protected void sendUpdate(int resultCode, Bundle data) { result = resultCode; if (callback != null) { callback.send(resultCode, data); } } } 

पदानुक्रम के अगले स्तर पर, मैंने HTTP अनुरोध तैयार करने वाले मूल आदेश को लागू किया, लेकिन यह, फिर से, लेख के दायरे से परे है। सामान्य तौर पर, आप आधार कमांड से विरासत में लेते हैं और doExecute को कार्यान्वित करते हैं, जिसमें यदि आवश्यक हो, तो SendUpdate विधि को कॉल करें, कोड (सफलता / त्रुटि) और डेटा के साथ बंडल पास करें।

ServiceHelper

ServiceHelper UI और सेवा के बीच की एक मध्यवर्ती परत है, UI के लिए सेवा कॉल को सरल करता है, और पैकेजिंग इंटेंट के लिए नियमित संचालन करता है। वह सेवा से प्रतिक्रियाओं का समन्वय भी करता है और इसमें उन कमांडों के बारे में जानकारी होती है जो वर्तमान में चल रहे हैं।

तो यह कैसे काम करता है:

• UI कॉल सहायक विधि, सहायक रिटर्न अनुरोध आईडी
• हेल्पर को अनुरोध आईडी याद है
• एक इरादा एकत्र करता है जिसमें ResultReceiver योगदान देता है और इसे सेवा में भेजता है
• जब सेवा कार्य पूरा कर लेती है, तो सभी सुनने वाले UI घटक onReceiveResult में अधिसूचित हो जाते हैं

आइए कोड को देखें:

 public class ServiceHelper { private ArrayList<ServiceCallbackListener> currentListeners = new ArrayList<ServiceCallbackListener>(); private AtomicInteger idCounter = new AtomicInteger(); private SparseArray<Intent> pendingActivities = new SparseArray<Intent>(); private Application application; ServiceHelper(Application app) { this.application = app; } public void addListener(ServiceCallbackListener currentListener) { currentListeners.add(currentListener); } public void removeListener(ServiceCallbackListener currentListener) { currentListeners.remove(currentListener); } // ..... 

सहायक सेवा एक सरणी में ग्राहकों की एक सूची रखता है, यह इस सूची में है कि टीमों के काम पर सूचनाएं भेजी जाएंगी।

  private Intent createIntent(final Context context, String actionLogin, final int requestId) { Intent i = new Intent(context, WorkerService.class); i.setAction(actionLogin); i.putExtra(WorkerService.EXTRA_STATUS_RECEIVER, new ResultReceiver(new Handler()) { @Override protected void onReceiveResult(int resultCode, Bundle resultData) { Intent originalIntent = pendingActivities.get(requestId); if (isPending(requestId)) { pendingActivities.remove(requestId); for (ServiceCallbackListener currentListener : currentListeners) { if (currentListener != null) { currentListener.onServiceCallback(requestId, originalIntent, resultCode, resultData); } } } } }); return i; } 

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

  public boolean isPending(int requestId) { return pendingActivities.get(requestId) != null; } private int createId() { return idCounter.getAndIncrement(); } private int runRequest(final int requestId, Intent i) { pendingActivities.append(requestId, i); application.startService(i); return requestId; } 

अब एक सार्वजनिक विधि का एक उदाहरण जो हमारी सेवा पर कुछ कार्रवाई करेगा:

 public int doAwesomeAction(long personId) { final int requestId = createId(); Intent i = createIntent(application, AwesomeHandler.ACTION_AWESOME_ACTION, requestId); i.putExtra(AwesomeHandler.EXTRA_PERSON_ID, personId); return runRequest(requestId, i); } 

और इस तरह की विधियाँ पूरी तरह से उतनी ही होंगी जितनी आपकी सेवा का समर्थन करती हैं।

गतिविधि

इसलिए, जैसा कि मैंने कहा, हमारे पास एक इंटरफ़ेस है:

 public interface ServiceCallbackListener { void onServiceCallback(int requestId, Intent requestIntent, int resultCode, Bundle data); } 

मेरा मानना ​​है कि बुनियादी सार गतिविधि में इस इंटरफ़ेस को लागू करना सुविधाजनक है। फिर, विशिष्ट गतिविधियों में, आपको केवल सूचनाएं प्राप्त करने के लिए onServiceCallback विधि को फिर से परिभाषित करने की आवश्यकता होती है, जो गतिविधि में मानक कॉलबैक विधियों के समान है, अर्थात यह आपके ग्राहक कोड में सुशोभित है।

 public abstract class AwesomeBaseActivity extends FragmentActivity implements ServiceCallbackListener { private ServiceHelper serviceHelper; protected AwesomeApplication getApp() { return (AwesomeApplication ) getApplication(); } protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); serviceHelper = getApp().getServiceHelper(); } protected void onResume() { super.onResume(); serviceHelper.addListener(this); } protected void onPause() { super.onPause(); serviceHelper.removeListener(this); } public ServiceHelper getServiceHelper() { return serviceHelper; } public void onServiceCallback(int requestId, Intent requestIntent, int resultCode, Bundle resultData) { } } 

ध्यान दें कि एक्टिविटी सब्सक्राइबर्स और अनसब्सक्राइबर्स सर्विसहेल्पर से उसके ऑनस्क्यूम / ऑनपॉज के तरीकों को कैसे करती है। यह आपको गतिविधि को पुनर्व्यवस्थित करते समय समस्याओं से बचने की अनुमति देता है, उदाहरण के लिए, जब आप स्क्रीन को घुमाते हैं, या एप्लिकेशन को छोटा करते हैं।

आइए देखें कि हमें क्या आता है onServiceCallback:

• requestId - अनुरोध भेजते समय उत्पन्न अद्वितीय पहचानकर्ता
• requestIntent - मूल आशय जो हमने भेजा है
• परिणाम कोड - निष्पादन परिणाम कोड
• परिणामडेटा - डेटा

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

 class AwesomeActivity extends AwesomeBaseActivity { private int superRequestId; ... private void myMethod() { superRequestId = getServiceHelper().doAwesomeAction(); } public void onServiceCallback(int requestId, Intent requestIntent, int resultCode, Bundle resultData) { if (AwesomeHandler.ACTION_AWESOME_ACTION.equals(requestIntent.getAction()) { //   } if (requestId == superRequestId) { //   } } } 

इसके अलावा, अनुरोध आईडी होने पर, हम एक लंबित चेक का प्रदर्शन कर सकते हैं। अनुक्रम की कल्पना करें:

• उपयोगकर्ता ने कार्रवाई शुरू की, स्पिनर ने शुरू किया
• 2 मिनट के लिए आवेदन बंद कर दिया
• कार्रवाई पहले ही पूरी हो चुकी है
• उपयोगकर्ता फिर से खोला गया
• यहाँ हम onResume में जाँच करते हैं कि क्या ऑपरेशन पूरा हो गया था और ट्विस्ट को हटा दें

यानी अगर हमें जरूरत है तो बस getServiceHelper () .Pending (रिक्वेस्ट) कॉल करें।

निष्कर्ष

शायद यही सब है।

मुझे तुरंत कहना होगा कि मैं इस वास्तुकला की सार्वभौमिकता या इसकी किसी विशिष्टता का ढोंग नहीं करता। यह मेरे द्वारा परीक्षण और त्रुटि, विभिन्न सामग्रियों के विचारों आदि के माध्यम से धीरे-धीरे हटा दिया गया था, लेकिन अब तक, यह वास्तविक वाणिज्यिक परियोजनाओं के लिए मेरी सभी जरूरतों को 100% कवर करता है।

इसके अलावा, अगर कुछ गायब है, तो इसे आसानी से विस्तारित किया जा सकता है। स्पष्ट से:

• प्रगति कोड को सफलता और विफलता के अलावा जोड़ दें, तो सेवा से कार्य की प्रगति के बारे में जानकारी संचारित करना और इसे प्रदर्शित करना संभव होगा, ProgressBar कहते हैं
• कार्य को बाधित करने के लिए कोड को जकड़ना
• और एम। पी।

एक अन्य विवरण, मेरा ServiceHelper कोड सिंक्रनाइज़ नहीं है, क्योंकि यह समझा जाता है कि इसके तरीकों को हमेशा UI थ्रेड में कहा जाएगा। यदि आपके साथ ऐसा नहीं है, तो आपको ServiceHelper की स्थिति में किसी भी परिवर्तन के लिए सिंक्रनाइज़ेशन जोड़ने की आवश्यकता है ।

सामान्य तौर पर, आपके ध्यान के लिए धन्यवाद, मुझे आशा है कि कोई आपकी मदद करेगा। टिप्पणियों में आपके सवालों और टिप्पणियों का जवाब देने के लिए तैयार हैं।

UPD : मैंने GitHub पर वास्तुकला का चित्रण करते हुए एक छोटा सा सैंडबॉक्स उदाहरण पोस्ट किया: https://github.com/TheHiddenDuck/android-service-arch

UPD 2 : थ्रेड पूल पर चलने वाली सेवा को लागू करने का एक उदाहरण है