Community Created "Work in Progress" Books; Tread Carefully
In the last day or two lots of people have helped circulate a link to an O’Reilly effort to create a cookbook of community supplied Android examples, which is a noble effort, but there is a big drawback; and that’s the potential quality of the information.
Any healthy community tends to be pyramid shaped when it comes to knowledge and experience. At the bottom are the people who are starting out and have little knowledge or experience of the subject matter, and at the top are the people who’ve been involved in the area for a (relatively) long time and have studied it in depth. In the Android world you’ve got the people just picking up Android at the bottom, and the Google development team at the top, and there are far less people in the Google team than there are new arrivals.
This means that if you open something up to the entire community your chances of getting a lesser experienced person posting something are greater than those of getting someone further up the pyramid to post (purely because there are far more of them). This may be slightly mitigated by many newcomers being less willing to offer up a solution, but if you add in incentives (such as getting your name in print in a book), you’re increasing the chances of lesser experienced members of the community making submissions because those higher up the pyramid usually already have a fairly high profile (and tend to get paid to work on the subject matter) so working for nothing just to have their name in a book as one contributor amongst many has far less appeal.
There will, of course, be some good contributions, but it does mean that there will also be a fair number of comments and examples which have been created by people who may not have a full grasp of what’s being discussed.
When you also consider that those further down the pyramid will, most likely, have less money to spend on training materials for the subject in question, you can start to see why a free, openly available, community written book can lead to the propagation of some poorly thought out ideas.
If you wondering what happens for non-community written books; Most publishers send the books out to technical reviewers before distribution. I’ve been a technical reviewer for a few books from a few publishers and the process seems to work well, but I’ve also been asked to be a technical reviewer for some books on subjects which I have very little experience of, so it’s far from perfect, but if you buy a book on a subject from a major publisher you can be pretty sure that it’s been reviewed by a few people in the upper part of the community pyramid.
I’ve already commented on the O’Reilly site about issues I have with one example in the O’Reilly cookbook which shows an example of catching checked exceptions, wrapping them in a RuntimeException and then throwing the RuntimeException, and in the process loses the ability for any method which uses the example method to quickly tell the difference between when a file doesn’t exist and when there are problems reading the file, which is far from ideal.
The article also implies that the Core Java API and the Android OS libraries have got things wrong by using checked exceptions. Sun, the creators of Java, made a very clear statement about unchecked exceptions, and it’s definately not what the cookbook article advocates.
So if you want to read & contribute to the community book you can find it at http://androidcookbook.oreilly.com/ , but please make sure you understand the reasoning behind the articles and don’t just accept everything you read in it as being as reliable as a Google web page or a published book from a major publisher.
[For those who are wondering; Checked exceptions force developers to acknowledge they have considered what to do for a specific type of error in the same way the Javas' use of strongly typed variables forces developers to consider the implications of using one type of variable where another type should be used. Wrapping checked exceptions in unchecked ones can allow recoverable problems to be treated as unrecoverable ones because the developer didn’t consider the error case]
