Slashdot Mirror
Android Application Development
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.
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.
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.
The one really big hurdle which Android faces and which WinMo and iPhone have worked around is the problem of a moving target. Since Android is a work in progress, with OEMs deciding which version to release, there is only a core set of functionality that could be expected to exist across all versions on all phones. Now, this core set of functionality may be very large and useful, but without a rigorous breakdown of the differences between devices it still feels like a crapshoot.
Attention to this "always in beta" aspect of developing on the Android platform would have been nice. Of course, Google just wants people developing apps and not worrying about how things may change. Unfortunately, this is a serious concern for developers of enterprise applications, and it may end up being Android's Achilles Tendon in the long run.
Android is not an open platform. It may be free(as in beer), but it is not fully free(as in freedom). Anyone ever tried starting up their G1 phone while out of network coverage after a hard reset. OUCH.
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).
When one develops for a mobile platform, is there a basic screen size/resolution/ratio (HD 16:9-4:3) you shoot for? I mean what are the specs? Is there a recommendation? I always wondered if this would be an obstacle with Android and the multiple devices.
Let's face it, most of us are scoffers. But moments before zero hour, it does not pay to take chances.
Just a reminder: Google and Android are not affiliated in any way any longer except that Google is a member of the Open Handset Alliance (OHA).
Google bought Android the company, developed Android the OS, then spun it off under control of the OHA, in which they are one participating member.
When a phone company develops hardware using Android, the operating system is open source/freely available. They can customize it. But if they want to bundle applications on it, say Google Maps, they have to license those apps from Google. Android is not Google, Google is not Android.
For what it's worth, I run a G1 with Cyanogen's latest mod. I have no Google apps that I care about anymore.
For someone scrutinizing repetitious repetition, this review certainly repeats many points repeatedly.
The OS is open source, some of the Apps are not. It's no different than some developing a closed source app for Linux and expecting to be paid for it, which is perfectly in line with every open source licensing system in the world.
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.
Better yet, bash factually.
In the interest of full disclosure, per my sig, I'm involved in the Android development community.
The Busy Coder's Guide to Android Development
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
What? Last week's situation was caused by someone distributing proprietary software that did not have permission. Google could not have stopped Cyanogen had the mod not included Google's proprietary software. Google deserves no ire for their actions, and Cyanogen's response was 100% class. Android is coming of age quickly.
-- $G
So what you are saying is that it is okay to advertise something that is partially Open Source as completely open source. It doesn't matter what part was balked at. The fact of the matter is that the way that the system is advertised, it is completely open source. If you put proprietary pieces into place, it is no longer open source by definition, because not all of the code is open for alteration and that part of code is not redistributable. Therefore, Android is just like everyone else's OS, except instead of putting in an SDK and spending money on figuring out ways to keep part of the system closed while opening other parts, you leave the code open for the same things that you would normally make an SDK for and lock down the parts you don't want touched. That's not open source. That is a very efficient and cost effective way to avoid making SDKs. More power to Google for taking this route...but it is NOT open source. Give me a phone where every part of the code is open for alteration and I will see an Open Source phone. Otherwise, Android is JUST like every other system. BTW, with all of the talk of customization, Windows Mobile is almost as customizable after developers get done with it? The iPhone can be jailbroken and heavily customized. While neither of these companies outright ALLOW this, DevTeam and others have been doing it since the cell phone became popular. Basically, without the "Open Source" moniker and a different (not necessarily better) UI, there is no difference between Android and anything else. Therefore, it becomes much more grave of a situation when one of the only selling points for your product is only partially true when no indication had been given as such before. This is called "false advertising." True "open source," such as OpenOffice and Firefox or the huge majority of Linux distros, use ONLY open source software. Everything is code-downloadable, not just the OS or parts of the OS. In addition, with the way that the Google tools interact with the OS, how can you say that it is not in the OS for these parts? You can remove it, and some of the vaunted integration goes away. Splitting hairs is always a way to win an argument, but not one to improve upon products.
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.
I wrote parts of this stuff
If you advertise that your system is open source, you should be advising that the system contains closed source software or remove said software. You should not advertise as COMPLETELY open source. It isn't. While you are right, at the same time, if you remove the closed source apps, the OS and phone is almost useless, and doesn't operate anywhere near advertised. This makes major portions of the operation of the phone as closed source. It's legal, just immoral. If Google was really committed to open source, Android would include a barebones email system, maps, etc, and leave the option for closed source downloads through their app store. The shocking part about that whole business for many non-IT professionals was not the fact that Google was heavy-handed, but that not all of the system was open source. Also, remember when Android didn't have a store? That means, although the system was "open source," there was no other programs for some items (MAPS, etc) other than Google's proprietary "stuff," which isn't open source.
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
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.
You shouldn't be an unmitigated idiot and asshole, but you are.
Sometimes shit happens.
Once you've built your app, how do you market it on the Google app store? Do you need a license or registration to upload it? How do you upload it? Does it have to be signed or otherwise processed after it's an executing binary? How do you get paid? How do you include a GPL or other license, and the source code if required/desired?
Those details of "development" are going to be the greatest incentive, or inhibitor, to developers. Especially like me.
--
make install -not war
I have to hand it to Google for trying to break the proprietary locked cell phone one trick pony problem, but so far everything I have seen indicates that we just have another locked up OS. This is free software for the handset makers, not the end user.
What we want and need is a fully Linux, no bs platform, no hidden anything. So far, the nokia n900 looks like it will do that. Especially with the announcement of the qt libraries will be in the next versions of maemo.
I am sick of being treated like a criminal for jail-breaking / accessing my own hardware and software that I payed lots of money to own and use as I see fit. F*** Google and all their handset Android makers. I am voting with my dollars and my companies dollars, and going with a full linux distro I can customize as needed for my business.
Now I just hope Nokia does not get stupid and drop the ball. They seem to have a tendency to loose their momentum.
Living in Chile
I always think it is appropriate to have a section on getting things setup. If you are going to write a book about development for a platform you better be ready to be thorough. If you start assuming things then your book will suck, and believe me I have had to go through a lot that have. The only exception I would make is if you have something like "advanced" in the title or something. I have been programming for over 20 years, and anytime I have to setup anything that isn't integrated I need some help to get things to see each other. Android is no different. Because of its open source nature and its ability to run on as many platforms as possible can present a slight challenge to get things working. You can't always rely on some quick tutorials since they often leave out the meat. I had to deal with some that would show you how to do something, but completely left out the part about adding anything to the manifest. It still beats iPhone development whereby XCode would eat perfectly good signature files. I have to admit I am a little biased on iPhone since I can't stand Objective-C and would rather on that platform go back to straight assembly. In closing it is always better for me and others to skip over something rather than having to find that material later on the author assumed we knew.
I have been working on a windows mobile app in my spare time for the last year or so in C# and it has been a serious pain. I have really enjoyed all of what the Android API has to offer. I found it ridiculous that I had to implement my own view stack in windows mobile or see all of my views as separate windows on the device, Android handles this very well on its own.
This super-guide will put you straight on the Android-track.
http://www.futuredesktop.org/developing_android_apps_on_ubuntu.html
Use Ubuntu 9.04. The latest Eclipse IDE does not run well on the Ubuntu 9.10 (Karmic) development version. Let's hope it will when Karmic is ready.
Kindly
Moma from Grønland/Oslo
See
http://www.futuredesktop.org/developing_android_apps_on_ubuntu.html
You cuss me out after calling me an unmitigated idiot. Classy. Intelligent. Definitely not idiotic at all.
You're right. Sometimes ish does in fact happen. For mentioning this ish, you decide to personally attack me. You don't make any argument about the point and in fact conceded the validity of my statement by saying "Sometimes shit happens."
Stay classy, Dog-Cow.
Since I disagree with your viewpoint and you have no counter-argument, you sir or ma'am have shown yourself to be the close-minded, unmitigated idiot in this discussion. I cannot comment on your personality as I have never met you, as you have made the assumption about mine with the comment of "asshole."
If you have an issue, please, by all means, refute with facts and an argument so that these cogent points can be reviewed. Otherwise, I guess the rest of the crowd on this site sees fit to hound and pursue anyone that disagrees with an opinion if you have no cogent response and insult people personally. Next you will probably call me a "fag" because I use words and grammar that are alien to you by the looks of your response.
The fact remains that if there is a system that you advertise as fully open source, then all programs included should also be open source, especially when there is no possibility of changing the included programming to something different.