退出应用程序会感到皱眉吗? [英] Is quitting an application frowned upon?
问题描述
我继续学习Android，只是已读以下:
问题:用户是否可以选择终止该应用程序 除非我们在菜单选项中将其杀死?如果不存在这样的选项， 用户如何终止应用程序?
答案:(Romain Guy):用户没有，系统会自动处理.这就是活动生命周期(尤其是onPause/onStop/onDestroy)的用途.无论您做什么，都不要放置退出"或退出"应用程序按钮.对于Android的应用程序模型，它是没有用的.这也与核心应用程序的工作方式相反.
呵呵，我在Android世界中迈出的每一步都会遇到某种问题=(
显然，您不能在Android中退出应用程序(但是Android系统可以在需要时完全销毁您的应用程序).那是怎么回事?我开始认为不可能编写一个功能像普通应用程序"的应用程序-用户可以在决定退出应用程序时退出该应用程序.那不是应该依靠操作系统来完成的事情.
我尝试创建的应用程序不是适用于Android Market的应用程序.它不是公众广泛使用"的应用程序，而是将在非常狭窄的业务领域中使用的商业应用程序.
实际上，我真的很期待开发Android平台，因为它解决了Windows Mobile和.NET中存在的许多问题.但是，上周对我来说是个休假……我希望我不必放弃Android，但是现在看起来还不太好=(
我有办法真的退出该应用程序吗?
这最终将解决您的问题，但是我首先想解决您在各种评论中针对当时已经给出的各种答案提出的一些问题.这本书.我无意改变您的想法-相反，这些是供将来阅读此帖子的其他人使用的.
重点是我不能允许 Android确定我的应用何时 将被终止.那一定是 用户的选择.
数以百万计的人对环境根据需要关闭应用程序的模型感到非常满意.这些用户根本不会考虑终止" Android应用程序，而只是考虑终止"网页或终止"恒温器.
iPhone用户的使用方式大致相同，因为按下iPhone按钮并不一定像终止应用程序一样感觉"，因为许多iPhone应用程序都从用户离开的地方开始接听，即使该应用程序确实已关闭(因为iPhone目前一次只允许一个第三方应用程序.
正如我上面说的，有很多 我的应用中发生的事情(数据正在 推送到设备，列出任务 总是应该在那里，等等.
我不知道列出总是应该存在的任务"是什么意思，但是将数据推送到设备上"是一种令人愉快的小说，在任何情况下都不应由活动来完成.使用计划任务(通过AlarmManager)来更新数据，以实现最大可靠性.
我们的用户登录后无法执行 他们每次接到电话 然后Android决定终止该应用.
有许多iPhone和Android应用程序可以解决此问题.通常是因为它们保留登录凭据，而不是强迫用户每次手动登录.
例如，我们要检查更新 退出应用程序时
在任何操作系统上都是错误的.据您所知，您的应用程序退出"的原因是因为操作系统正在关闭，然后您的更新过程中途会失败.通常，这不是一件好事.要么在启动时检查更新，要么完全异步地(例如，通过计划任务)检查更新，而永远不会退出.
一些评论表明，点击 后退按钮不会终止该应用程序 全部(请参阅上面我的问题的链接).
按下返回"按钮不会杀死应用程序".当用户按下返回"按钮时，它将完成屏幕上的活动.
它仅应在 用户想要终止它-从不 任何其他方式.如果你不会写 在Android中表现类似的应用程序， 那我认为不能使用Android 用于编写真实的应用程序=(
Web应用程序也不能.或 WebOS ，如果我正确理解了他们的模型(还没有机会玩一个模型) ).在所有这些情况下，用户都不会终止"任何东西-他们只是离开. iPhone有点不同，它目前仅允许一次运行一次(有一些例外情况)，因此离开的行为意味着该应用程序将立即终止.
有没有办法让我真正戒烟 该应用程序?
正如其他人告诉您的那样，用户(通过BACK)或您的代码(通过finish())可以关闭您当前正在运行的活动.用户通常不需要其他任何东西，对于编写正确的应用程序，只需要使用退出"选项即可使用Web应用程序.
根据定义，没有两个应用程序环境是相同的.这意味着您可以看到随着新环境的出现和其他环境被掩埋而造成的环境趋势.
例如，有越来越多的人试图消除文件"的概念.大多数Web应用程序都不强迫用户考虑文件. iPhone应用程序通常不会强迫用户考虑文件. Android应用程序通常不会强迫用户考虑文件.依此类推.
类似地，有越来越多的人试图消除终止"应用程序的概念.大多数Web应用程序并不强迫用户注销，而是在一段时间不活动之后隐式注销用户.与Android相同，在较小程度上与iPhone(可能还有WebOS)相同.
这需要更加强调应用程序设计，将重点放在业务目标上，而不是坚持与先前的应用程序环境绑定的实现模型.缺乏时间或意愿去做的开发人员会因新环境破坏了他们现有的思维模式而感到沮丧.这不是这两种环境的错，更不是因为山峰绕过而不是通过风暴而造成的.
例如，某些开发环境(例如 Hypercard 和Smalltalk)具有应用程序和开发内容工具在一种设置中混合在一起.除了应用程序的语言扩展(例如， VBA 中的 Excel ，在AutoCAD中使用Lisp ).因此，想出了心理模型的开发人员以为应用程序本身已存在开发工具，因此他们要么不得不更改其模型，要么将自己限制在能够满足其模型要求的环境中.
所以，当你写的时候:
除了其他杂乱的事情，我 发现，我认为发展 我们针对Android的应用不会 发生.
现在看来，这对您来说是最好的.同样，我建议您不要尝试将应用程序移植到Web上，因为您在Android应用程序中发现的一些相同问题也将在Web应用程序中发现(例如，没有终止").相反，或者相反，有一天，如果您将应用程序做移植到Web上，则可能会发现Web应用程序的流程可能更适合Android，因此您可以在那时重新访问Android端口./p>
Moving on in my attempt to learn Android, I just read the following:
Question: Does the user have a choice to kill the application unless we put a menu option in to kill it? If no such option exists, how does the user terminate the application?
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.
Hehe, for every step I take in the Android world I run into some sort of problem =(
Apparently, you cannot quit an application in Android (but the Android system can very well totally destroy your app whenever it feels like it). What's up with that? I am starting to think that it's impossible to write an app that functions as a "normal app" - that the user can quit the app when he/she decides to do so. That is not something that should be relied upon the OS to do.
The application I am trying to create is not an application for the Android Market. It is not an application for "wide use" by the general public, it is a business app that is going to be used in a very narrow business field.
I was actually really looking forward to developing for the Android platform, since it addresses a lot of issues that exist in Windows Mobile and .NET. However, the last week has been somewhat of a turnoff for me... I hope I don't have to abandon Android, but it doesn't look very good right now =(
Is there a way for me to really quit the application?
This will eventually get to your question, but I first want to address a number of issues you raise in your various comments to the various answers already given at the time of this writing. I have no intention of changing your mind -- rather, these are here for others who come to read this post in the future.
The point is that I cannot allow for Android to determine when my app is going to be terminated. that must be the choice of the user.
Millions of people are perfectly happy with the model where the environment closes up the application as needed. Those users simply don't think about "terminating" the Android app, any more than they think about "terminating" a Web page or "terminating" a thermostat.
iPhone users are much the same way, in that pressing the iPhone button does not necessarily "feel" like the app was terminated, since many iPhone apps pick up where the user left off, even if the app really was shut down (since iPhone only allows one third-party app at a time, at present).
As I said above, there is a lot of things going on in my app (data being PUSHed to the device, lists with tasks that always should be there, etc.).
I don't know what "lists with tasks that always should be there" means, but the "data being PUSHed to the device" is a pleasant fiction and should not be done by an activity in any case. Use a scheduled task (via AlarmManager) to update your data for maximum reliability.
Our users log in and can't be doing that every time they get a phone call and Android decides to kill the app.
There are many iPhone and Android applications that deal with this. Usually, it is because they hold onto logon credentials, rather than forcing users to log in every time manually.
For example, we want to check updates when exiting the application
That is a mistake on any operating system. For all you know, the reason your application is being "exited" is because the OS is shutting down, and then your update process will fail mid-stream. Generally, that's not a good thing. Either check updates on start or check updates totally asynchronously (e.g., via a scheduled task), never on exit.
Some comments suggest that hitting the back button does not kill the app at all (see link in my question above).
Pressing the BACK button does not "kill the app". It finishes the activity that was on-screen when the user pressed the BACK button.
It should only terminate when the users wants to terminate it - never ever any other way. If you can't write apps that behave like that in Android, then I think that Android can't be used for writing real apps =(
Then neither can Web applications. Or WebOS, if I understand their model correctly (haven't had a chance to play with one yet). In all of those, users don't "terminate" anything -- they just leave. iPhone is a bit different, in that it only presently allows one thing to run at a time (with a few exceptions), and so the act of leaving implies a fairly immediate termination of the app.
Is there a way for me to really quit the application?
As everybody else told you, users (via BACK) or your code (via finish()) can close up your currently-running activity. Users generally don't need anything else, for properly-written applications, any more than they need a "quit" option for using Web applications.
No two application environments are the same, by definition. This means that you can see trends in environments as new ones arise and others get buried.
For example, there is a growing movement to try to eliminate the notion of the "file". Most Web applications don't force users to think of files. iPhone apps typically don't force users to think of files. Android apps generally don't force users to think of files. And so on.
Similarly, there is a growing movement to try to eliminate the notion of "terminating" an app. Most Web applications don't force the user to log out, but rather implicitly log the user out after a period of inactivity. Same thing with Android, and to a lesser extent, iPhone (and possibly WebOS).
This requires more emphasis on application design, focusing on business goals and not sticking with an implementation model tied to a previous application environment. Developers who lack the time or inclination to do this will get frustrated with newer environments that break their existing mental model. This is not the fault of either environment, any more than it is the fault of a mountain for storms flowing around it rather than through it.
For example, some development environments, like Hypercard and Smalltalk, had the application and the development tools co-mingled in one setup. This concept did not catch on much, outside of language extensions to apps (e.g., VBA in Excel, Lisp in AutoCAD). Developers who came up with mental models that presumed the existence of development tools in the app itself, therefore, either had to change their model or limit themselves to environments where their model would hold true.
So, when you write:
Along with other messy things I discovered, I think that developing our app for Android is not going to happen.
That would appear to be for the best, for you, for right now. Similarly, I would counsel you against attempting to port your application to the Web, since some of the same problems you have reported with Android you will find in Web applications as well (e.g., no "termination"). Or, conversely, someday if you do port your app to the Web, you may find that the Web application's flow may be a better match for Android, and you can revisit an Android port at that time.
这篇关于退出应用程序会感到皱眉吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
