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.
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.)
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.
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 ..
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).
>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:
That's interesting.. because while I agree, I rarely look inside of my SD card. I've rooted too, so use it frequently for that purpose (flashing a rom). I agree more with the previous commenter though, because while Android does have their own UI guidelines, no one seems to follow them. There are a ton of really ugly and poorly designed (not just in a pixel sense, but workflow sense) Android apps out there =(
I'd go one step further and say that some of this is even a design flaw in the platform. Depending on developers to check a system setting to see if they should make updates is absolutely backwards. The OS should provide an API that allows an app to request an update, but is denied if the user's settings don't allow it.
It's also just that Android is an immature platform. Apple has no way of enforcing its UX guildelines on OS X apps, but yet most applications are at least pretty close. (well, mostly)
I think that is a fair reason for the current state of Mac applications, as theirs is a cultured built over many years between a relatively small number of people. But the iPhone has brought a hoard of developers who are new to the platform, so I find it hard to believe that a real, distinct culture has formed yet when compared to Android developers.
They need to start moving away from using the Menu button. It's silly to have this big touchscreen that requires physical button presses so often. Tap, Menu, Tap, Menu, Tap. It's just not a smooth experience.
I disagree completely; it's silly to have a big touchscreen that's filled with buttons to do things that aren't part of the normal application workflow.
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.
Having a standardized back button means that when I hit "back," I have* a hard time predicting what it's going to do. Same for "menu." Sometimes "back" goes back in history (e.g., browser), sometimes it goes back to the last activity (if I got here via a notification). Menu doesn't always work, and I have to tap it to see if what I want to do is in the list of options.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This is why I think Apple adding multi-tasking to OS 4.0 is a mistake. Nobody really missed it, and now a lot of people are going to have to concern themselves with understanding what is going on, when they do not want to. Or, they are going to wonder why their new device is so slow, and the battery does not last as long.
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 can't disagree more. Multi-tasking is inevitable it just so happens that this is one place where Android devices beat the iPhone to the punch. In time both platforms will mature and the task switching will get smoother.
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.
to follow up for future readers, i have an HTC incredible, played with a task killer, and didnt see a difference. and, the shortened app startup time from unhibernating an app is pretty awesome.
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.
> 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.
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.
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).
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.
"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.
The article seems to be arguing that applications shouldn't keep resources or keep running when not visible without making it clear to the user and providing a convenient way to make the app release its resources and completely stop running.
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.
