Чи нахмурився додаток?

Продовжуючи свою спробу вивчити Android, я просто прочитав наступне :

Питання: Чи є у користувача вибір вбити програму, якщо ми не поставимо варіант меню, щоб її вбити? Якщо такої опції немає, як користувач припиняє програму?

Відповідь: (Ромен Гай): Користувач цього не робить, система обробляє це автоматично. Ось для чого складається життєвий цикл діяльності (особливо onPause / onStop / onDestroy). Незалежно від того, що ви робите, не кладіть кнопку "вийти" або "вийти". Це марно з додатковою моделлю Android. Це також суперечить тому, як працюють основні програми.

Хе-хе, за кожен крок, який я роблю в світі Android, я стикаюся з якоюсь проблемою = (

Мабуть, ви не можете вийти з програми в Android (але система Android може дуже добре знищити ваш додаток, коли вам це здасться). Що з цим? Я починаю вважати, що неможливо написати додаток, який функціонує як "звичайний додаток" - що користувач може вийти з програми, коли він / вона вирішить це зробити. Це не те, на що слід покладатися ОС.

Додаток, який я намагаюся створити, не є додатком для Android Market. Це не додаток для "широкого використання" широкою громадськістю, це діловий додаток, який буде використовуватися у дуже вузькому бізнесі.

Я насправді дуже сподівався розробити для платформи Android, оскільки вона вирішує безліч проблем, які існують у Windows Mobile та .NET. Однак останній тиждень був для мене дещо поворотом ... Я сподіваюся, що мені не доведеться відмовлятися від Android, але зараз він виглядає не дуже добре = (

Чи є спосіб, щоб я справді закрив заявку?

Це врешті-решт дістанеться до вашого питання, але спершу я хочу звернутися до ряду питань, які ви ставите у своїх коментарях до різних відповідей, вже даних під час написання цього повідомлення. Я не маю наміру змінювати свою думку - скоріше, це тут для інших, хто прийде прочитати цю публікацію в майбутньому.

Справа в тому, що я не можу дозволити Android визначити, коли моє додаток буде закрито. це повинен бути вибір користувача.

Мільйони людей цілком задоволені моделлю, де навколишнє середовище закриває додаток у міру необхідності. Ці користувачі просто не замислюються про те, щоб "закрити" додаток для Android, більше, ніж думають про "припинення" веб-сторінки або "припинення" термостата.

Користувачі iPhone майже однаково, тому що натискання кнопки iPhone не обов'язково "відчуває", як додаток було припинено, оскільки багато додатків iPhone піднімаються там, де користувач припинився, навіть якщо додаток справді було вимкнено (оскільки лише iPhone дозволяє одночасно додавати сторонні додатки).

Як я вже говорив вище, у моєму додатку відбувається багато речей (дані, які PUSHed на пристрій, списки із завданнями, які завжди повинні бути там тощо).

Я не знаю, що означає "списки із завданнями, які завжди повинні бути там", але "дані, які передаються на пристрій", є приємною вигадкою, і це не повинно робитись діяльністю ні в якому разі. Використовуйте заплановане завдання (через AlarmManager), щоб оновити свої дані для максимальної надійності.

Наші користувачі входять у систему і не можуть цього робити щоразу, коли отримують телефонний дзвінок, і Android вирішує вбити програму.

Існує багато додатків для iPhone та Android, які займаються цим. Зазвичай, це тому, що вони тримають облікові дані для входу, а не змушують користувачів кожного разу входити вручну.

Наприклад, ми хочемо перевірити оновлення під час виходу з програми

Це помилка в будь-якій операційній системі. Як ви знаєте, причина, коли ваша програма "закривається", полягає в тому, що ОС вимикається, і тоді процес оновлення завершиться невдачею середнього потоку. Взагалі, це не дуже добре. Або перевіряйте оновлення при запуску, або перевіряйте оновлення повністю асинхронно (наприклад, за допомогою запланованого завдання), ніколи не виходячи.

Деякі коментарі говорять про те, що натискання кнопки "назад" зовсім не вбиває додаток (див. Посилання в моєму питанні вище).

Натискання кнопки НАЗАД не "вбиває додаток". Він закінчує активність, яка була на екрані, коли користувач натискав кнопку НАЗАД.

Він повинен припинятись лише тоді, коли користувачі хочуть його припинити - ніколи інакше. Якщо ви не можете писати програми, які так поводяться в Android, я думаю, що Android не можна використовувати для написання реальних додатків = (

Тоді і веб-додатки не можуть. Або WebOS , якщо я правильно розумію їхню модель (ще не мали можливості зіграти з нею). У всьому цьому, користувачі нічого не "припиняють" - вони просто залишають. iPhone дещо відрізняється тим, що він лише зараз дозволяє запускати одну річ (за кількома винятками), і тому акт виходу передбачає досить негайне припинення роботи програми.

Чи є спосіб, щоб я справді закрив заявку?

Як усі говорили вам, користувачі (за допомогою BACK) або ваш код (через finish()) можуть закрити вашу поточну діяльність. Користувачі, як правило, не потребують нічого іншого, для правильно написаних програм, більше, ніж їм потрібна опція "вийти" для використання веб-програм.

Немає двох середовищ додатків однакові за визначенням. Це означає, що ви можете бачити тенденції в оточенні, коли виникають нові, а інші потрапляють.

Наприклад, зростає рух, щоб спробувати усунути поняття "файл". Більшість веб-додатків не змушують користувачів думати про файли. Зазвичай програми iPhone не змушують користувачів думати про файли. Зазвичай програми Android не примушують користувачів думати про файли. І так далі.

Так само зростає рух, щоб спробувати усунути поняття "припинення" програми. Більшість веб-додатків не змушують користувача виходити з системи, а скоріше неявно виходять з нього після періоду бездіяльності. Те саме і з Android, і в меншій мірі, з iPhone (і, можливо, з WebOS).

Це вимагає більшого акценту на розробці додатків, орієнтації на бізнес-цілі та не дотримуючись моделі реалізації, прив’язаної до попереднього середовища застосування. Розробники, яким не вистачає часу або схильності на це, розчаруються в нових середовищах, які порушують існуючу ментальну модель. Це не вина жодного середовища, більше, ніж вина гори за бурі, що протікають навколо неї, а не через неї.

Наприклад, у деяких середовищах розробки, як Hypercard та Smalltalk, програма та інструменти розробки поєднуються в одній програмі. Ця концепція не зачепила багато, крім мовних розширень програм (наприклад, VBA в Excel , Lisp в AutoCAD ). Розробники, які придумали ментальні моделі, які припускали існування інструментів розробки в самому додатку, тому повинні були або змінити свою модель, або обмежитися середовищем, де їх модель справдиться.

Отже, коли ви пишете:

Поряд з іншими безладними речами, які я відкрив, я думаю, що розробити наш додаток для Android не відбудеться.

Це, здається, найкраще, для вас, зараз. Так само я б радив вас не намагатися перенести свою програму в Інтернет, оскільки деякі ті самі проблеми, про які ви повідомляли з Android, ви знайдете і в веб-додатках (наприклад, відсутність "припинення"). Або, навпаки, коли - небудь , якщо ви робите порт додаток до Інтернету, ви можете виявити , що потік веб - додаток може бути краще підходить для Android, і ви можете повернутися до Android порт в той час.

Я просто хотів би додати тут виправлення для майбутніх читачів цієї теми. Цей особливий нюанс давно уникає мого розуміння, тому я хочу переконатися, що ніхто з вас не робить однакових помилок:

System.exit()не вбиває ваш додаток, якщо у вас є кілька дій у стеку. Що насправді відбувається, це те, що процес вбивається та негайно перезапускається з меншою кількістю активності на стеку. Це також відбувається, коли ваш додаток вбито в діалоговому вікні «Закрити» або навіть при спробі вбити процес із DDMS. Наскільки мені відомо, це абсолютно незадокументований факт.

Коротка відповідь полягає в тому, що якщо ви хочете закрити свою програму, ви повинні відслідковувати всі дії у вашому стеку та finish()ВСІ з них, коли користувач хоче вийти (і ні, немає ніякого способу ітерації через стек Activity , тому вам доведеться все цим керувати самостійно). Навіть це насправді не вбиває процес або будь-які звисаючі посилання, які ви можете мати. Він просто закінчує діяльність. Крім того, я не впевнений, чи Process.killProcess(Process.myPid())працює краще; Я цього не перевіряв.

Якщо, з іншого боку, у вас все нормально, щоб у вашому стеку залишилися дії, є ще один метод, який полегшує вам речі: Activity.moveTaskToBack(true)просто ви перетворите ваш процес і покаже головний екран.

Довга відповідь передбачає пояснення філософії, що стоїть за цією поведінкою. Філософія народжується з ряду припущень:

1. Перш за все, це відбувається лише тоді, коли ваш додаток на першому плані. Якщо він знаходиться на задньому плані, процес закінчиться просто чудово. Однак, якщо вона стоїть на передньому плані, ОС передбачає, що користувач хоче продовжувати робити все, що він / вона робив. (Якщо ви намагаєтеся вбити процес із DDMS, спершу слід натиснути кнопку додому, а потім вбити)
2. Він також передбачає, що кожна діяльність не залежить від усіх інших видів діяльності. Це часто справедливо, наприклад, якщо ваш додаток запускає активність веб-переглядача, яка є повністю окремою і не написана вами. Активність веб-переглядача може бути створена або не може бути створена для одного завдання, залежно від атрибутів маніфесту.
3. Це передбачає, що кожна ваша діяльність є повністю самовідданою і може бути вбита / відновлена ​​за мить. (Мені більше не подобається це припущення, оскільки в моєму додатку є багато видів діяльності, які покладаються на велику кількість кешованих даних, занадто великі, щоб бути ефективно серіалізованими під час onSaveInstanceState, але що робитиму?) Для більшості добре написаних програм для Android це має бути правдою, оскільки ви ніколи не знаєте, коли ваш додаток буде вибитий у фоновому режимі.
4. Остаточним фактором є не стільки припущення, скільки скоріше обмеження операційної системи: вбивство програми явно те саме, що і збій програми, а також те саме, що Android, що вбиває додаток, щоб повернути пам'ять. Це завершилося нашим граціозним переворотом: оскільки Android не може визначити, чи додаток вийшов з ладу або загинув у фоновому режимі, він передбачає, що користувач хоче повернутися туди, де вони припинилися, і тому ActivityManager відновлює процес.

Коли ви думаєте про це, це підходить для платформи. По-перше, саме це відбувається, коли процес вбивається у фоновому режимі, і користувач повертається до нього, тому його потрібно перезапустити там, де він припинився. По-друге, це те, що відбувається, коли програма виходить з ладу і представляє жахливий діалог Force Close.

Скажіть, я хочу, щоб мої користувачі могли сфотографувати та завантажити його. Я запускаю Camera Activity зі своєї діяльності і прошу повернути зображення. Камера висувається на вершину мого поточного завдання (а не створюється в його власному завданні). Якщо в камері є помилка, і вона виходить з ладу, чи це може призвести до збою всього додатка? З точки зору користувача, лише Камера вийшла з ладу, і їх слід повернути до їх попередньої діяльності. Тож він просто перезавантажує процес із усіма тими ж діями у стеці, за вирахуванням камери. Оскільки Ваша діяльність повинна бути розроблена таким чином, щоб вони могли бути вбиті та відновлені при падінні шапки, це не повинно бути проблемою. На жаль, не всі програми можуть бути розроблені саме так, так і єпроблема для багатьох із нас, незалежно від того, що вам каже Ромен Гай чи хтось інший. Отже, нам потрібно використовувати обхідні шляхи.

Отже, моя заключна порада:

• Не намагайтеся вбити процес. Або зателефонуйте finish()на всі дії або зателефонуйте moveTaskToBack(true).
• Якщо ваш процес виходить з ладу або вбивається, і якщо, як я, вам потрібні дані, які були в пам'яті, які втрачені зараз, вам потрібно буде повернутися до кореневої активності. Для цього вам слід зателефонувати startActivity()з наміром, який містить Intent.FLAG_ACTIVITY_CLEAR_TOPпрапор.
• Якщо ви хочете вбити свій додаток з точки зору Eclipse DDMS, краще не бути на передньому плані, інакше він перезапуститься. Спершу слід натиснути кнопку Головна, а потім вбити процес.

У всіх моїх програмах є кнопки виходу ... і я часто отримую позитивні коментарі від користувачів через це. Мені байдуже, чи платформа була розроблена таким чином, що програми не потребують їх. Сказати "не клади їх туди" - це щось смішно. Якщо користувач хоче вийти ... Я надаю їм доступ зробити саме це. Я не думаю, що це зменшує те, як Android взагалі працює, і здається, що це добра практика. Я розумію життєвий цикл ... і моє зауваження було, що Android не справляється з цим .... і це основний факт.

Перестаньте думати про свою заяву як про монолітну програму. Це набір екранів інтерфейсу користувача, за допомогою яких користувач може взаємодіяти з вашими "додатками" та "функціями", що надаються через сервіси Android.

Не знаючи, що "робить" ваш таємничий додаток, насправді не важливо. Припустимо, що він тунель у якусь супер безпечну корпоративну інтранет, виконуючи певний моніторинг або взаємодію, і залишається ввійти доти, поки користувач не закриє програму. Оскільки ваш ІТ-відділ командує ним, користувачі повинні бути дуже усвідомлені, коли вони ВХОДУТЬ або ВІД ІНТЕРНЕТ. Отже, ваша думка про важливість для користувачів "виходу".

Це просто. Створіть службу, яка розміщує поточне повідомлення на панелі сповіщень із запитом "Я в інтрамережі, або я бігаю". Дозвольте цій службі виконувати всі функції, необхідні для вашої програми. Проводьте діяльність, яка пов'язується з цією послугою, щоб ваші користувачі мали доступ до бітів інтерфейсу, необхідного для взаємодії з вашою "програмою". А також у меню Android -> Вийти (або вийти з системи, чи будь-що інше), яка сповіщає службу вийти, а потім закриє саму діяльність.

Це для всіх намірів і цілей саме те, що ви кажете, що хочете. Виконав Android-спосіб. Подивіться на Google Talk або Навігацію на Картах Google, щоб приклади цього "виходу" є можливим менталітетом. Єдина відмінність полягає в тому, що натискання кнопки "назад" у вашій діяльності може залишити ваш процес UNIX у режимі очікування на випадок, якщо користувач захоче відновити вашу програму. Це насправді нічим не відрізняється від сучасної операційної системи, яка кешує нещодавно доступні файли в пам'яті. Після того, як ви закриєте програму Windows, найімовірніше, що потрібні їй ресурси все ще залишаються в пам'яті, чекаючи, що їх замінять інші ресурси, оскільки вони завантажуються зараз, коли вони більше не потрібні. Android - це те саме.

Я справді не бачу вашої проблеми.

Це цікава та глибока дискусія з такою великою кількістю експертів. Я вважаю, що цю публікацію слід перенести на головний веб-сайт для розробки Android, оскільки він обертається навколо однієї з основних конструкцій ОС Android.

Я також хотів би додати тут свої два центи.

Поки що я був вражений способом управління Android подіями життєвого циклу, наближаючи концепцію веб-подібного досвіду до рідних програм.

Сказавши, що я все ще вважаю, що має бути Quitкнопка. Чому? ... не для мене або Теда чи когось із технічних гуру тут, а з єдиною метою задоволення потреб кінцевого споживача.

Хоча я не є великим шанувальником Windows, але давно вони запровадили концепцію, до якої звикли більшість кінцевих користувачів (кнопка X) ... "Я хочу кинути роботу із віджетом, коли" хочу ".

Це не означає, що хтось (ОС, розробник?) Подбає про це на власний розсуд ... це просто означає "де моя червона кнопка X, до якої я звик". Моя дія повинна бути аналогічною "припинення дзвінка при натисканні кнопки", "вимкнення пристрою натисканням кнопки" і так далі і так далі ... це сприйняття. Вона сама по собі дає задоволення, що моя дія дійсно досягає своєї мети.

Навіть незважаючи на те, що розробник може підробляти цю поведінку, використовуючи запропоновані тут пропозиції, сприйняття все ще залишається, тобто додаток повинен повністю перестати функціонувати (зараз) незалежним, надійним та нейтральним джерелом (ОС) на вимогу кінцевого користувача.

Ви можете вийти, натиснувши Backкнопку або зателефонувавши finish()у свою Activity. Просто зателефонуйте finish()з, MenuItemякщо ви хочете, щоб явно знищити його.

Ромен не каже, що цього не можна зробити, просто безглуздо - користувачам не потрібно піклуватися про те, щоб залишити чи зберегти свою роботу чи що завгодно, оскільки спосіб життєвого циклу програми заохочує вас писати розумне програмне забезпечення, яке автоматично зберігає та відновлює свій стан незалежно від того, що станеться.

Ця дискусія зводиться до вікового питання, чи розробники знають найкраще, чи користувач знає найкраще. Професійні дизайнери у всіх сферах людських факторів щодня борються з цим.

Тед зазначив, що однією з найбільш завантажених програм на ринку є "App Killer". Люди отримують трохи зайвого серотоніну, коли вони закривають заявки. Вони звикли до цього з робочим столом / ноутбуком. Це змушує речі швидко рухатися. Це тримає процесор прохолодно і вентилятор не включається. Він використовує менше енергії.

Якщо ви вважаєте, що мобільний пристрій є набагато меншим судном, то ви можете особливо оцінити їх стимул "кидати за борт те, що вам більше не потрібно". Зараз розробники Android обґрунтували, що ОС найкраще знає, і що вийти з програми є антикваріатом. Я щиро підтримую це.

Однак я також вважаю, що ви не повинні засмучувати користувача, навіть якщо це невдоволення випливає з їх власного незнання. Через це я роблю висновок, що варіант «Вийти» - це гарний дизайн, навіть якщо це здебільшого кнопка плацебо, яка не робить нічого іншого, як закрити вигляд.

Теде, те, що ти намагаєшся зробити, може бути зроблено, можливо, просто не так, як ти зараз це думаєш.

Я пропоную вам прочитати на тему "Діяльність та послуги". Перестаньте використовувати термін "додаток" і почніть посилатися на компоненти, тобто активність, сервіс. Я думаю, вам просто потрібно дізнатися більше про платформу Android; це зміна мислення зі звичайного додатка для ПК. Той факт, що в жодному з ваших дописів не було слова "Активність" (окрім цитати, тобто не ваших слів), вказує на те, що вам потрібно прочитати ще кілька.

Повідомлення в блозі Коли потрібно включити кнопку виходу в додатки для Android (Підказка: Ніколи), це пояснює це набагато краще, ніж я можу. Я хочу, щоб кожен розробник Android вже прочитав його.

Витяги:

На мій досвід, що насправді хочуть [користувачі]: це однозначний спосіб гарантувати, що додаток перестане витрачати ресурси (акумулятор, цикли процесора, передача даних тощо).

Багато користувачів розуміють, що кнопка виходу реалізує цю вимогу і просять її додати. Розробники, прагнучи догодити своїм користувачам, обов’язково додають його. Незабаром після цього вони обоє зазнають невдачі.

• У більшості випадків кнопка виходу просто дзвонить Activity.finish(). Це точно еквівалентно натиснувши кнопку назад. Саме так. Служби продовжують працювати, а опитування триває. Користувачі можуть подумати, що вони вбили додаток, але цього не зробили, і незабаром вони ще більше роздратуються.
• Зараз поведінка виходу неоднозначна. Якщо ваша кнопка виходу просто закриє активність, або вона також зупинить усі пов'язані служби, приймачі та сигнали тривоги? Що Backробити? Що станеться, якщо вони вдарять Homeзамість цього? Що станеться, якщо у вашої програми є віджет? Чи повинна кнопка виходу зупинити це також від оновлення?

Рішення полягає в тому, щоб змусити кнопку "Назад" вести себе так, як ви очікували на кнопку виходу. Що ще краще, просто припиніть витрачати ресурси, коли додаток не відображається.

Вперед і прочитайте всю статтю.

Відповідь: (Ромен Гай): Користувач цього не робить, система обробляє це автоматично. Ось для чого складається життєвий цикл діяльності (особливо onPause / onStop / onDestroy). Незалежно від того, що ви робите, не кладіть кнопку "вийти" або "вийти". Це марно з додатковою моделлю Android. Це також суперечить тому, як працюють основні програми.

1: Повністю закриття програми може бути, як правило, необов’язковим, але це не марно. Що робити, якщо Windows не мала можливості виходу? Система буде собачою повільно, оскільки пам'ять заповнена, і ОС повинна була здогадуватися, з якими програмами ви працювали. Мені все одно, що кажуть Ромен Гай чи навіть Ларрі Пейдж та Сергій Брін - це безперечні факти: системи працюють повільніше, коли їм потрібно вбити завдання, щоб отримати пам'ять, перш ніж запустити новий додаток. Ви просто не можете сказати мені, що не потрібно часу, щоб убити додаток! Навіть світло від далеких зірок зайняти деякий час ... Там є деяка користь в дозволяючи користувачеві повністю закривати додатки.

2: На відміну від того, як працюють основні програми? Що це має означати? Коли я закінчую запускати додаток, він більше не робить ніякої роботи ... Він просто чекає, коли ОС буде вбита, коли потрібна його пам'ять.

Підводячи підсумок, існує чітка різниця між мінімізацією та виходом, і жоден прищик не підходить для іншого. Чи залишаємо викрутку в кожному гвинті? Або ключ у кожних дверях? Чи залишаємо ми весь прилад високим, доки не вийде вимикач і нам потрібно включити інший прилад? Ми залишаємо посудомийну машину наповненою посудом, і лише щоразу виймаємо достатньо, щоб звільнити місце для нових брудних? Ми залишаємо всі машини, що бігають на проїжджій частині, поки - о, неважливо.

Якщо користувач хоче мінімізувати додаток, то найкраще - мінімізувати його. Якщо користувач хоче вийти з програми, тоді найкраще вийти.

Це нахмурилося? Такий погляд на Android - вони на це хмуряться. І безліч незалежних розробників-початківців Android нахмурилися на нього.

Але коли справа доходить до цього, є хороше кодування та погане кодування. Є хороші моделі програмних потоків і є погані моделі програмних потоків.

Залишати програми в пам’яті, коли користувач знає, що з ними робиться, просто не надто добре програмує. Він абсолютно не виконує жодної мети, і сповільнює роботу при запуску нових програм або при запуску додатків виділяє більше пам’яті.

Це так, як ваш автомобіль: Бувають випадки, коли ви залишаєте його працювати, як зупинка на зупинці, або, можливо, проїзд швидкого харчування, або зупинка в банкоматі. Але є й інші ситуації, коли ви хочете її вимкнути - як, наприклад, коли ви приїжджаєте на роботу, у продуктовий магазин чи навіть додому.

Так само, якщо ви граєте в гру і телефон дзвонить, так. Призупиніть гру та продовжуйте її працювати. Але якщо користувач деякий час займається грою, то всіма силами нехай вони виходять.

Кнопка виходу в деяких додатках повинна бути більше, ніж на інших. Наприклад, ігри, або програми, з яких користувач, можливо, захоче повністю вийти, повинні мати очевидний вихід. Інші програми, як-от, можливо, програми електронної пошти, де вихід - це малоймовірне бажання (щоб він міг постійно перевіряти електронну пошту) - ці програми не повинні витрачати простір вхідного простору керування за допомогою параметра виходу, але для хорошого потоку програми це повинен мати варіант виходу. Що робити, якщо хтось вирішить, що вони не хочуть, щоб їх поштова програма намагалася перевірити електронну пошту, коли вони знаходяться в зоні поганого покриття, або, можливо, під час виклику по Skype чи іншому? Нехай вони вийдуть з програми електронної пошти, якщо хочуть!

Призупинення та вихід з роботи - це два життєво важливих завдання, і жодне не виконує ролі іншого.

Я думаю, що справа в тому, що немає необхідності виходити з програми, якщо у вас немає програмного забезпечення. Android запускає додаток, коли користувач не використовує його та пристрою потрібно більше пам’яті. Якщо у вас є додаток, якому потрібно запустити послугу у фоновому режимі, ви, ймовірно, захочете відключити послугу.

Наприклад, Google Listen продовжує відтворювати подкасти, коли додаток не видно. Але завжди є кнопка паузи, щоб вимкнути подкаст, коли користувач виконає його. Якщо я добре пам’ятаю, Слухай, навіть кладе ярлик на панель сповіщень, щоб завжди можна було швидко дійти до кнопки паузи. Інший приклад - наприклад, додаток на Twitter, наприклад, який постійно оглядає послугу в Інтернеті. Ці типи програм дійсно повинні дозволяти користувачеві вибирати частоту опитування сервера або навіть опитувати у фоновому потоці.

Якщо вам потрібен код, який працює під час виходу, ви можете змінити команду onPause (), onStop () або onDestroy () у відповідних випадках. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Якщо ви не можете зрозуміти, як зробити свої дані / з'єднання (і тим самим "додаток") стійкими, то ви не зможете робити те, що вам потрібно "робити" з Android.

Ті, хто завантажує ці маленькі вбивці додатків, зазвичай виявляють, що вони не допомагають ресурсу акумулятора чи використання пам'яті, але заважають ОС виконувати свою роботу з ефективного управління пам'яттю ...

http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

Я б подумав прочитати "Розробка бездротових додатків для Android", опубліковану Addison-Wesley. Я тільки закінчую це, і це ДУЖЕ ретельно.

Схоже, у вас є деякі принципові непорозуміння платформи Android. Спочатку я також був трохи розчарований життєвим циклом додатків для Android, але, досягнувши більшого розуміння, мені дуже сподобався цей підхід. Ця книга відповість на всі ваші запитання та багато іншого. Це дійсно найкращий ресурс, який я знайшов для нових розробників Android.

Крім того, я думаю, що вам потрібно відпустити порт для рядка наявного додатка. Для того, щоб перенести вашу програму на платформу Android, частина дизайну програми буде змінена. Використовуваний життєвий цикл додатків необхідний, оскільки мобільні пристрої мають дуже обмежені ресурси щодо настільних систем і дозволяють пристроям Android запускати декілька додатків впорядковано та з урахуванням ресурсів. Ще трохи поглиблено вивчіть платформу, і я думаю, ви зрозумієте, що те, що ви хочете зробити, цілком можливо. Удачі.

До речі, я жодним чином не пов’язаний з Аддісон-Веслі чи будь-якою людиною чи організацією, пов’язаною з цією книгою. Після перечитування свого допису я відчуваю, що трохи відкинувся. Мені просто дуже, дуже сподобалось і я вважаю це надзвичайно корисним. :)

Майже у 99% часу немає необхідності в застосуванні Android для перейому власного життєвого циклу. Більшість часу це зводиться до кращого планування або розумнішого дизайну програми. Наприклад, скоріше створити внутрішню службу (не експортується) для обробки завантажень тощо, або проектування дій та завдань навколо робочого процесу користувача.

Але, як кажуть, там, де є воля, є спосіб. Android забезпечує - через клас android.os.Process набагато кращий API, ніж Java для управління базовим процесом. І на відміну від Java, він не ставиться до розробника як до дебіла, ховаючи все це за простим викликом java.lang.System.exit ().

Тож як ви просите свою заяву про самогубство в Android? Ну, хитрість проста:

Створіть власний клас додатків Android, успадкувавши від стандартного класу android.app.Application (не забудьте оголосити його у файлі AndroidManifest.xml).

Замініть метод onCreate () та збережіть ідентифікатор процесу, який розпочав вашу програму:

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

Тепер, щоб вбити вашу програму, надайте метод kill ():

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

Тепер, коли вам потрібно, щоб ваш додаток покінчив життя самогубством, просто введіть кинути контекст програми та зателефонуйте своєму методу вбити!

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

Пам’ятайте лише, що завдяки політиці управління процесами в Android, спеціально пов’язаній із службами, Android може просто вибрати перезапуск служби (див. Не слід використовувати вбивць завдань на Android ).

Коли я створюю додаток в Android, я бачу це так:

• Ви працюєте зі своєю заявою
• Телефон задзвонив
• Ви приймаєте дзвінок
• Після закінчення дзвінка ви повертаєтесь до своєї заявки там, де ви були

Для цього вам потрібна лише Backкнопка або Homeкнопка вашого телефону (коротким або довгим натисканням) та панель сповіщень.

Коли я Backвиходжу зі своєї програми, користуюся кнопкою лише до тих пір, поки не вийду з неї або Homeкнопки.

Ось так я вважаю більшість програм. Але якщо мені потрібен якийсь сеанс чи з'єднання, я зрозумів користувачеві кнопку за допомогою входу / виходу та повідомлення (рядок заголовка чи що-небудь ще). Це досить інший стиль, ніж чистий додаток у стилі "вихід".

На комп'ютерах у вас стільниця з графічним графічним інтерфейсом, а на Android у вас, очевидно, є багатозадачі, але ви показуєте лише один додаток за один раз (я не вважаю тут віджети ^^). А на мобільному телефоні в будь-який час ви можете отримувати сповіщення про щось важливіше, ніж те, що ви робите.

Таким чином, вся концепція програми покладається на щось інше, що "введіть заявку - робота - вихід у додаток".

Гмммм ...

Я думаю, що ви просто не бачите додаток Android належним чином. Ви можете легко зробити щось схоже на те, що хочете:

• Чи зберігають / відновлюють програми програми так, як це рекомендується в документації живого циклу розробника.

• Якщо на етапі відновлення потрібен певний вхід (інформація про вхід / сеанс відсутня), зробіть це.

• Врешті-решт додайте кнопку / меню / час очікування, і в цьому випадку ви зробите finish()без збереження логіна та іншої інформації про сеанс, неминуче закінчуючи сеанс роботи програми: тому, якщо додаток запустити / привести до початку, він розпочне новий сеанс.

Таким чином, вам зовсім не байдуже, чи дійсно додаток видалено з пам'яті чи ні.

Якщо ви дійсно хочете , щоб видалити його з пам'яті (це не рекомендується, і BTW для якої мети?) , Ви можете вбити його умовно в кінці onDestroy()з java.lang.System.exit(0)(або , можливо restartPackage(..)?). Звичайно, зробіть це лише в тому випадку, коли ви хочете "по-справжньому закінчити додаток", тому що onDestroy()це частина нормального життєвого циклу діяльності, а не кінець програми взагалі.

Оскільки додаток в контексті Android - це лише купа неясно пов’язаних заходів, вихід із програми насправді не має великого сенсу. Ви можете закінчити () активність, і буде показано подання попередньої активності в стеку "Активність".

Я згоден з Тедом. Я розумію, що вихід із програми - це не «спосіб Android», але, схоже, це не слід виключати. Ось три причини, чому ви хочете справжнього виходу з програми (не лише активності):

1. Користувач може захотіти деякого контролю над тим, який додаток загине у випадку низької пам’яті. Якщо важлива програма A працює у фоновому режимі, ви, можливо, захочете вийти з програми B, коли закінчите з цим, щоб додаток A не загинув операційною системою.

2. Якщо у вашій програмі є чутливі дані, кешовані в пам’яті, можливо, ви хочете вбити програму, щоб вірус / черв'як / негідник не міг потрапити на неї. Я знаю, що модель безпеки повинна запобігти цьому, але про всяк випадок ...

3. Якщо ваша програма використовує ресурси (наприклад, мережа, процесор, датчики тощо), які можуть негативно вплинути на телефон, то одним із способів забезпечення звільнення цих ресурсів є вихід із програми. Я розумію, що добре сприйняті програми повинні звільняти ресурси, коли вони не потрібні. Але знову ж таки, вихід із програми видається розумним способом забезпечення цього.

Ядро Linux має функцію, яка називається вбивцею поза пам’яті (як уже згадувалося вище, політики можна настроювати на рівні простору користувачів, так як ядро ​​не є оптимальним, але аж ніяк не зайвим).

І він активно використовує Android:

• Вбивця OOM не для користувачів

• Android Notes (Інформація про вбивцю OOM - де можна налаштувати функцію OOM на Android)

• Перенесення Android на реальну ціль

Деякі програми користувальницького простору доступні, щоб допомогти з цими програмами вбивства, наприклад:

• Автоматичний / Налаштування внутрішнього вбивці завдань Android

Ви, мабуть, знайшли потрібну відповідь у команді Finish (). Це не вилучить ваш додаток із пам’яті, але Android буде робити це завжди, коли йому знадобляться ресурси, тому це не має ніякої різниці, що ви цього не будете робити явно.

Я хотів би лише додати, що для досягнення повного ефекту, який зазвичай матиме вихід із програми, ви хочете повернути стан додатка до того, у якому він є, як правило, у момент першого запуску після завантаження пристрою, безпосередньо перед цим зателефонувати до кінця () про всі ваші дії. Таким чином, якщо користувач вибере ваш додаток ще раз, він, здається, був запущений "свіжим", без будь-якого стану, що залишився від точки до імітованого "виходу".

Якщо є якісь спеціальні дії, які повинні відбуватися лише під час "виходу", наприклад, збереження роботи користувача або будь-якого іншого, ви також можете виконати їх до початку ініціалізації вищевказаної програми.

Такий підхід дозволяє досягти своєї мети мати команду "вихід", не порушуючи філософію Android, залишаючи управління операційними ресурсами ОС, включаючи закриття додатків, в руках операційної системи.

Особисто я б не використовував цей підхід, оскільки користувачі Android очікують, що додаток збереже його наступність під час перегляду його, і тому вони не звикли до модальності "виходу" з програми. Я б замість цього підтримав "чітку" функцію, яку користувач може викликати для відновлення програми до деякого початкового стану за замовчуванням, без необхідності "залишати" це в процесі.

Єдиним винятком буде те, коли користувач натискав кнопку "назад" достатню кількість разів, щоб програма закривалась. У цій ситуації від користувача не очікується, що стан буде збережено (і якщо в додатку немає збереженого стану, ви, як розробник, повинні мати код обробки кнопки "назад", що виявляє ці збережені дані, і спонукає користувача зберегти його до SharedPreferences або до файлу, або до іншого енергонезалежного носія).

Щодо system.exit (0):

Якщо ви все-таки вирішите використовувати system.exit (0), щоб закрити додаток із грубою остаточністю (наприклад, в результаті остаточного натискання кнопки "назад", я б попередив вас, що, хоча для мене це "працює", і в деяких випадки - це єдиний спосіб, коли мені вдалося закрити додаток, не залишивши жодного сліду, є один незначний збій, який виникає в Jelly Bean, коли ви використовуєте цей підхід.

Зокрема, якщо ви використовуєте список останніх програм, щоб відкрити додаток, а потім скористатися кнопкою "Назад", щоб закрити додаток (при закритті, що реалізується через system.exit (0)), список останніх програм знову стане видимим, як і буде ніколи не були закриті. Якщо потім натиснути запис додатка у цьому списку, щоб запустити його вдруге із того ж уже відкритого списку останніх програм, відповіді не буде.

Я підозрюю, що причиною цього є те, що список останніх програм переглядає посилання на ваше додаток, яке стало нефункціональним через те, що ви закрили додаток за допомогою system.exit (0). Більш цивілізоване закриття вашої програми за допомогою закінчення (), можливо, повідомило б ОС таким чином, що дозволило б оновити список останніх програм, але system.exit (0), мабуть, цього не робить.

Це сама по собі не є величезною проблемою, оскільки дуже мало людей відкриє додаток із "Недавніх додатків", потім вийде з нього, а потім негайно знову відкриє його з того самого відкритого списку "Недавні програми". І якщо вони натискають кнопку додому та повторно відкривають список останніх програм, запис у вашій програмі буде там, і він буде повністю функціональним. Але я думаю, що це показує, що використання system.exit (0) може перешкоджати належному зв’язку між вашим додатком та ОС, і це говорить про те, що можуть бути й інші, більш серйозні, можливо, тонкі наслідки використання цього підходу.

Я сподіваюся, що з часом все зміниться. Користувач повинен мати змогу знищити додаток або процес, якщо ОС додаток належним чином пісочниці. Існує думка, що програми повинні бути написані ідеально або користувач буде використовувати лише ті програми, які відповідають усім рекомендаціям SDK. Я думаю, що це високе замовлення.

Існує (відносно) проста конструкція, яка дозволить обійти «вихідну» загадку. Зробіть так, щоб у вашому додатку було "базове" стан (діяльність), який є лише порожнім екраном. У першому onCreate діяльності ви можете запустити іншу діяльність, в якій є основна функціональність вашої програми. Потім "вихід" можна виконати, якщо закінчити () цю другу діяльність і повернутися до основи просто порожнього екрана. ОС може зберегти цей порожній екран в пам'яті стільки, скільки хоче ...

По суті, оскільки ви не можете вийти з ОС, ви просто перетворюєтесь на самостворене небуття.

Без функції виходу для розробника програми вбивати власну програму дуже поганий дизайн.

У моїй програмі потрібно дозволити користувачеві динамічно змінювати дані під час виконання, а користувачеві потрібно перезапустити мою програму, щоб зробити ефект зміни, але Android не дозволив самому перезапустити додаток. У ОС Android дуже поганий життєвий цикл дизайнерських програм.

Щоб закрити додаток у будь-який момент, використовуйте FLAG_ACTIVITY_CLEAR_TOPпрапор у Намір, а потімsystem.exit();

Або є подібний спосіб, але без того, system.exit()коли ви хочете вийти, викликайте цей метод:

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

У вашому HomeActivity.onCreate()додати наступні

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

Це буде працювати без порушення життєвого циклу Android.

Перш за все, ніколи ніколи не використовуйте System.exit (0). Це як змусити людину спати, ударяючи його по голові!

По-друге: Я зіткнувся з цією проблемою. Перш ніж поділитися своїм рішенням, я хочу поділитися своїми думками.

Я думаю, що "кнопка виходу" дурна. Дійсно дійсно дуже дурно. І я думаю, що користувачі (споживачі), які запитують кнопку виходу для вашої програми, теж дурні. Вони не розуміють, як працює ОС і як керує ресурсами (і це робить чудову роботу).

Я думаю, що якщо ви напишете хороший фрагмент коду, який зробить правильні речі (оновлення, збереження та натискання) в потрібний момент та умови та використання правильних речей (Сервіс та приймач), він буде працювати досить добре, і ніхто не буде скаржитися .

Але для цього вам доведеться вивчити і дізнатися, як все працює на Android. У всякому разі, це моє рішення надати користувачам "Кнопку виходу".

Я створив Меню параметрів, яке завжди видно в кожній діяльності (у мене супердія, яка це робить).

Коли користувач натискає цю кнопку, це відбувається:

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

Тому я зберігаю в SharedPreferences, що я хочу вбити свою програму, і я запускаю Інтенцію. Будь ласка, подивіться на ці прапори; вони очистять усі мої ранки, називаючи мою діяльність DashBoard, що є моєю "домашньою" діяльністю.

Отже, у своїй діяльності на інструментальній панелі я запускаю цей метод у 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();
    }
}

І це буде працювати досить добре.

Єдине, що я не розумію, чому це відбувається, це те, що коли я виконую останнє завершення (і я перевірив: він слідкує за всім правильним потоком onPause → onStop → onDestroy), програма все ще перебуває в останній активності (але це порожнє).

Схоже, останній намір (який запустив DashboardActivity) все ще є в системі.

Я мушу більше копати, щоб також його вийняти.

Життєвий цикл додатків Android призначений для користувачів мобільних телефонів, а не користувачів комп'ютерів.

Життєвий цикл програми - жорстоко спрощена парадигма, необхідна для перетворення сервера Linux на споживчий пристрій.

Android - це Java через Linux, справжня багатопрофільна серверна ОС. Ось так воно швидко поширилося. Життєвий цикл додатка інкапсулює основну реальність ОС.

Для мобільних користувачів додатки просто встановлені або не встановлені. Немає концепції бігу чи виходу. Насправді, програми додатків призначені для запуску до тих пір, поки ОС не звільнить їх за збережені ресурси.

Оскільки це Stack Overflow, кожен, хто читає це, є користувачем комп’ютера і повинен вимкнути 90% своїх знань, щоб зрозуміти життєвий цикл мобільних додатків.

Щоб прочитати це запитання, мені знадобилося більше часу, ніж реально реалізувати напівправильний життєвий цикл додатків Android.

Це програма GPS, яка опитує очки та надсилає поточне місце розташування у веб-сервіс кожні кілька секунд за допомогою потоку ... Це може опитувати кожні 5 хвилин у випадку Теда для оновлення, тоді onStop може просто запустити активність оновлення. Тед був су стурбовані тим, чи знайдено його (асинхронний Тед, не кодуйте, як програміст Windows, або ваші програми працюватимуть як програми Windows ... еww, це не так складно).

Я зробив початковий код у onCreate, щоб налаштувати речі протягом життя, включаючи 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();
}

Цей код може бути абсолютно неправильним, але він працює. Це одне з моїх перших додатків для Android.

Voilà, додаток, який не споживає процесор, коли він знаходиться у фоновому режимі, але миттєво готовий до відкриття, оскільки він знаходиться в оперативній пам’яті (хоча не має оперативної пам’яті, як життєвий цикл Android)… додаток завжди готовий, це телефон , хлопці / гелі. Якщо додаток повинен використовувати всю оперативну пам’ять, і ОС не може бути вимкнена, тоді річ може перестати дзвонити = P Ось чому ОС повинна мати змогу закрити додаток, коли він знаходиться у фоновому режимі (якщо ваша програма не є 't' hog ресурсу, це не буде закрито BTW), тому давайте просто напишемо кращі програми.

Кожного разу під час переходу на наступну сторінку за допомогою намірів використовуйте:

`YourActivityname.this.finish()`;

Приклад:

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

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

Щоб жодна активність не працювала у фоновому режимі, і коли ви хочете вийти зі свого додатка, використовуйте:

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

Цей вихід працював як шарм для мене :)

У будь-якому випадку, якщо ви хочете припинити свою заявку, ви завжди можете зателефонувати System.exit(0);.

Якщо у вас працює 10,20 .. декілька видів діяльності, і ви хочете закінчити їх і вийти з системи.

Створіть статичний масив у application classабоconstants class.

Константи

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