继续学习Android,我读了以下内容:
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.
呵呵,我在Android世界里每走一步都会遇到一些问题=(
显然,你不能在Android中退出应用程序(但Android系统可以随时完全销毁你的应用程序)。这是怎么回事?我开始认为这是不可能写一个应用程序的功能作为“正常的应用程序”-用户可以退出应用程序时,他/她决定这么做。这不应该依靠操作系统来完成。
我正在尝试创建的应用程序不是Android市场的应用程序。它不是一个被大众“广泛使用”的应用程序,它是一个将在非常狭窄的商业领域使用的商业应用程序。
我其实很期待为Android平台开发,因为它解决了Windows Mobile和。net中存在的许多问题。然而,上周对我来说有点令人失望……我希望我不必放弃Android,但它现在看起来不太好=(
有办法让我真的退出应用程序吗?
Android应用程序的生命周期是为手机用户设计的,而不是电脑用户。
应用程序生命周期是将Linux服务器转变为消费者设备所需的极其简单的范例。
Android是基于Linux的Java,一个真正的跨平台服务器操作系统。这就是为什么它传播得这么快。应用程序生命周期封装了操作系统的底层现实。
对于手机用户来说,应用只是安装或不安装。没有奔跑或退出的概念。事实上,应用程序进程应该一直运行到操作系统释放它们以获取所拥有的资源为止。
因为这是Stack Overflow,任何阅读这篇文章的人都是计算机用户,必须关闭他们90%的知识来理解移动应用程序的生命周期。
不要把您的应用程序看作一个整体应用程序。它是一组UI屏幕,用户可以通过Android服务与你的“应用程序”和“功能”进行交互。
不知道你的神秘应用程序“做什么”并不重要。让我们假设它通过隧道进入某个超级安全的企业内部网,执行一些监控或交互,并保持登录状态,直到用户“退出应用程序”。因为您的IT部门命令它,所以用户必须非常清楚他们何时进入或退出内部网。因此你认为用户“退出”很重要。
这很简单。创建一个服务,在通知栏中放置一个持续通知,说“我在内部网中,或者我正在运行”。让该服务执行应用程序所需的所有功能。拥有绑定到该服务的活动,以允许用户访问与“应用程序”交互所需的UI部分。并有一个Android菜单->退出(或登出,或其他)按钮,告诉服务退出,然后关闭活动本身。
This is, for all intents and purposes exactly what you say you want. Done the Android way. Look at Google Talk or Google Maps Navigation for examples of this "exit" is possible mentality. The only difference is that pressing back button out of your activity might leave your UNIX process lying in wait just in case the user wants to revive your application. This is really no different than a modern operating system that caches recently accessed files in memory. After you quit your windows program, most likely resources that it needed are still in memory, waiting to be replaced by other resources as they are loaded now that they are no longer needed. Android is the same thing.
我真不明白你有什么问题。
这是一个有这么多专家参与的有趣而有见地的讨论。我觉得这篇文章应该从Android开发的主要网站中循环回来,因为它确实围绕着Android操作系统的核心设计之一。
我还想在这里发表我的意见。
到目前为止,我对Android处理生命周期事件的方式印象深刻,它将类似web的体验概念引入原生应用。
话虽如此,我仍然认为应该有一个退出按钮。为什么?... 不是为了我,不是为了泰德,也不是为了在座的任何一位技术大师,而是为了满足终端用户的需求。
虽然我不是Windows的忠实粉丝,但很久以前他们引入了一个大多数终端用户都习惯的概念(X按钮)……“我想在‘我’想要的时候停止运行一个小部件”。
这并不意味着有人(操作系统、开发人员?)会根据自己的判断来处理……它仅仅意味着“我习惯的红色X按钮在哪里”。我的行为应该类似于“按下按钮结束通话”,“按下按钮关闭设备”,等等……这是一种感知。它本身带来了一种满足感,我的行动确实达到了目的。
尽管开发人员可以使用这里给出的建议来欺骗这种行为,但仍然存在这样的看法,即应用程序应该完全停止运行(现在),由最终用户要求的独立、可信和中立的来源(OS)。
当我在Android上构思一个应用程序时,我是这样看的:
您正在使用您的应用程序
电话响了
你接电话
在通话结束时,您将回到应用程序所在的位置
要做到这一点,你只需要手机的后退键或Home键(短按或长按)和通知栏。
当我退出我的应用程序时,我只使用后退按钮,直到我退出它或Home按钮。
我认为这就是大多数应用的构思。但如果我需要某种会话或连接,我会用登录/注销按钮和通知(标题栏或其他任何东西)向用户明确表示。这是一种与纯“退出”样式应用程序相当不同的样式。
在pc上,你有一个多gui桌面,在Android上,你显然有多个任务,但你一次只显示一个应用程序(这里我不考虑小部件^^)。在手机上,任何时候,你都可能收到比你正在做的事情更重要的通知。
因此,应用程序的整个概念依赖于不同的东西,即“进入应用程序-工作-退出应用程序”。
我花了更长的时间来阅读这个问答,而不是真正实现一个半正确的Android应用程序生命周期。
这是一个GPS应用程序,轮询积分,并每隔几秒钟通过线程将当前位置发送到web服务…在Ted的情况下,这可能是每5分钟轮询一次更新,然后onStop可以简单地启动Ted所关心的更新活动,如果发现了一个(异步Ted,不要像Windows程序员那样编码,否则您的程序将像Windows程序一样运行……呃,这也没那么难)。
我在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à, an application that doesn't consume CPU when it's in the background, yet is instantly ready to reopen because it is in RAM (although not holding RAM as is the Android lifecycle) ... an app is always ready, it's a phone, guys/gals. If an app was to use up all the RAM and couldn't be shut down by the OS then the thing might stop ringing =P That's why the OS needs to be able to close your app when it's in the background (if your application isn't a resource hog it won't be closed BTW), so let's just write better applications.