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!

Android Application Development

samzenpus posted about 5 years ago | from the read-all-about-it dept.

Android 74

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

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

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

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

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

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

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

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

You can purchase Android Application Development: Programming with the Google SDK from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

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

for android users: (4, Informative)

poetmatt (793785) | about 5 years ago | (#29721907)

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

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

Re:for android users: (1)

dada21 (163177) | about 5 years ago | (#29722637)

+1 on this.

My G1 runs incredibly well and consistently with CM + Enoch. I can't believe what a difference it is from my corporate phone (identical G1 but running T-Mobile's latest ROM).

Re:for android users: (1)

poetmatt (793785) | about 5 years ago | (#29722977)

damn, what company do you work for that lets you have a G1 for a corporate phone? I'm stuck at a workplace that sticks with blackberry only, etc.

Re:for android users: (1)

Nerdposeur (910128) | about 5 years ago | (#29723233)

That's because a BlackBerry lets them control their company data. And decide to allow/deny every little function of the device.

Unfortunately, with phones, fun != good for business. Though they sometimes overlap.

Solidity of the platform? (5, Insightful)

BadAnalogyGuy (945258) | about 5 years ago | (#29721975)

The one really big hurdle which Android faces and which WinMo and iPhone have worked around is the problem of a moving target. Since Android is a work in progress, with OEMs deciding which version to release, there is only a core set of functionality that could be expected to exist across all versions on all phones. Now, this core set of functionality may be very large and useful, but without a rigorous breakdown of the differences between devices it still feels like a crapshoot.

Attention to this "always in beta" aspect of developing on the Android platform would have been nice. Of course, Google just wants people developing apps and not worrying about how things may change. Unfortunately, this is a serious concern for developers of enterprise applications, and it may end up being Android's Achilles Tendon in the long run.

Re:Solidity of the platform? (0)

Anonymous Coward | about 5 years ago | (#29722027)

here is only a core set of functionality that could be expected to exist across all versions on all phones. Now, this core set of functionality may be very large and useful, but without a rigorous breakdown of the differences between devices it still feels like a crapshoot.

Unlike, say, the myriad revisions of the iPhone and iPod touch with hugely different hardware capabilities? With Android, at least you know you've got a phone, mic, camera, almost certainly GPS, etc.

RAM is probably the bigger issue. IIRC, the Samsung Galaxy has a pretty meager 128MB, even though it's only slightly cheaper than the HTC Hero with 288MB.

Re:Solidity of the platform? (1)

poetmatt (793785) | about 5 years ago | (#29722415)

You don't really need ram. With a swap and storing apps on the SD card, the ram just makes the OS run smoother. Rooted, my phone runs just as smooth as hero (and can run the hero build).

Of course the hardware will result in continual improvements to performance, but the ram by itself doesn't do what people think it does in this case.

Re:Solidity of the platform? (1)

oakgrove (845019) | about 5 years ago | (#29725819)

Here's the issue with the RAM on my G1 and of course I'm running Cyanogenmod. I have Debian on it in a bootstrap environment. In order really use it, I need to first start it up in the terminal, start some Window manager inside of debian and get vncserver going. Then I start the vncviewer on Android to be able to see the desktop. About the time I start a program in debian, the phone runs out of RAM and the terminal gets killed. There goes debian, et al. More ram would cure that problem. Also, Opera gets closed a lot and since it doesn't implement best practices correctly, i.e. when it is restarted, it goes to the default home page instead of resuming on the page it left off like any good Android program should. I'd also like to at least have the option of running some fatter binaries.

Of course, I have a swapfile but this only takes you so far in Android. If the swap file is too big, the OS starts swapping itself into it. Consequently, it slows down to a crawl. So, yes, Android devices do need more RAM. And the more the better.

Re:Solidity of the platform? (1)

poetmatt (793785) | about 5 years ago | (#29727661)

you're trying to run debian on the droid. Until we have some better ARM accelerating that in itself is quite hard. Custom firmware is different than straight up debian.

I agree more ram is better period but you know, there are better mobile devices for that purpose. Plenty.

Re:Solidity of the platform? (1)

oakgrove (845019) | about 5 years ago | (#29734089)

Respectfully, I'm not sure if I am understanding you correctly but if you are saying that Debian is running in the Dalvik VM, that would be incorrect. It is running just like it would run bootstrapped on any Linux box. And according to my benchmarks, it runs as fast as you would expect it to given the particulars of the hardware. It just runs out of RAM and gets puked out by the Android runtime life cycle.

Re:Solidity of the platform? (1)

jcr (53032) | about 5 years ago | (#29722509)

myriad revisions of the iPhone and iPod touch with hugely different hardware capabilities

Myriad? There are a handful of variants of each, and they're all capable of running the latest version of the OS. Older iPhones don't have GPS, but their location sensing still uses the same API, you just don't get as accurate a reading as you do with the the new ones.

-jcr

Re:Solidity of the platform? (1)

alen (225700) | about 5 years ago | (#29722571)

every iphone and ipod touch runs the latest OS. only difference is touch users have to pay for a major release.

my wife's iphone 3G came with 2.1 and i'm going to upgrade it to 3.1.2 soon because some apps are requiring 3.1 at the minimum due to new functionality introduced.

Re:Solidity of the platform? (1)

rxan (1424721) | about 5 years ago | (#29722225)

Actually, applications developed on earlier API levels (as Android calls them) are always forward compatible with newer API levels. Sure, APIs may be deprecated and replaced with newer interfaces, like any platform, but it won't cause your app to break as you are implying.

With the new Android SDK things like different screen sizes are being allowed, which I consider a boon. The one thing that always bugged me about BlackBerry was the different screen sizes and device capabilities. Now Android developers have the same thing to worry about. Bah... It's the one thing that Apple did right: keep the core platform identical and you save developers a lot of hard work.

Re:Solidity of the platform? (1)

salesgeek (263995) | about 5 years ago | (#29723891)

Actually, Android's "always in beta" has been a boon for users. The package management system is a boon for developers. I bought my phone nearly one year ago and periodically it tells me there is a system update. After the update things are usually much better. It shouldn't be a concern for enterprise developers familiar with developing for Linux - upgrades are handled very automatically, and distributing and installing software is easy. It really isn't much more different than writing for any stack - where most enterprise programs head south is when they take shortcuts and do silly things like assume since the corporate standard is 1024x768 to design the gui for 1024x768 only. If anything diversity of hardware will be a boon for Android, just like it was for PCs.

BTW - if your expectation of a new kind of platform (connected smartphone) is that there be no change in APIs, do us all a favor and retire now. The platform has a lifetime of less than two years (cell phone contracts force upgrades and change) - it's time to stop expecting it to work like Windows XP.

Re:Solidity of the platform? (1)

0xdeadbeef (28836) | about 5 years ago | (#29724925)

The one really big hurdle which Android faces and which WinMo and iPhone have worked around is the problem of a moving target.

What does this mean? Do you have any understanding of what you're talking about? Please explain to us how these other platforms "worked around" this issue.

Re:Solidity of the platform? (1)

recharged95 (782975) | about 5 years ago | (#29725103)

Beta doesn't have an impact when you're constantly downloading 2.7GB Xcode-based SDKs that change from version 3.1.1 o 3.1.2 (from the current leader in the smart phone market). Even MSVS makes you wait a year before downloading a few gigs of IDE, not per version of the OS.
Having to download Eclipse IDE (not the full version) and a plugin is refreshing to the developer and the way it should be done.

Re:Solidity of the platform? (1)

mjwx (966435) | about 5 years ago | (#29727137)

The one really big hurdle which Android faces and which WinMo and iPhone have worked around is the problem of a moving target. Since Android is a work in progress, with OEMs deciding which version to release, there is only a core set of functionality that could be expected to exist across all versions on all phones. Now, this core set of functionality may be very large and useful, but without a rigorous breakdown of the differences between devices it still feels like a crapshoot.

Attention to this "always in beta" aspect of developing on the Android platform would have been nice. Of course, Google just wants people developing apps and not worrying about how things may change. Unfortunately, this is a serious concern for developers of enterprise applications, and it may end up being Android's Achilles Tendon in the long run.

Parent does not understand nor has used Android.

Android is no longer in beta, its a finished product. Android is always improving which presents some of the issue you describe but not many. What you'll find is that across different android phones there are a great deal of similarities, its like comparing a Windows laptop made and configured by Dell to a Windows laptop made and configured by Lenovo. Both use the same OS but change the default programs, use a different interface for connecting to wireless networks and have a different default background, this has not presented an issue with selling laptops.

Android is not an open platform (0, Redundant)

douglas.barton (1643183) | about 5 years ago | (#29722077)

Android is not an open platform. It may be free(as in beer), but it is not fully free(as in freedom). Anyone ever tried starting up their G1 phone while out of network coverage after a hard reset. OUCH.

Re:Android is not an open platform (3, Informative)

douglas.barton (1643183) | about 5 years ago | (#29722235)

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


/end excerpt


Support a true honest open platform, support angstrom: http://www.angstrom-distribution.org/ [angstrom-d...bution.org]

Re:Android is not an open platform (0)

Anonymous Coward | about 5 years ago | (#29722469)

So it's not completely built on standard software and doesn't use a license as restrictive as the GPL.

It's still open source and anybody can develop for it. That sounds like an open platform by any reasonable definition.

Re:Android is not an open platform (0)

Anonymous Coward | about 5 years ago | (#29726497)

I'm not sure what the list of Wikipedia criticisms that you listed have to do with the openness of the Android platform.

The first criticism, that Android's license allows for vendor-controlled market places, doesn't seem to have anything to do with openness. I could release my own version of Debian that replaces with the APT system with my own software that only lets users download binaries that I approve. Does that mean that Debian isn't open?

Let's see:
    - It's not a conventional Linux distribution: sure, but neither is Hurd and I hear that is supposed to be open
    - It doesn't use Java ME: That's not surprising considering its licensing restrictions (http://www.betaversion.org/~stefano/linotype/news/110/)

The rest are just complaints about performance, driver scarcity, etc. and don't have anything to do with openness.

Re:Android is not an open platform (1)

porl (932021) | about 5 years ago | (#29730645)

you know, i didn't check who posted that wikipedia article and assumed that it was someone showing the previous poster that it was the companies releasing the phone, not the platform that wasn't 100% open. hahaha he rebutted his own post! :D

Re:Android is not an open platform (0)

Anonymous Coward | about 5 years ago | (#29722255)

The platform is open. The distribution on the G1 as customized by T-Mobile and Google requires you to jump through hoops.

Re:Android is not an open platform (1, Interesting)

douglas.barton (1643183) | about 5 years ago | (#29722477)

This is true, and will be the same story with the other carriers as well. Shall we see what happens when the Sprint Hero starts to hit.

Android is not open, parts of it are still locked down. Not even the SDK is open. How is it that all of the carriers all have their own flavor planned, and all of which are going to create limitations for the consumer, not empower them. This is the same system we are both talking about right? OH wait, AT&T must have a pure android flavor planned right? they are going to let you use tethering and VOIP, and incur no additional charges right? bullshite.

Google is too big, and they have revenue at heart. Google will be the killer of the FOSS spirit. I cant wait till I have the ability to view some ads on my Goobuntu box, it will be much better then that old Ubuntu system.

As if developing for this platform is truly going to benefit much more than those carriers that will continue the same process.

You might as well go dev for Microsoft's WM.

We need a middle point for us to market our wares yes, but not within the limitations created by giants such as Google and phone carriers. What strength they bring, creates a great weakness for the community.

Re:Android is not an open platform (1)

oakgrove (845019) | about 5 years ago | (#29726393)

I understand what you are saying and all but as far as Android goes, it is open source. You can go right now and download the source code, compile it for the device of your choice, sell millions of them with a high quality OS and not pay a dime in licensing costs. You can't say that for WinMo or whatever else. Maybe Symbian, I haven't looked. People like Cyanogen, Hikaru, etc., can go and get it, tweak it out the wazoo and as long as they aren't distributing closed source apps with it, can release it to anybody they want with root, tethering, multi-touch, and everything else. So, that works for me. That's seems pretty open to me.

To me the real issue is the proprietary hardware and binary blob kernel modules that the handset manufacturers are releasing to make the handsets work. That's really what keeps you in lockstep with the officially blessed Android releases more than anything else. What if I don't want the 2.6.29 kernel that came on my G1. What if I want to use the 2.6.31 that just dropped. What if in 10 years I pick my G1 off the shelf and want to put the 3.6.31 kernel on it. I can't because if I do the touchscreen won't work. The wlan won't work. Who knows what else won't work. And Nokia does the same thing with their Maemo tablets. I have a 770 that I'd love to actually be able to do cool stuff with. I would like to put stock debian on it but, last I checked, half the hardware doesn't work. In fact, the only open phone I know is the Openmoko and we all know how that is working (worked) out. We just read a big story a couple of days ago about routers with dd-wrt, et al, that appear open until you realize you are stuck with the 2.4 blessed kernel because anything else and sure enough, the damn things don't work.

Anyway, I'm rambling but for the tl;dr folks, to me these "open" phones are not really open if I can't get open drivers for all of the useful hardware.

Re:Android is not an open platform (0)

Anonymous Coward | about 5 years ago | (#29728045)

What binary blob kernel modules? Have you looked at the kernel source for G1/Dream? There are none.

http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog;h=refs/heads/android-msm-2.6.29-donut

Touchpanel driver is in there along with most other stuff.

The wifi driver is in another repository, but it's also open source. And there's a complete rewrite of it (done by some folks at Nokia) going into mainline.

Proprietary software included on G1/Dream (all userspace):
- htc ril (radio interface library), just glue between a tty modem control driver and the rest of the telephony stack
- hw gl library (typical for hw gl stacks to be closed, sadly)
- akmd (does "secret sauce" postprocessing on compass/accelerometer, you could replace it -- the actual hardware driver itself is GPLv2)
- hw video encode/decode support (can live without 'em in most cases)
- google apps (gmail, maps, etc)

I mean, you can gripe about a lot of stuff, but I'm perplexed at people who keep insisting that drivers that are open source aren't.

Re:Android is not an open platform (1)

oakgrove (845019) | about 5 years ago | (#29728353)

Fair enough. I don't have time to follow your link now so I'll take your word for it and stand corrected. However, how come if there are no binary modules holding them back, why is it that all of the mods like Cyanogen, etc. always use the default 2.6.29? I really am curious.

Re:Android is not an open platform (1)

mjwx (966435) | about 5 years ago | (#29727307)

This is true, and will be the same story with the other carriers as well. Shall we see what happens when the Sprint Hero starts to hit.

This is not true. Here in Australia I've been able to start my HTC Dream (G1 for you yanks) outside Three's (Hutchinson telco in Australia) coverage, both in zero coverage and roaming coverage.

The rest of your post is pointless complaining. APK's from any source can be installed bypassing telco app control and an android rom can be replaced with a community ROM if the default one is not good enough. Android is a lot more open then WinMo, Symbian and they are a lot more open then iphone.

Re:Android is not an open platform (1)

vxvxvxvx (745287) | about 5 years ago | (#29724075)

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

Re:Android is not an open platform (2, Informative)

mjwx (966435) | about 5 years ago | (#29727327)

Disclosure: Android owner in Australia.

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

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

O'reilly books (3, Informative)

dslbrian (318993) | about 5 years ago | (#29722311)

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

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

Re:O'reilly books (1)

frogola (676494) | about 5 years ago | (#29723389)

I agree, it's been many years since O'Reilly books were consistently excellent. My first disappointment was 'Security Warrior'. They still have may good titles, though.

Re:O'reilly books (0)

Anonymous Coward | about 5 years ago | (#29727043)

Unconfirmed Errata: third sentence, "They still have may good titles, though." now reads: "They still have many good titles, though."

Question (1)

kdogg73 (771674) | about 5 years ago | (#29722351)

When one develops for a mobile platform, is there a basic screen size/resolution/ratio (HD 16:9-4:3) you shoot for? I mean what are the specs? Is there a recommendation? I always wondered if this would be an obstacle with Android and the multiple devices.

Re:Question (0)

Anonymous Coward | about 5 years ago | (#29732141)

http://developer.android.com/guide/practices/screens_support.html

Google != Android (3, Insightful)

dada21 (163177) | about 5 years ago | (#29722473)

Just a reminder: Google and Android are not affiliated in any way any longer except that Google is a member of the Open Handset Alliance (OHA).

Google bought Android the company, developed Android the OS, then spun it off under control of the OHA, in which they are one participating member.

When a phone company develops hardware using Android, the operating system is open source/freely available. They can customize it. But if they want to bundle applications on it, say Google Maps, they have to license those apps from Google. Android is not Google, Google is not Android.

For what it's worth, I run a G1 with Cyanogen's latest mod. I have no Google apps that I care about anymore.

Re:Google != Android (0)

Anonymous Coward | about 5 years ago | (#29722733)

Not even Google Maps? Do you not use maps, or do you use another solution?

Re:Google != Android (1)

FunkyELF (609131) | about 5 years ago | (#29722747)

Do you use maps?... what do you use?
Do you use mail?... what do you use?

Re:Google != Android (0)

Anonymous Coward | about 5 years ago | (#29722905)

I like GPSmid [sf.net] a lot. J2ME with embedded Openstreetmap maps, so no data needed, and it does routing. It might be possible to port it using j2mepolish, but haven't seen that working yet.

Re:Google != Android (2, Interesting)

douglas.barton (1643183) | about 5 years ago | (#29722797)

OpenHandsetAlliance = Google + Network Carriers + Hardware Manufacturers;

peoplesChoice = People + OpenMeshPoint2PointNetwork + OpenSoftware + OpenHardware;

Start making it, or Microsoft/Danger says "all your data are belong to us"

Re:Google != Android (2, Interesting)

FooAtWFU (699187) | about 5 years ago | (#29723201)

Open software / hardware, sure, lovely.

And the "open mesh point-to-point network" idea is cute too, but doesn't work so well for VOIP and voice (too many hops, ick!) and doesn't work at all unless there's a bunch of people in the area doing it: lots of Silicon Valley hops, sure, but how do you string over the mountains even to a place as close as Santa Cruz? and what's the point if you can't ?

So I don't see that replacing my network carrier any time soon. Mesh-huggers. Gaah.

Re:Google != Android (2, Interesting)

douglas.barton (1643183) | about 5 years ago | (#29725053)

That should have read: Mesh+P2P. The details of such could not be spelled out within this comment box.
Just as our modern "Free" internet is, a new wireless network would have to operate on a variety of technologies. A mesh would actually work out great for metro areas in terms of simple data, handset to handset, but there would have to be more powerful fixed site connections to allow continuity across the lager scope of the project. There is a Ukrainian guy who made a nice point to point with (i think) off the shelf parts. Its a Point to Point laser bridge.

Who needs net neutrality. We are the net.

These things we speak of however, are as most would say something like "out of the realm of possibility even for a group of autonomous people and their distributed development processes".

Anyone have any good links to this nature?

Re:Google != Android (1)

Karpe (1147) | about 5 years ago | (#29728505)

I believe Santa Cruz Operation is not supported. :)

Re:Google != Android (0)

Anonymous Coward | about 5 years ago | (#29722833)

Google does the lion's share of Android development, decides what goes in or is left out, keeps release schedules secret, ... Regardless of what you say, Google still practically owns Android.

Re:Google != Android (1)

farble1670 (803356) | about 5 years ago | (#29728191)

doesn't every app the uses the google (map) SDK require the google components? that's a large percent of the apps. AFAIK, there's no replacement for things like the google SDK, and even if there was, nobody is writing software to utilize it.

regardless. cyanogen != no google. in 5 steps you can get the latest cyanogenmod with google components, in a google-approved manner.

fagoRz (-1, Offtopic)

Anonymous Coward | about 5 years ago | (#29722787)

Review Needs and Editor (0)

Anonymous Coward | about 5 years ago | (#29722851)

For someone scrutinizing repetitious repetition, this review certainly repeats many points repeatedly.

Ummm...NOT Open Source (-1, Troll)

ReverendDC (1547301) | about 5 years ago | (#29722973)

It's only open source until Google decides that they don't want someone else using the "Open Source" code and files a court injunction as was done last week. If you are going to bash, bash evenly. Google deserves your ire as well.

Re:Ummm...NOT Open Source (1)

MozeeToby (1163751) | about 5 years ago | (#29723067)

The OS is open source, some of the Apps are not. It's no different than some developing a closed source app for Linux and expecting to be paid for it, which is perfectly in line with every open source licensing system in the world.

Re:Ummm...NOT Open Source (1)

ReverendDC (1547301) | about 5 years ago | (#29724989)

If you advertise that your system is open source, you should be advising that the system contains closed source software or remove said software. You should not advertise as COMPLETELY open source. It isn't. While you are right, at the same time, if you remove the closed source apps, the OS and phone is almost useless, and doesn't operate anywhere near advertised. This makes major portions of the operation of the phone as closed source. It's legal, just immoral. If Google was really committed to open source, Android would include a barebones email system, maps, etc, and leave the option for closed source downloads through their app store. The shocking part about that whole business for many non-IT professionals was not the fact that Google was heavy-handed, but that not all of the system was open source. Also, remember when Android didn't have a store? That means, although the system was "open source," there was no other programs for some items (MAPS, etc) other than Google's proprietary "stuff," which isn't open source.

Re:Ummm...NOT Open Source (1)

Dog-Cow (21281) | about 5 years ago | (#29725903)

You shouldn't be an unmitigated idiot and asshole, but you are.

Sometimes shit happens.

Re:Ummm...NOT Open Source (1)

ReverendDC (1547301) | about 5 years ago | (#29771225)

You cuss me out after calling me an unmitigated idiot. Classy. Intelligent. Definitely not idiotic at all.

You're right. Sometimes ish does in fact happen. For mentioning this ish, you decide to personally attack me. You don't make any argument about the point and in fact conceded the validity of my statement by saying "Sometimes shit happens."

Stay classy, Dog-Cow.

Since I disagree with your viewpoint and you have no counter-argument, you sir or ma'am have shown yourself to be the close-minded, unmitigated idiot in this discussion. I cannot comment on your personality as I have never met you, as you have made the assumption about mine with the comment of "asshole."

If you have an issue, please, by all means, refute with facts and an argument so that these cogent points can be reviewed. Otherwise, I guess the rest of the crowd on this site sees fit to hound and pursue anyone that disagrees with an opinion if you have no cogent response and insult people personally. Next you will probably call me a "fag" because I use words and grammar that are alien to you by the looks of your response.

The fact remains that if there is a system that you advertise as fully open source, then all programs included should also be open source, especially when there is no possibility of changing the included programming to something different.

Re:Ummm...NOT Open Source (4, Informative)

mmurphy000 (556983) | about 5 years ago | (#29723103)

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

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

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

If you are going to bash, bash evenly.

Better yet, bash factually.

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

Re:Ummm...NOT Open Source (1)

salesgeek (263995) | about 5 years ago | (#29723695)

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

What? Last week's situation was caused by someone distributing proprietary software that did not have permission. Google could not have stopped Cyanogen had the mod not included Google's proprietary software. Google deserves no ire for their actions, and Cyanogen's response was 100% class. Android is coming of age quickly.

Re:Ummm...NOT Open Source (1)

ReverendDC (1547301) | about 5 years ago | (#29724469)

So what you are saying is that it is okay to advertise something that is partially Open Source as completely open source. It doesn't matter what part was balked at. The fact of the matter is that the way that the system is advertised, it is completely open source. If you put proprietary pieces into place, it is no longer open source by definition, because not all of the code is open for alteration and that part of code is not redistributable. Therefore, Android is just like everyone else's OS, except instead of putting in an SDK and spending money on figuring out ways to keep part of the system closed while opening other parts, you leave the code open for the same things that you would normally make an SDK for and lock down the parts you don't want touched. That's not open source. That is a very efficient and cost effective way to avoid making SDKs. More power to Google for taking this route...but it is NOT open source. Give me a phone where every part of the code is open for alteration and I will see an Open Source phone. Otherwise, Android is JUST like every other system. BTW, with all of the talk of customization, Windows Mobile is almost as customizable after developers get done with it? The iPhone can be jailbroken and heavily customized. While neither of these companies outright ALLOW this, DevTeam and others have been doing it since the cell phone became popular. Basically, without the "Open Source" moniker and a different (not necessarily better) UI, there is no difference between Android and anything else. Therefore, it becomes much more grave of a situation when one of the only selling points for your product is only partially true when no indication had been given as such before. This is called "false advertising." True "open source," such as OpenOffice and Firefox or the huge majority of Linux distros, use ONLY open source software. Everything is code-downloadable, not just the OS or parts of the OS. In addition, with the way that the Google tools interact with the OS, how can you say that it is not in the OS for these parts? You can remove it, and some of the vaunted integration goes away. Splitting hairs is always a way to win an argument, but not one to improve upon products.

I am a co-author... (3, Informative)

Zigurd (3528) | about 5 years ago | (#29724473)

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

Re:I am a co-author... (-1, Troll)

Anonymous Coward | about 5 years ago | (#29725023)

So when is Google/OHA going to shit out a JIT? Because performance on the platform is abysmal compared to an iPhone .. or even.. gasp.. a WinMo - even considering the "Java/Dalvik tax".

Re:I am a co-author... (2, Informative)

Zigurd (3528) | about 5 years ago | (#29725345)

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

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

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

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

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

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

Re:I am a co-author... (-1, Troll)

Anonymous Coward | about 5 years ago | (#29729147)

Yes it is, that's one of the few lingering advantages of J2ME development - that otherwise reeking p.o.s platform has reached "maturity" with its way-ahead-of-time compiling vm:s (e.g. Nokia and SonyEricsson).

Re:I am a co-author... (1)

AmberBlackCat (829689) | about 5 years ago | (#29727125)

It's my understanding that the apps are done in Java, and it's fairly easy to get the source code to a Java program. If this is so, how do people port their commercially viable applications to Android without other people easily ripping off their source code? Does the book cover any better methods of protecting the source code than "obfuscation"?

Re:I am a co-author... (1)

Zigurd (3528) | about 5 years ago | (#29727505)

The book does not cover code obfuscation. I have also not tried obfuscation for Android projects.

Android applications are distributed as archives -.apk files - made mostly of Dalvik bytecode files - .dex files. While you can "dump" a dex file to human readable code, I do not know of a dex to Java decompiler, nor a dex to Java bytecode reverse translator.

This thread in the Android developers group...

http://groups.google.com/group/android-developers/browse_thread/thread/dcc5808b002a47fc?tvc=2 ...includes an Ant script that the is supposed to obfuscate classes in an Android project. This script uses Proguard, which I used back when I was working on mobile games, but mainly to reduce jar file size. You can see in the discussion in that thread that there are some Android-specific issues to watch out for, such as that classes referred to in Android manifest files and the names of View subclasses used in layout files should be excluded from obfuscation.

You can also use native code libraries and JNIs for the code you are most concerned about, if compiling code to ARM instructions seems more resistant to reverse engineering than Davik byte codes.

Re:I am a co-author... (-1, Troll)

Anonymous Coward | about 5 years ago | (#29727193)

Do you have hairy balls?

More (great) Android Books (2, Informative)

cnkurzke (920042) | about 5 years ago | (#29725453)

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

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

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

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

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

Re:More (great) Android Books (1)

joshki (152061) | about 5 years ago | (#29728713)

I like Mark Murphy's subscription format as well -- you get all of them for one fee plus updates for as long as you keep the subscription. They're also great books, and they're how I learned.

App Store? (1)

Doc Ruby (173196) | about 5 years ago | (#29726423)

Once you've built your app, how do you market it on the Google app store? Do you need a license or registration to upload it? How do you upload it? Does it have to be signed or otherwise processed after it's an executing binary? How do you get paid? How do you include a GPL or other license, and the source code if required/desired?

Those details of "development" are going to be the greatest incentive, or inhibitor, to developers. Especially like me.

Re:App Store? (1)

rufus t firefly (35399) | about 5 years ago | (#29726775)

Once you've built your app, how do you market it on the Google app store? Do you need a license or registration to upload it? How do you upload it? Does it have to be signed or otherwise processed after it's an executing binary? How do you get paid? How do you include a GPL or other license, and the source code if required/desired?

Those details of "development" are going to be the greatest incentive, or inhibitor, to developers. Especially like me.

You generate a key and sign your binary. Applicable links would be : http://developer.android.com/guide/publishing/app-signing.html [android.com] and: http://developer.android.com/guide/publishing/publishing.html [android.com]

I recently developed an app for Android. It took a moderate amount of Java programming knowledge and a week or two to crank out a working application (working in my spare time). I figure that's a pretty resounding endorsement of the SDK.

Re:App Store? (1)

mjwx (966435) | about 5 years ago | (#29727221)

Once you've built your app, how do you market it on the Google app store?

Marketing is entirely up to you, there is no "staff pick" or other kind of rigged personality contest. Advertise by any method you see fit, you can even direct link to the Android marketplace by URL or QR code from another web site or even a print or web ad using a QR code. QR codes on Cyrket [cyrket.com] are useful as I can brows the market on my PC and then use a bar code scanner to take my phone straight to the installer page on the marketplace.

Do you need a license or registration to upload it?

A once off US$25 fee is required for listing on the Android Marketplace. This allows for infinite apps to be added. Further more you do not need to use the Android marketplace and can publish the .apk (Android installer) on any web site or other distribution medium.

How do you upload it?

Should be a simple process, I'm certain google will tell you how.

Does it have to be signed or otherwise processed after it's an executing binary?

No. Google do not vet the Marketplace and if they did, Android does not prevent you from installing from other sources. Once you have registered as a developer you can upload applications to the Marketplace.

How do you get paid?

If you are using the Android marketplace provided by google, Google handles the transaction and credits your account. The details of this are part of the registration.

How do you include a GPL or other license, and the source code if required/desired?

That's up to you to comply with the license of the code you are using (or have created). The GPL specifies how the code must be made accessible to the public.

Re:App Store? (1)

joshki (152061) | about 5 years ago | (#29728783)

Just a few nits to pick:

Google does have a "featured apps" section. I'm not sure how they determine what gets featured, but it does exist.

Uploading the binary is as simple as filling out a web form -- just fill in the details, select the binary, and hit submit.

Google does require you to sign your binaries. It's a simple process, it can be done either from the plugin in Eclipse or manually.

Google does vet the app store, just not the same way as Apple does theirs. When you upload an app, you have to verify that you've complied with their TOS for applications, and if you violate it they can remove the app as well as your dev account if they so choose. They've removed a few apps and made a few accessible only in certain countries or on certain carriers.

Re:App Store? (1)

mjwx (966435) | about 5 years ago | (#29728901)

As far as I've been able to tell, the "featured apps" section at the top of the Marketplace seems to be pretty random but I've noticed that they have a high user rating (3.5+ stars) and a significant number of downloads so I'm guessing it just randomly picks app's that meet the minimum criteria.

Is Nokia maemo / N900 an android killer? (3, Interesting)

cenc (1310167) | about 5 years ago | (#29726787)

I have to hand it to Google for trying to break the proprietary locked cell phone one trick pony problem, but so far everything I have seen indicates that we just have another locked up OS. This is free software for the handset makers, not the end user.

What we want and need is a fully Linux, no bs platform, no hidden anything. So far, the nokia n900 looks like it will do that. Especially with the announcement of the qt libraries will be in the next versions of maemo.

I am sick of being treated like a criminal for jail-breaking / accessing my own hardware and software that I payed lots of money to own and use as I see fit. F*** Google and all their handset Android makers. I am voting with my dollars and my companies dollars, and going with a full linux distro I can customize as needed for my business.

Now I just hope Nokia does not get stupid and drop the ball. They seem to have a tendency to loose their momentum.

new to development (1)

drkwatr (609301) | about 5 years ago | (#29727113)

I always think it is appropriate to have a section on getting things setup. If you are going to write a book about development for a platform you better be ready to be thorough. If you start assuming things then your book will suck, and believe me I have had to go through a lot that have. The only exception I would make is if you have something like "advanced" in the title or something. I have been programming for over 20 years, and anytime I have to setup anything that isn't integrated I need some help to get things to see each other. Android is no different. Because of its open source nature and its ability to run on as many platforms as possible can present a slight challenge to get things working. You can't always rely on some quick tutorials since they often leave out the meat. I had to deal with some that would show you how to do something, but completely left out the part about adding anything to the manifest. It still beats iPhone development whereby XCode would eat perfectly good signature files. I have to admit I am a little biased on iPhone since I can't stand Objective-C and would rather on that platform go back to straight assembly. In closing it is always better for me and others to skip over something rather than having to find that material later on the author assumed we knew.

Definitely an easy platform to develop for. (1)

Spety (1269166) | about 5 years ago | (#29727331)

I have been working on a windows mobile app in my spare time for the last year or so in C# and it has been a serious pain. I have really enjoyed all of what the Android API has to offer. I found it ridiculous that I had to implement my own view stack in windows mobile or see all of my views as separate windows on the device, Android handles this very well on its own.

Moma's Android guide (0)

Anonymous Coward | about 5 years ago | (#29731787)

This super-guide will put you straight on the Android-track.
http://www.futuredesktop.org/developing_android_apps_on_ubuntu.html
Use Ubuntu 9.04. The latest Eclipse IDE does not run well on the Ubuntu 9.10 (Karmic) development version. Let's hope it will when Karmic is ready.

Kindly
  Moma from Grønland/Oslo

Moma's Android guide (0)

Anonymous Coward | about 5 years ago | (#29732327)

See
http://www.futuredesktop.org/developing_android_apps_on_ubuntu.html

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?