6 ms·

Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the

Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the platform is relatively new to me, and I didn't even know Java (although, to be fair, I knew C# fairly well a couple years ago, which is arguably the same thing plus type inference.) In a few days, with relatively few problems, I was able to build an app and I'll be releasing it in various markets soon (once I stop polishing and let it go, which is hard for me to do.) I found the experience to be straightforward and intuitive. I was able to find tutorials for any task I couldn't figure out myself and the API documentation is perfectly adequate. Working with images and settings files are two areas where I was very pleasantly surprised at just how easy it was. There were some minor frustrations. The Android emulator fought me a little so I started just debugging on my actual device. Debugging certain problems can be difficult, Eclipse can cause headaches and throw random nonexistent exceptions, etc. but overall I think you've vastly overstated the difficulty level of jumping into Android development. "The depth of knowledge of in design patterns required is so great..." It's really not. With almost no experience with Java or Android, I've put together a working app in a few days that, in my opinion at least, is pretty good, and that works on various mobile devices with different resolutions and capabilities. Some other things I'm happy with about the Android platform: the SDK is free, Android is open source, you're very unrestricted with regards to what your app can do, and Android Market developer accounts cost a one time fee of $25 instead of $100 a year.

dpcan 15y ago
Just a word of advice on Android, polish your app really well before launch. The Android Market comment system is relentless. If you don't have a smashingly nice app out of the gate, you'll probably get a couple 1-star "sucks"/"rubbish" reviews before you can finish your post-launch exhale.
- ZoFreX 15y ago
  This is interesting because I, having no knowledge of the Android market but a lot of knowledge of development in general, would give the exact opposite advice! In general I think it's agreed that the best thing to do is release, and then tweak. If the Android Market punishes people that do this then I think that's a very real problem with the market that will directly lead to poorer quality software.
  - kenjackson 15y ago
    The release and tweak model works well for web apps -- today. Because there is no real review model for web apps. Mobile apps are a lot more like movies. Opening weekend means a LOT. If you are weak out the gate, you'll have bad reviews. When you update, no one will care, because not many people will buy the updated app because of all the one-star reviews. The only time this doesn't apply is if you a huge built in userbase like Facebook, where even with bad reviews, people will still get the updated version of the app.
    - ZoFreX 15y ago
      What would you advise then for app developers - how easy is it to operate a closed beta on Android or iPhone, for example?
      - kenjackson 15y ago
        I don't know for iphone and Android, but Windows Phone just added private betas :-)
      - msbarnett 15y ago
        On iOS it is quite easy using the excellent TestFlight service: http://testflightapp.com/ http://testflightapp.com/
      - joelhaus 15y ago
        For Android, the market can be avoided by just offering the .apk file (e.g. you can self-host the .apk and only share the link with a select group, or if that's not secure enough, require a unique key to unlock the app once it's loaded). More here: http://www.google.com/search?q=android+sideload+apk http://www.google.com/search?q=android+sideload+apk P.S. Has anyone had success developing an Android app with Google's App Inventor tool (http://appinventor.googlelabs.com/about/index.html http://appinventor.googlelabs.com/about/index.html)?
  - SomeCallMeTim 15y ago
    It's very, very true that you need to be solid out of the gate on Android OR iPhone. Android's app rankings, in particular, seem to be tuned to give an advantage to new apps, so apps that get good ratings and a bunch of downloads out of the gate can potentially place. Once an app is a month or two old, even if it's well rated and doing decent, it can crash in the rankings and get buried under thousands of other apps, even if it has a lot of enthusiastic fans. And it seems like this happens simply if people don't download it ENOUGH -- if it loses momentum, you're toast.
- bignoggins 15y ago
  this is just as true on iOS. In mobile you can get away with releasing something that is unfinished, but you cannot get away with releasing something that is unpolished.
sjs 15y ago
I prefer using and making software for iOS over Android but I think you're right. Cocoa programming requires a lot of up front knowledge about their design patterns and tools. It's no small undertaking for someone to learn about KVO, delegate pattern (so simple but confuses people for some reason, I think it's the name), MVC, and then add actions and outlets, resizing masks, and all the other unique things to Xcode/IB that people have to learn. Once you know Cocoa and Xcode iOS development is faster and more fun than Android development but it's no small learning curve. It's worth it for the fast turnaround of using the simulator compared to Android where both the emulator and device are slow, you're looking at 5-10x as long to launch your app compared to the iOS simulator. Plus ObjC > Java if you ask me, but I'm a masochist who likes both C and dynamic languages. Individual statements are verbose in Cocoa but I'd have to look at how much boilerplate is caused by the Java straight jacket to speculate on which is ultimately more verbose. You also have to be willing to put with some crusty stuff. Nothing compared to OS X programming but it still feels old next to Java's APIs. Two good examples are string manipulation and interacting w/ the filesystem, so verbose on iOS but pretty good in Java.
- reidmain 15y ago
  I agree whole hardly. I was doing C# and WPF dev right out of Uni and really loved the total power that you were given to create cutting edge apps (I worked primarily with the Microsoft Surface). I don't really have anything bad to say about WPF but when I first got my hands on UIKit and Objective-C I fell in love. In WPF you can do anything and customize everything. UIKit is Apple's magical black box but it will get you like 80-90% of the way to your goal so you don't need to engineer everything like I did with WPF. Couple that with Foundation and their other great frameworks like CoreLocation and so much boilerplate code seems to be hidden behind Apple's walls. I'm also probably in the minority but I like the verboseness of Objective-C and the dynamic nature of it. Honestly it is a small thing but not having to put null pointer checks all over my code is the thing about the language I love the most.
- serge2k 15y ago
  Verbose is putting it mildly. Objective C isn't a bad language, but the syntax is just horrible IMO. So much extra typing to do something simple. That said, the app I'm writing at work does a lot of stuff with strings, which you did mention specifically as a problem. Properties also drive me crazy. just a ton of extra annoyance just to declare a variable. I also prefer eclipse to xcode, and visual studio to both. oh and good point about the simulator. The iOS simulators are MUCH better than the android simulator. So much faster.
SomeCallMeTim 15y ago
I'm a long-time game programmer, and not at all an Apple fan (somewhat the opposite, in fact). When I picked up Android I really, really wanted to like it. Every time I turned around, the Android platform surprised me. In a bad way. Full disclosure: I'm also not a Java fan, and think it was a completely brain-dead idea to make Java the first-class API. I'm certainly not a Microsoft fan, but even C#/Mono would have been better (not that I know any C#), if only so they wouldn't have had to waste time reimplementing the VM for licensing reasons. But it's not Java that I had a hard time with. I've developed games on 12 different hardware/software platforms. There are so many things missing and/or broken about the way Android does things that I feel embarrassed for Google. Some of those things have subsequently been fixed, but many haven't, and some have been ignored in the bug database for YEARS now. A LOT of those things wouldn't have been problems if they didn't have so many layers between the app and the hardware (Java being one of those layers, but not the only problem). As you say, it's really Not That Hard to just throw a simple app together that does what it needs to. Intents and Services are also ABSOLUTELY not the problem. The developer who wrote the original article didn't read enough of the docs or the right docs, or isn't as smart as he thinks he is -- the concept of Intents is not rocket science. The application lifecycle isn't even hard to understand -- it's laid out in the intro docs pretty clearly. If only Android actually DID what those docs said, things would be a lot easier for a game developer. In fact, an "app" can be stopped and then a new one started before the old one actually receives its shut-down message. In the same (Linux) process -- so any native code with static data is still sitting around. One of many annoying problems I ran into. I think the core mistake of almost every new platform is one of ego. "We'll design this NEW AND DIFFERENT platform in some revolutionary and awesome way, and make everyone rewrite their apps in this way feel is Better." When dealing with platforms, the one most important thing to do, in my opinion, is to HIDE the differences between one and another platform as much as possible. Android does this to some degree WITHIN the Android ecosystem, but we simply DON'T NEED multiple ecosystems. I submit it would be better for everyone if there were a single cross-platform engine that everyone used. Before I get dismissed as a kook, please think about OpenGL, and the fact that something as complex as a rendering subsystem IS in fact supported on all platforms, to everyone's benefit. What would have been better is a library that abstracts away the fact that Android is its own unique OS, period. When I write code, I don't want it to be Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux code. I want it to be, as much as possible, completely cross-platform. I want the platform to fade into the background. You could bootstrap this by creating all the UI and other OS code as a portable layer that can run on many different systems. But no new platform developer ever seems to get that, and so we end up with a new ecosystem for every new platform, and it's left to third parties to fill in the gap with cross-platform libraries. But it's not the developers -- or the users -- that big initiatives like Android get funded to satisfy. /rant
rudy750 15y ago
I keep hearing from iOS camp that NO ONE buys android apps. What are your experiences?
koko775 15y ago
You're high on the post-development rush. It's addicting. But it doesn't mean the platform will scale with you. I've done extensive iOS and Android development (more extensive on the Android side due to business necessity). Here's some gotchas that I've encountered, from memory, because these are only the recent ones (plus one or two memorable ones from way back). EDIT: Disclosure - I am one of the rare types who is actually a big fan of both Java and Objective-C's syntax, though I'm more partial to Scala's approach than Java's, overall. I view Objective-C, conceptually, as somewhat in between C and Python, with good parts from both (though of course ObjC is far older) Example #1: I made the mistake of using ArrayAdapters, and hand-writing my own wrappers around the android sqlite libraries to manage my app's data. What did it get me? Garbage collection cycles that crashed the app, among other things. Example #2: I am of the opinion that in order to build a stable, robust app, Content Providers, at the very least, are required (for many reasons, the primary one currently being the ability to use LoaderManagers and CursorLoaders). But where was the documentation that explained why this was so? The complete lack of a centralized, high-level overview of Android systems have lead me to several development dead-ends, resulting in rewrites. While I'm wiser for the effort, and have finally settled on a sane, reusable, fairly general pattern for data-driven Android apps, I used up some really valuable development time finding this out. And you know what? Looking at the codebase before my (just-deployed) rewrite, and looking at the Android codebase at the job I left before it, everyone is making these same mistakes, and not many are realizing it until later. Aside - Rant: BaseColumns (http://developer.android.com/reference/android/provider/BaseColumns.html http://developer.android.com/reference/android/provider/Base...) has no discernible use other than for a class to inherit some static variables. This is kind of ridiculous, as there's no requirement to use the column constants anyways, and they're static. I use enums instead, for each database table. Works much better. At my last job I even wrote an automatic SQL create statement generator for use in onUpgrade(). Oh, and if you want to use anything other than _id for the column name for your objects' unique IDs, you're not going to have an easy time with automatically binding your database objects to your UI. Example #3: Lots of stuff requires contexts. Against your common sense, you should try to avoid supplying the current activity as a context when you can use the application context instead. Why? Because if an Activity, which is a context, is retained as a member variable in something - perhaps a class that is, itself, a member variable of the aforementioned Activity, voila! You've got a circular reference and a potential memory leak! Where was this in the documentation? Nowhere. It was in a blog post that isn't exactly on most people's radar: http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html http://android-developers.blogspot.com/2009/01/avoiding-memo... Example #4: Changing orientation destroys and recreates an Activity. Did a AsyncTask run at an inconvenient time? Oops. Chances are you're going to crash if you needed to do anything special with your Activity's state. Example #5: Using Apache's HTTP client? Careful. Don't use RequestWrapper, because executing a POST request wrapped in one can cause it to drop headers from the request. Just use different methods for HttpGet and HttpPost, and add on (for example) authentication parameters, device model names, other info for metrics, etc. separately for each. Funny thing is, I had better luck duplicating code for GET/POST here than reusing it, which I found disgusting, because duplicating code is not a good solution to anything, but it just got the work done. Example #6: I've gotten unreasonable Cursor closings that weren't my fault because someone at Motorola thought they were being clever and closing Cursors in a finalize() method was somehow a good idea: http://stackoverflow.com/questions/6552405/android-compatibility-library-cursorloader-java-lang-illegalstateexception-cur/6683898#6683898 http://stackoverflow.com/questions/6552405/android-compatibi... TL;DR (my main argument): Android has many avoidable gotchas that require a solid programmer to identify and work around, but which aren't immediately fatal if ignored. Android provides a lot of infrastructure, and some of it is even good! Despite its mess of poorly-written, poorly-documented, or incorrect APIs, it manages to allow decent programmers to write pretty decent solutions and some pretty robust code. But it does a damn piss-poor job of documenting its wrongness when it rears its ugly head, and it fails to make clear that while there's freedom to do things many ways in Android, there are really only a few ways to do them well. Rant #2: All android devices seem to suffer from gross over-logging, some far more than others, like Motorola, or some newer HTC phones., which is a huge pain in the ass when I'm just concerned with my own error logs, and not spurious calls to the logger that the software author or device manufacturer forgot to or didn't care enough to elide. Rant #3 (emphatically): The worst and most fundamental flaw with it, though, IMO, is that the classes for the views and the serialization format representing them (the layout xml's) do not have anything even close to a 1:1 mapping. Serializing a class - it's not that hard. iOS does it by literally serializing the state of the view objects as configured in Interface Builder into what was once a binary file, but now is an XML file (nib, xib). Anything you can initialize or style or otherwise edit to affect the initial state of a view in interface builder or (were it reasonable) another method of directly editing the serialized representation you can also do in code. Not so in Android. Here's a link to a post of mine last month that addresses some more gripes with Android: http://news.ycombinator.com/item?id=2737284 http://news.ycombinator.com/item?id=2737284 P.S. I've talked to Bob Lee (of Square; former core library lead of Android) about this before. Even he agreed that Android's APIs were poorly thought-out and designed in places. That's pretty damning right there.

dpcan 15y ago

Just a word of advice on Android, polish your app really well before launch. The Android Market comment system is relentless. If you don't have a smashingly nice app out of the gate, you'll probably get a couple 1-star "sucks"/"rubbish" reviews before you can finish your post-launch exhale.

ZoFreX 15y ago
This is interesting because I, having no knowledge of the Android market but a lot of knowledge of development in general, would give the exact opposite advice! In general I think it's agreed that the best thing to do is release, and then tweak. If the Android Market punishes people that do this then I think that's a very real problem with the market that will directly lead to poorer quality software.
- kenjackson 15y ago
  The release and tweak model works well for web apps -- today. Because there is no real review model for web apps. Mobile apps are a lot more like movies. Opening weekend means a LOT. If you are weak out the gate, you'll have bad reviews. When you update, no one will care, because not many people will buy the updated app because of all the one-star reviews. The only time this doesn't apply is if you a huge built in userbase like Facebook, where even with bad reviews, people will still get the updated version of the app.
  - ZoFreX 15y ago
    What would you advise then for app developers - how easy is it to operate a closed beta on Android or iPhone, for example?
    - kenjackson 15y ago
      I don't know for iphone and Android, but Windows Phone just added private betas :-)
    - msbarnett 15y ago
      On iOS it is quite easy using the excellent TestFlight service: http://testflightapp.com/ http://testflightapp.com/
    - joelhaus 15y ago
      For Android, the market can be avoided by just offering the .apk file (e.g. you can self-host the .apk and only share the link with a select group, or if that's not secure enough, require a unique key to unlock the app once it's loaded). More here: http://www.google.com/search?q=android+sideload+apk http://www.google.com/search?q=android+sideload+apk P.S. Has anyone had success developing an Android app with Google's App Inventor tool (http://appinventor.googlelabs.com/about/index.html http://appinventor.googlelabs.com/about/index.html)?
- SomeCallMeTim 15y ago
  It's very, very true that you need to be solid out of the gate on Android OR iPhone. Android's app rankings, in particular, seem to be tuned to give an advantage to new apps, so apps that get good ratings and a bunch of downloads out of the gate can potentially place. Once an app is a month or two old, even if it's well rated and doing decent, it can crash in the rankings and get buried under thousands of other apps, even if it has a lot of enthusiastic fans. And it seems like this happens simply if people don't download it ENOUGH -- if it loses momentum, you're toast.
bignoggins 15y ago
this is just as true on iOS. In mobile you can get away with releasing something that is unfinished, but you cannot get away with releasing something that is unpolished.

sjs 15y ago

I prefer using and making software for iOS over Android but I think you're right. Cocoa programming requires a lot of up front knowledge about their design patterns and tools. It's no small undertaking for someone to learn about KVO, delegate pattern (so simple but confuses people for some reason, I think it's the name), MVC, and then add actions and outlets, resizing masks, and all the other unique things to Xcode/IB that people have to learn. Once you know Cocoa and Xcode iOS development is faster and more fun than Android development but it's no small learning curve. It's worth it for the fast turnaround of using the simulator compared to Android where both the emulator and device are slow, you're looking at 5-10x as long to launch your app compared to the iOS simulator. Plus ObjC > Java if you ask me, but I'm a masochist who likes both C and dynamic languages. Individual statements are verbose in Cocoa but I'd have to look at how much boilerplate is caused by the Java straight jacket to speculate on which is ultimately more verbose. You also have to be willing to put with some crusty stuff. Nothing compared to OS X programming but it still feels old next to Java's APIs. Two good examples are string manipulation and interacting w/ the filesystem, so verbose on iOS but pretty good in Java.

reidmain 15y ago
I agree whole hardly. I was doing C# and WPF dev right out of Uni and really loved the total power that you were given to create cutting edge apps (I worked primarily with the Microsoft Surface). I don't really have anything bad to say about WPF but when I first got my hands on UIKit and Objective-C I fell in love. In WPF you can do anything and customize everything. UIKit is Apple's magical black box but it will get you like 80-90% of the way to your goal so you don't need to engineer everything like I did with WPF. Couple that with Foundation and their other great frameworks like CoreLocation and so much boilerplate code seems to be hidden behind Apple's walls. I'm also probably in the minority but I like the verboseness of Objective-C and the dynamic nature of it. Honestly it is a small thing but not having to put null pointer checks all over my code is the thing about the language I love the most.
serge2k 15y ago
Verbose is putting it mildly. Objective C isn't a bad language, but the syntax is just horrible IMO. So much extra typing to do something simple. That said, the app I'm writing at work does a lot of stuff with strings, which you did mention specifically as a problem. Properties also drive me crazy. just a ton of extra annoyance just to declare a variable. I also prefer eclipse to xcode, and visual studio to both. oh and good point about the simulator. The iOS simulators are MUCH better than the android simulator. So much faster.

SomeCallMeTim 15y ago

I'm a long-time game programmer, and not at all an Apple fan (somewhat the opposite, in fact). When I picked up Android I really, really wanted to like it. Every time I turned around, the Android platform surprised me. In a bad way. Full disclosure: I'm also not a Java fan, and think it was a completely brain-dead idea to make Java the first-class API. I'm certainly not a Microsoft fan, but even C#/Mono would have been better (not that I know any C#), if only so they wouldn't have had to waste time reimplementing the VM for licensing reasons. But it's not Java that I had a hard time with. I've developed games on 12 different hardware/software platforms. There are so many things missing and/or broken about the way Android does things that I feel embarrassed for Google. Some of those things have subsequently been fixed, but many haven't, and some have been ignored in the bug database for YEARS now. A LOT of those things wouldn't have been problems if they didn't have so many layers between the app and the hardware (Java being one of those layers, but not the only problem). As you say, it's really Not That Hard to just throw a simple app together that does what it needs to. Intents and Services are also ABSOLUTELY not the problem. The developer who wrote the original article didn't read enough of the docs or the right docs, or isn't as smart as he thinks he is -- the concept of Intents is not rocket science. The application lifecycle isn't even hard to understand -- it's laid out in the intro docs pretty clearly. If only Android actually DID what those docs said, things would be a lot easier for a game developer. In fact, an "app" can be stopped and then a new one started before the old one actually receives its shut-down message. In the same (Linux) process -- so any native code with static data is still sitting around. One of many annoying problems I ran into. I think the core mistake of almost every new platform is one of ego. "We'll design this NEW AND DIFFERENT platform in some revolutionary and awesome way, and make everyone rewrite their apps in this way feel is Better." When dealing with platforms, the one most important thing to do, in my opinion, is to HIDE the differences between one and another platform as much as possible. Android does this to some degree WITHIN the Android ecosystem, but we simply DON'T NEED multiple ecosystems. I submit it would be better for everyone if there were a single cross-platform engine that everyone used. Before I get dismissed as a kook, please think about OpenGL, and the fact that something as complex as a rendering subsystem IS in fact supported on all platforms, to everyone's benefit. What would have been better is a library that abstracts away the fact that Android is its own unique OS, period. When I write code, I don't want it to be Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux code. I want it to be, as much as possible, completely cross-platform. I want the platform to fade into the background. You could bootstrap this by creating all the UI and other OS code as a portable layer that can run on many different systems. But no new platform developer ever seems to get that, and so we end up with a new ecosystem for every new platform, and it's left to third parties to fill in the gap with cross-platform libraries. But it's not the developers -- or the users -- that big initiatives like Android get funded to satisfy. /rant

rudy750 15y ago

I keep hearing from iOS camp that NO ONE buys android apps. What are your experiences?

koko775 15y ago

You're high on the post-development rush. It's addicting. But it doesn't mean the platform will scale with you. I've done extensive iOS and Android development (more extensive on the Android side due to business necessity). Here's some gotchas that I've encountered, from memory, because these are only the recent ones (plus one or two memorable ones from way back). EDIT: Disclosure - I am one of the rare types who is actually a big fan of both Java and Objective-C's syntax, though I'm more partial to Scala's approach than Java's, overall. I view Objective-C, conceptually, as somewhat in between C and Python, with good parts from both (though of course ObjC is far older) Example #1: I made the mistake of using ArrayAdapters, and hand-writing my own wrappers around the android sqlite libraries to manage my app's data. What did it get me? Garbage collection cycles that crashed the app, among other things. Example #2: I am of the opinion that in order to build a stable, robust app, Content Providers, at the very least, are required (for many reasons, the primary one currently being the ability to use LoaderManagers and CursorLoaders). But where was the documentation that explained why this was so? The complete lack of a centralized, high-level overview of Android systems have lead me to several development dead-ends, resulting in rewrites. While I'm wiser for the effort, and have finally settled on a sane, reusable, fairly general pattern for data-driven Android apps, I used up some really valuable development time finding this out. And you know what? Looking at the codebase before my (just-deployed) rewrite, and looking at the Android codebase at the job I left before it, everyone is making these same mistakes, and not many are realizing it until later. Aside - Rant: BaseColumns (http://developer.android.com/reference/android/provider/BaseColumns.html http://developer.android.com/reference/android/provider/Base...) has no discernible use other than for a class to inherit some static variables. This is kind of ridiculous, as there's no requirement to use the column constants anyways, and they're static. I use enums instead, for each database table. Works much better. At my last job I even wrote an automatic SQL create statement generator for use in onUpgrade(). Oh, and if you want to use anything other than _id for the column name for your objects' unique IDs, you're not going to have an easy time with automatically binding your database objects to your UI. Example #3: Lots of stuff requires contexts. Against your common sense, you should try to avoid supplying the current activity as a context when you can use the application context instead. Why? Because if an Activity, which is a context, is retained as a member variable in something - perhaps a class that is, itself, a member variable of the aforementioned Activity, voila! You've got a circular reference and a potential memory leak! Where was this in the documentation? Nowhere. It was in a blog post that isn't exactly on most people's radar: http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html http://android-developers.blogspot.com/2009/01/avoiding-memo... Example #4: Changing orientation destroys and recreates an Activity. Did a AsyncTask run at an inconvenient time? Oops. Chances are you're going to crash if you needed to do anything special with your Activity's state. Example #5: Using Apache's HTTP client? Careful. Don't use RequestWrapper, because executing a POST request wrapped in one can cause it to drop headers from the request. Just use different methods for HttpGet and HttpPost, and add on (for example) authentication parameters, device model names, other info for metrics, etc. separately for each. Funny thing is, I had better luck duplicating code for GET/POST here than reusing it, which I found disgusting, because duplicating code is not a good solution to anything, but it just got the work done. Example #6: I've gotten unreasonable Cursor closings that weren't my fault because someone at Motorola thought they were being clever and closing Cursors in a finalize() method was somehow a good idea: http://stackoverflow.com/questions/6552405/android-compatibility-library-cursorloader-java-lang-illegalstateexception-cur/6683898#6683898 http://stackoverflow.com/questions/6552405/android-compatibi... TL;DR (my main argument): Android has many avoidable gotchas that require a solid programmer to identify and work around, but which aren't immediately fatal if ignored. Android provides a lot of infrastructure, and some of it is even good! Despite its mess of poorly-written, poorly-documented, or incorrect APIs, it manages to allow decent programmers to write pretty decent solutions and some pretty robust code. But it does a damn piss-poor job of documenting its wrongness when it rears its ugly head, and it fails to make clear that while there's freedom to do things many ways in Android, there are really only a few ways to do them well. Rant #2: All android devices seem to suffer from gross over-logging, some far more than others, like Motorola, or some newer HTC phones., which is a huge pain in the ass when I'm just concerned with my own error logs, and not spurious calls to the logger that the software author or device manufacturer forgot to or didn't care enough to elide. Rant #3 (emphatically): The worst and most fundamental flaw with it, though, IMO, is that the classes for the views and the serialization format representing them (the layout xml's) do not have anything even close to a 1:1 mapping. Serializing a class - it's not that hard. iOS does it by literally serializing the state of the view objects as configured in Interface Builder into what was once a binary file, but now is an XML file (nib, xib). Anything you can initialize or style or otherwise edit to affect the initial state of a view in interface builder or (were it reasonable) another method of directly editing the serialized representation you can also do in code. Not so in Android. Here's a link to a post of mine last month that addresses some more gripes with Android: http://news.ycombinator.com/item?id=2737284 http://news.ycombinator.com/item?id=2737284 P.S. I've talked to Bob Lee (of Square; former core library lead of Android) about this before. Even he agreed that Android's APIs were poorly thought-out and designed in places. That's pretty damning right there.