Является ли отказ от приложения недоверчивым?

Ответ 1

Это, в конечном счете, дойдет до вашего вопроса, но я сначала хочу рассмотреть ряд вопросов, которые вы поднимаете в своих различных комментариях, к различным ответам, уже указанным на момент написания этой статьи. Я не собираюсь менять свой разум - скорее, они здесь для других, которые приходят читать этот пост в будущем.

Дело в том, что я не могу допускать Android, чтобы определить, когда мое приложение будет прекращено. это должно быть выбор пользователя.

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

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

Как я сказал выше, существует много вещи, происходящие в моем приложении (данные Подгружается на устройство, списки с задачами что всегда должно быть там и т.д.).

Я не знаю, что означает "списки с задачами, которые всегда должны быть там", но "данные, которые PUSHed для устройства" являются приятной фикцией и в любом случае не должны выполняться какой-либо деятельностью. Используйте запланированную задачу (через 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 в это время.

Ответ 2

Я просто хотел бы добавить исправление для будущих читателей этой темы. Этот особый нюанс долгое время избегал моего понимания, поэтому я хочу убедиться, что никто из вас не совершает те же ошибки:

System.exit() не убивает ваше приложение, если в стеке есть более одного действия. На самом деле происходит то, что процесс убит и сразу же перезапускается с помощью одного меньше активности в стеке. Это также происходит, когда ваше приложение убивается диалогом Force Close или даже когда вы пытаетесь убить процесс из DDMS. Насколько мне известно, это факт, который, как мне кажется, полностью не документирован.

Короткий ответ: если вы хотите выйти из приложения, вам нужно отслеживать все действия в вашем стеке и finish() ВСЕ, когда пользователь хочет выйти (и нет, нет способа для итерации по стеку активности, поэтому вам нужно все это самостоятельно управлять). Даже это фактически не убивает процесс или какие-либо болтающиеся ссылки, которые у вас могут быть. Он просто заканчивает деятельность. Кроме того, я не уверен, работает ли Process.killProcess(Process.myPid()) лучше; Я не тестировал его.

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

Длинный ответ включает объяснение философии, лежащей в основе этого поведения. Философия рождается из ряда предположений:

• Прежде всего, это происходит только тогда, когда ваше приложение находится на переднем плане. Если он находится в фоновом режиме, процесс завершится просто отлично. Однако, если он находится на переднем плане, ОС предполагает, что пользователь хочет продолжать делать то, что он/она делает. (Если вы пытаетесь убить процесс из DDMS, сначала нажмите кнопку "домой", а затем убейте его).
• Он также предполагает, что каждое действие не зависит от всех других видов деятельности. Это часто бывает так, например, в том случае, если ваше приложение запускает действие браузера, которое полностью разделено и не написано вами. Активность браузера может создаваться или не создаваться в одной и той же Задаче, в зависимости от ее атрибутов манифеста.
• Предполагается, что каждая ваша деятельность полностью независима и может быть убита/восстановлена ​​в одно мгновение. (Мне скорее не нравится это конкретное предположение, поскольку в моем приложении много действий, которые основаны на большом количестве кэшированных данных, слишком больших, чтобы эффективно сериализоваться во время onSaveInstanceState, но что делать?). Для большинства хорошо написанных приложений для Android это должно быть правдой, так как вы никогда не знаете, когда ваше приложение будет убито в фоновом режиме.
• Конечным фактором является не столько предположение, сколько ограничение ОС: убийство приложения явно такое же, как и при сбое приложения, а также то же, что Android, убивающий приложение для восстановления памяти. Это завершает наш coup de grace: поскольку Android не может сказать, что приложение вышло из строя или было разбито или было убито в фоновом режиме, предполагается, что пользователь хочет вернуться туда, где они остановились, и поэтому ActivityManager перезапустит этот процесс.

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

Скажите, что я хочу, чтобы мои пользователи могли делать снимок и загружать его. Я запускаю Camera Activity из своей активности и прошу вернуть изображение. Камера помещается в верхнюю часть моей текущей задачи (а не создается в ее собственной Задаче). Если у камеры есть ошибка, и она падает, это должно привести к сбою всего приложения? С точки зрения пользователя только сбой камеры, и они должны быть возвращены к предыдущему действию. Таким образом, он просто перезапускает процесс со всеми теми же действиями в стеке, минус камера. Поскольку ваши действия должны быть разработаны так, чтобы их можно было убить и восстановить при падении шляпы, это не должно быть проблемой. К сожалению, не все приложения могут быть спроектированы таким образом, поэтому это проблема для многих из нас, независимо от того, что говорит Ромен Гай или кто-либо еще. Итак, нам нужно использовать обходные пути.

Итак, мой заключительный совет:

• Не пытайтесь убить процесс. Вызывайте finish() для всех действий или вызывайте moveTaskToBack(true).
• Если ваш процесс вылетает из строя или его убивают, и если, как и мне, вам нужны данные, которые были в памяти, которые теперь потеряны, вам нужно вернуться к корневой активности. Чтобы сделать это, вы должны вызвать startActivity() с намерением, который содержит флаг Intent.FLAG_ACTIVITY_CLEAR_TOP.
• Если вы хотите убить свое приложение с точки зрения Eclipse DDMS, лучше не быть на переднем плане или перезапустить его. Сначала вы должны нажать кнопку "Домой", а затем убейте процесс.

Ответ 3

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

Ответ 4

Прекратите рассматривать приложение как монолитное приложение. Это набор экранов пользовательского интерфейса, которые пользователь может взаимодействовать с вашим "приложением" и "функциями", предоставляемыми через службы Android.

Не зная, что ваше таинственное приложение "делает" не очень важно. Предположим, что он туннелируется в суперсерверную корпоративную интрасеть, выполняет некоторый мониторинг или взаимодействие и остается включенным до тех пор, пока пользователь не "покинет приложение". Поскольку ваш ИТ-отдел командует им, пользователи должны быть очень внимательны, когда они находятся в IN или OUT из интрасети. Следовательно, ваше мышление важно для пользователей "выйти".

Это просто. Сделайте службу, которая отправляет текущее уведомление на панели уведомлений, говоря: "Я в интрасети, или я запущен". Попросите эту службу выполнить все функции, необходимые для вашего приложения. Имейте действия, которые привязаны к этой службе, чтобы позволить вашим пользователям получать доступ к битам пользовательского интерфейса, которые им необходимы для взаимодействия с вашим "приложением". И у вас есть кнопка Android Menu → Quit (или выход из системы или что-то еще), которая сообщает службе о завершении работы, а затем закрывает сама деятельность.

Это, для всех целей и целей, именно то, что вы говорите, чего хотите. Сделал способ Android. Посмотрите на Google Talk или Google Maps Navigation, примеры этого "выхода" - это возможный менталитет. Единственное различие заключается в том, что нажатие кнопки "Назад" из вашей активности может привести к тому, что ваш процесс UNIX будет ждать, если пользователь захочет оживить ваше приложение. Это ничем не отличается от современной операционной системы, которая кэширует недавно полученные файлы в памяти. После того, как вы покинете свою программу Windows, скорее всего, ресурсы, которые ей нужны, все еще находятся в памяти, ожидая замены другими ресурсами, поскольку они загружаются сейчас, когда они больше не нужны. Android - это то же самое.

Я действительно не вижу твоей проблемы.

Ответ 5

Это интересное и проницательное обсуждение с участием многих экспертов. Я чувствую, что этот пост должен быть зациклен на основном веб-сайте Android, потому что он вращается вокруг одного из основных проектов ОС Android.

Я также хотел бы добавить здесь свои два цента.

До сих пор я был впечатлен Android-способом обработки событий жизненного цикла, в результате чего концепция веб-подобных впечатлений появилась в родных приложениях.

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

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

Это не значит, что кто-то (ОС, разработчик?) позаботится об этом по своему усмотрению... это просто означает "где моя кнопка" Красный X ", к которой я привык". Мое действие должно быть аналогично "завершать вызов нажатием кнопки", "выключать устройство, нажимая кнопку" и т.д. И т.д.... это восприятие. Это приносит удовлетворение как таковое, что мои действия действительно достигают своей цели.

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

Ответ 6

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

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

Ответ 7

Это обсуждение сводится к старому вопросу о том, знают ли разработчики лучше всего или знает ли пользователь лучше. Профессиональные дизайнеры во всех областях человеческих факторов ежедневно борются с этим.

Тед сделал вывод, что одним из самых загруженных приложений на рынке является "Убийца приложений". Люди получают немного лишнего серотонина, когда они прекращают применение. Они привыкли к этому с помощью настольного компьютера/ноутбука. Это заставляет вещи двигаться быстро. Он поддерживает охлаждение процессора и включение вентилятора. Он использует меньше энергии.

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

Однако я также считаю, что вы не должны расстраивать пользователя, даже если это разочарование подтверждается их собственным невежеством. Из-за этого я пришел к выводу, что наличие опции "Выход" - это хороший дизайн, даже если это в основном кнопка плацебо, которая делает не что иное, как закрытие вида.

Ответ 8

Тед, что вы пытаетесь сделать, может быть сделано, возможно, просто не так, как вы думаете об этом прямо сейчас.

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

Ответ 9

Сообщение в блоге Когда включать кнопку выхода в приложениях Android (подсказка: никогда) объясняет это далеко, намного лучше, чем я могу. Желаю, чтобы каждый разработчик Android уже прочитал его.

Выдержки:

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

Многие пользователи считают, что кнопка выхода реализует это требование и попросите его добавить. Разработчики, стремящиеся порадовать своих пользователей, обязуйтесь добавить один. Вскоре после этого они оба терпят неудачу.

• В большинстве случаев кнопка выхода просто вызывает Activity.finish(). Это в точности эквивалентно нажатию кнопки "Назад". Точно. Службы продолжают работать, и опрос продолжается. Пользователи могут подумать, что они убили приложение, но они этого не сделали, и вскоре они будут еще более раздражены.
• Теперь поведение вывода неоднозначно. Если ваша кнопка выхода просто закроет Activity или она также остановит все связанные службы, приемники и сигналы тревоги? Что делать Back? Что произойдет, если они ударят Home вместо этого? Что произойдет, если ваше приложение имеет виджет? Должна ли кнопка выхода останавливать это от обновления?

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

Идите дальше и прочитайте полную статью.

Ответ 10

Ответ: (Romain Guy): Пользователь этого не делает, система обрабатывает это автоматически. Это то, что жизненный цикл деятельности (особенно onPause/onStop/onDestroy) - для. Независимо от того, что вы делаете, не ставьте кнопка "выйти" или "выйти". Это бесполезно для Android модель приложения. Это также противоречит тому, как основные приложения работа.

1: Полностью выход из приложения может быть вообще неуправляемым, но это не бесполезно. Что делать, если у окон не было выхода? Система была бы медленной, поскольку память была заполнена, и OS должна была угадать, с какими программами вы были сделаны. Меня не волнует, что говорят Ромен Гай или даже Ларри Пейдж и Сергей Брин - это неоспоримые факты: системы работают медленнее, когда им приходится убивать задачи, чтобы получить их память, прежде чем можно будет запустить новое приложение. Вы просто не можете сказать мне, что не требуется время, чтобы убить приложение! Даже свет от далеких звезд требует времени... Там есть, что позволяет пользователю полностью закрыть приложения.

2: Вопреки тому, как работают основные приложения? Что это значит? Когда я закончил запуск приложения, он больше не выполняет никаких действий... Он просто ждет, когда его память будет убита, когда потребуется его память.

Таким образом, существует четкое различие между минимизацией и выходом, и ни один из них не подходит для другого. Разве мы оставляем отвертку в каждом винте? Или ключ в каждой двери? Оставляем ли мы все наши приборы высоко до тех пор, пока не ударит выключатель, и нам нужно включить другой прибор? Выходим ли мы из посудомоечной машины, полной посуды, и вынимаем только каждый раз, чтобы освободить место для новых грязных? Оставим ли мы все машины, идущие на подъездной дорожке, до тех пор, пока не опустится.

Если пользователь хочет свести к минимуму приложение, лучше всего его минимизировать. Если пользователь хочет выйти из приложения, то, в любом случае, лучше выйти.

Он нахмурился? Этот вид Android - они нахмурились. И многие многие независимые разработчики Android-новичков нахмурились.

Но когда дело доходит до него, есть хорошее кодирование и плохое кодирование. Есть хорошие модели потока программ, и есть плохие модели потока программ.

Выход программ в память, когда пользователь знает, что с ними делается, просто не является хорошим потоком программ. Он не имеет абсолютно никакой цели, и он замедляет работу при запуске новых приложений или при запуске приложений выделяет больше памяти.

Это похоже на ваш автомобиль: бывают случаи, когда вы оставляете его на работе, например, останавливаетесь на стоп-сигнале или, возможно, в машине быстрого питания, или останавливаетесь в банкомате. Но есть и другие ситуации, когда вы хотите отключить его - например, когда вы приступаете к работе, или в продуктовый магазин или даже дома.

Аналогично, если вы играете в игру, и телефон звонит, да. Приостановите игру и продолжайте ее работу. Но если пользователь закончил игру некоторое время, то, во что бы то ни стало, они могут выйти.

Кнопка выхода в некоторых приложениях должна быть больше впереди, чем другие. Игры, например, или программы, где пользователь, скорее всего, захотят полностью выйти, должны иметь очевидный выход. Другие программы, такие как, возможно, программы электронной почты, где выход - это маловероятное желание (чтобы он мог продолжать проверять электронную почту) - эти программы не должны тратить основное пространство ввода управления с опцией выхода, но для хорошего потока программы должен иметь опцию выхода. Что, если кто-то решит, что они не хотят, чтобы их почтовая программа пыталась проверить электронную почту, когда они находятся в плохой зоне покрытия, или, может быть, в Skype-звонке или что-то еще? Пусть они выйдут из программы электронной почты, если они захотят!

Приостановка и выход - две жизненно важные задачи и не выполняет роль другого.

Ответ 11

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

Например, Google Listen продолжает воспроизводить подкаст, когда приложение не отображается. Но всегда есть кнопка паузы, чтобы отключить подкаст, когда пользователь с ним работает. Если я правильно помню, Listen, даже добавляет ярлык в панель уведомлений, чтобы вы могли быстро перейти к кнопке паузы. Другим примером является приложение, например приложение twitter, которое постоянно проверяет службу в Интернете. Эти типы приложений должны действительно позволять пользователю выбирать, как часто опросить сервер, или даже опросить фоновый поток.

Если вам нужен код, который выполняется при выходе, вы можете переопределить onPause(), onStop() или onDestroy(), если это необходимо. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Ответ 12

Если вы не можете понять, как сделать ваши данные/подключения (и тем самым ваше "приложение") постоянным, вы не сможете делать то, что вам "нужно" для Android.

Те, кто действительно загружает этих причудливых App Killers, обычно считают, что они не помогают использовать батареи или использование памяти, но препятствуют тому, чтобы ОС выполняла работу по эффективному управлению памятью...

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

Ответ 13

Я бы подумал о том, чтобы прочитать "Android Wireless Application Development", опубликованную Addison-Wesley. Я просто заканчиваю его, и это ОЧЕНЬ тщательно.

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

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

Кстати, я не отношусь к Аддисону-Уэсли или к любому человеку или организации, связанной с этой книгой. После повторного чтения моего сообщения я чувствую, что я отрылся от маленького фанатика. Я просто действительно наслаждался этим и нашел его чрезвычайно полезным.:)

Ответ 14

Почти в 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);

Теперь, когда вам нужно приложение для совершения самоубийства, просто введите приведение контекста приложения и вызовите метод kill!

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

Просто помните, что из-за политик управления процессами в Android, особенно связанных с сервисами, Android может просто выбрать перезапуск службы (см. Вы не должны использовать убийцы задач на Android).

Ответ 15

Когда я представляю приложение на Android, я вижу его так:

• Вы работаете с вашим приложением
• Телефон зазвонил
• Вы берете вызов
• В конце вызова вы вернетесь в свое приложение в том же месте, где вы были.

Для этого вам нужна кнопка Back или кнопка Home вашего телефона (короткое или длинное нажатие) и панель уведомлений.

Когда я выхожу из своего приложения, я использую только кнопку Back, пока не выйду из нее, или кнопку Home.

То, как большинство приложений задумано, я думаю. Но если мне нужна какая-то сессия или соединение, я дал понять пользователю с кнопкой входа/выхода из системы и уведомлением (панель заголовка или что-то еще). Это совсем другой стиль, чем чистое приложение "выход".

На ПК у вас есть компьютер с несколькими GUI, и на Android у вас, очевидно, есть несколько задач, но вы показываете только одно приложение за раз (я не рассматриваю виджеты здесь ^^). И на мобильном телефоне в любое время вы можете получить уведомление о чем-то более важном, чем то, что вы делаете.

Таким образом, вся концепция приложения зависит от чего-то другого, что "введите приложение - работа - выход из приложения".

Ответ 16

Хммм...

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

• Поддерживает ли приложение состояние сохранения/восстановления, как это рекомендуется в документации для разработчиков.

• Если на этапе восстановления требуется какой-либо логин (нет доступной информации входа/сессии), сделайте это.

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

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

Если вы действительно хотите удалить его из памяти (это обескуражено и BTW с какой целью?), вы можете убить его условно в конце onDestroy() с помощью java.lang.System.exit(0) (или, возможно, restartPackage(..)?). Конечно, сделайте это только в том случае, если вы хотите "действительно закончить приложение", потому что onDestroy() является частью обычного жизненного цикла действий, а не конца приложения.

Ответ 17

Как приложение в контексте Android - это всего лишь куча неопределенно связанных действий, выход из приложения на самом деле не имеет большого смысла. Вы можете закончить() действие, и будет отображаться представление предыдущего действия в стеке "Активность".

Ответ 18

Я согласен с Тедом. Я понимаю, что выход из приложения не "Android-путь", но похоже, что это не должно быть исключено. Вот три причины, по которым вам может потребоваться реальный выход приложения (не просто активность):

• Пользователь может захотеть получить контроль над тем, какое приложение будет убито в случай низкой памяти. Если важное приложение A работает в фоновом режиме, то вам может потребоваться выйти из приложения B, когда вы закончите с ним, так что что приложение A не уничтожается операционной системой.

• Если ваше приложение имеет секретные данные, кэшированные в памяти, вы можете например, убить приложение, чтобы приложение virus/worm/rogue не могло его получить. я знать, что модель безопасности должна предотвращать это, но на всякий случай...

• Если ваше приложение использует ресурсы (например, сеть, ЦП, датчики и т.д.), которые могут негативно повлиять на телефон, а затем один из способов эти ресурсы освобождаются, чтобы выйти из приложения. я понимаю что хорошо управляемые приложения должны освобождать ресурсы, когда они не нужны. Но опять же, выход из приложения кажется разумным способом обеспечения этого.

Ответ 19

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

И он сильно используется Android:

• Убийца OOM не для пользовательского пространства

• Заметки для Android (OOM Killer Info - где вы можете настроить функцию OOM на Android)

• Android Портирование по реальной цели

Некоторые приложения для пользовательского пространства доступны для помощи в этих приложениях для удаления, например:

• Autokiller/Настройка внутреннего убийцы задач Android

Ответ 20

Я надеюсь, что со временем все изменится. Пользователь должен уметь убивать приложение или процесс, если ОС приложения корректно изолирует ОС. Существует мнение, что приложения должны быть написаны отлично или пользователь будет использовать только те приложения, которые следуют всем рекомендациям SDK. Я думаю, что это высокий порядок.

Ответ 21

Вы, видимо, нашли ответ, который вы хотите в команде finish(). Это не приведет к удалению вашего приложения из памяти, но Android будет делать это каждый раз, когда ему понадобятся ресурсы, поэтому не имеет никакого значения, что вы не будете делать это явно.

Я бы добавил только, что для достижения полного эффекта, который обычно имеет выход приложения, вы бы хотели reset состояние приложения независимо от того, что его состояние обычно в то время, когда оно запускается после загрузки устройство, непосредственно перед вызовом finish() для всех ваших действий. Таким образом, если пользователь снова выберет ваше приложение, он, кажется, будет запущен "свежим", без какого-либо состояния, оставшегося от точки до симулированного "выхода" .

Если есть некоторые специальные действия, которые должны выполняться только при "выходе", например, при сохранении работы пользователя или что-то еще, вы также можете выполнить их до части повторной инициализации описанной выше процедуры.

Этот подход позволяет вам выполнить свою команду "выхода" , не нарушая философии Android, оставляя управление ресурсами ОС, включая закрытие приложений, в руках операционной системы.

Лично я бы не использовал этот подход, потому что пользователи Android ожидают, что приложение сохранит свою преемственность, когда они пересмотрят его, и поэтому они не привыкли к модальности "выхода" из приложения. Вместо этого я бы поддержал "ясную" функцию, которую пользователь может вызвать в reset приложение в какое-то начальное состояние по умолчанию, без необходимости "оставить" его в процессе.

Единственное исключение - когда пользователь несколько раз нажал кнопку "Назад" , чтобы закрыть приложение. В этой ситуации в пользовательской части не ожидается, что состояние будет сохранено (и если в приложении есть несохраненное состояние, тогда у вас, как разработчика, должен быть код, обрабатывающий кнопку "Назад" , которая обнаруживает несохраненные данные, и предлагает пользователю сохранить его в SharedPreferences или в файл или на какой-либо другой энергонезависимый носитель).

Что касается system.exit(0):

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

В частности, если вы используете список последних приложений для открытия своего приложения, а затем используйте кнопку "Назад" , чтобы закрыть приложение (с помощью этого закрытия, реализованного через system.exit(0)), список последних приложений снова станет видимым, так как он никогда не был закрыт. Если вы затем коснитесь своей записи приложения в этом списке, чтобы запустить ее во второй раз из того же, уже открытого, списка последних приложений, ответа не будет.

Я подозреваю, что причиной этого является то, что список последних приложений поддерживает ссылку на ваше приложение, которое стало неработоспособным из-за закрытия приложения с помощью system.exit(0). Более цивилизованное закрытие вашего приложения с помощью функции finish() могло бы сообщить OS таким образом, который позволил бы ему обновить список последних приложений, но system.exit(0), по-видимому, этого не делает.

Это не огромная проблема сама по себе, так как очень немногие люди откроют приложение из последних приложений, а затем выйдут из него, а затем немедленно откроют его из того же открытого списка последних приложений. И если они нажмут кнопку "Домой", а затем снова откроют список "Недавние приложения", ваша запись в приложении будет там, и она будет полностью функциональной. Но я думаю, что это показывает, что использование system.exit(0) может помешать правильной связи между вашим приложением и ОС, и это говорит о том, что могут быть другие, более серьезные, возможно, тонкие последствия использования этого подхода.

Ответ 22

Без функции выхода для разработчика приложения для их собственного приложения это очень плохой дизайн.

Мое приложение должно позволить динамически динамически изменять данные динамически во время выполнения, и пользователю необходимо перезапустить мое приложение, чтобы сделать эффект изменения, но Android не разрешил мое приложение перезапускать сам по себе. Android OS имеет очень плохой жизненный цикл приложения.

Ответ 23

Существует (относительно) простой дизайн, который позволит вам обойти головоломку "выхода". Сделайте свое приложение "базовым" состоянием (активностью), которое является просто пустым экраном. В первом onCreate активности вы можете запустить еще одно действие, в котором находится основная функциональность вашего приложения. Затем "exit" можно завершить, завершая() второе действие и возвращаясь к базе только пустого экрана. OS может хранить этот пустой экран в памяти до тех пор, пока он хочет...

В сущности, потому что вы не можете выйти из ОС, вы просто превращаетесь в самосозданное ничто.

Ответ 24

Прежде всего никогда никогда не используйте 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) по-прежнему находится в системе.

Мне нужно больше копать, чтобы удалить его.

Ответ 25

Мне потребовалось больше времени, чтобы прочитать этот Q & A, чем фактически реализовать полузадачный жизненный цикл приложений Android.

Это приложение GPS, которое опросает точки и отправляет текущее местоположение в веб-службу каждые несколько секунд с помощью потока... Это может быть опрос каждые 5 минут в случае Ted для обновления, тогда onStop может просто запустить операцию обновления Тед беспокоился о том, что если кто-то был найден (асинхронный Тед, не кодируйте, как программист Windows, или ваши программы будут работать как программы Windows... eww, это не так сложно).

Я сделал некоторый исходный код в 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à, приложение, которое не потребляет процессор, когда оно находится в фоновом режиме, но сразу же готово к повторному открытию, потому что оно находится в ОЗУ (хотя и не содержит RAM, как и жизненный цикл Android)... приложение всегда готово, это телефон, парни/девушки. Если приложение должно было использовать всю оперативную память и не могло быть выключено ОС, тогда вещь может перестать звонить = P. Поэтому ОС должна иметь возможность закрыть приложение, когда оно находится в фоновом режиме (если ваше приложение не является 't ресурс hog он не будет закрыт BTW), поэтому давайте просто писать лучшие приложения.

Ответ 26

Для закрытия приложения в любой точке используйте флаг FLAG_ACTIVITY_CLEAR_TOP в Intent, а затем 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.

Ответ 27

Каждый раз, когда вы переходите на следующую страницу с помощью намерения, используйте:

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

Этот выход работал как прелесть для меня:)

Ответ 28

Жизненный цикл приложения Android предназначен для пользователей мобильных телефонов, а не для пользователей компьютеров.

Жизненный цикл приложения - это жестоко упрощенная парадигма, необходимая для превращения сервера Linux в потребительское устройство.

Android - это Java over Linux, настоящая кросс-платформенная серверная ОС. Так оно и распространилось так быстро. Жизненный цикл приложения инкапсулирует базовую реальность ОС.

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

Поскольку это переполнение стека, любой, кто это читает, является пользователем компьютера и должен отключить 90% своих знаний, чтобы понять жизненный цикл мобильного приложения.

Ответ 29

В любом случае, если вы хотите завершить свое приложение, вы всегда можете позвонить System.exit(0);.

Ответ 30

Если у вас есть 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);
            }
        });
    }
}