Droid Doesn’t: It’s Not Ready For Prime Time | Hacker News Reader

Droid Doesn’t: It’s Not Ready For Prime Time

alsop-louie.com

18 pointsWump34 comments

I've used my droid for a month, and most of the time it has been flawless. It doesn't have the dialing issue my blackberry tour had. I have only had to force quit a couple of times, and usually when I was exiting the app anyways. My only complaint is the keyboard and sometimes the phone comes out of sleep (setting a lock pattern prevents this) and dials people that I didn't want them to. Other than that, the phone has been great. Fast as I would expect, and plenty of apps to keep me busy.

The "force quit" thing is real? How do you "force quit" on a Droid phone? Does it lock the whole phone up, or just a single app?

(I've never had my iPhone reach a state where I couldn't make or answer a call immediately, but I might just be lucky).

Basically the phone detects that the app is locked up, and brings up a dialog asking you if you want to Force quit or Wait. If you force quit, it kills it (probably something along the lines of kill -9)

I wonder why this is even necessary - I understand on the iPhone this is an immediate kill -9, no user intervention required. This seems like the correct way to do this - to expect your average phone user to operate this like a PC power user is absurd. "Force quit" should not be in the vernacular for operating a phone.

I can think of some sort of hypothetical scenario:

I'm using my Android phone loaded with some sector-specific application that's, let's say, not written so well. Occasionally, when I go scan something at the factory with it, it takes a while to process because there's more data than the author thought there would be (or something like that), and the application hangs for a few seconds before returning an answer that I need to do my job.

I'm just playing devil's advocate though, I have no idea how common that sort of thing is or if it should be the default behavior. Just that in an open environment, there might be some less than stellar applications that the user should be able to control, rather than the phone.

Devs don't work in a vacuum even though some think they do. If the app was released through the normal app store it probably wouldn't see the light of day in that state. The reviewers would reject it until they fixed it. If they are distributing through enterprise than they would be hauled in to the office to fix it.

No application should be so busy that is consuming all the resources.

> If they are distributing through enterprise than they would be hauled in to the office to fix it.

Because big companies never, ever get by on annoying, but functional software?

The iPhone doesn't have to deal with this because it doesn't support multitaskeng, hence an app becoming "unresponsive" isn't such a problem. To be honest, I would be rather angry if the OS shut down my browser process just because some image-heavy website slowed it down for a few seconds.

One of the reasons I like Android is that I got more control over stuff and I know I'm not alone. Some people don't like the Apple "we know what's right for you" mentality. My point is, people are different, there's no "average phone user". This is not a question of technical skill as there's really nothing technical in "wait" and "force quit". Some people like to be in charge, some people don't, personally I do.

actually, the iPhone OS does support multitasking, and it's used quite heavily. you can start a call, then the phone app continues to run in the background while you start something else. the iPod app runs in the background playing music while you're running other apps. and so on.

even if iPhone didn't allow multiple apps to run at once, it would still have to deal with crashes. it handles them by unceremoniously quitting the dead app and sending you back to the home screen.

claiming that an average user should be able to know what to do with a dialog box that gives the options 'wait' or 'force quit' ... man, that sort of thinking by competitors is exactly why apple keeps winning all the time, isn't it.

If an app crashes on Android, of course there are no questions asked. We're talking about unresponsive apps, not crashes. And as far as I know, the iPhone only allows "system" apps to be background apps. You can't listen to Spotify while browsing.

About the other issue: I think Apple "keeps winning all the time" because of the combination of the consistent experience they deliver bundled with a competitive line of auxiliary services (such as iTunes or the App Store) and very strong branding. There's nothing wrong with that, but I don't think that artificially limiting the choices available to the user is a huge contributing factor.

Actually, iPhone will kill -9 unresponsive apps also. Try writing an app that sticks itself into a tight loop, then start giving the phone inputs (home button, touches, etc)... the OS will soon realize your app is out to lunch and kill it.

This is the correct way to do it.

I'm sorry, but every time I have checked out a G Phone or the Droid and tried to scroll through their menus, I am both thoroughly disappointed at how jerky it is and a bit shocked that for some reason, no other company has been able to pull off the smooth touch screen scrolling like the iPhone has. It gets me every time and is a big reason why I wouldn't purchase a Droid, as pathetic as that reason may be.

why "no other company has been able to"

I gonna take a wild guess that it's because Apple folks don't want to hear Steve Jobs say those magic words.

Huh? Companies other than Apple haven't been able to make scrolling work nicely because Apple folks don't want to hear Steve Jobs say, er, whatever magic words you have in mind?

What am I missing here?

[EDITED ~1m after posting to add: Perhaps what you mean is that the reason why Apple has been able to do it is that everyone there is scared of having Jobs tell them their user interface isn't good enough. But the previous poster's question wasn't "how come Apple were able to do this astonishingly difficult thing?" but "how come other companies haven't bothered to do this apparently easy thing that would make the user experience so much better?". Jobs's perfectionism can hardly explain that.]

I think these kinds of harsh reviews are where a video would really come in handy.

Mostly because it seems like it's almost too horrible to believe. Also (though fanboys will never truly accept the problems) it's just too easy for them to respond with 'you're doing it wrong!'

This account does speak to some specific points, but I'd be nice to see some clear examples that all can see and discuss, instead of just describing general experiences. Shouldn't be too hard to collect, either, if the phone is consistently this bad.

Maybe the guy has a defective phone. It doesn't seem that his experiences line up with anyone else's. My 'underpowered' 192MB HTC Magic certainly doesn't have these problems. Seems strange of him to assume that this is the experience that many others are raving about.

yeah, it seems like he is out of the norm. I've played with a couple different droids and loved it. still plan on getting one.

If the article's author's Droid behaves in the ways he says it does, it is clearly defective. I have never, not once, had to "force quit" any built-in application. The contact list works flawlessly. When I click an application icon, it starts every time. As a phone, the thing is rock solid.

The only applications that I have had to "force quit" have been a couple buggy apps from the market, which I subsequently uninstalled. Yes, buggy software is allowed into the market. That's fine by me; sometimes a buggy beta app is better than no app at all.

And about the shutter button: why would I want it to launch the camera app? On my standalone digital camera I sure don't expect the shutter button to turn it on...

Just to add my own data point: I've had the Droid for about a month, and I've never had to force quit the phone, maps, or browser (which I consider the three most important apps). The scrolling on the menus and desktop sometimes feels laggy, but is usually good. The camera button either doesn't work, or I don't know what it's supposed to do (I just use the button on the touch screen). Besides that, I haven't had any problems. I love the keyboard, and I've never dropped a call or accidentally dialed a number in my pocket.

I don't buy the implication that voice has to be glitch-free. First, many people who buy smartphones are light voice users, and use the web most of the time. Second, many cell phone users have imperfect voice calling anyways, due to coverage issues or network glitches. Finally, if a product really shines in some important areas, there will always be people who are willing to put up with poor performance in other areas.

This was the same excuse people used for Windows Mobile. Because of it it became a niche player and not taken serious. Blackberry gets it, Apple gets it, Microsoft didn't get it until too late.

Seriously, how we use phones hasn't change much in a hundred years. The damn thing should be bulletproof at this point. In a smartphone the dialer should be absolutely simple and absolutely work 100%. And the markets don't think like you or I do. They'll put up with something for so long, but if your competitor gets it and you don't you become branded as a failure. It's very hard to recover from that. Ask GM.

Everything is a feature. So, the iPhone can always make or receive a call. And what does Droid have to make up for that? More pixels? A keyboard that many people find inferior to the software one? A replaceable battery that no one will ever replace? Most people would take the bug-free OS.

Is everyone forgetting how many people are complaining about iPhone dropped calls? Might be AT&T or something else, I'm not seeing as many complaints with their other phones.

I have an HTC magic, never had issues with the dialer. Rogers in canada is pretty good, no dropped calls after 4 months of use. Only app that seems to hang my phone is twidgit. Great app, horrible performance.

AT&T isn't an iPhone. I have an iPhone on SFR and it works fine. If the network is built properly than any phone should be able to use it just fine.

I certainly hope Apple disconnects themself from that deathstar and chain called AT&T. Because everywhere else (except maybe the UK where O2 had the exclusive) the iPhone works just fine.

I'm in Oregon and ATT works great here. The big problem with ATT's network is that it sucks in the two places anyone writes anything about wireless networks: San Francisco and New York.

--Second, many cell phone users have imperfect voice calling anyways, due to coverage issues or network glitches.

I do not remember ever having a network issue when using a phone. However I do not use a phone in the US. I own a smartphone and primarily use it for its multimedia abilities and not the web.Most of the times I would use the web is to play a song/clip from youtube. Maybe my usage patterns explain why I am a Nokia fanboy.

I still maintain that Java is not a good choice for a mobile OS. Dalvik might be the best Java VM ever in the history of personal computing, but it's still just a VM. It cannot beat native code, especially on a mobile device like the Droid. I think GCC is smart enough at producing fast, tight machine code. And then there's LLVM. Why choose Java?

I'm sick of people going on about how programmer productivity is more important than performance. I seriously don't give a fuck about programmer productivity. I only care about the end product. You have a 600MHz processor with about 128megs of RAM on your mobile device, and you still can't make it perform well? There was a time when desktop computers were slower than that, and programmers optimized the hell out of their software to make it perform acceptably on the limited hardware. I can't believe that a company like Google can't make Android perform at least acceptably, if not blazing, fast.

I consider performance a feature. If it's not fast, I'm not using it. This is how I choose my desktop software, and this is how I choose my mobile devices. Currently, I'm looking at some Symbian devices. Symbian might not be the best mobile OS, but it's extremely responsive even on my mum's ancient Nokia 6600.

EDIT: removed offending "bring on the downvotes" comment.

I'm upvoting, but go take a deep breath. The world will not turn on you just because you like your software to be fast.

Sorry, went a bit overboard there :)

Performance is something I feel strongly about. At this point, people who know me are sick of my rants on how product X is too slow.

The problem is idiots, managed idiots.

C devs read way, way, way too much into performance issues with managed environments. I'm currently running a large system on an embedded device using a managed environment and its FINE. However we have been careful about our implementation.

The problem is when less "able" teams are able to use managed code to create software on an embedded device. They can be utterly careless with the resources on the device as they are commonly used to playing with desktop where you can get away with a lot. They then create something that doesn't work very well and the C hackers point and laugh and state that managed software and embedded devices is a no-no.

If anything managed teams just need to appreciate the limitations of the device and be more careful when assessing what toys to use. Do that and the managed world is full of win.

Update: "Idiot" is probably a bit harsh. "Naive" is probably a more apt description.

I largely agree with that, but downvoted you on principle because I always do that to people who play the "oooo, I'm going to get downvoted, see what a nonconformist I am" card. (Which I think lowers the signal-to-noise ratio both of HN's content and, since unfortunately it sometimes works and garners lots of upvotes, of the rating system.)

Point noted. I've edited that part out now.

I regret that the HN software doesn't allow me to un-downvote you.

On Android one can switch to C++/NDK for real performance-sensitive components. Other than that most Java use is either in tracking data structures, performing simple operations on them, or else in managing/responding to systems services and events (drawing UIs, responsing to keypresses, reading/writing datastores, etc). In all the latter cases there are so many layers to what happens between initiation and final result that the userland Java code represents a small portion of the total processing time. There would be NO advantage in using C there.

I can buy that game programming will push the limits because many games handle large userland models and need to display much onscreen, but for MOST APPS the biggest problems that lead to perceived sluggishness don't come from using Java but instead from lazy programming where devs assume optimal response to indeterminate-time actions and don't get the optimal case ... e.g., freezing a UI while calling a web service w/ a 30-second timeout.

Reply on news.ycombinator.com