I worked on an Android app for about 2 months together with some experienced Android developers. Most things, like displaying dialogs, storing things to the Db, etc. worked quite well and I really came to like intents. However, I completely agree with the authors criticism of the implementation of asynchronous calls. We implemented in app purchase functionality for our app and it was a huge pain. Google provides lots of documentation around this. However it's very convoluted and looking at their example IAP app makes you wonder if they had some contest going on to achieve the highest number Gang of 4 design patterns per lines of code. That massively distracted from what the example was supposed to teach you. We ended up spending around 2 weeks to get a solidly tested implementation of IAP working and get all edge cases covered. My main complaint about this is, that we weren't doing anything fancy and 99% of the code we had to write was not specific to our application. Something that just takes our vendor information and one callback for the success case and one for the error case would have totally done the job. I am sure there are hundreds of dev teams out there writing the exact same code as we did. Many of those probably are not testing their code or even just copying Google's example, without understanding what's going on. This is a huge waste of everyone's resources and will probably lead to many buggy apps. I understand that Google wants to allow for the flexibility to cover 99.9% of all use cases. However, they could still have offered a simple library method for the 99% case and have allowed the other 1% to write their own thing. Now everyone has to write their own solution. I hope someone will open source their IAP solution. If not, I actually might do it, since it's just crazy right now.