games - android update




هل يتم التخلي عن أحد التطبيقات المجهول؟ (20)

عند الانتقال إلى محاولة تعلم Android ، قرأت ما يلي فقط:

سؤال: هل لدى المستخدم خيار لقتل التطبيق ما لم نضع خيار قائمة لقتلها؟ في حالة عدم وجود مثل هذا الخيار ، كيف يقوم المستخدم بإنهاء التطبيق؟

الإجابة: (Romain Guy): لا يقوم المستخدم ، يعالج النظام هذا تلقائيًا. هذا هو ما هي دورة حياة النشاط (خاصة onPause / onStop / onDestroy). بغض النظر عن ما تفعله ، لا تضع زر تطبيق "إنهاء" أو "إنهاء". لا فائدة من نموذج تطبيق Android. هذا أيضا يتعارض مع كيفية عمل التطبيقات الأساسية.

Hehe ، في كل خطوة أتخذها في عالم Android ، أواجه نوعًا من المشكلة = (

على ما يبدو ، لا يمكنك إنهاء تطبيق في Android (ولكن نظام Android يمكنه تدمير التطبيق تمامًا متى شعرت به). ما الأمر مع ذلك؟ بدأت أعتقد أنه من المستحيل كتابة تطبيق يعمل "كتطبيق عادي" - بحيث يمكن للمستخدم إنهاء التطبيق عندما يقرر القيام بذلك. هذا شيء لا ينبغي الاعتماد عليه في نظام التشغيل للقيام به.

التطبيق الذي أحاول إنشاءه ليس تطبيقًا لـ Android Market. إنه ليس تطبيقًا "للاستخدام الواسع" من قِبل عامة الناس ، بل هو تطبيق تجاري سيتم استخدامه في مجال تجاري ضيق للغاية.

لقد كنت أتطلع حقًا لتطوير نظام Android الأساسي ، نظرًا لأنه يتناول الكثير من المشكلات الموجودة في Windows Mobile و .NET. ومع ذلك ، كان الأسبوع الماضي نوعًا ما من الانطواء بالنسبة لي ... آمل ألا أضطر إلى التخلي عن Android ، ولكنه لا يبدو جيدًا الآن = (

هل هناك طريقة بالنسبة لي لإنهاء التطبيق؟


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.


أود فقط إضافة تصحيح هنا لقراء هذا الموضوع في المستقبل. لقد نجا هذا الفوارق الدقيقة الخاصة من فهمي لفترة طويلة لذلك أريد أن أتأكد من أن أيا منكم ارتكب الأخطاء نفسها:

لا يقتل System.exit() تطبيقك إذا كان لديك أكثر من نشاط واحد في بنية تخزين العناصر. ما يحدث في الواقع هو أن يتم قتل العملية وإعادة تشغيلها على الفور مع عدد أقل من النشاط على المكدس. وهذا أيضًا ما يحدث عندما يتم قتل تطبيقك من خلال مربع الحوار "إغلاق" ، أو حتى عند محاولة إنهاء العملية من DDMS. هذه حقيقة غير موثقة بالكامل ، على حد علمي.

الإجابة المختصرة هي ، إذا كنت تريد الخروج من التطبيق الخاص بك ، فعليك تتبع جميع الأنشطة في مجموعتك finish() جميعهم عندما يريد المستخدم الخروج (ولا ، لا توجد طريقة للتكرار من خلال كومة النشاط ، لذلك عليك إدارة كل ذلك بنفسك). حتى هذا لا يقتل العملية أو أي مراجع متدلية قد تكون لديك. إنها ببساطة تنتهي من الأنشطة. أيضا ، لست متأكدا ما إذا كان Process.killProcess(Process.myPid()) يعمل بشكل أفضل. لم أختبره

من ناحية أخرى ، إذا كان من الأفضل بالنسبة لك أن تظل لديك أنشطة في مجموعتك ، فهناك طريقة أخرى تجعل الأشياء سهلة للغاية بالنسبة لك: Activity.moveTaskToBack(true) ستقوم ببساطة بمراجعة العملية وإظهار الشاشة الرئيسية.

تتضمن الإجابة الطويلة تفسيرًا للفلسفة وراء هذا السلوك. الفلسفة تولد من عدد من الافتراضات:

  1. أولاً ، يحدث هذا فقط عندما يكون تطبيقك في المقدمة. إذا كانت في الخلفية ستنتهي العملية على ما يرام. ومع ذلك ، إذا كان في المقدمة ، يفترض نظام التشغيل أن المستخدم يريد أن يستمر في فعل أي شيء كان يقوم به. (إذا كنت تحاول قتل العملية من DDMS ، يجب أن تضغط على زر البداية أولاً ، ثم تقتلها)
  2. كما يفترض أن كل نشاط مستقل عن جميع الأنشطة الأخرى. وغالبًا ما يكون ذلك صحيحًا ، على سبيل المثال في حالة تشغيل تطبيقك لنشاط المتصفح ، وهو منفصل تمامًا ولم يتم كتابته من قبلك. قد يكون أو لا يتم إنشاء نشاط المستعرض في نفس المهمة ، اعتمادًا على سمات البيان الخاصة به.
  3. يفترض أن كل نشاط من أنشطتك يعتمد على نفسه تمامًا ويمكن أن يُقتل / يسترد في أي لحظة. (أنا لا أحب هذا الافتراض المعين ، حيث أن التطبيق يحتوي على العديد من الأنشطة التي تعتمد على كمية كبيرة من البيانات المخزنة مؤقتًا ، كبيرة جدًا بحيث لا يتم تسلسلها بكفاءة أثناء onSaveInstanceState ، ولكن whaddya ستفعل؟) بالنسبة إلى معظم تطبيقات Android المكتوبة بشكل جيد ، يجب أن يكون هذا صحيحًا نظرًا لأنك لا تعرف مطلقًا متى سيتم قتل تطبيقك في الخلفية.
  4. العامل النهائي ليس افتراضًا كبيرًا ، بل هو مجرد قيود على نظام التشغيل: يقتل التطبيق بشكل صريح تمامًا كما هو الحال في التطبيق ، كما يماثل أيضًا Android الذي يقتل التطبيق لاستعادة الذاكرة. ويبلغ هذا الأمر ذروة الانقلاب لدينا: نظرًا لأن Android لا يستطيع معرفة ما إذا تم إنهاء التطبيق أو تعطله أو تم قتله في الخلفية ، فإنه يفترض أن المستخدم يريد العودة من حيث توقف ، وبالتالي فإن ActivityManager يعيد تشغيل العملية.

عندما تفكر في ذلك ، هذا مناسب للمنصة. أولاً ، هذا هو بالضبط ما يحدث عندما يتم قتل العملية في الخلفية ويعود المستخدم إليها ، لذلك يجب إعادة تشغيلها حيث توقفت. ثانيًا ، هذا ما يحدث عندما يتعطل التطبيق ويعرض مربع حوار Force Close اللعين.

قل أرغب في أن يتمكن المستخدمون من التقاط صورة وتحميلها. أقوم بتشغيل "نشاط الكاميرا" من النشاط الخاص بي ، وأطلب منه إرجاع صورة. يتم دفع الكاميرا إلى أعلى مهمتي الحالية (بدلاً من أن يتم إنشاؤها في مهمتها الخاصة). إذا كانت الكاميرا تحتوي على خطأ وتعطلت ، فهل يؤدي ذلك إلى تعطل التطبيق بالكامل؟ من وجهة نظر المستخدم ، فشلت الكاميرا فقط ، ويجب إعادتها إلى أنشطتها السابقة. لذلك فقط إعادة تشغيل العملية مع كافة الأنشطة نفسها في المكدس ، ناقص الكاميرا. بما أنه يجب أن تصمم أنشطتك بحيث يمكن قتلها واستعادتها عند قطرة من قبعة ، فإن هذا لا ينبغي أن يكون مشكلة. لسوء الحظ ، لا يمكن تصميم جميع التطبيقات بهذه الطريقة ، لذا فهي مشكلة بالنسبة للكثيرين منا ، بغض النظر عن ما يقوله لك رومان جاي أو أي شخص آخر. لذا ، نحتاج إلى استخدام الحلول البديلة.

لذا ، نصيحتي الختامية:

  • لا تحاول قتل العملية. إما finish() المكالمة finish() على جميع الأنشطة أو الاتصال moveTaskToBack(true) .
  • إذا تعطلت العملية أو تعرضت للقتل ، وإذا كنت مثلي ، تحتاج إلى البيانات الموجودة في الذاكرة المفقودة الآن ، ستحتاج إلى العودة إلى نشاط الجذر. للقيام بذلك ، يجب عليك استدعاء startActivity() مع Intent يحتوي على علامة Intent.FLAG_ACTIVITY_CLEAR_TOP .
  • إذا كنت تريد قتل تطبيقك من منظور Eclipse DDMS ، فمن الأفضل ألا يكون في المقدمة ، أو سيعيد تشغيل نفسه. يجب عليك الضغط على زر الصفحة الرئيسية أولاً ، ثم إنهاء العملية.

توقف عن التفكير في طلبك كتطبيق مترابط. وهي عبارة عن مجموعة من شاشات واجهة المستخدم التي يمكن للمستخدم التفاعل معها باستخدام "التطبيق" و "الوظائف" المقدمة عبر خدمات Android.

لا يعرف ما هو "غامض" التطبيق الخاص بك ليست مهمة حقا. دعونا نفترض أنه الأنفاق إلى بعض إنترانت الشركات فائقة آمنة ، وأداء بعض المراقبة أو التفاعل ويبقى تسجيل الدخول حتى "إنهاء المستخدم للتطبيق". نظرًا لأن قسم تكنولوجيا المعلومات لديك هو الذي يتولى أمر ذلك ، يجب أن يكون المستخدمون على وعي تام عندما يكونون داخل أو خارج شبكة الإنترانت. ومن ثم ، فإن التفكير الخاص بك من المهم بالنسبة للمستخدمين "إنهاء".

هذا بسيط. قم بعمل خدمة تضع إخطارًا مستمرًا في شريط الإشعارات موضحًا "أنا في الإنترانت أو أقوم بتشغيل". اطلب من هذه الخدمة أداء جميع الوظائف التي تحتاجها للتطبيق الخاص بك. اطلب من الأنشطة التي ترتبط بهذه الخدمة السماح للمستخدمين بالوصول إلى وحدات واجهة المستخدم التي يحتاجون إليها للتفاعل مع "التطبيق". ولديك قائمة Android -> إنهاء (أو الخروج ، أو أيًا كان) الزر الذي يخبر الخدمة بالإنهاء ، ثم يغلق النشاط نفسه.

هذا ، لجميع المقاصد والأغراض بالضبط ما تقوله تريده. انتهج طريقة أندرويد. انظر إلى Google Talk أو التنقل في خرائط Google للحصول على أمثلة لهذا "الخروج" هو عقلية ممكنة. والفرق الوحيد هو أن الضغط على زر الرجوع من النشاط الخاص بك قد يترك عملية UNIX الخاصة بك في الانتظار فقط في حالة أراد المستخدم لإحياء التطبيق الخاص بك. هذا في الحقيقة لا يختلف عن نظام تشغيل حديث يقوم بتخزين ملفات تم الوصول إليها مؤخرًا في الذاكرة. بعد إنهاء برنامج windows الخاص بك ، لا يزال في الغالب الموارد التي يحتاجها في الذاكرة ، في انتظار أن يتم استبدالها بموارد أخرى حيث يتم تحميلها الآن أنها لم تعد هناك حاجة إليها. Android هو الشيء نفسه.

أنا حقا لا أرى مشكلتك.


تيد ، ما تحاول إنجازه يمكن القيام به ، ربما ليس فقط كيف تفكر فيه الآن.

أقترح عليك القراءة في الأنشطة والخدمات. التوقف عن استخدام مصطلح "التطبيق" والبدء في الإشارة إلى المكونات ، أي النشاط ، الخدمة. أعتقد أنك تحتاج فقط إلى معرفة المزيد عن نظام Android الأساسي ؛ إنه تغيير في عقلية تطبيق PC القياسي. إن حقيقة أن أيا من مشاركاتك لم تتضمن كلمة "نشاط" (أي أقل من اقتباس الأسئلة الشائعة ، أي ليست كلماتك) ، فأخبرني أنك بحاجة لقراءة المزيد.


سيصل ذلك في النهاية إلى سؤالك ، لكني أريد أولاً تناول عدد من القضايا التي تثيرها في تعليقاتك المختلفة على الإجابات المختلفة التي قدمت في وقت كتابة هذه السطور. ليس لدي أي نية لتغيير رأيك - بدلاً من ذلك ، هذه موجودة هنا للآخرين الذين يأتون لقراءة هذه المشاركة في المستقبل.

الهدف من ذلك هو أنه لا يمكنني السماح لنظام Android بتحديد متى سيتم إنهاء تطبيقي. يجب أن يكون اختيار المستخدم.

ملايين الأشخاص سعداء تمامًا بالنموذج حيث تغلق البيئة التطبيق حسب الحاجة. هؤلاء المستخدمين ببساطة لا يفكرون في "إنهاء" تطبيق Android ، أي أكثر مما يفكرون في "إنهاء" صفحة ويب أو "إنهاء" منظم الحرارة.

مستخدمو iPhone هم بنفس الطريقة ، حيث أن الضغط على زر iPhone لا يعني بالضرورة "الشعور" مثل إنهاء التطبيق ، نظرًا لأن العديد من تطبيقات iPhone تلتقط من حيث توقف المستخدم ، حتى إذا تم إغلاق التطبيق بالفعل (بما أن iPhone فقط يسمح تطبيق طرف ثالث في وقت واحد ، في الوقت الحاضر).

كما قلت أعلاه ، هناك الكثير من الأشياء التي تجري في التطبيق الخاص بي (يتم نقل البيانات إلى الجهاز ، وقوائم المهام التي يجب أن تكون موجودة دائماً ، وما إلى ذلك).

لا أعرف ماذا تعني "القوائم ذات المهام التي يجب أن تكون موجودة دائمًا" ، ولكن "البيانات التي يتم نقلها إلى الجهاز" هي قصة خيالية ولا ينبغي القيام بها بأي نشاط على أي حال. استخدم مهمة مجدولة (عبر AlarmManager ) لتحديث بياناتك للحصول على أقصى قدر من الموثوقية.

يقوم مستخدمونا بتسجيل الدخول ولا يمكنهم فعل ذلك في كل مرة يحصلون فيها على مكالمة هاتفية ويقرر Android قتل التطبيق.

هناك العديد من تطبيقات iPhone و Android التي تتعامل مع هذا. عادةً ، يكون ذلك بسبب احتوائها على بيانات اعتماد تسجيل الدخول بدلاً من إجبار المستخدمين على تسجيل الدخول كل مرة يدوياً.

على سبيل المثال ، نريد التحقق من التحديثات عند الخروج من التطبيق

هذا خطأ في أي نظام تشغيل. بالنسبة إلى كل ما تعرفه ، يرجع السبب وراء "خروجك" من تطبيقك إلى توقف نظام التشغيل ، ومن ثم ستفشل عملية التحديث في منتصف البث. عموما ، هذا ليس أمرا جيدا. إما التحقق من التحديثات على بدء أو التحقق من التحديثات بشكل غير متزامن بشكل كامل (على سبيل المثال ، عبر مهمة مجدولة) ، أبدا عند الخروج.

تشير بعض التعليقات إلى أن ضرب زر الرجوع لا يقتل التطبيق على الإطلاق (انظر الرابط في سؤالي أعلاه).

الضغط على زر BACK لا "قتل التطبيق". ينتهي الأمر من النشاط الذي كان على الشاشة عندما قام المستخدم بالضغط على الزر BACK.

يجب أن تنتهي فقط عندما يرغب المستخدمون في إنهاؤها - دون أي طريقة أخرى. إذا كنت لا تستطيع كتابة التطبيقات التي تتصرف بهذه الطريقة في Android ، فعندئذ أعتقد أنه لا يمكن استخدام Android لكتابة تطبيقات حقيقية = (

ثم لا يمكن تطبيقات الويب. أو WebOS ، إذا فهمت نموذجهم بشكل صحيح (لم تكن لديهم فرصة للعب مع واحد حتى الآن). في كل ذلك ، لا يقوم المستخدمون "بإنهاء" أي شيء - فهم يغادرون فقط. يختلف iPhone قليلاً ، من حيث أنه يسمح حاليًا بشيء واحد للتشغيل في وقت واحد (مع بعض الاستثناءات) ، وبالتالي فإن فعل المغادرة يعني إنهاءًا فوريًا إلى حد ما للتطبيق.

هل هناك طريقة بالنسبة لي لإنهاء التطبيق؟

كما أخبرك الجميع ، يمكن للمستخدمين (عبر BACK) أو الرمز الخاص بك (عبر finish() ) إغلاق نشاطك الجاري حاليًا. وعموما لا يحتاج المستخدمون إلى أي شيء آخر ، للتطبيقات المكتوبة بشكل صحيح ، أي أكثر من أنهم بحاجة إلى خيار "إنهاء" لاستخدام تطبيقات الويب.

لا توجد بيئات تطبيق واحدة متطابقة ، بحكم التعريف. هذا يعني أنه يمكنك مشاهدة الاتجاهات في البيئات عندما تنشأ أخاديد جديدة وأن يتم دفن الآخرين.

على سبيل المثال ، هناك حركة متزايدة لمحاولة القضاء على فكرة "الملف". معظم تطبيقات الويب لا تجبر المستخدمين على التفكير في الملفات. عادة لا تجبر تطبيقات iPhone المستخدمين على التفكير في الملفات. لا تجبر تطبيقات Android بشكل عام المستخدمين على التفكير في الملفات. وما إلى ذلك وهلم جرا.

وبالمثل ، هناك حركة متزايدة لمحاولة القضاء على فكرة "إنهاء" التطبيق. معظم تطبيقات الويب لا تجبر المستخدم على الخروج ، ولكن بدلا من ذلك قم بتسجيل خروج المستخدم بعد فترة من عدم النشاط. نفس الشيء مع Android ، وإلى حد أقل ، iPhone (وربما WebOS).

وهذا يتطلب مزيدًا من التركيز على تصميم التطبيقات ، مع التركيز على أهداف العمل وعدم الالتزام بنموذج تنفيذ مرتبط ببيئة تطبيق سابقة. سيصاب المطورون الذين يفتقرون إلى الوقت أو الميل للقيام بذلك بالإحباط من البيئات الأحدث التي تكسر نموذجهم العقلي القائم. هذا ليس خطأ أي من البيئة ، أكثر من خطأ الجبل بسبب العواصف التي تتدفق حوله وليس عبره.

على سبيل المثال ، بعض بيئات التطوير ، مثل Hypercard و Smalltalk ، كان لها التطبيق وأدوات التطوير التي تم مزجها في إعداد واحد. لم يكتشف هذا المفهوم الكثير ، خارج ملحقات اللغة للتطبيقات (على سبيل المثال ، VBA في Excel ، Lisp في AutoCAD ). وبالتالي ، كان على المطورين الذين توصلوا إلى نماذج ذهنية يفترض وجود أدوات تطوير في التطبيق نفسه ، إما أن يغيروا نموذجهم أو أن يقتصروا على البيئات التي يكون فيها نموذجهم صحيحًا.

لذلك ، عندما تكتب:

إلى جانب أشياء أخرى فوضوية اكتشفتها ، أعتقد أن تطوير تطبيقنا لأجهزة Android لن يحدث.

يبدو أن هذا هو الأفضل بالنسبة لك ، الآن. وبالمثل ، أود أن أشير لك ضد محاولة تطبيق التطبيق الخاص بك على الويب ، نظرًا لأن بعض المشكلات نفسها التي أبلغت عنها على Android ستجدها في تطبيقات الويب أيضًا (على سبيل المثال ، لا يوجد "إنهاء"). أو ، على العكس ، في يوم من الأيام إذا قمت بتوصيل تطبيقك بالويب ، فقد تجد أن تدفق تطبيق الويب قد يكون أفضل تطابقًا مع Android ، ويمكنك إعادة زيارة منفذ Android في ذلك الوقت.


هذه مناقشة مثيرة للاهتمام ومثيرة للاهتمام مع العديد من الخبراء المساهمة. أشعر أنه يجب إعادة نشر هذه المشاركة من داخل موقع الويب الرئيسي لتطوير Android ، نظرًا لأنها تدور حول أحد التصميمات الأساسية لنظام التشغيل Android.

وأود أيضا أن أضيف سنتي هنا.

لقد تأثرت حتى الآن بطريقة Android للتعامل مع أحداث دورة الحياة ، مما جعل مفهوم تجربة الويب المشابهة للتطبيقات الأصلية.

بعد أن قلت أنني ما زلت أعتقد أنه يجب أن يكون هناك زر إنهاء . لماذا ا؟ ... ليس بالنسبة لي أو تيد أو أي من أخصائي التكنولوجيا هنا ، ولكن لغرض وحيد هو تلبية طلب المستخدم النهائي.

على الرغم من أنني لست من كبار المعجبين في Windows ، إلا أنه منذ فترة طويلة قاموا بتقديم مفهوم يستخدمه معظم المستخدمين النهائيين (زر X) ... "أريد إنهاء تشغيل الأداة عندما" أريد ".

هذا لا يعني أن شخص ما (نظام التشغيل ، المطور؟) سوف يعتني بذلك حسب تقديره الخاص ... يعني ببساطة "أين الزر الأحمر X الذي اعتدت عليه". يجب أن يكون أعمالي مشابهاً لـ "إنهاء المكالمة عند الضغط على زر" ، "قم بإيقاف تشغيل الجهاز بالضغط على زر" وهكذا ، وهكذا دواليك ... إنه إدراك. إنه يحقق الرضا في حد ذاته أن عملي يحقق بالفعل غرضه.

على الرغم من أن مطور البرامج يمكنه محاكاة هذا السلوك باستخدام الاقتراحات المقدمة هنا ، إلا أن الإدراك لا يزال قائما ، أي يجب أن يتوقف التطبيق تمامًا عن العمل (الآن) ، من خلال مصدر مستقل وموثوق ومحايدة (OS) حسب الطلب من المستخدم النهائي.


مقالة المدونة عند تضمين زر الخروج في تطبيقات Android (تلميح: أبدًا) يشرحها الآن ، أفضل بكثير مما أستطيع. أتمنى لو أن كل مطور برامج Android قد قرأه بالفعل.

وهذه مقتطفات:

من واقع تجربتي ، ما يريده [المستخدمون] بالفعل هو: طريقة لا لبس فيها تضمن أن التطبيق سيتوقف عن استهلاك الموارد (البطارية ، دورات CPU ، نقل البيانات ، وما إلى ذلك).

يرى العديد من المستخدمين أن زر الخروج يطبق هذا المطلب ويطلب إضافته. المطورين ، يتطلعون إلى إرضاء مستخدميها ، إضافة واحدة. بعد ذلك بفترة وجيزة فشل كلاهما.

  • في معظم الحالات ، يطلق زر الخروج ببساطة Activity.finish() . هذا يعادل بالضبط ضرب زر العودة. بالضبط. تستمر الخدمات في البقاء والاستمرار في التصويت. قد يظن المستخدمون أنهم قد قتلوا التطبيق لكنهم لم يفعلوا ذلك ، وسرعان ما سيكونون أكثر إزعاجًا.
  • سلوك الخروج هو الآن غامض. هل يجب أن يؤدي زر الخروج إلى إغلاق النشاط ، أم يجب عليه أيضًا إيقاف جميع الخدمات ، وأجهزة الاستقبال ، وأجهزة الإنذار المرتبطة؟ ماذا يجب أن تفعل الظهر ؟ ماذا يحدث إذا قاموا بالضغط على Home بدلاً من ذلك؟ ماذا يحدث إذا كان تطبيقك يحتوي على أداة؟ هل يجب أن يوقف زر الخروج ذلك من التحديث أيضًا؟

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.


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.


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.


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 :)


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.


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.


I think the point is that there is no need to quit the app unless you have buggy software. Android quits the app when the user is not using it and the device needs more memory. If you have an app that needs to run a service in the background, you will likely want a way to turn the service off.

For example, Google Listen continues to play podcast when the app is not visible. But there is always the pause button to turn the podcast off when the user is done with it. If I remember correctly, Listen, even puts a shortcut in the notification bar so you can always get to the pause button quickly. Another example is an app like a twitter app for instance which constantly polls a service on the internet. These types of apps should really allow the user to choose how often to poll the server, or whether even to poll in a background thread.

If you need to have code that runs on exit, you can override onPause(), onStop(), or onDestroy() as appropriate. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle


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. :)


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>();

}

MainActivity أضف مرجع النشاط الحالي في هذه المصفوفة

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);
            }
        });
    }
}

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


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.


The Linux kernel has a feature called Out-of-memory killer (as mentioned above, the policies are configurable at the userspace level as well as the kernel is not an optimal one, but by no means unnecessary).

And it is heavily used by Android:

Some userspace apps are available to assist with these kill apps, for example:


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".


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.





android