Why your Android app doesn't need an exit button
blog.radioactiveyak.com
blog.radioactiveyak.com
http://developer.android.com/guide/practices/ui_guidelines/i...
... but it is certainly true that there is no review or enforcement mechanism in place to help developers conform to these guidelines.
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.)
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.
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).
In the Pandora system, we have PND files, which solve this problem pretty well. Perhaps Google can consider something similar:
Having a standardized Back button allows me to reflexively hit a button with the expectation of returning to the previous screen without needing to pay attention to what application I'm using or where the UI designer decided to place the button onscreen.
Having a standardized Menu button allows developers to place options or advanced workflow mechanics in an easily-discoverable location without needing to dedicate screen space to more buttons. This means more of the gorgeous touchscreen can be devoted to content I care about, and not the buttons that every application should have in the first place.
The iPhone's approach of putting these buttons on the screen has the major advantage that they are only visible when they actually have a purpose. Usually, the buttons are also labelled more specifically than simply "back" or "menu." For example, if you're looking at your folders in the Mail app, the back-equivalent button is labeled with "Accounts," indicating that hitting it will take you back to the accounts list. Also, the lack of a "menu" button discourages developers from just shoving everything into a menu. The result is that more common operations end up directly accessible (and immediately visible), while less common operations (if any) are usually tucked under a menu-equivalent "more" button.
The potential inconsistency in semantically-similar button placement between applications is mitigated through HIG enforcement. In practice, it's not an issue.
tl;dr: putting buttons on the screen instead of using physical buttons increases predictability.
* That said, I've gotten pretty good at predicting what back will do after several weeks of using my device (with the notable exception of GMail, which breaks back button behavior spectacularly). This was a huge pain point when I first got my device, though.
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.
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.
Android users that use task killers are like Windows users that disable their pagefiles.
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.
I understand people wanting to listen to Pandora in the background, I do not think there are that many people like that. I do not think they warrant this huge change.
I own a N1 and as for listening to music while I do something else I don't even think about it any more it just seems weird to not be able to do that.
As a device the N1 is very polished and for the most part the apps worth downloading are pretty smooth but every now and again I do have to resort to the task killer.
A good task killer is a must have for development or when testing beta apps.
On the iPhone, we already have notifications, so IM does not need to be running.
And you didn't address my point, I can understand you wanting and understanding it. The large numbers of people getting into smartphones DO NOT.
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.
Please go to the Market and check out how many people downloaded a task killer/manager.
Please explain to me why that is bad design?
This article is talking about apps that don't have a foreground service (and therefore no persistent notification).
"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.
In Android, application is not equal to process. Application may start in one process, the process may get killed when the application is backgrounded, and later the application continues in another process, where it is restored.
http://developer.android.com/guide/topics/fundamentals.html#...
The author is saying that most apps don't really need to keep doing things and using resources when not actively in use and visible(with GPS navigation and music players as two examples of apps that do); if an app doesn't need to keep using resources while not visible, it shouldn't need an explicit exit button because it should be releasing all of its resources when you leave the application with the back button.