Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Android Books Google Book Reviews News

Android Application Development 74

stoolpigeon writes "Google's mobile OS Android has received plenty of press. As with a lot of Google products, there was much anticipation before any devices were even available. Now a number of phones are available, with many more coming out world-wide in the near future. Part of the lure of Android is the openness of the platform and the freely available tools for development. The SDK and accompanying Eclipse plug-in give the would be creator of the next great Android application everything they need to make their idea reality. The bar to entry in the official Google Android Marketplace is very low and it doesn't seem to be much of a stretch to predict that the number of developers working on Android is only going to grow. As with any hot technology the number of books will grow as well and O'Reilly's Android Application Development has jumped into the fray, promising to help budding Android developers what they need to get started." Read on for the rest of JR's review.
Android Application Development: Programming with the Google SDK
author Rick Rogers, John Lombardo, Zigurd Mednieks, Blake Meike
pages 332
publisher O'Reilly Media Inc.
rating 7/10
reviewer JR Peck
ISBN 978-0-596-52147-9
summary Programming with the Google SDK.
The book begins with a brief introduction to Android followed by detailed instructions on procuring and installing the Android SDK. Space is given to Windows, Linux and Mac. The install is relatively simple on all three platforms, extra information is provided for Ubuntu users but no others distributions. Extra care is taken to help Windows users with items they may not use regularly, such as environmental variables. This is all pretty basic and gives the book very much of a 'for beginners' feel. Before I had the book I had already installed the SDK and Eclipse plug-in on Windows, Ubuntu and Fedora without any issues beyond getting a current version of Eclipse for the Ubuntu machine. The version I already had from the Ubuntu repositories was not able to run the plug-in. It's a short chapter and if someone really struggles with it, they probably should shift their focus from learning to code to learning how to use their platform of choice. This does set the tone though, that this is a book for those who are very new to development.

Chapter two steps the reader through the ever present "Hello World" and gives an overview of the structure of Android applications. Chapter three introduces the example application that will be used for the rest of the book. There is a lot of repetition here on just what directories and files make up the guts of an Android program. I was quickly worried ( the first four chapters are only fifty-six pages in ) that maybe four authors had been too many. The repetition made it feel as if separate work had been combined without enough editing to remove what was redundant. Fortunately this got better, though there was still a strange proclivity to list files while referring to earlier chapters that explained their purpose. This would be helpful to anyone jumping right into the middle of the book, but the index also serves the same purpose and saves space for more valuable content, as opposed to explaining the purpose of AndroidManifest.xml repeatedly.

Once I moved into the fifth chapter, Debugging Android Applications and the following chapters, things got better. The pace picked up and the repetition dropped off for the most part. The book did not become incredibly difficult, trying to be everything to everyone, but did maintain an introductory style. At the same time the example application makes use of many Android features that are likely to be used by developers. How to set up and use tools was covered step by step. This is very nice but did cause some issues for the authors due to the rapid pace of development on Android. A visit to the book's errata page will show that many readers struggled with changes to the SDK tool set that came out very shortly after the book. The authors say that future editions will fix these issues, but this creates a dilemma for that reader needing introductory level materials. They are more dependent upon the book than a more advanced user and so these issues can be very trying. Based on the responses to the errata posts it became trying for the authors as well. This isn't a knock on the book itself but rather a limitation of the delivery method.

Once the reader is digging down into the example application the team approach to writing the book does become an asset. The authors bring a number of skills to the table that closely resemble the players that would be necessary to a team developing a real-world application. The reader is now being pulled into an example that benefits from the knowledge of each and does a good job of exploring the range of options an Android developer has available. This includes core functionality, UI options and how to best take advantage of the platform while at the same time taking performance and user expectations into account. I felt like I was getting something beyond the excellent documentation provided by Google. This is where I felt the book stood strongest.

Working with a single, large example application was a move that probably helped move things along on writing the book and I think it's an interesting approach. The problem is of course, that means that this example must be right. Right for the task and technically correct. Small issues in the code are inevitable but now their impact is book wide. The changes to the platform just made it just that much more difficult to sort out. On the whole I still found this to be a better approach primarily due to the fact that it gives the features highlighted a better sense of context. Stand-alone examples are often good at highlighting technical features but completely ignore the issues necessary to using the feature in a larger piece of code.

I'm a fan of O'Reilly books. Interestingly enough this doesn't mean that I'll gloss over issues with what they produce. The result is actually the inverse, in that I go into all their titles with a high level of expectation with regards to quality on every level. This may mean that though I strive to be neutral when I look at a book, I'm probably a little tougher on O'Reilly titles. This made my rough start with Android Application Development a bit jarring. The repetition and what felt like sloppy editing are not what I expect. I was quickly given a sense that this book may have been rushed to publication a little sooner than it should have been. As I moved deeper into the book, things improved and while I think there were still editorial issues, things did seem to smooth out to some degree.

There is an interesting tension that exists purely do to the nature of print books. I don't like to bring up print versus electronic in reviews as I don't think it is on topic, but here it is unavoidable. The book is aimed at people that need a little more hand holding and help getting going. It does a good job of providing step by step instructions, the problem is that some of those steps have changed. I don't think anything in the code itself needs to be different, but the tools have changed enough that getting the code to run in a development environment against the new SDK is different. That means that portion of the book is no longer of as much value without going to other sources to find the new steps.

That said, warts and all I found this to be a helpful way to get my feet wet with Android. I really look forward to future versions as I think just a little more time and work will move this from my 'good' list to my 'great' list. Making things a little tighter and cleaning up the few typos and errors would certainly make this an 8 instead of an 7, which is really substantial in my mind. I'm no super developer and I need stuff like this, that can take things a little more slowly and make it all clear. I think this guide is great for those of us in that category as long as the reader is o.k. with hopping to external sources for the information they'll need to get the newer tool set working.

You can purchase Android Application Development: Programming with the Google SDK from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Android Application Development

Comments Filter:
  • for android users: (Score:5, Informative)

    by poetmatt ( 793785 ) on Monday October 12, 2009 @02:21PM (#29721907) Journal

    cyanogenmod + enochx = much more visually appealing, many features added to your phone.

    Rooting is not as complicated as it used to be - meanwhile, there are lots of sites out there on programming an android phone with great info, even google's. [android.com]

  • by douglas.barton ( 1643183 ) on Monday October 12, 2009 @02:42PM (#29722235)
    An excerpt from Wikipedia:
    * The un-restrictive terms of Android's license have allowed corporations using Android to place restrictions on their own customers. As an example, tethering (PC or laptop internet connectivity via the cell phone) is forbidden by T-Mobile USA, and the Android Market has de-listed such applications for T-Mobile customers.[109] This also means that the apps can be carrier-specific as chosen by Google.[110]. (As a note, users can still download any application that is hosted on the internet whether or not it is in the market).
    * Android uses Linux as its kernel,[111] but according to Google, it is not a conventional Linux distribution. It does not have a native X Window System, nor does it support the full set of standard GNU libraries like its system libraries (GNU C Library). This specific modification makes it difficult to reuse existing Linux applications or libraries on Android.[112]
    * Android does not use established Java standards, i.e. Java SE and ME. This prevents compatibility among Java applications written for those platforms and those for the Android platform. Android only reuses the Java language syntax, but does not provide the full-class libraries and APIs bundled with Java SE or ME.[113]
    * Because of potential security issues[114] Android does not officially allow apps to be installed on, nor run from, an SD card. Current Android products such as the HTC Dream and Magic have limited onboard memory and many users feel restricted by this lack of functionality.[115] Several unsupported modifications exist, however, to give the user this capability.[116]
    * Android is criticized for its multitasking abilities and the lack of a significant driver base. For these reasons ARM and Real have expressed doubt that it will gain a major market share as a netbook OS.[117]
    * Responsiveness can be poor due to the limitations of Dalvik's automatic memory management.[118]
    * Developers report that it's difficult to maintain applications working on different versions of Android, because of various compatibility issues between versions 1.5 and 1.6[119].


    /end excerpt


    Support a true honest open platform, support angstrom: http://www.angstrom-distribution.org/ [angstrom-d...bution.org]
  • O'reilly books (Score:4, Informative)

    by dslbrian ( 318993 ) on Monday October 12, 2009 @02:47PM (#29722311)

    I'm a fan of O'Reilly books. Interestingly enough this doesn't mean that I'll gloss over issues with what they produce. The result is actually the inverse, in that I go into all their titles with a high level of expectation with regards to quality on every level. This may mean that though I strive to be neutral when I look at a book, I'm probably a little tougher on O'Reilly titles. This made my rough start with Android Application Development a bit jarring. The repetition and what felt like sloppy editing are not what I expect. I was quickly given a sense that this book may have been rushed to publication a little sooner than it should have been.

    IMO, O'Reilly's once stellar reputation has gone downhill since the days when they only had a handfull of titles. I think these days in the rush to churn out a Learning/Mastering/Pocket Reference/Nutshell book for every language and variant thereof their editors miss quite a bit. Now you have to scrutinize their books just as much as the other publishers (although they haven't quite hit the abomination level that the Whatever-Language "Bible" books are that Wiley publishes).

  • by mmurphy000 ( 556983 ) on Monday October 12, 2009 @03:43PM (#29723103)

    It's only open source until Google decides that they don't want someone else using the "Open Source" code and files a court injunction as was done last week.

    And your proof of this claim is...what, exactly?

    Perhaps you are referring to an incident from about 2-3 weeks ago, when a ROM modder was sent a cease-and-desist letter by Google for including closed-source applications in his Android ROMs. The consensus opinion is that Google was legally right but clumsy in how they handled this incident. However, misrepresenting what happened helps nobody.

    If you are going to bash, bash evenly.

    Better yet, bash factually.

    In the interest of full disclosure, per my sig, I'm involved in the Android development community.

  • I am a co-author... (Score:4, Informative)

    by Zigurd ( 3528 ) on Monday October 12, 2009 @05:16PM (#29724473) Homepage

    I am a co-author of this book. Feel free to ask me about it. If I can't answer, I'll make sure your questions get to the other co-authors and/or our editor.

  • by Zigurd ( 3528 ) on Monday October 12, 2009 @06:23PM (#29725345) Homepage

    That's not really a subject of the book. And I don't have any access to Google's decision-making on that, but one of my co-authors and I created a system that, like Android, used Java on handsets, so we explored this issue in some depth:

    1. Making a good JIT is very difficult. Open source JITs, at the time we were putting a Java on ARM-based systems, provided very little performance improvement over an interpreter.

    2. Other system components, like the graphics stack and garbage collector have very large impacts on performance, probably larger than the difference a JIT could make. Most interactive applications spend a lot of time drawing the screen, and a JIT won't speed that up.

    3. Even if you could magically get a JIT as good as Sun's that worked on ARM, it's an open question if you want to spend CPU cycles, and therefore battery power, JIT-compiling code on a handset. You may need to design a JIT specifically for battery powered devices.

    I would guess Google has the resources to explore all the alternatives: JIT, pre-compiled Java, JIT/cached, etc. and will at some point speed up Java execution. But, depending on what your app does, it might make less difference than speeding up graphics.

    Alternatively, if you have something that is very compute-intensive, you can put it in a native code library compiled from C or C++, and access the library using JNIs: http://developer.android.com/sdk/ndk/1.6_r1/index.html

  • by cnkurzke ( 920042 ) on Monday October 12, 2009 @06:30PM (#29725453)

    First off, let me admit that I have not yet read the Book reviewed here, but from reading the review, it sounds like it is targeted mainly to the "new to programming" crowd.

    I have started my Android Development career by reading Mark Murphy's "Busy Coder's" books, and gotten a lot of details out of his Tutorial book.
    http://commonsware.com/books.html [commonsware.com]

    I'm not affiliated with him, but I'd like to really recommend his books to any developer who has an existing background in either Java and wants to quickly get productive in Android Development.

    As an additional bonus, all of Mark's books are available electronically or as self-published printed paper back's.

    He himself is also a great guy and very active on the Google Android developer forums.

  • by mjwx ( 966435 ) on Monday October 12, 2009 @09:37PM (#29727327)
    Disclosure: Android owner in Australia.

    As a practical matter, agree 100%. Google allows the cell phone networks to place all their usual restrictions on android. This is the same problem we've had for as long as cell phones have existed. The networks take a decent phone with good features, disable 90% of the features and functionality, load it up with their logo on everything and their own crappy software, and sell what amounts to a shiny turd to the consumers.

    This is an issue with US telco's not with Android. If you're looking for someone to blame then blame the telco's. Here in Australia we dont have this issue, Vodafone and Optus have provided fairly stock rom's with little in the way of customisation. The only issue with Optus was that it took them until September to update to Android 1.5 but most HTC Dream owners had just installed a community ROM like Cyanogen by that point.

For God's sake, stop researching for a while and begin to think!

Working...