I'm a fairly new user of Android and i'm annoyed by the fact that almost all apps lack a "close" button.
Is there any reason why developers don't make such an option?
|
|
The major mobile touch screen operating systems (iOS, Windows Phone 7, Android) don't trouble the user with "closing" applications in the way that desktop applications do. This simplifies the experience, making applications appear seamlessly built into the operating system. Typically, applications on these operating systems will "pause" when the user returns to another application or the home screen, using no CPU time but remaining "asleep" in memory. If the current application needs more memory, the operating system closes down the least used application, freeing up memory that can be used by the foreground application. The answer is: you simply don't need to close applications manually on modern mobile operating systems. |
|||||||||
|
|
At least with Facbok app there is no HOME button. The only way to get to HOME is go to main screen, open another app, double click the iPad home button, hold the icon until it wiggles, click the minus sign. Now when you open the Facebook app it puts you on your HOME page, and that is different than your wall. |
|||
|
|
|
It's because of the way Android is designed. The operating system manages the memory in a very different way to the way it's done on a desktop computer. The same goes for CPU. When you don't have an application on the screen (in the foreground) it no longer takes up any CPU. That is because unlike with desktop applications the OS knows that you can't be using it, so why bother keeping it running. At this point the memory it was using will still be allocated to it. However, if the operating system needs more memory for when you open a different application it will archive the memory that the older application used (not exactly, but you get the idea). This then frees up enough memory for other applications to run with no slow down. If you then relaunch the application which had its memory archived the OS the has the option to unarchive that memory and start the application exactly how the user left it. Again, this isn't 100% accurate but you get the idea. Essentially if you navigate away from an application it is no longer running. It doesn't use any CPU and the memory it uses will be aggressively cleared whenever the OS needs it. Therefore you will see extremely minimal battery life gain by closing an application. The exception to this is when applications make use of services. Services are separate from the bit of the application that you see (the UI). The application has the option to keep these running when the foreground application closes. They are designed to be short lived and shouldn't be open for long before they finish themselves. In the case of services it is possible to gain battery life by closing them, however only very badly designed applications should have services that run with no foreground application and drain the battery life. In this case the answer isn't a close button, it's to design the service better. |
|||
|
|
|
Honestly, I don't think the answer to this is UX related. It certainly can't be related to the size of the 'close' button being too small-- tablets are plenty big and don't have close buttons either. I think the answer is just system resources. Mobile devices are slow, and it's a lot easier to switch between apps if they stay open in memory. If you're a Mac user, you'll also be disappointed to know that the next Mac OS X (Lion) is reported to have this 'feature' as well-- the OS will determine when and which applications should be closed. On a personal level, I'm totally with you. Any power user needs to be able to close apps on demand. |
|||
|
|
|
Typically, unless the phone has multi-tasking, the app either closes or goes into a sleeping state when you hit the home key. WinPhone7 does this much to my annoyance. On a Nokia, if you hold down the home button it pops up a list of the open apps and you can then close the ones you don't want to keep open. On an iPhone (and presumably an iPod) if you double-click the home button it does the same thing. I haven't tried Android but I'd imagine they have something similar. |
|||
|
|
|
Personally, if I were to develop an Android app I wouldn't include a close button either. As others previously mentioned, it's too easy to accidentally hit the close button inadvertently. What I would do, is include a close/quit command as an option that comes up when the user hits the Menu button. It just feels like it should be a menu option instead of a UI element IMO anyhow. I think it's important to include a close/quit function in an app to try and save on battery life and increase available memory for other apps that the user is actually using. |
|||||||
|
|
With tiny little touchscreens and fingers typically bigger than the touch points and touch points normally too close together for said fingers, it would probably be far too easy to accidentally tap the close button when you intended to do something else. The only way that would work would be to have enough space around the close button where there isn't any other action that you would try to tap and accidentally hit close. And doing this (again, on small touchscreens) would waste way too much space in the application for a function that is handled natively by the device. This is similar to wasting space on a web application for a "Back" button only much worse because your available space is much smaller. |
|||
|
|
|
Closing iPhone applications from within the app itself goes against Apple guidelines, so most developers would not take this route for fear of the app being rejected from the App store. Quitting from within the app "looks like a crash to the user." (Apple's words, not mine). There's a question on StackOverflow about this issue. |
|||||||
|
|
You have turn off buttons for certain apps, especially the ones that should run in the background. The principle of hiding and not shutting down is borrowed from Mac OSX where it helps the loading time. Though the app is not using the processor while hidden, it starts instantly when you open it. I guess that for Android this also helps since the apps you use more often are running already. |
|||||
|