

Why your Android app doesn't need an exit button - whalesalad
http://blog.radioactiveyak.com/2010/05/when-to-include-exit-button-in-android.html

======
benofsky
As an owner of a Nexus One, I have to say this is one of the downfalls of
Android. The lack of an equivalent "Human Interface Guidelines" that there is
for iPhone _and_ shockingly, the app approval process leads to a very
inconsistent experience (due to ambiguous cases like this) between different
applications; resulting in a poorer user-experience.

~~~
barrkel
I'm less concerned by the UI. I think the market will gradually sort out; and
I don't really mind that my file manager has a distinct look to my twitter
feed, etc.

I am more bothered by the chaos on the SD card, and the apparently complete
lack of guidance from Google on standard locations. It's just a mess of root
directory folders of arbitrary names. You hope that your selected media
directory names won't conflict with something that an app may choose in the
future. (I personally use _music, _video etc. both to avoid conflict and to
come up top in most alphabetical listings.)

~~~
blasdel
The SD card in Android is a gibbering nightmare in far more ways than that.

For starters, that it's necessary at all! The first devices all had only 256mb
of flash, but then the OS got bigger than that (can't upgrade older devices
cleanly!), so they just doubled that to 512mb instead of doing anything
sensible. Is there a _single_ "Google Experience" Android device with more
built-in Flash than that?

What's worse is that they use it sparingly themselves but essentially force
everyone else to -- Apps don't fit in the onboard flash, you can't even run
Apps from the SD card, so everyone has to hack together their own asset
system. Now the SD card isn't removable without breaking your running apps!

It's a heap of ill-considered shit. Nobody would even propose these idiocies
at Apple, much less get them past their manager. Even Windows Mobile wasn't
this bad, but mostly just because they didn't try to do very much. The Android
team thinks they're clever -- but when the WM diaspora (<http://www.xda-
developers.com/>) are the community that fixes up your shit, you're clearly
not.

~~~
torpor
Blame Microsoft. If FAT weren't such a trojan horse, the SD-card could be used
a lot more effectively, but since FAT is a minefield, the SD card can't be
used as a reliable and permanent component in the OS base system ..

~~~
blasdel
FAT may be an incredibly shitty lowest common denominator, but that's
completely irrelevant here. The SD card can't be used reliably because
upstream never provided a common API for all apps to interface with it. They
didn't even have the courtesy to encourage apps to use their bundle
identifiers to segregate their shit!

They really shouldn't be exposing a shared RW traditional filesystem to apps
at all, no matter where it's located. Unfortunately that's the only API they
exposed!

They really should be forcing manufacturers to ship with at least 8gb of flash
to get the "Google Experience", but instead even their Nexus One ships with as
little storage as possible to save a couple dollars!

My whole point is that the SD card SHOULD NOT be used as a permanent component
in the OS base system at all. It should be _removable storage_ , but the way
apps are forced to use it makes it anything but!

The whole thing is completely incompetent. It would have been hard/impossible
for them to implement removable storage to Apple's standards of usability, but
they could have at least done better than WinMo! Really they should have just
shipped the original devices with a healthy amount of flash and no SD card
slot at all, and added removable storage support in a later iteration (which
is exactly what Apple did).

~~~
torpor
>My whole point is that the SD card SHOULD NOT be used as a permanent
component in the OS base system at all. It should be removable storage, but
the way apps are forced to use it makes it anything but!

In the Pandora system, we have PND files, which solve this problem pretty
well. Perhaps Google can consider something similar:

<http://pandorawiki.org/Libpnd_hub>

------
minouye
From my perspective, I like having an exit button, particular for services
that do some sort of push notifications (e.g. if I'm using Google Talk or
Skype, I want to ensure I don't continue to receive messages on my phone after
I exit). Pandora is also another example of an app that needs to have an exit
button (or 'quit' in their case).

Back and Exit are completely different in my mind. If I hit Back and the app
is still running or I continue to get notifications, then that's potentially
expected behavior from the app. If I "Exit" out of an app, then I know that if
I continue to get notifications, that's on the developer.

~~~
zzzmarcus
I agree. Another case is audio players. I have a couple that try to play
audiobooks (come on Audible...) and they usually put a play/pause notification
or toggle in the status bar. There's no way to get rid of it when I'm not
actually using the audiobook player apart from force-killing the app. The
notification doesn't hurt anything, but my OCD side says it shouldn't be there
if I'm not using it.

~~~
technomancy
That doesn't mean it needs an exit button; it just needs to quit putting a
notification up when it's not playing.

------
Sidnicious
I think that the vast majority of applications can be designed without exit
buttons.

Safari on the iPhone is a great example (I'm using iPhone applications because
I'm more familiar with their behavior). Safari always keeps track of its state
on disk. When it's closed, if pages are open it pauses some tasks (e.g.
JavaScript timers) but keeps running unless it gets a low memory warning. If
no pages are open, it exits completely. The user doesn't think about closing
Safari, he thinks about closing web pages.

Mail on the iPhone stays running if the user has set it to check mail in the
background.

The same principles can be applied to applications on any mobile OS. Pandora
should stay open if music is playing. A Twitter client should stay open if the
user has set it to check for Tweets in the background. An IRC client should
stay open if there are active connections.

~~~
JoeAltmaier
But now Android thinks it "knows" when it can kill your task - even if you
intended it to continue in the background. This is a perfect illustration of
why its a bad idea to take "exit" away from the app and put it in the OS.

------
dustingetz
interestingly, the comments on advanced task killer (android auto-kill app)
show that most users have no idea how android apps work--they are autokilling
many apps that autoserialized state to disk and don't consume a single
resource until reopened. or, maybe it's me who misunderstands.

~~~
sachinag
This may be the way it's supposed to work, but at least on my Devour, it
doesn't "feel" that way. The only way to make the device responsive - and to
stop apps from hanging - is to use ATK on a regular basis, multiple times a
day. I don't mind it - but it's just what I have to do.

~~~
moultano
I suspect placebo effect.

~~~
pbz
No placebo effect; on my N1, in sometimes gets to the point where opening
application, scrolling, and so on, lag significantly. Even apps that are part
of the OS slow down. After a task kill everything comes back to life and stays
that way for quite a while. The before and after speed difference is very
noticeable.

~~~
jrockway
Well, yeah. Android moves things out of memory when there is memory pressure.
You have to wait while this happens, and most currently-existing Android
devices are _massively_ underpowered. When you use a task killer, you are
spending the time when you press the "kill" button, instead of at some other
random time.

Android users that use task killers are like Windows users that disable their
pagefiles.

~~~
pbz
Bottom line is that it works. The theory behind how it should work may be nice
and dandy, but the reality is that it doesn't work as advertised. Whether it's
because I haven't waited enough (why would I need to wait in the first place?)
or whatever other reason, the unit slows down over time quite a bit and
killing processes brings it back to life.

The fact that current devices are underpowered has nothing to do with the
issue. N1 works just fine after a reboot but slowly degrades in performance.
If it was "massively underpowered" if would not have worked properly in the
first place.

I also don't understand why there is no easy way to disable some applications
from auto-starting. For example I've never used the MP3 Store application, but
it always starts up. There are a number of similar apps that do this and to my
knowledge there's no way to prevent this from happening.

~~~
jrockway
The N1 is not one of the underpowered phones; the Dream and Magic are. The
fact that you need to kill "processes" (which is not what the task killer
does, btw) means that there is a bug in some app you use regularly; narrow it
down and fix it, and your phone will be fine.

------
orblivion
Fine, don't have an exit button, but make sure I can stop whatever you're
doing. Chat doesn't have an "exit" but it has a "sign out", which is close
enough. If you don't have that for _everything_ you have going on in your app,
it needs an exit button.

------
jessriedel
> Users: Consider this. If an app needs an exit button because the back button
> doesn't properly manage resource use, what do you think the chances are that
> this exit button will be implemented properly?

Um, I don't think we can solve the problem of users desiring an unambiguous
"exit" button by telling them on developer's blog that this is a bad desire.
Might as well tell my mom she doesn't need really need a "save" button when
she's writing long emails online because they are auto-saved. It's not going
to work because (understandably) she finds the "save" button very reassuring
since she really doesn't know how computer work.

------
tszming
>> Why your Android app doesn't need an exit button

Please go to the Market and check out how many people downloaded a task
killer/manager.

------
portman
The built-in navigation app has an exit button. It will continue speaking
directions even when it's running in the background, unless you explicitly
exit.

Please explain to me why that is bad design?

~~~
sagarm
It's not. When the navigation app is navigating, it has a persistent
notification (representing the foreground service). "Exit navigation" exits
the foreground service and removes the persistent notification.

This article is talking about apps that don't have a foreground service (and
therefore no persistent notification).

------
JoeAltmaier
Its a noble goal - but Windows Mobile failed to make this work and I think
Android will too. Applications claim resources. You need to be able to kill
apps to free resources - think open file or locked database.

~~~
gvb
Here is another viewpoint of how applications run and (don't) exit:
[http://android-
developers.blogspot.com/2010/04/multitasking-...](http://android-
developers.blogspot.com/2010/04/multitasking-android-way.html)

"Once Android determines that it needs to remove a process, it does this
brutally, simply force-killing it. The kernel can then immediately reclaim all
resources needed by the process, without relying on that application being
well written and responsive to a polite request to exit. Allowing the kernel
to immediately reclaim application resources makes it a lot easier to avoid
serious out of memory situations.

"If a user later returns to an application that's been killed, Android needs a
way to re-launch it in the same state as it was last seen, to preserve the
"all applications are running all of the time" experience. This is done by
keeping track of the parts of the application the user is aware of (the
Activities), and re-starting them with information about the last state they
were seen in. This last state is generated each time the user leaves that part
of the application, not when it is killed, so that the kernel can later freely
kill it without depending on the application to respond correctly at that
point."

It sounds like Android has addressed the locked resource issue. I'm not
familiar with WinMo, but I suspect it tries to be cooperative and
uncooperative (ornery or crashed) processes will cause the reclamation to
fail.

~~~
JoeAltmaier
Cool - they addresses it. But how does Android know when one app needs to be
killed? Does any attempt to open an in-use resource kill the owning task?

