×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Unlocking Android

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Handhelds 117

Michael J. Ross writes "Of all the potential challengers to Apple's phenomenally popular iPhone, perhaps the one with the best prospects is Google's Android, which is not a mobile phone per se, but rather an open-source platform that the company encourages phone manufacturers to deploy in their own products. Similarly, Google encourages computer programmers to develop applications for the Android environment. But learning how to create such applications is daunting to the uninitiated, particularly for developers who have never before worked with the user interface controls, Web services, and other resources involved. A recently published book, Unlocking Android, is designed to help such developers." Read below for the rest of Michael's review.Unlocking Android was put out by Manning Publications on 28 May 2009, under the ISBN 978-1933988672. It was authored by W. Frank Ableson, Charlie Collins, and Robi Sen — all of whom have extensive experience in developing mobile software applications. The publisher's Web page makes available author biographies, descriptions of the book, all its ancillary parts (the foreword, preface, acknowledgments, table of contents, and index), a white paper on Android (oddly termed a "green paper"), and two sample chapters ("Targeting Android" and "Intents and services"). There is a link to download the source code from the Google Code site, organized by chapter. The Manning site also hosts a forum, where readers and the authors can discuss the book. As of this writing, there are 42 threads, comprising 120 messages. Lastly, the site has links to order both the print and electronic versions of the book. Note that purchasing the former automatically entitles one to a copy of the latter. Manning appears to be pioneering this approach to making e-books more readily available to customers, since every print copy now contains an insert with a list of codes that can be used to download a PDF copy of the book.

The book is ostensibly intended for Android beginners, even though it does contain enough detailed information to serve as a partial reference for more experienced developers. It is organized in a logical fashion, in three parts, starting with an overview of Android itself, both the technology and the organization behind it. Then the reader is introduced to the Android programming environment, along with its many components and capabilities. The book concludes with tutorial chapters that step the reader through creating a sample Android application and more. The material covers Android SDK 1.x. Since Android programs are written in Java, any reader fluent in that language will have a much easier time absorbing the ideas. However, the authors state that even non-Java programmers should be able to follow the examples, as long as they have knowledge of similar languages, such as C, C++, or C#. However, even a cursory glance at the code, by such a reader, would prove that Java knowledge is essential.

The first chapter — oddly named "Targeting Android" — introduces the platform, the organizations behind it, the mobile market as a whole, Android's features, how it differs from featured phones and smartphones, its open-source licenses, platform components, libraries, service managers, programming environment, and virtual terminal. Be warned that Figure 1.1 could be confusing to some readers, because it shows the layers of technology that compose the Android platform, but pictures them on the front of a mobile phone, showing a keypad, which makes the layers appear to be part of the actual user interface; the phone should be removed from the illustration, in a future edition. The chapter goes on to discuss booting and activating Android, as well as how to map applications to processes. Some readers anxious to get to the technical nitty-gritty, may become impatient when reading the first portion of this chapter, because it largely consists of introductory material. Yet this context can be helpful and interesting to people unfamiliar with the mobile phone market. (Articles and tutorials aimed at new mobile application developers, oftentimes assume that said developers are already extremely familiar with the rapidly changing mobile market.) In the later portion of the chapter, readers are shown a handful of code snippets, with some explanation as to what they are doing and how. In reading this material, the reader could be easily overwhelmed with all of the new terminology. One can only hope that the authors were not thinking that the typical reader would understand all of what is discussed, or be able to do anything with it. A canonical "Hello, world" program or something similar — with an explanation as to how to execute it — would have been a far more gentle introduction. By the way, the first few code snippets are poorly indented, and some of the method names are italicized, while others are not — with no mention as to what this might signify, either in the chapter or in the earlier "Code Conventions" section.

In Chapter 2, the reader is introduced to the key tools for basic Android development, including the SDK, Eclipse, and the Android Emulator. An example application — a tip calculator — is developed, step by step, to illustrate those tools. Clearly, this tutorial information should have been presented before the second section of the previous chapter. It nonetheless serves as a valuable introduction to programming Android. Incidentally, Figure 2.1 labels the development environment as being located on a laptop, incorrectly suggesting that desktop computers are not equally usable platforms. Later, when the authors suggest that readers add the Android SDK tools directory to their system search path, they specify only the release-independent directory (containing adb, for instance), and not the release-specific paths (containing aapt, which is the first tool discussed); readers presumably should add both. Also, the authors should specify which release to use, 1.1 or 1.5. The reader eventually is told how to run a sample application — and not a moment too soon, because at that point the reader is already 15 percent of the way into the book. To reach that point, she must wade through more introductory material than was needed, in addition to discussions of network speed and latency, command line tools, DDMS, Java packages, and other information. All of this could and should be covered later, when it would be much more meaningful, and the reader would have greater motivation to learn it, having seen an Android application running (if only in the emulator).

Part 2 forms the bulk of the book, consisting of nine chapters devoted to the essential aspects of Android application development: user interfaces, including the Activity class, views, resource types, and manifest files; Intent classes, broadcast receivers, task services, and inter-process communications; data storage and retrieval, including user preferences, files stored on the local system and on SD cards, databases, and the ContentProvider class; networking, including client/server interaction, HTTP, and Web services such as SOAP; telephony, including how to receive and initiate calls and SMS messages; notifications and alarms; generating graphics and animation; multimedia, including audio and video, utilizing the OpenCORE technology; location-based applications, using a variety of tools, including Google Earth's KML. All of these chapters make use of example applications, with annotated source code and screenshots of the applications running in the Android emulator.

The third and final part of the book comprises two chapters, each of which extends the core concepts of Android development. Chapter 12 steps the reader through the creation of a substantial application, named "Field Service Application," designed for mobile technicians who provide support services for customers of contracted clients. The application is designed to be used by both the technician and his home office to assign and manage job orders, capture customer signatures of completed jobs, order replacement parts, and receive navigation assistance. The final chapter, "Hacking Android," explores Android's utilization of Linux, the C programming language, and the SQLite database — as well as how the Android developer can access these capabilities under the hood.

Appendix A explains how to install the Eclipse integrated development environment (IDE), the Android software development kit (SDK), and the ADT plug-in for Eclipse. Readers who do not already have those components installed on their computers, may want to first read the appendix and follow the procedures. Note, however, that the procedures given in section A.4, for installing the ADT plug-in, are already out of date — namely, for Eclipse version 3.3. In addition, the URL given by the authors ("https://dl-sll.google.com/android/eclipse") is invalid, because it is missing the trailing directory slash, which is necessary for it to work within Eclipse. (This points up the importance of including root directories in URLs, despite their common absence, because even though Web browsers will automatically correct this upon receiving an error message from the server, Eclipse evidently does not.) The online Android installation instructions are much more useful, because they also include the latest version of Eclipse, 3.4.

As is to be expected with the first edition of any detailed computer programming book, this one contains some errata — for instance, in the first portion of the book alone: "Android[']s" (page xxii, twice), "Webkit" (page 7, in the caption), "SQLite[,] an" (page 11), and "byte code[s]" (page 13). Also, terms such as "Internet" and "Web" are in all-lowercase, throughout the book, even though they are proper names. (In our world of instant messaging and Twitter, grammatical degeneration continues apace.) For any reader who wishes to follow along and implement the sample projects, possibly the most disappointing decision by the authors was that of offering the sample code not as a single archive file, or even individual archive files for each of the 13 chapters. Instead, the reader must tediously click through multiple layers of directories, just to get the code displayed in a browser, one file at a time. Readers are advised to employee a Web copying utility, which, given a starting URL, will try to download all of the linked pages, recursively, and store those Web pages and other Web elements on their own computer (even localizing links, to retain working navigation in the saved pages).

Yet by far the biggest problem with this book, is that while it claims to be an introductory text, suitable for someone completely unfamiliar with Android, it does not bring the newcomer up to speed at a reasonable pace for learning. Instead, it presents a large number of code snippets and tools to the reader, without adequate explanation for the beginner to truly understand what is happening. This pattern begins even in the first chapter, which is sorely lacking a tutorial on how to execute the sample code — to better understand it and perhaps modify it (a practice that most programmers find quite valuable for assimilating a new technology). On page 23 is a frustratingly brief sidebar on testing the receipt of an SMS message, that is far from adequate for the reader anxious to begin testing out this new material. The second chapter continues this unfortunate tendency of describing tools prior to giving the reader enough information to run those tools themselves in the same manner, and see the same results. For instance, on page 41, the authors show how to use the adb tool to connect to a running emulator session, but at that point the reader has no such sessions running. (Sometimes the authors of programming books understand the material quite well, but neglect to view it from the perspective of someone who does not yet have that understanding.)

While more appropriate for intermediate Android developers than claimed, Unlocking Android contains a wealth of information to help Java programmers begin developing mobile applications for Google's new platform, with numerous code snippets and screenshots.

Michael J. Ross is a freelance Web developer and writer.

You can purchase Unlocking Android from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

117 comments

But... (2, Funny)

Anonymous Coward | more than 4 years ago | (#28517269)

My android wont let me near him because hes a little paranoid.

Ads Disabled (-1, Offtopic)

googlesmith123 (1546733) | more than 4 years ago | (#28517345)

------------------
Ads Disabled
Thanks again for helping make Slashdot great!
------------------

Unfortunately this doesn't disable stupid book "reviews" (otherwise know as ads).

Re:Ads Disabled (2)

bami (1376931) | more than 4 years ago | (#28517917)

Yo dawg, I heard you like adblocking so we block the ads here so we can block ads while you block ads (with adblock).

Re:Ads Disabled (0)

Anonymous Coward | more than 4 years ago | (#28518965)

yo nig. meez anig to, nowamin?

Re:Ads Disabled (0)

Anonymous Coward | more than 4 years ago | (#28518417)

Damn, it also doesn't block stupid comments. Oh well.

txt of Unlocking Android (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28517387)

Page 1: Android is already unlocked, sucker.

Fin

It still has quite a bit of "suckiness" (1, Informative)

goffster (1104287) | more than 4 years ago | (#28517427)

If you buy an unlocked android phone, you can not run applications *you paid for*
because of DRM.

If you buy an android phone and then unlock it, all is well.

Re:It still has quite a bit of "suckiness" (3, Informative)

spyingwind (961097) | more than 4 years ago | (#28517621)

"If you buy an unlocked android phone, you can not run applications *you paid for* because of DRM." This is a false statement unless your referring to a non Dev phone I have IM+ paid for and I am using it with out a fuss on my Dev phone. ~Spyinwind

Re:It still has quite a bit of "suckiness" (1)

poetmatt (793785) | more than 4 years ago | (#28517803)

Can you still use market apps on an unlocked non dev phone?

Re:It still has quite a bit of "suckiness" (1)

Adm.Wiggin (759767) | more than 4 years ago | (#28518265)

Most certainly. I don't think you can use copy-protected market apps, but I'm using and Android Dev Phone 1 and haven't had any trouble finding what I want in the Market.

Re:It still has quite a bit of "suckiness" (1)

poetmatt (793785) | more than 4 years ago | (#28518861)

Can you clarify by what you mean by copy protected? Do you mean I can't redownload apps I bought or you can't even buy apps on the unlocked phone?

Re:It still has quite a bit of "suckiness" (1)

schon (31600) | more than 4 years ago | (#28519425)

Can you clarify by what you mean by copy protected?

He means Apps with the "copy protected" flag set.

Do you mean I can't redownload apps I bought or you can't even buy apps on the unlocked phone?

Neither.

You can redownload apps you bought, and you can buy apps (even copy-protected ones) on an unlocked phone.

Apps that are flagged as "copy protected" cannot be copied from your phone to somewhere else. You can re-download them as many times as you want to your handset, however with a ADP1 (specific hardware purchased from Google for the purposes of software development) these apps are not available.

Re:It still has quite a bit of "suckiness" (1)

poetmatt (793785) | more than 4 years ago | (#28520569)

so if I homebrew my G1 to a custom firmware I won't be able to download the protected apps nor the actual app store apps, or only the protected ones? I was confused by the formatting of your response as to if you were saying I couldn't do either or the other comment afterwards.

Re:It still has quite a bit of "suckiness" (0)

Anonymous Coward | more than 4 years ago | (#28519463)

IIRC, Android Market allows software publishers the choice of selling DRM-laden downloads or downloads free of DRM, and the vast majority of Android Marketplace apps, even those that cost money, are being offered without DRM.

Re:It still has quite a bit of "suckiness" (2, Informative)

TheBracket (307388) | more than 4 years ago | (#28518681)

I have a g1 sitting here, running on AT&T. It was unlocked by purchasing an unlock code from a website - and all the market apps I've downloaded (including some for which I paid, such as Touchdown's Exchange client - need it for work) work just fine. I think the problem referred to above isn't with market apps you buy on the newly unlocked phone, but with losing access to already-purchased apps when you unlock; I'm not sure about that since this phone was wiped before I unlocked it.

Re:It still has quite a bit of "suckiness" (2, Insightful)

MrMista_B (891430) | more than 4 years ago | (#28518281)

Just felt like pointing out that you essentially just posted that 'This is a false statement unless it is a true statement'. :)

Re:It still has quite a bit of "suckiness" (0)

Anonymous Coward | more than 4 years ago | (#28517677)

[Citation Needed]

Re:It still has quite a bit of "suckiness" (1)

Abreu (173023) | more than 4 years ago | (#28517721)

On a related question... Are there any new android phones coming up?

The G1 is not available in my country

Re:It still has quite a bit of "suckiness" (3, Insightful)

curunir (98273) | more than 4 years ago | (#28518009)

There's the HTC Magic [htc.com] that's out in some countries. This is the phone that Google gave to all the attendees at their recent I/O conference.

Re:It still has quite a bit of "suckiness" (1)

EBMN (1563583) | more than 4 years ago | (#28518541)

HTC Hero will be out in Europe mid-July and that is one fine device.

Re:It still has quite a bit of "suckiness" (0)

Anonymous Coward | more than 4 years ago | (#28518135)

you're spreading FUD, thats completely false.

Re:It still has quite a bit of "suckiness" (1)

EvanED (569694) | more than 4 years ago | (#28518191)

It's not completely false... you can't load [slashdot.org] paid but copy-protected apps onto the Dev Phone.

Re:It still has quite a bit of "suckiness" (1)

Tony Hoyle (11698) | more than 4 years ago | (#28520263)

Yeah but a dev phone has one purpose - for development.

If you buy a phone from a retailer it is *not* a dev phone, and unlocked or not will work fine with all apps.

Re:It still has quite a bit of "suckiness" (1)

EvanED (569694) | more than 4 years ago | (#28520353)

Yeah but a dev phone has one purpose - for development.

I've considered getting a dev phone so that I can have an unlocked phone!

Is there a reason this is unreasonable (other than the aforementioned inability to load copy-protected apps from the store)?

Re:It still has quite a bit of "suckiness" (0, Troll)

larry bagina (561269) | more than 4 years ago | (#28518497)

Why would I pay for an app? I just pirate the drm-free version. Developers can make money giving lectures and selling support contracts, neither of which I'll pay for.

Re:It still has quite a bit of "suckiness" (1)

sammyF70 (1154563) | more than 4 years ago | (#28519985)

Hmm ... good idea! I mean, think about the 99c or even $2.99 you actually saved! Pirate two or three applications and you can even buy yourself a cup of coffee to go with that free wifi! Well ... I'll go back to giving lectures and selling "support contracts" for my 99c games ...

I hope you aint trolling. Here's food. (1)

Max Littlemore (1001285) | more than 4 years ago | (#28522875)

Why would I pay for an app? I just pirate the drm-free version.

Yeah, so the people who develop a game, for example resort to killing the game play by putting in ads. So noone uses the game. So they go broke.

No, hang on, that doesn't work. They developers give it away for free because they are nice people who don't really need to eat. But, although thoroughly nice, being so destitute, noone could be bothered listening to lectures by them about how they to could waste their talent and energy on a plan that is sure to fail. And who buys a support contract for a game? Don't people just try a different game?

That doesn't work either. Hey maybe, just maybe, USD0.99 is nothing to pay for 6 months of boredom relief while waiting for a train. Maybe, if the market is global, ten thousand people pay and the dev can live for a bit from it? Maybe the dev might create something that a couple of million end up paying for it and the dev can set him/her self up pretty well for? That works.

What works even better is where the dev gets the USD0.66 (after google takes a cut) and spends a portion of it on buying off law enforcement and hiring a personal security detail. Then, and here is the brilliant bit, they can track down arseholes who just run the 'pirated' version and force them to give the lectures. Naked. With fresh chilli shoved up their arses. At gun point with the threat of more chillis.

For the record, I have an unlocked G1, I use loads of free software - no MS or Apple at home, and I donate to projects that create software I like. I pay for games if they work on wine and then download a no cd crack if required. I would pay for apps for Android if I could get them on my market.

The Killer App Wll Be: +1, Informative (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28517429)

Intenet games of SKILL for your iPhone to kill time during job search. What else will the U.S.A. proletariat do given that their jobs have been exported to Mexico and China with the approval of their Criminals-In-Congress and corporate executies?

Why throw money away on a lottery when you can you use your SKILLS to play poker. Poker is NOT gambling !!

P.S.: Of course, this entertainment option requires payment with a credit card which is preferable form of payment in hedonistic U.S.A.

Yours In Entertainment,
Kilgore Trout [youtube.com]

Android just won't catch up with iPhone (4, Insightful)

Estanislao Martnez (203477) | more than 4 years ago | (#28517433)

The iPhone is winning on the basis of having a much superior interface. Open source development has always been notably bad at user interfaces, and more generally, at design; it is no accident that the most successful open source projects are all clones of some other software, or implementations of back-end protocols like HTTP. Very often superior clones, mind you, but it's still derivative.

Re:Android just won't catch up with iPhone (3, Interesting)

rmcd (53236) | more than 4 years ago | (#28517627)

Could you (or someone else) elaborate on the UI differences, and why one would prefer one or the other? And how much of this is android issues as opposed to app-specific issues?

Re:Android just won't catch up with iPhone (2, Interesting)

LDoggg_ (659725) | more than 4 years ago | (#28517657)

I have a g1 and a ipod touch. The differences are really multi-touch and apple's stuff is more round and bubbly.

Estanislao was trolling.

Re:Android just won't catch up with iPhone (1)

Mordok-DestroyerOfWo (1000167) | more than 4 years ago | (#28517777)

To be completely fair the G1 is capable of multitouch. The Jesus Freak mods [gizmodo.com] include a couple of test applications and a 'pinchable' browser.

Re:Android just won't catch up with iPhone (1)

LDoggg_ (659725) | more than 4 years ago | (#28517823)

I'm actually running JF 1.5, rooting was easy :)

The browser pinch zoom is cool, but I'd really like it in the maps application.

Would be nice to see this stuff official though.

Re:Android just won't catch up with iPhone (1)

Lord Jester (88423) | more than 4 years ago | (#28518243)

You can add multi-touch to the G1.

As to the "round and bubbly". If I wanted round and bubbly I would own a Mac instad of a PC running GNU/Linux.

I do not judge the worthiness of a tool by its outward appearance and whether or not it makes me feel all fuzzy inside. Likewise, I do not make my puchases based on how popular something is in a pathetic attempt to be part of the "in crowd". The latter is, IMNSHO, the reason the iPOD/iPhone is as popular as it is.

I was at the poker table last night comparing my G1 with two of the dealers' iPhone. As far as functionality, there is not too much difference. The biggest difference is not getting raped by AT&T for a dedicated data plan just for the iPhone. When I added my sister to the family plan, she wanted an iPhone. I said no, as the existing text/data coverage on the plan did not cover the iPhone, it requirfed its own ancillary addons.

Re:Android just won't catch up with iPhone (2, Interesting)

Americano (920576) | more than 4 years ago | (#28520079)

The latter is, IMNSHO, the reason the iPOD/iPhone is as popular as it is.

What do you base this opinion on? I've seen this meme before, and I fail to see any useful logic behind it. Do you really believe that a majority of people would choose to buy a product that is completely inadequate for their needs simply because it makes them part of the "in crowd"? And if you do believe that, what do you base that belief on?

Re:Android just won't catch up with iPhone (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#28520933)

I thought the myth that a product's commercial success is based on its factual qualities and not on better marketing had been dispelled a long time ago.

Re:Android just won't catch up with iPhone (1)

Lord Jester (88423) | more than 4 years ago | (#28522359)

My opinion is based on my personal experience and observation. That is why it is called an opinion.

When I ask people why they have an iPhone vs , the first response I get a majority of the time is "its cool" or "it has a lot of cool features". The common word being cool.

I will admit, freely, that iPhone was, when released, the best at what it offered. It was a whale in a pond. Now it is an old fish in a lake full of younger fish.

I will also admit, I did not jump on the iPhone bandwagon for the same reason I did not jump on the iPOD band wagon, I don't like Macintosh. However, IO do not let that cloud my judgment as to their technical capabilities.

But I digress.

A large portion of iPOD/iPhone success is marketing. Whether it be traditional advertising or partnering with other companies/vendors to offer exclusive rights or focused "value-add" products that are unique to iPOD/iPhone.

Re:Android just won't catch up with iPhone (4, Informative)

Greenisus (262784) | more than 4 years ago | (#28518749)

I've published an Android app (Slicehost), as well as a few iPhone apps, and here are the biggest differences in development that ultimately (in my opinion) make Android apps inferior:

  1. It's Java + Eclipse, which is notoriously slow when compared to XCode and the iPhone Simulator
  2. UI design is done in very verbose XML, as opposed to Apple's Interface Builder, which lets you easily drag things where you want them
  3. Since Android is a platform and not tied to a single device, you have to design in "device independent pixels" which is much different than the iPhones set-in-stone 320x480 resolution
  4. Core Animation... 'nuff said

Re:Android just won't catch up with iPhone (0)

Anonymous Coward | more than 4 years ago | (#28519091)

Oh man, you rock 2DNth degree. How you do those flowcharty things?

Re:Android just won't catch up with iPhone (4, Insightful)

LDoggg_ (659725) | more than 4 years ago | (#28519277)

It's Java + Eclipse, which is notoriously slow when compared to XCode and the iPhone Simulator

Eclipse isn't required for development, though it is extremely useful. And you don't like Java, there's a Native SDK now: http://developer.android.com/sdk/ndk/1.5_r1/index.html [android.com]

UI design is done in very verbose XML, as opposed to Apple's Interface Builder, which lets you easily drag things where you want them

The GUI is described in XML, but you don't have to use a text editor to build or edit it. There are in fact tools in Eclipse to drag and drop components into the GUI. Heck, there's even an applet I've seen that will do some point and clicky GUI creation and spit out XML.
Would you rather that there was only a closed source proprietary IDE that spit out binary data to build your GUI for Android?

Since Android is a platform and not tied to a single device, you have to design in "device independent pixels" which is much different than the iPhones set-in-stone 320x480 resolution

You say that like it's a bad thing. So if apple decided to put out an in-dash car PC using the iphone OS, you'd like the fact that the existing iphone apps look like shit in it? Or would you want the in-dash screen to run at an obscenely low resolution?
How about programming GUIs in way that allows them to play nicely in multiple screen resolutions?

Core Animation... 'nuff said

No, not enough. Please elaborate on why that makes iphone such a great platform to develop on.

Re:Android just won't catch up with iPhone (1)

Timmmm (636430) | more than 4 years ago | (#28520119)

The native SDK doesn't allow you to do much at the moment. Your app still has to be Java but it can call native functions. Those native functions can't do much useful apart from number crunching at the moment. For example you can't do graphics, input or sound.

Re:Android just won't catch up with iPhone (2, Interesting)

Greenisus (262784) | more than 4 years ago | (#28520829)

I shouldn't have listed Java, as I have no problem with the Java language; it's really Eclipse that bugs me and only because it (and the simulator) are so slow on my (fast) machine.

And all of the Android UI design tools I've used have been extremely awkward when compared to Interface Builder. In fact, I gave up on the tools and decided to simply write XML by hand (and only then could I finally get the results I wanted). As for IB being closed source and proprietary, that doesn't really matter much to me as I simply want to build the best UI possible (and IB's output is actually extremely verbose XML). I love open source and use/build plenty of it, but ultimately I'm going to use what I think are the best tools regardless of price or openness.

If Apple made a iPhone OS device with different resolution, I might be screwed. But in that case, I'd rather redesign the app to fit the specific device and its nuances, so that doesn't worry me so much. Ultimately, it's a difference in philosophy. The iPhone approach is more like native app design, and the Android approach is more fluid like web design. Both are good in different ways, but I personally prefer the precision of the iPhone OS approach.

As for Core Animation, it's great because it's very simple and intuitive. You can create very sophisticated animations with very little code. In fact, you can do the same kind of morph effects that you see in Javascript libraries like script.aculo.us and and jQuery, which is so easy. Maybe it's that easy in Android too, but on first glance it didn't seem to be to me.

Just so you know, I don't hate Android, and I will probably write another app at some point. If the iPhone wasn't out, it would be my phone of choice, and I think the openness of the platform is great, and publishing to the Android Market is drastically better than the App Store approval process.

Re:Android just won't catch up with iPhone (0)

Anonymous Coward | more than 4 years ago | (#28521871)

I'm sorry to tell you; your machine isn't "fast" if it can't run eclipse at a reasonable pace. It loads in under 3 seconds on my miserly entry level 8GB DDR2, 4core, regular 7200 rpm sata drive and once it's up it runs like any other application. you just need to give it a gig of memory rather than being a miser with the default 128. You need to get out of 2008 my friend and get a real machine.

Re:Android just won't catch up with iPhone (0)

Anonymous Coward | more than 4 years ago | (#28519405)

UI design need not be done in XML. It can be done directly in code which, as a programmer, I find easier to do.
Speed is also not an issue. See the Android game entitled "Around The World" available on the Android Market
(paid app unfortunately $0.99) which is very responsive to user actions.

Re:Android just won't catch up with iPhone (1)

Greenisus (262784) | more than 4 years ago | (#28520345)

I'm not talking about the speed of apps. I'm quite happy with the performance of my app on a G1. I'm talking about how responsive Eclipse is compared to XCode.

Re:Android just won't catch up with iPhone (1)

IamTheRealMike (537420) | more than 4 years ago | (#28519577)

I've written an Android app but not an iPhone app, so, my opinion is less informed than yours. That said, you can write native code now. It's not really meant to write entire apps in because the APIs are still Java and that is unlikely to change, but if you want to do something compute intensive in C/C++ that's certainly now an option. Personally I think Objective-C is a pretty stupid language compared to Java, so, having at least the option to mix and match approaches is nice.

There is a visual UI designer, so you don't have to write XML. That said, the UI designer sucks donkey balls, so it's not a superior alternative. It's balanced by the Android layout managers which are superb. RelativeLayout in particular is very intuitive. You just say "I want this control to be below that one, and that control to be to the right side of this one" etc. It's probably the best GUI toolkit I've used so far.

You don't have to design in DIPs. You can use regular pixel measurements if you want. Of course then you get to do extra work if you want to support other screen resolutions, but that's the inevitable result of Androids "many hardware designs" philosophy. Is the iPhone hardware the last word in handset design? If you believe it is, then DIPs are a waste of time. If (like me) it seems unlikely, then DIPs are probably a good idea.

As to Core Animation, I'll have to take your word for it. There is animation support in the Android UI toolkit and I've used it to make nice swipes/fades etc. I don't know how much more sophisticated Core Animation is, but the Android API demos show how to do things like 3D screen flips etc.

Re:Android just won't catch up with iPhone (1)

Greenisus (262784) | more than 4 years ago | (#28520505)

I probably shouldn't have mentioned Java in my list of criticisms, as I really have no issue with the language. Most of my career has been in Java and I'm quite comfortable with it (though we differ on opinions about Objective-C).

I definitely agree with you about the UI designer. I found it (and third party UI designers) far more confusing than simply writing the XML, and if it had not been for the layout managers I would probably still be working on the first version of the app :)

And since I have no idea what's coming in the future for Android devices, I felt that it was smartest to design with DIPs. To me the approach is kind of similar to web design, and while I like it as a philosophical level, I found it to be clumsy in practice compared to Interface Builder.

Back to the web design point, Core Animation is quite intuitive if you're comfortable with Javascript morphing effects from libraries like script.aculo.us or jQuery. It's almost the exactly same idea, but in Objective-C and more options than just CSS rules. Maybe Android is the same way, but I don't really know.

Re:Android just won't catch up with iPhone (0)

Anonymous Coward | more than 4 years ago | (#28522077)

I have your Android app and I love it. I'd counter by saying:

- java and eclipse will mean more toolsets

- native code compilation has just been added to the android platform. scripting too, if you favour the other kind of rapid

- set-in-stone resolution is going to bite you one day. Device-independent pixels are coming to the Mac soon and will arrive in the iPhone OS, but I suspect a lot of apps are going to be relegated to working in the corner of the screen on bigger devices

- android UI designers are beginning to appear, though interfacebuilder is a tough thing to match. XML means programmatic interface generation should be easier, along with conversion from other tools

- bugfixes to your app will (do!) turn up in the Android market more quickly

Can't fault the Core Animation point. But I'd say that the developer-friendliness of Android isn't in general going to be weaker than the iPhone... it's going to have different friends.

Re:Android just won't catch up with iPhone (1)

Greenisus (262784) | more than 4 years ago | (#28522729)

Thanks! I'm glad you love the app! :)

I am concerned about what will happen when iPhone goes device independent. The UIKit widgets should be fine, and hopefully my custom ones will be fine too, but I'm more concerned about images (for instance, the OS logos in the Slicehost iPhone app).

And yeah, I like them both really. I think they're both fantastic platforms. The Android Market is wonderful though. I had a bug with the Android app and I was able to push it out as soon as I finished it, which was lovely.

Re:Android just won't catch up with iPhone (1)

shutdown -p now (807394) | more than 4 years ago | (#28522225)

Since Android is a platform and not tied to a single device, you have to design in "device independent pixels" which is much different than the iPhones set-in-stone 320x480 resolution

So what you're saying is that once Apple decides to upgrade iPhone to, say, 800x480 (which is what a few WinMo phones have had for a few years now), all existing applications will break?

We have already went through this on the desktop. Older UI frameworks required you to lay out the widgets using absolute pixel positioning. Now, this is faux pas - any decent modern UI framework supports dynamic layouts, and better ones strongly encourage them. I'm glad to hear that Google is doing the right thing from the get go for Android.

Re:Android just won't catch up with iPhone (1)

Coward Anonymous (110649) | more than 4 years ago | (#28523747)

Motif. When I first played with an Android phone the first thing it reminded me of was the Motif Window Manager with a colorful wallpaper and some pretty icons put in as a distraction. That about sums up the look and feel of Android.

UI failures that immediately hit me:
1. It's cluttered. You've got the app icons on your desktop. You've got the little tab thingy to pull up yet more apps (some of which already have "shortcuts" on your desktop. You've got that odd pulldown thingy from the top for notifications and a couple other things (like enabling external USB access to the flash, if I recall correctly). It's not really clear what goes where and why.
2. Motif. The UI elements (buttons, etc.) are horribly ugly and not user friendly as they are all kind of grayish.
3. A classic example of UI amateurism in Android is the touch scrolling. The iPhone has a neat trick which I'm guessing most people are convinced is a gimmick. I didn't realize the genius of the trick until I played with an Android phone and missed it. When you scroll to the end of a viewable area, the iPhone will "bounce scroll", it'll animate your view scrolling past the limit and then glide it back. Android does nothing in the same situation. So when you reach the end of the scrolling area on an iPhone you instantly realize it because the iPhone just gave you feedback. On an Android you slide your finger a couple more times with some uneasiness to be sure because there is no feedback of any kind. Someone at Apple thought this stuff through and it shows.
4. The iPhone provides a very robust set of UI widgets and API infrastructure that allow even an artfully-challenged person to create apps which are visually passable.

Re:Android just won't catch up with iPhone (2, Insightful)

vertinox (846076) | more than 4 years ago | (#28517671)

Open source development has always been notably bad at user interfaces, and more generally, at design; it is no accident that the most successful open source projects are all clones of some other software, or implementations of back-end protocols like HTTP.

I know the OP is being a bit hostile, but with many Open Source projects UI are basically "what would I like to have" following then "what would my user's like to have" and followed "what my user's should have but don't know they need" last.

I think more thought should be done to the interface via a graphic design and human nature standpoint rather than simply doing what you are the user asks for.

I'm not saying that the developers or users are stupid, it is just that often when asked they really want, they don't know what they really want so they throw everything in and end up with feature UI bloat.

Sometimes less is more, and if you work from a standpoint of what you shouldn't or can't do, and work around that, then sometimes you will make users less frustrated when having to remember what random command or finger swipe gesture does what.

That said, if my iPhone resets its damn icon order again because I had my finger on the screen too long I'm GOING TO THROW IT VERY HARD!!

Re:Android just won't catch up with iPhone (1)

mbarkhau (1137557) | more than 4 years ago | (#28517755)

Have you used one? The interface is pretty nice if you ask me. The main thing I would change about the G1 is battery life, other than that I think it's on par with the iphone. Tactile feedback FTW.

The main things I see Android has going for it:
lots of (cheaper) devices
great dev tools
Java > ObjectiveC (at least more people know it)
no need to buy a mac for development

The android challenge 2 seems to have created a lull in released apps, but over time I think the better environment for developers will ensure more and better apps than for the iphone.

Re:Android just won't catch up with iPhone (1, Informative)

Anonymous Coward | more than 4 years ago | (#28518175)

I have a G1, and have the following complaints about it: 1) Slow response to input touch 2) No support for Bluetooth stereo profile (has this been fixed yet?) 3) It tends to do things like call people and display youtube videos without me telling it to (do other touchscreens have this problem?) 4) GPS receiver is less sensitive than iPhone (this might be just my specific phone)

Battery life? Yeah, you have to recharge it _every_ night, but it has no problem making it through a full day's use. "On par with the iPhone"? Hardware/feature wise, yes. Software wise, the iPhone has been longer in development, so it is more ready for prime time and has more apps available. I bought the G1 betting that Android software would improve faster; it may yet surpass iPhone but to date I have been disappointed by the rate of improvement.

Biggest problem with both phones? iPhone is tied to AT&T and G1 is tied to Tmobile. I would LOVE to see and end to the exclusive deals between mobile manufacturers and cell phone providers.

Re:Android just won't catch up with iPhone (1)

JaiWing (469698) | more than 4 years ago | (#28518473)

Um, AD2P has been supported since the release of 1.5. It has been out for 2-3 weeks.

Re:Android just won't catch up with iPhone (0, Flamebait)

larry bagina (561269) | more than 4 years ago | (#28518637)

Check your history. Java is a poor knockoff of objective c. Sun ditched OpenStep in favor of Java. Apple ditched Java in favor of OpenStep.

Res Ipsa Loquitur.

Re:Android just won't catch up with iPhone (1)

kaffiene (38781) | more than 4 years ago | (#28520889)

That is complete and utter rubbish. Noone who has actualy *used* both Objective-C and Java could imagine that the latter was a 'knock off' of the former.

Re:Android just won't catch up with iPhone (0)

Anonymous Coward | more than 4 years ago | (#28517767)

Shouldn't you be picking lettuce?

Re:Android just won't catch up with iPhone (1)

jbacon (1327727) | more than 4 years ago | (#28517783)

Seeing as I actually own a G1, I enjoy the ability to make my interface whatever the hell I want it to be. On the Market alone are several complete Home screen replacement apps, offering a plethora of features including iPhone-style dock bars, skinnability, and more. And once you break out of the one-click comfort zone and check out xda-developers [xda-developers.com], the opportunities abound. Custom roms, roms for other phones that are ported to the G1, and so much more.

So, the G1 ends up being a delightfully hackable, surprisingly polished platform. Considering Apple has a year's head start on them, the Android platform is doing superbly. Further considering that there are many, many phones on many carriers slated for release that run Android, I'm fairly confident in saying that the platform will be taken to a whole new level this time next year. Once carriers start learning that Android makes them money, they will throw their support behind it, and that'll be the game.

Re:Android just won't catch up with iPhone (1)

FunkyELF (609131) | more than 4 years ago | (#28517787)

The iPhone is winning on the basis of having a much superior interface. Open source development has always been notably bad at user interfaces, and more generally, at design; it is no accident that the most successful open source projects are all clones of some other software, or implementations of back-end protocols like HTTP. Very often superior clones, mind you, but it's still derivative.

XBMC has the best user interface of any application I have ever used.

Re:Android just won't catch up with iPhone (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28518289)

This is hilariously wrong. For one thing, the UI of Android is distinctive, and not derivative of the iPhone in any appreciable manner (like the iPhone it has a lot of similarities with other, earlier touch-screen smartphones and PDAs, going back as far as the DEC Itsy and the Compaq iPaq, and the Palm VII).

The snipe about open source being bad at 'design' is crass stupidity, unless you think that gcc, BSD, TCP/IP and webkit are all bad design... Apple doesn't. Android's design is subtle and sophisticated, with advanced features like gesture-based screen unlocking, and the "Intent"-based mechanism that allows apps to interact.

Android apps are capable of some things that iPhone apps simply cannot do, and the hardware of the devices launched so far, designed by HTC, is significantly more advanced than the iPhone 3GS until it was launched. There are apps built on Android that were simply not possible on the iPhone until the 3GS (check out wikitude, Layar, Lastminute NRU and IBM's new Wimbledon navigator if you don't believe me).

The iPhone is winning at the moment because of an astonishingly clever and successful marketing effort, polished delivery of product and the attention to detail that has allowed, for example, games to flourish, but unless you're a complete idiot you can't possibly believe it will remain dominant over a capable, fast-advancing, more hardware-agnostic OS that has sold a couple of million handsets on the back of almost no marketing whatsoever and is available for the entire industry to adopt. The fact that it is open source is not really that significant.

iPhone's destiny is as a major but not dominant player, like the (lovely) Mac I am typing this on. Android is not broken, nor is it bad, and it has no flaws significant enough to stop it being deployed and improved by any number of players.

Competition is a wonderful thing.

Re:Android just won't catch up with iPhone (1)

jackspenn (682188) | more than 4 years ago | (#28520355)

The iPhone is winning on the basis of having a much superior interface

Here is the best AD for Android, you run it the end of this year or early 2010.

You have a cut of the Apple conference where they show how many apps they have compared to other phones with the date. - Advantage iPhone

Then you show the current apps between Android and the iPhone with trend lines and the date Android will pass the iPhone sometime next year. - Advantage Android

Then you show apps that Apple has banned but are available for Android, starting with wifi tethering that allows you to connect multiple Windows, Linux and OS X machines to your service providers network, etc. - Advantage Android

Then you run the number of iPhone models available versus the number of Android phones available. Phones with keyboards or without keyboards, phones from HTC, motorola and Samsung (all will have phones by the end of 2009). - Advantage Android

Then you show how iPhone only works on AT&T and how Android works on T-Mobile or AT&T and probably other providers by the end of year. - Advantage Android

So you basically say, do you want the most censored apps you can play in the foreground right now? Apps that are policed by Apple and AT&T?

Or do you want the phone what has the most apps by end of 2010, is open, with advanced apps, background services and alerts, etc. with more choices on service providers and hardware manufactures?

Do you want a phone that you can hack and customize endlessly, a phone you can tweak infinitely and even code for yourself or your friends?

In short do you want to feel cool, or do you want to be free (which is what makes most people cool)?

eclipse (3, Informative)

LDoggg_ (659725) | more than 4 years ago | (#28517457)

The online Android installation instructions are much more useful, because they also include the latest version of Eclipse, 3.4.

Actually 3.5 (Galileo) is out now. There aren't explicit instructions for it on developer.android.com, but it's still works the same way. Add the update site, and install the plugin.

furries?! (3, Funny)

jollyreaper (513215) | more than 4 years ago | (#28517507)

Why is there a furry on the cover? I thought the mascot was a cute little robot.

Re:furries?! (1)

Tehrasha (624164) | more than 4 years ago | (#28519301)

That was my first thought as well. I knew they liked putting animals on the covers, but a furry??!? I had to go to Amazon to get a higher detail picture to figue out what was going on...

Re:furries?! (0)

Anonymous Coward | more than 4 years ago | (#28519457)

No, Orielly does the animals. Manning always does weird shit like this to somehow show that they're cool with cultural diversity and stuff.
Personally I think a picture of a robot would have been more appropriate to the subject matter than a tatted up dude in a loin cloth.

Catwoman on the cover? (2)

themightythor (673485) | more than 4 years ago | (#28517531)

What is that thing on the cover? It looks kind of like Catwoman got a bunch of crappy henna tattoos. Though the idea of her with a tramp stamp does...things...for me. I'll be in my bunk.

Scripting now available as well. (3, Interesting)

rusty0101 (565565) | more than 4 years ago | (#28517607)

If you would rather program in python, lau or bsh (not bash, but bean shell, a java based shell scripting language) and have an android based phone, have a look at ASE. Currently at version 0.8, found at http://code.google.com/p/android-scripting/ [google.com]

You will want to follow the instructions under help once you have ASE installed. I found it easiest to save the script interpreters for python and lau along with the sample scripts to my phone's sd card as a separate action, then run the ASE application which immediately installed the interpreters and made the scripts available.

See also the wiki and related pages for explanations of why ASE might be of interest to you. Or may not be of interest.

Re:Scripting now available as well. (1)

Aladrin (926209) | more than 4 years ago | (#28517757)

Nice! I've been hoping for Python on Android for a while... I looked at Jython and another, but they didn't seem to be far enough along yet... And looked to be a pain to install, too. (It's been a while, and they may have changed, though.)

Re:Scripting now available as well. (0)

Anonymous Coward | more than 4 years ago | (#28519945)

Awesome but, how much support does the python interpreter have for all the cool modules you can import in the regular python? Is it just a toy or can I do the cool things I can do on my desktop with python?

Got COMSEC? (0, Troll)

Psyber_Netik (1587819) | more than 4 years ago | (#28517669)

Does anybody know if Android got it's security locked down? Last I heard when it came out there were a bunch of Vulns in it.

Re:Got COMSEC? (0)

Anonymous Coward | more than 4 years ago | (#28517891)

...Last I heard when it came out there were a bunch of Vulns in it.

Glad I don't have to worry about that. My phone doesn't have a Vuln in it.

I got as far as (0)

Anonymous Coward | more than 4 years ago | (#28517737)

'per se' and you lost me there....

Re:I got as far as (0)

Anonymous Coward | more than 4 years ago | (#28518067)

Update your English parser.

The Android Platform (1)

c0d3r (156687) | more than 4 years ago | (#28517859)

Can someone please simplify the Android Platform for us developers? Is it a Java VM with some extra libs, and a linux kernel?

Re:The Android Platform (0)

Anonymous Coward | more than 4 years ago | (#28517967)

It's the Dalvic VM.

Its API is very similar to the Java APIs, but, like you said, with extra libs and a linux kernel.

Graphics AWT / SWING (1)

c0d3r (156687) | more than 4 years ago | (#28518043)

Thanks for the response, and it seems as if AWT/SWING aren't supported. I wonder what they use.. their own set of JButton's JCanvas's... etc? Whats the over heard on learning the UI elements? Is it thread safe unlike swing?

Re:The Android Platform (2, Informative)

$1uck (710826) | more than 4 years ago | (#28518781)

It doesn't use a JVM is uses Dalvik vm. SO it is something more than a typical j2me vm and something less than a full JVM. It has its own windowing tool kit, it does not use awt or swing or swt. Personally I think the Android OS is pretty slick, inter-application communication is interesting.

Re:The Android Platform (1)

josteos (455905) | more than 4 years ago | (#28520013)

What would really help would be a VM that would JIT... Dalvik works but is not speedy -- it remains an interpreter. All it really needs is some JIT compilation to take off. Yes, you could do native stuff using the new NDK, but with like 18 announced phones coming out by year-end, I'd rather not get stuck writing custom code for each CPU.

Sorry....have to say it....the cover (3, Funny)

sabernet (751826) | more than 4 years ago | (#28518509)

The platform is called "Android". It basically TELLS you what the cover should have.

Instead they have a tattooed aboriginal hunter with hair from the boss on the Dilbert comics.

Because when I think "android", I think "mostly naked male aboriginal tattoed hunter with Dilbert boss hair".

Re:Sorry....have to say it....the cover (0)

Anonymous Coward | more than 4 years ago | (#28523629)

Manning has their cover themes in much the same way as Oreilly. The animal on the front often has little to do with the content. Example: O'Reilly's _Learning Python_ has a rat/gerbil on the cover. A rat... on a book about a programming language named for a comedy troupe named for a.. uh .. naked snake?? [citation needed... hell I need someone to lookup what they are actually named for. Is there even a consistent answer for that? Or will we have to wait for all but one of them to be dead?] ...

[The author of the previous citation needed citation reference has been sacked] ...

[lexicon]

Michael Jackson BREAKING NEWZ!!! (0)

Anonymous Coward | more than 4 years ago | (#28519057)

Just heard on Irish television. Michael Jackson still dead. Polaksky Frenseh confirms it.

Re:Michael Jackson BREAKING NEWZ!!! (0, Offtopic)

josteos (455905) | more than 4 years ago | (#28520095)

I think I saw him in L4D last night :( I threw a Molotov at the horde, and one of them survived by moonwalking back around the corner!

Better than the O'Reilly book (1)

canowhoopass.com (197454) | more than 4 years ago | (#28520009)

I'm subscribed to O'Reilly Safari, where I have both Unlocking Android [safaribooksonline.com] and O'Reilly's Android Application Development [safaribooksonline.com] in my bookshelf. The O'Reilly book uses the "build a big application" approach to teaching. So each chapter goes into adding a different feature. There is an expectation that the reader has the examples installed, but unfortunately they don't work with Android v1.5(cupcake). I was lost since I couldn't follow. Luckily I found this book which does a much better job of explaining things. The reviewer is absolutely correct on one thing though. It isn't great at explaining the initial install, and doing a hello world example. If you want to learn Android Development I recommend the following order:
  1. 1) Follow the Eclipse install guide [android.com] from the Android dev site.
  2. 2) Complete the various Hello World, Hello Views, and Notepad tutorials [android.com] from the Android dev site. They are kept updated and are well written.
  3. 3) Then read through this book. It really is a good one.

-Rod

And no, the TX won't be the standard bearer. (1)

Impy the Impiuos Imp (442658) | more than 4 years ago | (#28520225)

> Unlocking Android

Assholes! We're already past 2:14 AM easter daylight time, August 29, 1997 and riding on thin ice. Leave them locked up!

Android Java is java is syntax only (0)

Anonymous Coward | more than 4 years ago | (#28520591)

The Android java is java in syntax only. Google/Android created their own classes, etc so it you know any Sun Java classes then you don't know anything except the syntax.

I h8 iPhone development (0, Offtopic)

TheSync (5291) | more than 4 years ago | (#28522171)

OK, so to develop for the iPhone I have to 1) learn a new version of C and 2) deal with yet another overly complex set of classes, invented to make your life more difficult.

Where is the "Visual Basic" for iPhone?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...