Not a Programmer? You Can Still Create Android Apps!

Google has introduced a new tool today called App Inventor. It uses the Open Blocks Java library to allow visual creation of applications, online.

This could be useful for regular developers to prototype quick apps. But, the real use is for non-developers or young folks. What would your kid create if they could create something with no coding required? Might it be silly? Might it be something other kids would have fun with? If you're not a developer, what would you create?

The tool, as it stands now, isn't fully open to the public. You have to fill out a form and then Google will eventually add access. The form is definitely aimed at educators. It's clear Google is looking at this as a teaching tool of sorts. We've always thought mobile programming would make a great target for teaching. This is evidence we aren't alone in that thought.

Sam's Teach Yourself Android Application Development in 24 Hours NOW AVAILABLE!

Our new book, Sam's Teach Yourself Android Application Development in 24 Hours, is now IN STOCK at Amazon! You might even have it already if you pre-ordered it. ;)


Remember, this is a full color book. Figures are color, code is syntax-highlighted. Color and a lower price? How do they do that? Anyway, it's more beginner oriented than our first book, Android Wireless Application Development, but it also covers some new topics. We're underway on an update to our first book, too.

Our New Android Book Printed!

We just got our first copy of Sam's Teach Yourself Android Application Development in 24 Hours in both print form and "folded and gathered" form. (That's for us to make corrections on, but it's kind of neat.) It's still pre-order on Amazon, but it should be available pretty soon! So, don't forget to pre-order and be amongst the first to get one. :)

It's a full-color book, too. The code samples are color coded which, to us, makes them far easier to read. Images are easier to view, too.

Don't Mess with Android!

Korean operator SK Telecom has created what we think are the best series of Android commercials to date. Enjoy!
















Rawr! Korean Android is Spunky!

Working with the Android Calendar

Last December, we wrote an article at developer.com about how to use the undocumented Android Calendar content provider. At the time, we'd written the code for Android SDK 1.6. Numerous updates later, this code still worked on Android 2.1. Now, however, Android SDK 2.2 finally broke it. Interestingly, the fixes were rather straight forward, though.

Instead of trying to update the article, write a new one, or try to post all the changes somewhere, we've decided to open source the code so others can see it and, if they'd like, contribute to it. The idea of the code is to demonstrate how to use the calendar content provider. Right now, it shows how to add, edit, and delete a basic entry as well as read the contents. If you'd like to see more, why not contribute to the code so others can see more to?

This uses an undocumented content provider. As it has changed, it may continue to change. The use of this code is at your own risk. Any damage it does is not our fault. You've been warned.

We also don't necessarily recommend this method of controlling a user's calendar. It interfaces with Google Calendars, which has an API of its own that is well documented and can perform everything needed. This avoids any complications with the Android client, will work even if the devices doesn't have a calendar (a non-Google Android device, for instance), and its documented. :)

In any case, we've tested the current code on our Nexus One with Android 2.2 and our Evo 4G with Android 2.1-update1. It works, but it may not work on your devices. Use with care.

Book Updates

Our upcoming book, Sam's Teach Yourself Android Application Development in 24 Hours, is finally done with the editing process. This means it's heading off to the printers and will be on shelves in due time. (This is not the quickest of processes; those darned real world items! Be patient, but don't forget to pre-order to be first on the block.)

Generally, the downloadable code is made available only to folks who have purchased the print copy. However, due to popular demand, our publisher has made available the downloads as part of the Rough Cuts program. If you have access to Rough Cuts via Safari, the downloads are now available! Enjoy.

Finally, have we mentioned that there's another book in the pipeline?

Android Fragmentation

Android is fragmented. There, we said it (okay, so we said it yet again)!

Seriously, it's the so-called elephant in the room. According to Wikipedia , there are 3 dozen Android smartphones, and a handful of tablets and e-readers currently on the market. The list of upcoming Android devices is just as lengthy. But are all the new handsets running the latest and greatest Android platform? Of course not! Some recently released phones are still running Android 1.6. Older models are still running Android 1.5. Even the Motorola Droid is still rolling out the Android 2.1 update-this week! And remember, Android 2.0 (API Level 5) barely exists in the real world, as it was quickly replaced by Android 2.0.1 (API Level 6). It's not easy to keep track of all the Android devices out there, with their varied SDK versions, screen sizes and hardware capabilities. And that, my friend, is exactly what we're talking about when we say fragmentation.

Just How Fragged are We?

The Android platform has reasonably addressed the task of targeting different screen sizes, resolutions and orientations-not to say it's trivial, but at least there are methods of going about doing so. It still adds work as more variations reach the market, but goes a long way towards reducing the burden compared to some other platforms. In addition, various hardware configurations are relatively straightforward to query for or, at least, put smart error handling in for. (Admittedly, some devices don't behave correctly when they're missing certain hardware, and even if considered a bug, in many cases the burden is on the developer to create work-arounds.)

The answer largely depends on what type of developer you are.

What's an Android Developer to Do?

If you're a hobby developer, you'll likely want to target the handset you own. After all, who wants to write an app that can't run on their own phone? Perhaps start with the Android phone you've got, and then move on to the biggest and most stable Android handsets available to your target users.

If you're a mass market developer, you'll likely need to target the lowest available version that allows your application to perform the features it requires. You'll need to target as many phones as possible.

If you're a game company or technology company designing awesome new features, you'll probably want to target the Android devices with the very latest version of the platform, and those with the best performance so all of your nifty features run smoothly.

Is Fragmentation Going to Get Better, or Worse?

Better, and worse-but there is hope on the horizon. Google has recently come forward saying they have a plan on addressing at least part of the fragmentation issue. To us, the fact that Google has stepped forward and admitted that fragmentation is a problem is a very good sign.

Technically speaking, Android is a community developed, open source project run by the Open Handset Alliance. Google is but one of about 70 member companies, and not even the biggest though they may be one of the most influential. But, the reality is the Android is Google's baby. They created it and they should really control it, open source or not-someone's got to. Sure, getting community involvement is great, but direction must be provided by someone; going democratic only works when everyone (developers, manufacturers, operators) is on the same page and they just aren't. Platforms like the Apple iPhone haven't had this problem because they are a tightly locked down platform with a reasonably small set of devices, limited operators, and more controlled versioning; the iPhone is also a more mature platform and not going through rapid and successive improvements in a short time frame-it pisses their loyal user base off royally if they release one device only to have a new and improved one available three months later. On the Android platform, we've got an explosion of devices with a very broad range of features, price ranges, and networks.

Android Team to Adjust SDK Releases Based on Fragmentation Concerns

Anyway, Google has said that they will slow down the rollout of new Android SDK versions. The Android tools were separated from the SDK in Android 1.6, so now tools can be updated separately from the SDK. Google will also separate out the Android apps that generally ship with the platform so they can be updated on demand without a new SDK rollout to the field. This is basically the desktop model. Apple doesn't need to ship a new Mac OS X to ship a new version of Safari, iTunes, or Xcode. Microsoft doesn't need to ship a new version of Windows to update Internet Explorer, Outlook, or Visual Studio. So, why should Google ship a new version of the Android SDK just to get a new version of the browser, map app, email client, or any of the other apps out?

By splitting the Android SDK into components, its users, developers, handset manufacturers, and carriers should be able to work more effectively. Users won't have to wait for their manufacturer and carrier to approve a full firmware release just to get a security bug fix in the browser. Developers will have fewer platform targets to worry about; instead, there may be more downloadable, add-on components to manage. Manufacturers won't have to try to keep up with the crazy speed with which the Android platform has been progressing. (During our current book project, we saw the number of platform levels go from 3 to 7. That's pretty crazy!) And, finally, carriers won't be burdened by so many full firmware updates that always leave them at risk of confused users or broken handsets. Remember, the operator is the first line of support. Large rollouts are costly for them. With the desktop model, people call their manufacturer or developer first, not their ISP or OS maker; the opposite is true for phone apps and carriers.

Where Do We Go From Here?

The exact nature of how this will play-out is unknown. Claims that everything will settle down and become totally managable are likely overly optimistic. Will the Android team truly be able to add new platform features through add-ons rather than full platform upgrades? Hopefully, but we'll see.