android software क्या एक आवेदन छोड़ दिया जा रहा है?




android system download (24)

एंड्रॉइड सीखने के अपने प्रयास में आगे बढ़ते हुए, मैंने बस निम्नलिखित पढ़ा है :

प्रश्न: क्या उपयोगकर्ता के पास एप्लिकेशन को मारने का कोई विकल्प नहीं है जब तक कि हम इसे मारने के लिए मेनू विकल्प नहीं डालते? यदि ऐसा कोई विकल्प मौजूद नहीं है, तो उपयोगकर्ता एप्लिकेशन को कैसे समाप्त कर सकता है?

उत्तर: (रोमैन गाय): उपयोगकर्ता नहीं करता है, सिस्टम स्वचालित रूप से इसे संभालता है। गतिविधि जीवन चक्र (विशेष रूप से ऑन पॉज़ / ऑनस्टॉप / ऑनडेस्ट्राय) के लिए यही है। कोई फर्क नहीं पड़ता कि आप क्या करते हैं, "छोड़ें" या "बाहर निकलें" एप्लिकेशन बटन न डालें। यह एंड्रॉइड के एप्लिकेशन मॉडल के साथ बेकार है। यह भी कोर अनुप्रयोगों के काम के विपरीत है।

हे, मैं एंड्रॉइड दुनिया में हर कदम के लिए कुछ समस्या में भाग जाता हूं = (

जाहिर है, आप एंड्रॉइड में किसी एप्लिकेशन को नहीं छोड़ सकते हैं (लेकिन जब भी ऐसा लगता है तो एंड्रॉइड सिस्टम पूरी तरह से आपके ऐप को पूरी तरह से नष्ट कर सकता है)। उसके साथ क्या है? मुझे लगता है कि एक ऐसा ऐप लिखना असंभव है जो "सामान्य ऐप" के रूप में कार्य करता है - जब उपयोगकर्ता ऐसा करने का निर्णय लेता है तो उपयोगकर्ता ऐप छोड़ सकता है। यह ऐसा कुछ नहीं है जिसे ओएस पर निर्भर किया जाना चाहिए।

मैं जिस एप्लिकेशन को बनाने की कोशिश कर रहा हूं वह एंड्रॉइड मार्केट के लिए एक एप्लीकेशन नहीं है। यह आम जनता द्वारा "व्यापक उपयोग" के लिए एक आवेदन नहीं है, यह एक व्यावसायिक ऐप है जिसका उपयोग बहुत ही सीमित व्यापार क्षेत्र में किया जा रहा है।

मैं वास्तव में एंड्रॉइड मंच के लिए विकास करने की उम्मीद कर रहा था, क्योंकि यह विंडोज मोबाइल और .NET में मौजूद कई मुद्दों को संबोधित करता है। हालांकि, पिछले हफ्ते मेरे लिए कुछ हद तक टर्नऑफ रहा है ... मुझे आशा है कि मुझे एंड्रॉइड छोड़ना पड़ेगा, लेकिन यह अभी बहुत अच्छा नहीं दिख रहा है = (

क्या वास्तव में एप्लिकेशन को छोड़ने का कोई तरीका है?


यह बहस पुराने उम्र के सवाल के लिए उबलती है कि क्या डेवलपर्स सर्वश्रेष्ठ जानते हैं या उपयोगकर्ता सबसे अच्छा जानता है या नहीं। मानव कारकों के सभी क्षेत्रों में पेशेवर डिजाइनर हर दिन इसके साथ संघर्ष करते हैं।

टेड ने एक मुद्दा बनाया है कि बाजार पर सबसे डाउनलोड किए गए ऐप्स में से एक 'ऐप किलर' है। जब वे आवेदन छोड़ देते हैं तो लोग थोड़ा अतिरिक्त सेरोटोनिन प्राप्त करते हैं। उनका उपयोग डेस्कटॉप / लैपटॉप के साथ किया जाता है। यह चीजें तेजी से आगे बढ़ता रहता है। यह प्रोसेसर को ठंडा रखता है और प्रशंसक चालू होने से रोकता है। यह कम शक्ति का उपयोग करता है।

जब आप मानते हैं कि एक मोबाइल डिवाइस एक बहुत छोटा जहाज है, तो आप विशेष रूप से 'अब जिस चीज की आवश्यकता नहीं है उसे फेंकने' के लिए उनके प्रोत्साहन की सराहना कर सकते हैं। अब एंड्रॉइड के डेवलपर्स ने तर्क दिया है कि ओएस सर्वश्रेष्ठ जानता है और एक ऐप छोड़ना प्राचीन है। मैं पूरी तरह से इसका समर्थन करता हूं।

हालांकि, मुझे यह भी विश्वास है कि आपको उपयोगकर्ता को निराश नहीं करना चाहिए, भले ही वह निराशा उनकी अपनी अज्ञानता से उत्पन्न हो। इसके कारण, मैंने निष्कर्ष निकाला है कि 'छोड़ो' विकल्प अच्छा डिजाइन है, भले ही यह अधिकतर प्लेसबो बटन है जो दृश्य को बंद करने से ज्यादा कुछ नहीं करता है।


मैं इस धागे के भविष्य के पाठकों के लिए यहां एक सुधार जोड़ना चाहता हूं। यह विशेष ज्ञान लंबे समय से मेरी समझ से बच निकला है, इसलिए मैं यह सुनिश्चित करना चाहता हूं कि आप में से कोई भी एक ही गलती न करे:

यदि आपके पास स्टैक पर एक से अधिक गतिविधि हैं तो System.exit() आपके ऐप को नहीं मारता है। वास्तव में क्या होता है कि प्रक्रिया मारे जाती है और स्टैक पर एक कम गतिविधि के साथ तुरंत पुनरारंभ होता है। यह तब भी होता है जब आपका ऐप फोर्स क्लोज डायलॉग द्वारा मारा जाता है, या जब भी आप डीडीएमएस से प्रक्रिया को मारने का प्रयास करते हैं। यह एक तथ्य है जो पूरी तरह से अनौपचारिक है, मेरे ज्ञान के लिए।

संक्षिप्त जवाब यह है कि, यदि आप अपने आवेदन से बाहर निकलना चाहते हैं, तो आपको अपने स्टैक में सभी गतिविधियों का ट्रैक रखना होगा और उन सभी को पूरा करना होगा जब उपयोगकर्ता बाहर निकलना चाहते हैं (और नहीं, इसके माध्यम से फिर से शुरू करने का कोई तरीका नहीं है गतिविधि स्टैक, इसलिए आपको इसे स्वयं प्रबंधित करना होगा)। यहां तक ​​कि यह वास्तव में प्रक्रिया या आपके किसी भी हानिकारक संदर्भ को मार नहीं सकता है। यह बस गतिविधियों को खत्म करता है। साथ ही, मुझे यकीन नहीं है कि Process.killProcess(Process.myPid()) किसी भी बेहतर काम करता है; मैंने इसका परीक्षण नहीं किया है।

यदि, दूसरी तरफ, आपके लिए आपके ढेर में गतिविधियां शेष हैं, तो एक और तरीका है जो चीजों को आपके लिए बहुत आसान बनाता है: Activity.moveTaskToBack(true) बस आपकी प्रक्रिया को पृष्ठभूमि और होम स्क्रीन दिखाएगा।

लंबे उत्तर में इस व्यवहार के पीछे दर्शन की व्याख्या शामिल है। दर्शन कई मान्यताओं से पैदा हुआ है:

  1. सबसे पहले, यह तब होता है जब आपका ऐप अग्रभूमि में होता है। अगर यह पृष्ठभूमि में है तो प्रक्रिया ठीक हो जाएगी। हालांकि, अगर यह अग्रभूमि में है, तो ओएस मानता है कि उपयोगकर्ता जो कुछ भी कर रहा था वह करना जारी रखना चाहता है। (यदि आप डीडीएमएस से प्रक्रिया को मारने की कोशिश कर रहे हैं, तो आपको पहले होम बटन दबा देना चाहिए, और फिर इसे मारना चाहिए)
  2. यह भी मानता है कि प्रत्येक गतिविधि अन्य सभी गतिविधियों से स्वतंत्र है। यह अक्सर सच होता है, उदाहरण के लिए यदि आपका ऐप ब्राउज़र गतिविधि लॉन्च करता है, जो पूरी तरह से अलग है और आपके द्वारा नहीं लिखा गया था। ब्राउज़र गतिविधि अपने प्रकट गुणों के आधार पर, उसी कार्य पर बनाई जा सकती है या नहीं भी हो सकती है।
  3. यह मानता है कि आपकी प्रत्येक गतिविधियां पूरी तरह आत्मनिर्भर है और एक पल की सूचना में उसे मार / बहाल किया जा सकता है। (मैं इस विशेष धारणा को नापसंद करता हूं, क्योंकि मेरे ऐप में कई गतिविधियां हैं जो बड़ी संख्या में कैश किए गए डेटा पर भरोसा करती हैं, जो कि onSaveInstanceState दौरान कुशलता से क्रमबद्ध करने के लिए बहुत बड़ी है, लेकिन onSaveInstanceState क्या onSaveInstanceState ?) अधिकांश अच्छी तरह से लिखित एंड्रॉइड ऐप्स के लिए यह सच होना चाहिए , क्योंकि आप कभी नहीं जानते कि पृष्ठभूमि में आपका ऐप कब मारा जा रहा है।
  4. अंतिम कारक इतना धारणा नहीं है, बल्कि ओएस की सीमा है: ऐप को मारना स्पष्ट रूप से ऐप क्रैशिंग जैसा ही है, और एंड्रॉइड के समान ही स्मृति को पुनः प्राप्त करने के लिए ऐप को मारना। यह हमारे कूप डी ग्रेस में समाप्त होता है: चूंकि एंड्रॉइड यह नहीं बता सकता कि ऐप से बाहर निकला या दुर्घटनाग्रस्त हो गया था या नहीं, यह मानता है कि उपयोगकर्ता वापस लौटना चाहता है जहां उन्होंने छोड़ा था, और इसलिए गतिविधि प्रबंधक प्रक्रिया को पुनरारंभ करता है।

जब आप इसके बारे में सोचते हैं, तो यह मंच के लिए उपयुक्त है। सबसे पहले, यह तब होता है जब पृष्ठभूमि में प्रक्रिया मारे जाती है और उपयोगकर्ता इसके पास वापस आ जाता है, इसलिए इसे फिर से शुरू किया जाना चाहिए जहां यह छोड़ा गया था। दूसरा, यह तब होता है जब ऐप दुर्घटनाग्रस्त बल बंद संवाद को क्रैश और प्रस्तुत करता है।

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

तो, मेरी समापन सलाह:

  • प्रक्रिया को मारने की कोशिश मत करो। या तो सभी गतिविधियों पर कॉल finish() या moveTaskToBack(true) कॉल करें।
  • यदि आपकी प्रक्रिया दुर्घटनाग्रस्त हो जाती है या मार जाती है, और यदि, मेरे जैसे, आपको उस डेटा की आवश्यकता है जो स्मृति में थी जो अब खो गया है, तो आपको रूट गतिविधि पर वापस लौटना होगा। ऐसा करने के लिए, आपको Intent.FLAG_ACTIVITY_CLEAR_TOP startActivity() को उस इरादे से कॉल करना चाहिए जिसमें Intent.FLAG_ACTIVITY_CLEAR_TOP ध्वज शामिल है।
  • यदि आप ग्रहण डीडीएमएस परिप्रेक्ष्य से अपने ऐप को मारना चाहते हैं, तो यह अग्रभूमि में बेहतर नहीं था, या यह स्वयं को पुनरारंभ करेगा। आपको पहले होम बटन दबाएं, और फिर प्रक्रिया को मार दें।

I would consider reading "Android Wireless Application Development" published by Addison-Wesley. I am just finishing it up and it is VERY thorough.

It appears that you have some fundamental misunderstandings of the Android platform. I too was a little frustrated at first with the application life-cycle of Android apps, but after coming to a greater understanding, I have come to really enjoy this approach. This book will answer all of your questions and much more. It really is the best resource I have found for new Android developers.

Also, I think you need to let go of a line-for-line port of the existing app. In order to port your application to the Android platform, some of the application design is going to change. The application-lifecycle used is necessary as mobile devices have very limited resources relative to desktop systems and allows Android devices to run several applications in an orderly and resource-aware fashion. Do some more in depth study of the platform, and I think you will realize that what you are wanting to do is entirely feasible. Best of luck.

By the way, I am no way affiliated with Addison-Wesley or any person or organization associated with this book. After re-reading my post I feel that I came off a little fanboyish. I just really, really enjoyed it and found it extremely helpful. :)


As an Application in an Android context is just a bunch of vaguely related Activities, quitting an Application doesn't really make much sense. You can finish() an Activity, and the view of the previous Activity in the Activity stack will be drawn.


You apparently have found the answer you want in the finish() command. This will not remove your app from memory, but Android will do so whenever it needs the resources, so it doesn't make any difference that you won't be doing that explicitly.

I would only add that in order to attain the full effect that an application exit would typically have, you would want to reset the app's state to whatever its state is normally at the time it is first run after a boot of the device, just prior to calling finish() on all of your activities. That way, if the user selects your app again, it will appear to have been run "fresh," without any state left over from the point prior to the simulated "exit."

If there are some special actions that should only occur on "exit," such as saving the user's work or whatever, you can also perform them prior to the re-initialization part of the above routine.

This approach allows you to accomplish your goal of having an "exit" command without violating Android's philosophy of leaving the management of OS resources, including the closing of apps, in the hands of the operating system.

Personally, I would not use this approach, because Android users expect an app to preserve its continuity when they revisit it, and so they are not used to the modality of "exiting" an app. I would instead support a "clear" function that a user can invoke to reset the app to some default initial state, without the necessity of "leaving" it in the process.

The one exception would be when the user has hit the back button a sufficient number of times to cause the app to close. In that situation, there is no expectation on the user's part that state will have been saved (and if there is unsaved state in the app, then you, as the developer, should have code handling the back button that detects that unsaved data, and prompts the user to save it to SharedPreferences or to a file, or to some other non-volatile medium).

Regarding system.exit(0):

If you do decide to use system.exit(0) to close your app with rude finality (eg, as a result of a final back button press), then I would warn you that although for me this "works," and in some cases has been the only way I've been able to close an app without any trace of it remaining, there is one minor glitch that occurs in Jelly Bean when you use this approach.

Specifically, if you use the Recent Apps list to open your app, and then use the back button to close the app (with that close implemented via system.exit(0)), the Recent Apps list will become visible again, as it will never have been closed. If you then tap on your app's entry in that list to run it a second time from the same, already-open, Recent Apps list, there will be no response.

I suspect that the cause of this is that the Recent Apps list is holding on to a reference to your app that has become non-functional due to your having closed the app using system.exit(0). A more civilized closing of your app using finish() might have informed the OS in a manner that would have allowed it to refresh its Recent Apps list, but system.exit(0) apparently does not do this.

This is not a huge problem in and of itself, as very few people will open an app from Recent Apps, then exit it, and then immediately open it again from the same open Recent Apps list. And if they tap the home button and then re-open the Recent Apps list, your app's entry will be there, and it will be fully functional. But I think that it shows that the use of system.exit(0) can interfere with proper communication between your app and the OS, and this suggests that there may be other, more serious, possibly subtle, consequences of using this approach.


Every time while you move to the next page through intent, use:

`YourActivityname.this.finish()`;

उदाहरण:

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

So that no activity will be running on background and when you want to Exit your app, use:

MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();

This exiting worked like a charm for me :)


यह अंततः आपके प्रश्न पर पहुंच जाएगा, लेकिन मैं पहले इस लेखन के समय पहले से दिए गए विभिन्न उत्तरों के लिए आपकी विभिन्न टिप्पणियों में उठाए गए कई मुद्दों को संबोधित करना चाहता हूं। मुझे आपके दिमाग को बदलने का कोई इरादा नहीं है - बल्कि, ये यहां दूसरों के लिए हैं जो भविष्य में इस पोस्ट को पढ़ने के लिए आते हैं।

मुद्दा यह है कि मैं एंड्रॉइड को यह निर्धारित करने की अनुमति नहीं दे सकता कि मेरा ऐप कब समाप्त हो जाएगा। यह उपयोगकर्ता की पसंद होना चाहिए।

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

आईफोन उपयोगकर्ता बहुत समान हैं, आईफोन बटन दबाकर ऐप को समाप्त होने की तरह "महसूस" नहीं होता है, क्योंकि कई आईफोन एप्स उठाते हैं जहां उपयोगकर्ता ने छोड़ा था, भले ही ऐप वास्तव में बंद हो गया हो (केवल आईफोन के बाद से वर्तमान में एक समय में एक तिहाई पार्टी ऐप की अनुमति देता है)।

जैसा कि मैंने उपर्युक्त कहा है, मेरे ऐप में बहुत सी चीजें चल रही हैं (डेटा को डिवाइस पर पुश किया जा रहा है, कार्यों के साथ सूचीबद्ध है जो हमेशा वहां होना चाहिए, आदि)।

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

हमारे उपयोगकर्ता लॉग इन करते हैं और ऐसा नहीं कर सकते हैं जब भी उन्हें फोन कॉल मिलता है और एंड्रॉइड ऐप को मारने का फैसला करता है।

ऐसे कई आईफोन और एंड्रॉइड एप्लिकेशन हैं जो इससे निपटते हैं। आमतौर पर, ऐसा इसलिए होता है क्योंकि उपयोगकर्ता मैन्युअल रूप से लॉग इन करने के लिए उपयोगकर्ताओं को मजबूर करने के बजाय लॉगऑन प्रमाण-पत्रों पर निर्भर करते हैं।

उदाहरण के लिए, हम एप्लिकेशन से बाहर निकलने पर अपडेट देखना चाहते हैं

यह किसी भी ऑपरेटिंग सिस्टम पर एक गलती है। आप सभी जानते हैं कि आपका एप्लिकेशन "बाहर निकलने" का कारण है क्योंकि ओएस बंद हो रहा है, और फिर आपकी अपडेट प्रक्रिया मध्य-स्ट्रीम में विफल हो जाएगी। आम तौर पर, यह एक अच्छी बात नहीं है। या तो शुरूआत पर अद्यतनों की जांच करें या पूरी तरह से असीमित रूप से अद्यतनों की जांच करें (उदाहरण के लिए, एक निर्धारित कार्य के माध्यम से), बाहर निकलने पर कभी नहीं।

कुछ टिप्पणियों से पता चलता है कि बैक बटन मारना ऐप को बिल्कुल नहीं मारता है (उपरोक्त मेरे प्रश्न में लिंक देखें)।

बैक बटन दबाकर "ऐप को मारना" नहीं है। यह उस गतिविधि को समाप्त करता है जो स्क्रीन पर था जब उपयोगकर्ता ने बैक बटन दबाया था।

इसे केवल तभी समाप्त करना चाहिए जब उपयोगकर्ता इसे समाप्त करना चाहते हैं - कभी भी कोई अन्य तरीका नहीं। यदि आप एंड्रॉइड में ऐसा व्यवहार लिखने वाले ऐप्स नहीं लिख सकते हैं, तो मुझे लगता है कि एंड्रॉइड का उपयोग वास्तविक ऐप्स लिखने के लिए नहीं किया जा सकता है = (

फिर न तो वेब अनुप्रयोग कर सकते हैं। या WebOS , अगर मैं उनके मॉडल को सही ढंग से समझता हूं (अभी तक एक के साथ खेलने का मौका नहीं मिला है)। उन सभी में, उपयोगकर्ता कुछ भी "समाप्त" नहीं करते हैं - वे बस छोड़ देते हैं। आईफोन थोड़ा अलग है, जिसमें यह केवल एक समय में एक चीज चलाने के लिए अनुमति देता है (कुछ अपवादों के साथ), और इसलिए छोड़ने का कार्य ऐप की काफी तत्काल समाप्ति का तात्पर्य है।

क्या वास्तव में एप्लिकेशन को छोड़ने का कोई तरीका है?

जैसा कि सभी ने आपको बताया है, उपयोगकर्ता (बैक के माध्यम से) या आपका कोड ( finish() माध्यम से) वर्तमान में चल रहे गतिविधि को बंद कर सकते हैं। उपयोगकर्ताओं को आम तौर पर वेब अनुप्रयोगों का उपयोग करने के लिए "छोड़ने" विकल्प की आवश्यकता के मुकाबले उचित रूप से लिखित अनुप्रयोगों के लिए किसी और चीज की आवश्यकता नहीं होती है।

परिभाषा के अनुसार, कोई भी दो अनुप्रयोग वातावरण समान नहीं हैं। इसका मतलब यह है कि आप वातावरण में रुझान देख सकते हैं क्योंकि नए लोग उठते हैं और दूसरों को दफनाया जाता है।

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

इसी प्रकार, एक ऐप को "समाप्त करने" की धारणा को खत्म करने की कोशिश करने के लिए एक बढ़ती हुई आंदोलन है। अधिकांश वेब अनुप्रयोग उपयोगकर्ता को लॉग आउट करने के लिए बाध्य नहीं करते हैं, बल्कि निष्क्रियता की अवधि के बाद उपयोगकर्ता को स्पष्ट रूप से लॉग आउट करते हैं। एंड्रॉइड के साथ वही बात, और कुछ हद तक, आईफोन (और संभवतः वेबोस)।

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

उदाहरण के लिए, कुछ विकास वातावरण, जैसे Hypercard और स्मॉलटाक, में एक सेटअप में अनुप्रयोग और विकास उपकरण सह-मिलते थे। इस अवधारणा को ऐप्स पर भाषा एक्सटेंशन के बाहर बहुत कुछ नहीं मिला (उदाहरण के लिए, Excel में वीबीए, ऑटोकैड में लिस्प )। डेवलपर्स जो मानसिक मॉडल के साथ आए थे, जो ऐप में विकास उपकरण के अस्तित्व को मानते थे, इसलिए उन्हें या तो अपने मॉडल को बदलना पड़ा या अपने आप को उन वातावरणों तक सीमित करना पड़ा जहां उनका मॉडल सच रहेगा।

तो, जब आप लिखते हैं:

मैंने पाया कि अन्य गन्दा चीजों के साथ, मुझे लगता है कि एंड्रॉइड के लिए हमारे ऐप का विकास नहीं होने वाला है।

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


In any case, if you want to terminate your application you can always call System.exit(0);


Without an exit function for the application developer to kill their own application it is very bad design.

My application needs to allow the user to dynamically change data dynamically during runtime and the user needs to restart my application to make the change effect, but Android did not allow my application restart by itself. Android OS has a very bad design application life cycle.


For closing an app at any point use FLAG_ACTIVITY_CLEAR_TOP flag in Intent and then system.exit();

Or there is similar way, but without system.exit() when you want to exit call this method:

public void exit() {
    startActivity(new Intent(this, HomeActivity.class).
    setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}

In your HomeActivity.onCreate() add following code

protected void onCreate(Bundle savedInstanceState) {
    if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
        if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
            finish();
        }
    }
......................

This will work without breaking the Android life-cycle.


ब्लॉग पोस्ट एंड्रॉइड ऐप में एक एक्जिट बटन शामिल करने के लिए कब (संकेत: कभी नहीं) इसे बताता है, जितना संभव हो उतना बेहतर है। मेरी इच्छा है कि हर एंड्रॉइड डेवलपर ने इसे पहले ही पढ़ा है।

कुछ अंशः

मेरे अनुभव में [उपयोगकर्ता] वास्तव में क्या चाहते हैं: यह गारंटी देने का एक स्पष्ट तरीका है कि एक ऐप संसाधनों (बैटरी, सीपीयू चक्र, डेटा स्थानांतरण इत्यादि) का उपभोग बंद कर देगा।

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

  • ज्यादातर मामलों में निकास बटन बस Activity.finish() कॉल करता है। यह बैक बटन मारने के बराबर है। ठीक ठीक। सेवाएं चलती रहती हैं और मतदान होता रहता है। उपयोगकर्ता सोच सकते हैं कि उन्होंने ऐप को मार दिया है लेकिन वे नहीं हैं, और जल्द ही वे और भी परेशान होंगे।
  • बाहर निकलने का व्यवहार अब संदिग्ध है। क्या आपका निकास बटन सिर्फ गतिविधि को बंद कर देना चाहिए, या क्या यह सभी संबंधित सेवाओं, रिसीवर और अलार्म को भी रोकना चाहिए? वापस क्या करना चाहिए? अगर वे घर पर हिट करते हैं तो क्या होता है? यदि आपके ऐप में विजेट है तो क्या होगा? क्या निकास बटन को अद्यतन करने से रोकना चाहिए?

The solution is to make the back button behave as you'd expect the exit button to. Better yet, simply stop consuming resources whenever the app isn't visible.

Go ahead and read the complete article.


If you have 10,20 .. multiple Activities running and you want to finish all them and exit from system.

Create a static array in application class or constants class.

Constants

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

मुख्य क्रियाशीलता इस सरणी में वर्तमान गतिविधि संदर्भ जोड़ें

activity = MainActivity.this; Constants.activities.add(activity);

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        activity = MainActivity.this;
        Constants.activities.add(activity);

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}

I agree with Ted. I understand that exiting the application is not the "Android way", but it doesn't seem like it should be precluded. Here are three reasons why you might want a real exit to the application (not just the activity):

  1. The user might want some control over which app gets killed in the case of low memory. If important app A is running in the background, then you might like to exit app B when you are done with it so that app A doesn't get killed by the operating system.

  2. If your application has sensitive data cached in memory, you might like to kill the app so that a virus/worm/rogue app can't get at it. I know the security model is supposed to prevent that, but just in case...

  3. If your application uses resources (like network, CPU, sensors, etc.) that could adversely affect the phone, then one way of ensuring that those resources are freed up is to exit the application. I understand that well-behaved apps should free up resources when they are not needed. But again, exiting the application seems like a reasonable way of ensuring that.


First of all, never never never use System.exit(0). It is like making a person sleep punching him on the head!

Second: I'm facing this problem. Before sharing my solution a I want to share my thoughts.

I think that an "Exit Button" is stupid. Really really really stupid. And I think that users (consumer) that ask for an exit button for your application is stupid too. They don't understand how the OS is working and how is managing resources (and it does a great job).

I think that if you write a good piece of code that do the right things (updates, saves, and pushes) at the right moment and conditions and using the correct things (Service and Receiver) it will work pretty well and no one will complain.

But to do that you have to study and learn how things works on Android. Anyway, this is my solution to provide to users an "Exit Button".

I created an Options Menu always visible in each activity (I've a super activity that do that).

When the user clicks on that button this is what happens:

Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);

  // Commit the edits!
editor.commit();
startActivity(intent);
finish();

So I'm saving in SharedPreferences that I want to kill my app, and I start an Intent. Please look at those flags; those will clear all my backstack calling my DashBoard Activity that is my "home" activity.

So in my Dashboard Activity I run this method in the onResume:

private void checkIfForceKill() {

    // CHECK IF I NEED TO KILL THE APP

    // Restore preferences
    SharedPreferences settings = getSharedPreferences(
            getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
    boolean forceKill = settings.getBoolean(
            MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);

    if (forceKill) {

        //CLEAR THE FORCE_EXIT SETTINGS
        SharedPreferences.Editor editor = settings.edit();
        editor.putBoolean(FORCE_EXIT_APPLICATION, false);

        // Commit the edits!
        editor.commit();

        //HERE STOP ALL YOUR SERVICES
        finish();
    }
}

And it will work pretty well.

The only thing that I don't understand why it's happening is that when I do the last finish (and I've checked: it's following all the correct flow of onPause → onStop → onDestroy) the application is still on the recent activity (but it's blank).

It seems like the latest intent (that has started the DashboardActivity) is still in the system.

I've to dig more in order to also remove it.


Almost 99% of the time there is no need for an Android application to take over its own life cycle. Most of the time it comes down to better planning or smarter design of the application. For example, rather build an internal service (not exported) to handle downloads, etc., or design actions and tasks around user workflow.

But that being said, where there is a will there is a way. Android provides - through the android.os.Process class, a much better API than Java to control the underlying process. And unlike Java it does not treat the developer like a moron by hiding it all behind a simple java.lang.System.exit() call.

So how do you ask your application to commit suicide in Android? Well, the trick is simple:

Create your own Android application class by inheriting from the standard android.app.Application class (remember to declare it in the AndroidManifest.xml file).

Override the onCreate() method, and store the process ID which started your application:

this.pid = android.os.Process.myPid(); // Save for later use.

Now to kill your application, provide a kill() method:

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

Now whenever you need your app to commit suicide just type cast the application context, and call your kill method!

((MySuicidalApp) context.getApplicationContext()).kill()

Just remember that due to the process management policies in Android, specifically related to services, Android may just opt to restart your service (see You should not use task killers on Android ).


Hmmmm...

I think that you just don't see the Android app the right way. You can do something almost like what you want easily:

  • Do the app activities save/restore state like it is encouraged in the developer livecycle documentation.

  • If some login is needed at the restore stage (no login/session information available) then do it.

  • Eventually add a button/menu/timeout in which case you will do a finish() without saving the login and other session info, making implicitly the end of app session: so if the app is started/brought to front again it will start a new session.

That way you don't really care if the app is really removed from memory or not.

If you really want to remove it from memory (this is discouraged, and BTW for what purpose?) you can kill it conditionally at the end of onDestroy() with java.lang.System.exit(0) (or perhaps restartPackage(..) ?). Of course do it only in the case where you want to "really end the app", because the onDestroy() is part of the normal lifecycle of activities and not an app end at all.


It took me longer to read this Q&A than to actually implement a semi-proper Android Application Lifecycle.

It's a GPS app that polls for points and sends the current location to a webservice every few seconds using a thread... This could be polling every 5 minutes in Ted's case for an update, then onStop can simply start the update activity Ted was soo concerned about if one was found (asynchronous Ted, don't code like a Windows programmer or your programs will run like Windows programs ... eww, it's not that hard).

I did some initial code in onCreate to set up things for the activity lifetime, including checkUpdate.start(); :

...

@Override
public void onStart() {
    super.onStart();
    isRemote = true;
    checkUpdate.resume();

    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}

@Override
public void onPause() {
    isRemote = false;
    checkUpdate.suspend();
    locationManager.removeUpdates(luh);
    super.onStop();
}

This code may be completely wrong, but it works. This is one of my first Android applications.

Voilà, an application that doesn't consume CPU when it's in the background, yet is instantly ready to reopen because it is in RAM (although not holding RAM as is the Android lifecycle) ... an app is always ready, it's a phone, guys/gals. If an app was to use up all the RAM and couldn't be shut down by the OS then the thing might stop ringing =P That's why the OS needs to be able to close your app when it's in the background (if your application isn't a resource hog it won't be closed BTW), so let's just write better applications.


When I conceive an application in Android, I see it this way:

  • You are working with your application
  • The phone rang
  • You take the call
  • At the end of the call, you come back to your application at the same place you were

To do that, you only need the Back button or the Home button of your phone (either by short or long press) and the notification bar.

When I exit my application, I only use the Back button until I am out of it or the Home button.

That's how most of the applications are conceived I think. But if I need some sort of session or connection, I made it clear to the user with a login/logout button and notification (title bar or anything else). This is a rather different style than the pure "exit" style application.

On PCs, you have a multi-GUI desktop, and on Android, you obviously have multi-tasks, but you only display one app at a time (I don't consider widgets here ^^). And on a mobile phone, at anytime, you could have a notification for something more important than what you are doing.

So the whole concept of an application rely on something different that "enter application - work - exit application".


There is a (relatively) simple design which will allow you to get around the "exit" conundrum. Make your app have a "base" state (activity) which is just a blank screen. On the first onCreate of the activity, you can launch another activity that your app's main functionality is in. The "exit" can then be accomplished by finish()ing this second activity and going back to the base of just a blank screen. The OS can keep this blank screen in memory for as long as it wants...

In essence, because you cannot exit out to OS, you simply transform into a self-created nothingness.


मेरे सभी एप्लिकेशन ने बटन छोड़ दिए हैं ... और इसके कारण उपयोगकर्ताओं से मुझे अक्सर सकारात्मक टिप्पणियां मिलती हैं। मुझे कोई परवाह नहीं है कि मंच को इस तरह से डिजाइन किया गया था कि अनुप्रयोगों को उनकी आवश्यकता नहीं होनी चाहिए। कह रहे हैं "उन्हें वहां मत डालो" हास्यास्पद है। यदि उपयोगकर्ता छोड़ना चाहता है ... मैं उन्हें बिल्कुल ऐसा करने की पहुंच प्रदान करता हूं। मुझे नहीं लगता कि यह एंड्रॉइड कैसे काम करता है और एक अच्छा अभ्यास की तरह लगता है। मैं जीवन चक्र को समझता हूं ... और मेरा अवलोकन यह है कि एंड्रॉइड इसे संभालने में अच्छा काम नहीं करता .... और यह एक मूल तथ्य है।


The Android application life cycle is designed for mobile phone users, not computer users.

The app life-cycle is the brutally simplistic paradigm required to turn a Linux server into a consumer appliance.

Android is Java over Linux, a real cross-platform server OS. That is how it spread so quickly. The app life-cycle encapsulates the underlying reality of the OS.

To mobile users, apps are just installed or not installed. There is no concept of running or exiting. In fact, app processes are meant to run until the OS releases them for their held resources.

Since this is , anyone reading this is a computer user and must turn off 90% of their knowledge to understand the mobile app lifecycle.


आप बैक बटन दबाकर या अपनी Activity में finish() को कॉल करके छोड़ सकते हैं । यदि आप इसे स्पष्ट रूप से मारना चाहते हैं तो MenuItem से बस finish() को कॉल करें।

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


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

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

यह सरल है। ऐसी सेवा बनाएं जो अधिसूचना बार में जारी अधिसूचना रखती है, "मैं इंट्रानेट में हूं, या मैं दौड़ रहा हूं"। क्या वह सेवा आपके द्वारा अपने आवेदन के लिए आवश्यक सभी कार्यक्षमताओं को निष्पादित करती है। ऐसी गतिविधियां हैं जो उस सेवा से जुड़ती हैं ताकि आपके उपयोगकर्ताओं को यूआई के बिट्स तक पहुंचने की अनुमति मिल सके, उन्हें आपके "एप्लिकेशन" से बातचीत करने की आवश्यकता है। और एक एंड्रॉइड मेनू है -> छोड़ें (या लॉगआउट, या जो भी) बटन जो सेवा को छोड़ने के लिए कहता है, फिर गतिविधि को बंद कर देता है।

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

मैं वास्तव में आपकी समस्या नहीं देखता हूं।


Answer: (Romain Guy): The user doesn't, the system handles this automatically. That's what the activity lifecycle (especially onPause/onStop/onDestroy) is for. No matter what you do, do not put a "quit" or "exit" application button. It is useless with Android's application model. This is also contrary to how core applications work.

1: Totally exiting an application may be generally unmandatory, but it is not useless. What if windows had no exit option? System would be doggy slow as memory was full and the OS had to guess at which programs you were done with. I don't care what Romain Guy or even Larry Page and Sergey Brin say - these are unquestionable facts: Systems run slower when they have to kill tasks to get their memory before a new app can be launched. You just can't tell me that it doesn't take time to kill an app! Even the light from distant stars take time... There is some use in allowing the user to fully close apps.

2: Contrary to how core applications work? What's that supposed to mean? When I'm done running an app for now, it is no longer doing any work...It's just waiting to be killed by the OS when its memory is needed.

In summary, there is a distinct difference between minimizing and exiting, and neither pinch hits well for the other. Do we leave a screwdriver in every screw? Or a key in every door? Do we leave all of our appliances on high until the breaker blows and we need to turn on another appliance? Do we leave the dish washer full of dishes, and only take out enough each time to make room for some new dirty ones? Do we leave all the cars running in the driveway until -- oh never mind.

If the user wants to minimize an app, then the best thing is to minimize it. If a user wants to exit an app, then by all means it is best to exit.

Is it frowned on? That's Android's view - they frown on it. And many many independent rookie Android developers frown on it.

But when it comes right down to it, there is good coding and bad coding. There is good program flow models and there are bad program flow models.

Leaving programs in memory when the user knows they are done with them simply is not good program flow. It serves absolutely no purpose whatsoever, and it slows things down when launching new apps or when running apps allocate more memory.

It is sort of like your car: There are times when you leave it running, like stopping at a stop light, or perhaps the fast food drive through, or stopping at the ATM. But there are other situations where you do want to shut it off - like when you get to work, or the grocery store or even home.

Similarly, if you're playing a game and the phone rings, yes. Pause the game and keep it running. But if the user is done with the game for a while, then by all means let them exit.

The exit button on some applications should be more out in front than others. Games, for example, or programs where the user is likely to want to fully exit, should have an obvious exit. Other programs, like, perhaps, email programs, where exiting is an unlikely desire (so that it can keep checking for email) -- these programs should not waste prime control input screen space with an exit option, but for good program flow, it should have an exit option. What if someone decides they don't want their mail program trying to check email when they are in poor coverage area, or maybe in a Skype call or whatever? Let them exit the email program if they want!

Suspending and exiting are two vital tasks and neither fulfills the role of the other.





android