An Android Developer's Top Gripes (plusses and minuses) | Hacker News Reader

An Android Developer's Top Gripes (plusses and minuses)

developer.com

42 pointswglb15 comments

"I'm looking forward to an Android-powered toaster oven any day now."

I assume that he's joking, but at CES (Consumer Electronics Show) this weekend, a company called "Touch Revolution" had a microwave with a touchscreen running Android. They also had Android on a Washer/Dryer and on a printer. Thankfully, though, I did not see an actual toaster running Android.

NetBSD already did toasters: http://www.embeddedarm.com/software/arm-netbsd-toaster.php

"4. Applications Never, Ever Quit" -- That's really not the case. If you press the "Home" button the app will receive the onPause() event, but if you press the "Back" button the app will quit after an onDestroy() event.

After you press the 'Back' try holding the 'Home' button down for a second. You should still see the application in the list that comes up. Further, after you receive 'onDestroy()' your activity isn't actually unloaded. It just 'could' be unloaded at some point in the future. Good developers will null all their pointers so the GC can clean up....and we're all good developers right?

If you hold the home button and see a list of apps -- that's the history. Not related to currently running apps.

Furthermore, have a look at the Activity lifecycle: http://developer.android.com/guide/topics/fundamentals.html#... If your app receives the onDestroy() event, there is no way it will ever recover to a running state.

In my experience, getting an onDestroy() call doesn't mean your process is about to be terminated/unloaded (this may be different in newer versions?)

Unless the app uses the back button for something, right?

Hey HN, (author of that article here) was wondering if you guys had any general feedback. I'm an evolving tech writer and I'm always looking for pointers.

#3 sounds more like complete sarcasm, and just didn't seem to fit with the rest of the article in tone or meaning.

Regarding #8, have you explored the way that "Alternate Resources" [1] allows you to better handle fragmentation issues? I've found it at least to be useful enough to provide a few alternate layouts based on screen orientation, but it would be nice to get further feedback from fulltime Android developers about it. Things like how useful it is in the real world with real, fragmented devire types seems hard to come by...

[1] http://developer.android.com/guide/topics/resources/resource...

Thanks for the feedback. #3 was meant to be a more than a little sarcastic, but I guess it didn't mesh well with some of the others.

There are really two types of fragmentation. The first is UI screen size, which isn't too hard to work with. The second, and uglier, is code fragmentation. This is where a piece of code might work totally differently on two separate platforms. Right now Android has a lot of the former, but it's looking like there's a lot of the latter to come.

How could code run differently on one Android 1.6 device from another?

While Android might be internally consistant, the hardware drivers that support it isn't. Everywhere your software interacts with the hardware is suspect for fragmentation. Google will have compliance testing to force OEM's into correctly supporting the Android runtime. However, their only leverage is the inclusion or not of their Google Apps and the "Made with Google" logo for the back of the device.

The handset makers (mostly HTC) have taken to shipping the same kind of "value add" UI changes that they did with Windows Mobile.

What's most unfortunate is that it's not even bullshit -- they are actually adding real value! HTC's on-screen keyboard is better, and they add in some of the multitouch events that Google foolishly left out.

Regarding point #2... the author is criticizing a platform which promotes breaking your application into easily-reusable pieces that communicate with well-defined semantics? What?

Comment on the page: Most of your complaints can be summed up as, "I don't like developers having a choice," "I don't like consumers having a choice," and "I don't like not being given a choice."

Seems about right

Reply on news.ycombinator.com