Beta
×

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!

Hello, Android Third Edition

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

Google 74

eldavojohn writes "The third edition of Hello, Android brings the book up to date on Android versions from 1.5 to 2.2 (FroYo). The book is predominantly tied to the Eclipse editing environment with several pages devoted to screen shots of the IDE. As the title suggests, this book aims to give the user the equivalent of a "Hello, world!" application in Android and succeeds in doing that but doesn't take the reader much further. From creating a sudoku application with increasing support to dabbling in OpenGL ES, the book's prime audience are people who know a little Java (with no aversion to Eclipse) and XML but absolutely no Android. You can find the source for all the examples." Keep reading for the rest of eldavojohn's review.The first aspect of this book that jumps out at me is that it assumes the user is using Eclipse — even late in the book like on page 231, an entire page is a screenshot of the project creation wizard in Eclipse. While this might be helpful for initiates to Eclipse, it seemed like a bit of overkill at times when actions in Ecipse are revisited throughout the brief book. For example that same screenshot with different options checked can be found engulfing page 10. "If you don't want to use Eclipse (there's one in every crowd)" says the author on page 4 before referring the reader to Android's command line reference. It gets to the point that when Burnette is going to sign his app at the end, he uses an Eclipse wizard.

The second aspect of this book that jumped out at me is that Android apps are written by extending Java classes and utilizing a very verbose XML. So between the overridden class methods and the layout meta data in the XML, there is a lot of code consuming vertical space in the book. Ellipses are provided to avoid redundancy in some instances but in others it seems there is no avoiding the space consumption. A strength of the book is that, when possible, it shows how to do something simple in both XML and Java and gives reasoning for picking a certain way the rest of the book.

The chapters are laid out with brief introductions and "Fast-Forwards" at the end of each chapter that try to push the user past this Hello, Android introduction to complex concepts. The book is well divided with part one (chapters 1 and 2) providing instructions for setting up your emulator and the basics of Android like a state transition diagram showing how all Android applications transition through Java methods in a life cycle. Part two (chapters 3 through 6) builds the sudoku application with increasing support. Part three (chapters 7 through 10) focus on more complex aspects of Android like device sensors, SQLite and OpenGL. The fourth and final section delves into the future of multi-touch on Android, writing for all resolutions and devices as well as publishing to the Android Market. Throughout the book the author takes care to to mention when you will need to put in a permissions requirement in the manifest file when utilizing something on the device.

In creating the sudoku application, Burnette does a good job at introducing the reader to some basic concepts like procedural designing versus declarative designing and Dips versus Sps. The author introduces the automatically managed R.java file and the first extension of android.app.Activity with a good explanation of how we're going to add menus from XML strings. This chapter nicely sets up the sudoku game to have an opening screen, a settings menu, a theme and exiting the game. It is lengthy but introduces the reader to click listeners as well as explicit information about how to debug. Android 2.2 adds a cute debug level of Log.wtf() which stands for "What a Terrible Failure."

Following that chapter, the author delves into some basic two dimensional graphical capabilities involving extending View in order to manipulate the canvas object inside onDraw. The chapter sums up drawables and gives a short example of text in a circle before returning to the graphics in our sudoku application. Burnette shows explicitly how to draw the game board and give it a nice embossed effect, how to add and center numbers in each of their cells, how to override key events to bring up an input screen with only valid numbers and how to continuously update the game screen. The chapter even goes as far as showing you how to shade the squares in order to give hints to the user. One thing I did not care for in this chapter (and something that persists through the rest of the book) is that the author has no qualms with calling a method in code (like calculateUsedTiles on page 68) and not defining what it does or how it works until the end of the chapter twenty pages later. Given that its signature is descriptive and it's not key to understanding Android, it's probably the best way to teach but left me doing a lot of page flipping since I like understanding apps from the bottom up. Something else to note about this chapter is that the author mentions on page 70 that he experienced "many false starts" of trying different approaches like multiple ImageView classes in XML before finding the fastest and easiest way of having only one view. There's just a couple paragraphs on this in a side box but I really wish the author had expanded on this as it sounds like a vital part of the learning Android process.

What good is a phone app without some sound? Chapter five covers Android's MediaPlayer which Burnette calls "a fickle beast" although it improves with each release of Android. The chapter also touches on playing video in Android which takes just a few lines of code. The author helps the reader by continually explaining what happens in Android when the device is rotated (in these examples the video restarts since the app is recreated). He explains how to avoid this several different ways. He also discusses why using a background service for music isn't a great idea if you intend the music to end when your program ends. By the end of the chapter, you've got some music for your sudoku app.

The next chapter very briefly covers local data storage. This is not the SQLite chapter but rather the PreferenceActivity API as well as the instance state stored via the Bundle in Android's application stack. The author doesn't spend a lot of time on these and wraps the chapter up with a brief description of accessing the internal file system as well as an external SD card.

The seventh chapter covers the need for a browser capability inside your Android application. At first I thought this would be very rarely used (you've already got a web browser) but the author points out that when you need some ability past basic text views, you might opt instead to provide that file through a lean web browser in Android as opposed to a basic test viewer. The author argues this isn't as crazy as it seems because you don't want to waste your time enhancing a text view with more and more functionality when the web browser can do that already. So you get a wrapper around WebKit that allows you to add another view to your application resulting in a browser. Should this connect to the internet, the author explains how to ask for permission to do so and how to access those pages inside your application. The next part of the chapter is probably going to put a lot of security minded folks on edge and the author makes sure to explain very carefully that allowing JavaScript to call Java can be dangerous. So internal to the WebView class, the author demonstrates JavaScript in the web browser invoking your method in Android (and vice versa). Finally the chapter covers the intricacies of interfacing with web services. What the author did really well in this section was discuss his methods of how he came about adding millisecond delays to accommodate the user. The other great thing that makes this chapter so lengthy is that the author introduces threads both through ExecutorService and Handler.

Chapter eight covers GPS and other sensors your device might have that are supported through the latest Android API. The author takes care to understand how you need to setup your emulator if you are testing this on your computer and discusses listening for updates from sensors as well as interpreting that data. Unsurprisingly, the Android API has a MapActivity class to extend for applications that wish to impose data onto a map. I feel the author could have spent more time on the more novel sensor types that are becoming prevalent in cell phones but the GPS and maps might be adequate for an introductory book.

The ninth chapter is an introduction to SQLite in Android. Android supports other data storage solutions like db4o but the author sticks to SQLite and covers all SQL relational database aspects up to a simple cursor. It's done very well and anyone with a little knowledge of SQL should be able to create, modify and update tables inside Android applications with this chapter. A very interesting thing about this chapter is that it covers how to implement inter-process communication by way of a content provider. Android utilizes URIs that programmers can define to provide a framework for storage. The book is mediocre at describing both SQLite and ContentProviders in this chapter although I felt like the ContentProvider has enough material to deserve its own chapter — even in an introductory book. I personally feel it would be interesting to consider a chapter devoted to defining a content provider with reuse by a community intended. We get an EVENTS and EVENTS_ID example but I feel this falls short of the real beauty of ContentProviders.

The next chapter is a venture into three dimensional graphics in OpenGL ES (embedded systems). Twenty pages isn't a lot of space to work with when you're discussing OpenGL but this is a good basic introduction that leaves the reader with the means to do very basic OpenGL. The chapter starts off with some good fundamentals but also carefully explains that your devices might not have 3D hardware. The API is still there but the lag might be intolerable. The author thanks John Carmack for "single-handedly" saving us from Direct3D and starts off on the very verbose code of OpenGL. In it, there are great explanations on some basic options like ambient, diffuse and specular lighting as well as discussions of fixed versus floating point. Several pages later we have a transparent rotating cube with an Android image for a surface.

Chapter eleven is devoted to the buggiest part of Android: multi-touch. A side note titled "Warning: Multi-bugs Ahead" warns the reader about how problematic the following code is going to be and how it might perform differently on different quality of hardware. As Burnette builds out the image viewing application it's a lot of similar code to view an image with the new stuff revolving around debugging logs to give the reader key insight into how the author's phone interpreted his multi-touch interactions. Dragging and pinching are covered to zoom and move the image in the viewer and seems simple enough with the exception of bugs.

Twelve will show you how to build widgets and implement live wallpapers. To a lot of developers this chapter might be a turn off but to a lot of people looking to make money with Android, this seemed like the fastest route. The example just displays a semi-transparent "Hello World!" string but it is then demonstrated how an overriding the update allows you to put date or whatever else you might need to display. The live wallpaper seemed to me like the perfect way to drain the battery on a phone. Although more complicated than the widget, the chapter covers extending the Engine class to provide a drawing engine that will redraw the background — even with our OpenGL code from a previous chapter that the author then implements. The author really goes the distance on the live wallpaper, even explaining how to extend the surface of your wallpaper so that when you transition to another part of your space it slides the rotating cube. For better or for worse, you too can have a continuous rendering of OpenGL code for your home screen!

Chapter thirteen addresses the "fragmentation" issue that so many people have been criticizing Android for. It discusses declaring and demanding an API version as well as building different emulators out on your computer in order to run your application (although earlier in the book, the author heavily criticized the emulator as being terribly slow compared to the real hardware and I experienced the same thing with my Motorolla DROID). The author does a great job of discussing the unfortunately lengthy and complicated process of preparing your software for all hardware. From subclassing to reflection to delegation/factory, he analyzes each one and explains the strengths and weaknesses. If you're having problems with your application across hardware, this chapter is a great starting point. In the next piece of this chapter, the author calls out the Android API on a bug in the ImageView class that prevents the setImageMatrix from working in some cases (this is from 1.5 and has since been fixed). For those of you who are seriously dependent on Android, the author describes in detail his five steps in discovering and addressing this bug with the final step being a peak at the commit comments to the source tree. It's good to see an author doing legwork like this and telling the story but it's also a little unnerving to see the bug. Nevertheless, I applaud the author on this frank discussion. The final parts of this chapter are spent addressing screen size (an increasing issue with tablets) and installation by way of the SD card (something that can be auto or preferred).

The final chapter addresses publishing to the Android market and provides some actually really good insight into how one should approach this and how to interact with your user community. I'd like to note a couple things that the author lists as lessons learned. The first I found interesting was "you can make a paid app free, but you can't make a free app paid." What that means is if you publish something as free and then you update the app to move a piece of what was one free functionality to requiring payment, the backlash might destroy your app's user base. The other thing is something I flat out don't agree with: "If possible, I suggest you perform frequent updates, every two weeks or so." He claims it makes users happy and gives them a feeling of support as well as bumping it up to the top of the recently updated apps in the Market. I personally find it annoying and if I have an app that I use infrequently that frequently requests updates, I uninstall it. Case in point for me is TuneWiki Social Media Player. It seemed every other week that app was requiring an update and since I used it seldom, it was promptly uninstalled. I don't know if I'm alone in this sentiment but I found this chapter to be very insightful with the exception to that suggestion.

The appendices of this book were actually fairly interesting. I didn't know what the subset of the current Android app was for the Java Standard Edition 5.0 library. You can find a list of packages that will be unavailable to you like much of javax. The author also gives great pointers like try to avoid the expensive reflection no matter how elegant it might be for you.

This book is well written with only a few minor editing mistakes. It has a lot of illustrations which are often Eclipse screen shots. While some aspects of this book might alienate a few users, it is a great learning tool for its intended audience. I found it to be "okay" for my needs but perhaps was geared a bit more towards a more novice programmer.

You can purchase Hello, Android: Introducing Google's Mobile Development Platform from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

Android (-1)

devxo (1963088) | more than 3 years ago | (#34678196)

To be honest.. Java, XML and Eclipse sound like a horrible platform for development. Eclipse itself isn't ready for enterprise development - it's mostly a free tool to teach students Java programming. Java makes everything isolated, horrible to develop to different versions (your old Android phone doesn't have the latest Java? Too bad, you're out of luck) and forcing the use of XML.. it might be verbose, but damn it's horrible and has its own drawbacks.

In my opinion there is a huge advantage for Windows Phone 7 - You can develop with extremely professional tools like Visual Studio, you have XNA which is also used to create Windows and XBOX360 games and you can use more current languages like C#. WP7 phones also have more strict requirements regarding hardware so you know beforehand what you need to be aware of. Android is one hell of a fragmented mess ranging from underpowered cheap phones to top of the line phones, all with varying resolutions, capabilities and hardware.

As the book also notes, multi-touch on Android is really crappy. On iPhone and Windows Phone 7 it just works like expected. Things like this NEED to work in the system, you don't leave it to the application developers to do work arounds.

Android has a lot of possibilities, and as much as I like it (I own a HTC phone with Android), it really isn't up to par with iOS or WP7 - from both developers and users point of view.

Re:Android (0)

Anonymous Coward | more than 3 years ago | (#34678278)

You sound like a dumbass shill.

Nah-- I love the android dev env... been doing it since 2008. Eclpise + ADT powerful, flexible, and well documented--- way more fun to code on than iOS. (which I do too) I don't know about WP7--- I know that winmo SUCKED coding for... so I can't imagine wp7 is a ton better.

Re:Android (2, Funny)

Anonymous Coward | more than 3 years ago | (#34678292)

To be honest.. Java, XML and Eclipse sound like a horrible platform for development. Eclipse itself isn't ready for enterprise development - it's mostly a free tool to teach students Java programming.

Sorry, where have you been the last decade?

Re:Android (0)

Anonymous Coward | more than 3 years ago | (#34679612)

Taking his FUD classes, of course. He scored an A++!

Re:Android (0)

binarylarry (1338699) | more than 3 years ago | (#34678314)

Right.

Only little companies like Google (Android ADK), IBM (Websphere, Cell SDK, etc), Adobe (Flash Builder), Microsoft (Sliverlight tooling), Apache (Apache directory suite), Redhat (JBoss IDE), etc. are building their tools on Eclipse.

The real companies are busy making their employees post uninformed, moronic posts on Slashdot.

Re:Android... moronic posts. (1)

theNAM666 (179776) | more than 3 years ago | (#34678378)

>The real companies are busy making their employees post uninformed, moronic posts on Slashdot.

Please see my next post in this thread for example.

Re:Android (1)

bigstrat2003 (1058574) | more than 3 years ago | (#34678318)

I disagree that your last statement is true from the user's point of view. Having used both iOS and Android, I can honestly say I see no differences that would cause me to favor iOS over Android. There are, however, things that Android has that iOS doesn't (such as the notification tray). Not to mention, of course, the ability to use whatever apps I choose, which iOS will never have. iOS is a decent enough option, but imo it isn't bringing anything to the table that Android doesn't.

That may well hold true for WP7, but I haven't used it so I can't comment on that.

Re:Android (1)

rvw (755107) | more than 3 years ago | (#34679788)

iOS is a decent enough option, but imo it isn't bringing anything to the table that Android doesn't.

Maybe from a developer point of view (or development platform/programming language pov) - however let me tell you that iOS brings one thing to the table a lot better than Android, and that is a proper user interface. Maybe this is just a question of rearranging buttons, actions, whatever, but for now Apple does the job a lot better than Google. I have an Android phone, and there are so many situations where I'm confused at what button to press. Especially the back-button is confusing. When the (touchscreen) keyboard appears, I see three buttons in the lower right corner which point all three to the left.

1) the backspace button
2) the enter/new line button
3) the (hardware) back-button

On my laptop I'm never confused about the enter- or the backspace-button, let alone the back-button. On my ipod touch I have never thought about this for a second.

Another confusing thing is the back-button, once again. When I get an sms, and I see the alert in the top notification bar, I pull that down and open the message. Then I press the back button to go where? It can be either:

a) the previous screen
b) the index of the sms list

Okay, for a good 70% I can predict which it is, but many times it doesn't do what I expect.It should be so that you allways know intuitively what button to press, and what will happen if you do so. Google does great things, but the Android user interface is not one of them.

Re:Android (1)

bigstrat2003 (1058574) | more than 3 years ago | (#34679814)

See, that's the thing. I'm not a developer. When I make that statement, I mean it from the user point of view. I have had my Android phone for a year, and I have not once had an issue where I was unsure of how the UI functioned. I consider it very intuitive and easy to use. Maybe other devices are fucking it up horribly, but based on my experience with the Droid (which runs pretty much just stock Android, iirc), the UI is every bit as good as what Apple offers.

Re:Android (1)

g_rampage (1117503) | more than 3 years ago | (#34682720)

I have found the UI to be extremely consistent throughout all of my Android apps. You really don't know what to expect from backspace on the keyboard, back on the phone, and new line/enter? That's a shortcoming in you, not Android.

Re:Android (2)

mlts (1038732) | more than 3 years ago | (#34678370)

Eclipse is a decent tool, but infuriating sometimes. On Windows, I tried installing it, and it just would exit, no error code, no anything. So, I use it on a Mac. I'd love to see NetBeans pushed forward as a steady IDE with hooks for the Dalvik VM and development there.

As for Android, I am sure multi-touch will get fixed. It is likely one reason it has lagged behind is because Apple is sitting there with its legions of lawyers who will sue anybody into the ground who shows 2+ finger controls on anything but their devices.

People cry "fragmentation" when it comes to Android, but other platforms have it too. Windows Phone 7/Windows Mobile has this. iOS doesn't because Apple only has a few models (iPhone/iPhone 3G/iPhone 3GS/iPhone 4/iPad) that developers need to worry about. However, what is gained with that is lost in the fact that Apple is part of the development cycle, with a step of having each update approved. Android is a very quickly evolving platform. It wasn't that long ago that the G1 was the only device running it. Android is going through in about a year and a half of what other platforms have had to evolve though in 5-7 years.

Android's "fragmentation" isn't Google's fault either. A good portion of it can be blamed squarely on some phone makers who deliberately de-function their devices to prevent unofficial OS upgrades.

Java may seem boring, but it does provide two important feature to Android as a platform -- platform independence, so it isn't locked to just the ARM architecture, and security. A rogue app has to crack out of the Dalvik VM, as opposed to be able to attack the OS directly by directly executing CPU instructions. Even after it gets out of the Dalvik VM, it likely won't get past Android's permission structure. Finally, if it does, people will review and report it, and Google will boot it off the marketplace for good.

All and all, I tell people to give Android time if it does not have what they want. For example, I was bellyaching about the lack of encryption for Exchange. While Google is working on an elegant mechanism to solve it, third party apps have addressed this. NitroDesk's Touchdown solves this problem by encrypting mail (with 3DES) as well as attachments stored on the SD card. It also provides a remote kill mechanism to erase all Exchange data which is important in the enterprise (and even to individuals) should a phone get lost/stolen.

Re:Android (1)

gad_zuki! (70830) | more than 3 years ago | (#34683256)

Activesync on Android certainly in encrypted using SSL. Youre complaining about local mail storage, which is a real concern but is far from saying "lack of encryption for Exchange."

Also, remote wiping is built into the Activesync protocol and has been since Exchange 2003 SP2 (October 2005). The issue with it is that certain phone/OS manufacturers decided not to support that part of the spec. Those third party apps aren't adding the feature to the protocol, they are adding what Google and others should have put into their implementation of the protocol.

Windows Mobile phone supported that feature years ago before iphone or Android existed. Your IT department could have standardized on that and had all these features. Don't like the status quo? Blame your phone manufacturer. The protocol isn't at fault.

Re:Android (1)

Nadaka (224565) | more than 3 years ago | (#34678454)

I agree that VS is a fine development environment and c# is a reasonable language, but eclipse is also a fine development environment and java superior to c# in many ways, even if a bit clunkier at times. XML is annoying, and the worst standardized markup language except all the ones that came before it.

Re:Android (1)

JonySuede (1908576) | more than 3 years ago | (#34678980)

S-expression [wikipedia.org] came before XML and IMHO they are superior in every way

Re:Android (1)

Nadaka (224565) | more than 3 years ago | (#34679568)

It was intended as something of a joke, referencing the Churchill quote.

But yes, something like an s-expression would be much more compact. But it would replace closing tag hell with closing parenthesis hell, and while I prefer that hell, I don't think many others would.

Technically I do not think parenthesis are appropriate, linguistically, the contents of a parenthetic enclosure can be omitted without changing the meaning of an expression. When viewed as a collection, parenthesis typically represents a multiset where the order of the contents is not relevant.

Linguistically, chevrons (that can be represented as for standard keyboards) are most appropriate because you are annotating or highlighting the contents. It also makes sense mathematically because chevrons are one of the notations typically used for tuples.

For document markup you probably also want to be able to apply an arbitrary number of attributes to a single collection of elements without repeatedly nesting the enclosing expressions.

I may have given this way to much thought...

Re:Android (1)

Nadaka (224565) | more than 3 years ago | (#34679586)

(that can be represented as <> for standard keyboards)

forgot to use html escapes for the symbols.

Re:Android (1)

badkarmadayaccount (1346167) | more than 3 years ago | (#34720246)

What's more depressing is that most of /. isn't even aware of them, or so it seems.

Re:Android (1)

JonySuede (1908576) | more than 3 years ago | (#34679602)

I agree about the chevron and I may have given this way to much thought too, since for all practical purpose we are stuck in XML closing tag hell

Re:Android (1)

shutdown -p now (807394) | more than 3 years ago | (#34681212)

java superior to c# in many ways

That is interesting. Do you mean the language (in which case it doesn't make any sense whatsoever), or the libraries? If the latter, can you give some specific examples?

Re:Android (1)

Nadaka (224565) | more than 3 years ago | (#34687160)

I mostly mean the differences between the JVM and CLR. Java does have more accurate libraries for math though.

Re:Android (1)

shutdown -p now (807394) | more than 3 years ago | (#34687336)

I mostly mean the differences between the JVM and CLR.

It is still an interesting topic to discuss. JVM beats CLR on optimizations (which does not always equate performance, though), but CLR is waaay ahead on features, so it's not all that clear-cut.

Re:Android (4, Insightful)

Facegarden (967477) | more than 3 years ago | (#34678464)

... Java makes everything isolated, horrible to develop to different versions (your old Android phone doesn't have the latest Java? Too bad, you're out of luck) and forcing the use of XML....

You clearly don't know anything about Android development. Android doesn't rely on Java versions... everything is tied to the Android release. When you code, you can select which APIs you want based on which platform you want to develop for. Want to develop for every android phone every made? Select Android 1.5 APIs. Need something extra (a lot was provided in 1.5 though)? Then select 1.6, 2.1, 2.2, or 2.3. Google provides clear charts of user base, so its easy to know what you're in for.

Also, for XML, I'm less familiar, but isn't the whole point of XML that it is a good general purpose markup language? XML is only used for arranging visual elements on screen - for layout. Web developers will be extremely used to this. I'm used to C# and visual studio's graphical drag and drop interface, so the XML part has held me up, but I don't consider myself a real programmer, so I don't fault android just because I didn't get it right away.

You also drag on multi-touch being crappy on Android, but that's bullshit. I have a Nexus One, and even with an inferior touchpanel driver (everyone uses the much better ATMEL chips now) my Nexus One multitouch performs flawlessly for everything except rotation, which the Nexus One's hardware is to blame for - most every phone made in the last 10 months features the better chips that track fingers even if the axes cross.

So clearly, Android isn't what's faulty if you have multitouch issues, since the OS is quite capable of preforming nicely. You claim to have an HTC Android phone, but that doesn't mean much - for all we know you still have the 2 year old G1. It was never designed for multi touch, so I wouldn't be blown away if it wasn't perfect. The Nexus One was the first Android phone to get multi-touch (Google, it seemed, finally got over the litigation fears), and every reasonable android device after the Nexus One has had great multitouch (I've tried quite a few - Incredible, Droid 2, Droid X, Tmobile G2).

Stop spreading FUD. You don't even know what you're talking about. Yes, some android phones can be crappy. That's the nature of a free OS. It does put extra burden on the consumers to pick a good phone, and sometimes that is bad. Apple's idea of "one phone, it's decent" has a lot of value, but there are plenty of people who want a bigger screen, physical keyboard, etc and just can't use the one iDevice jobs has honed. WP7 is great for allowing multiple devices, but just because Microsoft does something good doesn't mean Android has failed or is terrible. Android is a great platform.
-Taylor

Re:Android (0)

Anonymous Coward | more than 3 years ago | (#34678544)

The original Motorola Droid had multi-touch before the Nexus One was even built. However, it didn't have it in all apps. But the browser, maps, and others had it. Not the day the Droid shipped with the 2.0 version of Android, but once it went to 2.1 it had multi-touch.

Re:Android (1)

Chapter80 (926879) | more than 3 years ago | (#34679498)

XML is only used for arranging visual elements on screen - for layout.

No, XML is a powerful data interchange language too.

Think of the old .INI files. XML can be used like those.
Think of RSS feeds. Hardly just "layout". XML is used for those.

I'm not a huge fan of XML for data exchange (I prefer JSON if possible), but it is fairly readable. Check out the wikipedia article [wikipedia.org] for more info.

Re:Android (1)

Facegarden (967477) | more than 3 years ago | (#34679582)

XML is only used for arranging visual elements on screen - for layout.

No, XML is a powerful data interchange language too.

Think of the old .INI files. XML can be used like those.
Think of RSS feeds. Hardly just "layout". XML is used for those.

I'm not a huge fan of XML for data exchange (I prefer JSON if possible), but it is fairly readable. Check out the wikipedia article [wikipedia.org] for more info.

Ah, yes but I was talking about specifically in android. That Android isn't some frankenstein mixture of XML and Java like the OP sort of implied ("Java, XML and Eclipse sound like a horrible platform for development"), but that the XML is being used just for layout, and is basically being used just like CSS, so its straightforward.

I know XML has other uses and have considered it for a variety of machine readable things I've done, but I think in android they only use it for layout. Actually, I remember now that they use it for storing strings, and some configuration stuff. Really I was just trying to clarify to the OP that all the real coding in Android is Java-based, because he seemed to think it was some horrible mixture of the two. But OP was an idiot.
-Taylor

Re:Android (1)

JonySuede (1908576) | more than 3 years ago | (#34678956)

WOW !!!
what an ms shill you are

Re:Android (1)

Eponymous Coward (6097) | more than 3 years ago | (#34679078)

Extremely professional? What does that even mean? Professional is one of the most meaningless labels to apply to a programmer. It would apply perfectly well to some idiot working for a Fortune 500 company sitting in a cubicle relying on wizards to get them through their day as it would to John Carmack.

And do you really have that much trouble moving between C# and Java? They are roughly equivalent with Java's biggest problem being Oracle. They are far more similar than they are different.

The big problem with developing for Windows Phone 7 is the missing audience. Microsoft has actually lost market share since launch of their most recent mobile OS despite their $100 million ad campaign (only because Apple, RIM, and Google sold so many phones in the last 30 days).

If you think Android is a big fragmented mess, then what do you think of developing for the various versions of Microsoft's phone operating system? Good luck with that. As always, you have to pick the minimum platform that your app needs and that's what you develop for. This is true for any operating system and platform.

A rich ecosystem of hardware vendors is a PITA for developers, but for consumers it means choice. Traditionally this has been what Microsoft has excelled at. This round, Google is taking over this territory and Microsoft is following Apple.

Microsoft! HAH HA HA HAH HA!! (0)

Anonymous Coward | more than 3 years ago | (#34679210)

Windows Phone 7 - You can develop with extremely professional tools like Visual Studio

If anybody actually liked Visual Studio, it would have been ported to a modern platform by now. Instead, nobody cared. When the world moved on, it obviously didn't miss Microsoft's development tools very much.

You people remind me of the the guys who raved about Big Mac on the Apple II or Merlin on the C64. "What a great line editor! And you can assemble and test right in memory!" You know, that was kind of convenient back in 1984, but if you're still holding onto your obsolete dead-end platform 10 years later, maybe the rest of the world knows something that you don't.

WP7 phones also have more strict requirements regarding hardware

i.e. less flexibility; less probabilty that the models that are for sale just happen to be what you're looking for. Slightly convenient for you as a developer, saving you 3% of the development effort, but a disaster as a user. So, how is "fuck the users" working out with regard to the marketshare? Oh right, Windows phones are about as popular as ColecoVisions. Funny how Microsoft can so dominate a market where they got all the share thanks to preloads (desktops) but as soon as there's a situation where users make choices, Microsoft is about as impressive and invisible (except for laughs) as a riceboy's 83 horsepower Honda Civic at the dragstrip.

The grownups are talking about real computers here, little boy. Take the playing card out of your spokes and enjoy your little tricycle for what it is . When you're ready for something a little more serious, it'll all be waiting for you.

Re:Microsoft! HAH HA HA HAH HA!! (0)

Anonymous Coward | more than 3 years ago | (#34680176)

I'm ready to shoot a load of jizz down your throat. Are you still waiting?

Re:Android (0)

Anonymous Coward | more than 3 years ago | (#34679236)

Java makes everything isolated, horrible to develop to different versions (your old Android phone doesn't have the latest Java? Too bad, you're out of luck) and forcing the use of XML..

So wait - MS is supposed to save us from XML? You're either a masochist or you've never had to deal with SOAP if you think that statement has any sense to it.

YOU KNOW, IT'S NOT ALL THAT GREAT (-1)

Anonymous Coward | more than 3 years ago | (#34678224)

HTC makes cheap ass shit. And the OS is for idiots !! Lame-ass SDK if you want to call this google-laid shit an SDK.

If you like this shit, you ARE SHIT !!

Because after all you are what you wear.

Grl

Re:YOU KNOW, IT'S NOT ALL THAT GREAT (0)

Anonymous Coward | more than 3 years ago | (#34679378)

Steve Jobs? Is that you?

Re:YOU KNOW, IT'S NOT ALL THAT GREAT (1)

Gerzel (240421) | more than 3 years ago | (#34679946)

Yeah and they got rid of THACO and the Armor Class rules are fricking backwards! HIGHER armor is better?

It take a WHOLE BOOK? (-1, Troll)

theNAM666 (179776) | more than 3 years ago | (#34678352)

It takes a WHOLE BOOK to show me how to make "Hello World" in Android? O-M-F-G.

What is this 'hello World' coming to?

Re:It take a WHOLE BOOK? (0)

Anonymous Coward | more than 3 years ago | (#34678602)

try RTFA douche

Re:It take a WHOLE BOOK? (0)

theNAM666 (179776) | more than 3 years ago | (#34678914)

Troll? I may be a karma whore, but I'm no troll. And tell me who modded this down... I've got 15 mod points to burn, and ...

Re:It take a WHOLE BOOK? (1)

synaptik (125) | more than 3 years ago | (#34680770)

In this case, you either *were* trolling, or else you didn't RTFA. Your respondents assumed the latter, and your moderator(s) assumed the former.

It is clear from the review that it contains more than just a hello world app (OpenGL ES, SQLite, Sudoku, and multi-touch to name a few.)

Since there isn't a "-1 Didn't RTFA" mod option, I think "-1 Troll" is an acceptable substitute. :) At least, that's how I'd meta-moderate it, if asked.

Re:It take a WHOLE BOOK? (1)

theNAM666 (179776) | more than 3 years ago | (#34681056)

Whatever. It's called sarcasm, which is a linguistic construct you are evidently unable or unwilling to take the time to comprehend, regardless of your UID.

The immediately following post takes the same view as me (or anyone with a sense of humor, or an IQ above 100)-- the summary is terrible, because it says exactly that the book tells you how to write "Hello World," and a poor summary that is contradicted by the article is STUPID.

Otherwise, having been here for well over a decade, I'm pretty much in agreement with those who believe that /. has been invaded by idiots, and the moderation system fails because idiocy is modded up while insight, humor or dissent is often modded down by the abusive, brain-dead morons it allows to be users.

See: http://slashdot.org/journal/239880/Slashdot-moderation-is-awful [slashdot.org]

Re:It take a WHOLE BOOK? (1)

theNAM666 (179776) | more than 3 years ago | (#34734658)

No response from UID 125? Hmm. Let's do this again.

I did RTFA. The summary sucks. The summary is misleading and downright pathetic.

I made a smart-ass comment about it.

-1, "I don't like your opinion" is not one of the options. Under current conditions, things do not "work out." People who post pointed, dissenting opinions will get modded down consistently.

Of course, all one needs to do to restore karma in return, is post better stupid jokes at the top of threads-- just being careful that they don't step on and consistituency's fragile toes.

Fuck that. But /. is edging towards the reign of idiots.

Good review, bad summary (5, Informative)

ashidosan (1790808) | more than 3 years ago | (#34678472)

"this book aims to give the user the equivalent of a "Hello, world!" application in Android and succeeds in doing that but doesn't take the reader much further"

From the review, the book does the following:
1. Hello World
2. Create a Sudoku game
3. Play video and audio using Android MediaPlayer
4. Add music to previously mentioned Sudoku
5. PreferenceActivity API
6. WebKit wrapper for displaying HTML content
7. Android sensor types (GPS, accelerometer, and so on)
8. SQLite on Android
9. OpenGL ES
10. Multitouch on Android
11. Widgets and live wallpapers
12. Analysis of platform fragmentation
13. Android Marketplace

How is that not "much further" than a Hello World app? That sounds like most of the information an Android developer needs.

Re:Good review, bad summary (4, Interesting)

whoop (194) | more than 3 years ago | (#34679008)

Also, the book "only" really talks about developing in Eclipse. I mean, there are at least 50,000 other possible editors/IDEs. Why not talk about each of those too? The reviewer has quite a few personal beefs it would seem. Google provides the most support, easiest setup, etc for Eclipse. So, for one new to Android, that makes good sense to start with Eclipse. Any programmer worth a couple nickels should be able to translate what they learn to other IDEs.

I found a funny item of note on Amazon's page. In the "Formats" section, I clicked the plus for other formats. The previous edition (2009) can be bought new from $976.98. I'll jump on that!

Android is a Pain in the Ass to Code for (0, Informative)

Anonymous Coward | more than 3 years ago | (#34678488)

I tried to get Eclipse and Android's SDK one day to try my hand at writing "hello world".

What a mess. A ton of programs to download and install. Some of them had trouble running in Windows 7 (64) and others just never really worked right. The end result is that I spent 8 hours trying to write "hello world" until I finally gave up.

My $50+ Android development book collects dust as I contemplate my next move. I'll probably either dual boot Linux or run it in a virtual machine. Hopefully Google cares more about Linux than they do about Windows.

Does anyone have any advice for getting an Android development environment working?

Re:Android is a Pain in the Ass to Code for (1, Troll)

binarylarry (1338699) | more than 3 years ago | (#34678560)

Sounds like this is the first time you've ever written software?

Re:Android is a Pain in the Ass to Code for (0)

Anonymous Coward | more than 3 years ago | (#34678664)

>> Does anyone have any advice for getting an Android development environment working?

Yes. Learn programming.

Re:Android is a Pain in the Ass to Code for (4, Insightful)

Tr3vin (1220548) | more than 3 years ago | (#34678794)

It has worked just fine for me on every environment I have tried it on (Win7 x64, OSX 10.6, various versions of Ubuntu.) It also didn't require me to spend 50 dollars on a book that wouldn't have much more information than the official developer site [android.com] .

Re:Android is a Pain in the Ass to Code for (1)

ErikZ (55491) | more than 3 years ago | (#34756752)

The book is less than 19$.

Re:Android is a Pain in the Ass to Code for (1)

Tr3vin (1220548) | more than 3 years ago | (#34757748)

I was referring to the $50+ figure that the AC listed. Still, free documentation is better. Maybe some of these books are good for a starting point, but I almost always end up using the official docs. Most of these mobile and web 2.0 books look like a quick way to make a buck, providing basically the same information that the original authors of the software provide.

Re:Android is a Pain in the Ass to Code for (0)

Anonymous Coward | more than 3 years ago | (#34679022)

Are you serious?

http://developer.android.com/sdk/eclipse-adt.html#installing

They even give you links to each thing you need install.

In a nutshell:

Install Eclipse
Install Android SDK
Install ADT Plugin for Eclipse

The instructions on that site have worked perfectly for me on XP, Windows 7-32 and Windows 7-64. Asusming you have broadband internet, it shouldn't take you more than 30 minutes to install everything and crank out your first hello world application (http://developer.android.com/resources/tutorials/hello-world.html )

Re:Android is a Pain in the Ass to Code for (0)

Anonymous Coward | more than 3 years ago | (#34679282)

Sorry, I didn't explain the problems I was having properly. I'm not able able to get the Android virtual device to run or be recognized on by Eclipse.

Step 3 of your nutshell explanation didn't work for me. If anyone knows how to fix the problem I've described I'd appreciate it.

The fact that other people were able to get it working without any trouble is encouraging to me. I'll try again the next time I have a bit of free time.

Thanks!

Re:Android is a Pain in the Ass to Code for (0)

binarylarry (1338699) | more than 3 years ago | (#34679778)

Way to make me feel like a dick for my previous post, dick.

Re:Android is a Pain in the Ass to Code for (0)

Anonymous Coward | more than 3 years ago | (#34698348)

Having recently set up the Android SDK I wonder why Google don't release a single package with a customized Eclipse and the SDK. If you're unfamiliar with Eclipse just knowing which package to download can be a bit overwhelming. Compared to that, Apple's single Xcode install is a lot easier.

Re:Android is a Pain in the Ass to Code for (1)

vsage3 (718267) | more than 3 years ago | (#34679806)

You will need a new-ish (core 2 or better, probably) computer to even run the emulator. Download the SDK and Eclipse and then set yourself up to test on your phone and save yourself a lot of grief. http://developer.android.com/guide/developing/device.html [android.com]

Re:Android is a Pain in the Ass to Code for (1)

whoop (194) | more than 3 years ago | (#34680432)

Hardly. I set everything up on my EeePC (Atom 1.6GHz CPU, 2GB RAM, WinXP). It takes a bit to start up, but it was certainly workable when I had a video card go out on my main PC. Just follow the Eclipse setup howto Google provides and it worked just fine.

Re:Android is a Pain in the Ass to Code for (0)

Anonymous Coward | more than 3 years ago | (#34690122)

core 2 isn't very "newish". It's over 4 years old now.

just in time for Gingerbread (1, Troll)

SuperBanana (662181) | more than 3 years ago | (#34678746)

The third edition of Hello, Android brings the book up to date on Android versions from 1.5 to 2.2 (FroYo)

Perfect. Just in time for gingerbread, which just hit the market a few weeks ago with the Nexus S.

Doing a reset on my phone (trying to cure a number of problems, like not being able to type from the homescreen to start a search, and general ass-slow performance) a few days ago showed the sad state of affairs of the Android platform. Virtually none of the installed applications, including a number of Google apps, retained their settings...which were supposedly backed up "in the cloud" (yes, I have always had such options enabled.) Application preference backup was provided in a new API in Froyo, and apparently not even Google is taking advantage of their own API.

Hell, even my system preferences changed; I started getting notifications about open Wifi points (had been disabled), my screen brightness changed, etc.

Re:just in time for Gingerbread (1)

jiteo (964572) | more than 3 years ago | (#34678870)

I think your problem is a defective phone, not Android...

Re:just in time for Gingerbread (1)

Anonymous Coward | more than 3 years ago | (#34678898)

Hell, even my system preferences changed; I started getting notifications about open Wifi points (had been disabled), my screen brightness changed, etc.

Since when does (or should) a 'factory reset' preserve your personal customizations to the system settings? That seems a bit counter productive, really.

Re:just in time for Gingerbread (1)

Eponymous Coward (6097) | more than 3 years ago | (#34679104)

The GP expected his settings to be backed up in the cloud. I also thought this to be true. Resetting the phone (which doesn't reset the hardware id numbers) should restore from the cloud, no?

Re:just in time for Gingerbread (0)

Anonymous Coward | more than 3 years ago | (#34679248)

The only reset I'm familiar with in Android is a factory reset. To me, the idea is to return it to the original packaging condition, useful for resale, gifting, etc. Why would your preferences be preferable to someone else using the phone?

Re:just in time for Gingerbread (2)

DeathFromSomewhere (940915) | more than 3 years ago | (#34681442)

Factory reset disassociates the phone from your google account (among other things), which would nicely prevent the phone from restoring the cloud settings. Signing in to the same google account should bring the cloud settings back.

Thanks Captain Obvious! (1)

SuperBanana (662181) | more than 3 years ago | (#34682662)

No shit, really? I never thought to try that! Good thing you suggested it! I was just going to use my google phone without signing into any google services!

Re:Thanks Captain Obvious! (0)

Anonymous Coward | more than 3 years ago | (#34682696)

Maybe you should have read the thread before making stupid comments you would regret.

Re:just in time for Gingerbread (2)

Gaygirlie (1657131) | more than 3 years ago | (#34680634)

I also thought this to be true. Resetting the phone (which doesn't reset the hardware id numbers) should restore from the cloud, no?

It's actually quite counter-intuitive to restore all settings from the cloud after doing a factory reset: in most cases people do factory reset exactly because there is something wrong with the settings and no other way of resetting them. If it just restored those settings after the reset it would all have been for nothing.

Though, I agree that it should be stated more clearly what actually gets stored in the cloud and what doesn't.

Android 3 already? (1)

clone52431 (1805862) | more than 3 years ago | (#34678944)

I thought it wasn’t due till 2011... [wikipedia.org]

(Yeah, I know. Just pointing it out... I thought the headline was pretty misleading.)

300 pages? (1)

pedantic bore (740196) | more than 3 years ago | (#34679372)

Three hundred pages to cover a "hello world" app and not "take the reader much further?"

Good lord, there must be a better programming platform for android than this. For comparison, the entirety of K&R is only 274 pages!

Re:300 pages? (3, Funny)

Chapter80 (926879) | more than 3 years ago | (#34679520)

Three hundred pages to cover a "hello world" app and not "take the reader much further?"

It's actually "Hello World", greeting each of the 7 Billion people individually.

Re:300 pages? (1)

pedantic bore (740196) | more than 3 years ago | (#34679722)

I wish I could mod you up.

Beware of android (-1)

Anonymous Coward | more than 3 years ago | (#34679766)

My fellow brothers do not run android on your phone as it has not received the coveted 'nigger-free code' certification from the Klean Komputing Korporation, or KKK for short. If you run any version of android that lacks this you open yourself up to malware, AIDS, and the chances of having your aryan princesses raped and murdered by nigger thugs. YOU HAVE BEEN WARNED!

Thanks (2)

DurendalMac (736637) | more than 3 years ago | (#34681796)

As someone who is looking to get an app up and running on Android, I'd just like to say thanks as this book looks like it will be a huge help. Yes, you can monkey around online, but it's so much handier to have a full tutorial in one place that you can chop through. I just ordered it via Amazon. Here's hoping it helps me get this thing done (or at least to beta) within the next few months!

After reading much of thread, and reviews (0)

Anonymous Coward | more than 3 years ago | (#34682824)

I bought it. I put my money where my post is.

pop music, pop caps, champion caps (1)

hennyjack (1933170) | more than 3 years ago | (#34683848)

nfl jerseys [jerseysshopsonline.com] , wholesale jersey [jerseysshopsonline.com] , cheap jersey [jerseysshopsonline.com] , football jerseys [jerseysshopsonline.com] , nba shop [jerseysshopsonline.com] , nfl jersey [jerseysshopsonline.com] wholesale jersey [jerseysshopsonline.com] cheap jersey [jerseysshopsonline.com] nba shop [jerseysshopsonline.com] nfl jersey [jerseysshopsonline.com] nba shop [jerseysshopsonline.com] football jerseys [jerseysshopsonline.com] winter cap [popbrandcaps.com] , red bull cap [popbrandcaps.com] , monster hat [popbrandcaps.com] , music hats [popbrandcaps.com] , dc winter cap [popbrandcaps.com] , winter cap [popbrandcaps.com] red bull cap [popbrandcaps.com] monster hat [popbrandcaps.com] music hats [popbrandcaps.com] dc winter cap [popbrandcaps.com] music Hats [popbrandcaps.com] red bull caps [popbrandcaps.com] winter caps [popbrandcaps.com] http://www.jerseysshopsonline.com/ [jerseysshopsonline.com] Our email:jerseysshopsonline@hotmail.com http://www.popbrandcaps.com/ [popbrandcaps.com] Our email:popbrandcaps@hotmail.com

Book is the wrong medium (1)

ThatsNotPudding (1045640) | more than 3 years ago | (#34685078)

For Android, a monthly magazine would be more appropos.
I've given up on keeping track as to how many versions of Android are now in the wild, but I think the number is equal to the number of greedy bastard, lock-down, carrier CEOs.

Fashion gife, fashion life (1)

hennyjack (1933170) | more than 3 years ago | (#34696374)

music caps [voguecaps.com] , red bull caps [voguecaps.com] , monster caps [voguecaps.com] , music caps [voguecaps.com] red bull caps [voguecaps.com] monster caps [voguecaps.com] music caps [voguecaps.com] red bull caps [voguecaps.com] monster caps [voguecaps.com] LV handbags [handbagsexport.com] , Hermes Handbag [handbagsexport.com] , Fendi handbag [handbagsexport.com] , LV handbags [handbagsexport.com] Hermes Handbag [handbagsexport.com] Fendi handbag [handbagsexport.com] LV handbags [handbagsexport.com] Hermes Handbag [handbagsexport.com] Fendi handbag [handbagsexport.com] mac 180 color eyeshadow [sellingmac.com] , mac wholesale [sellingmac.com] , mac makeup [sellingmac.com] , mac 180 color eyeshadow [sellingmac.com] mac wholesale [sellingmac.com] mac makeup [sellingmac.com] MAC 9 color eyeshadow [sellingmac.com] MAC 12 color eyeshadow [sellingmac.com] MAC 21 color eyeshadow [sellingmac.com] http://www.sellingmac.com/ [sellingmac.com] our email:sellingmac@hotmail.com http://www.voguecaps.com/ [voguecaps.com] our email:voguecaps@hotmail.com http://www.handbagsexport.com/ [handbagsexport.com] our email:handbagsexport@hotmail.com
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?